Software Methodologies

1
Software Methodologies

• How to pick it
• How to document it

2
What is a methodology?

• A framework of activities, grouped into steps or
  stages.
• Each step/stage has
• Prerequisites
• techniques
• deliverables
• Documentation must follow an industry standard.

3
Process Models and methodologies

• Waterfall Model
• SSADM, Gane Sarson.
• Prototyping (RAD)
• DSDM (not sufficiently rigorous for academic
  software development)
• Spiral Model / Incremental model
• RUP
• Select Perspective

4
Which to choose?

• Spiral
• Software development with obvious core
  functionality
• Possibly tiered application
• Possibility of developing software in increments
• Often the analysis will cover a larger scope than
  the final developed solution

5
Why SSADM?

• Usual reason is because the developer is more
  familiar with it
• This is not a good reason!
• Only strictly suited to applications where
• there is a single tier
• there is no web access
• could be suited in this situation.

6
Why Object Oriented?

• Rational Unified Process
• Whole thing is designed for corporate use
• Subset may be used.
• Select Component Factory
• Available on college network
• Can be difficult to use
• If doing a group project, several users can use
  the same model.

7
What documentation?

• For each stage state
• An intent
• A procedure
• Expected deliverables
• These can include diagrammatic and
  non-diagrammatic deliverables
• e.g. code, diagram, description.

8
Code-intensive systems

• Some systems may be code-intensive, with little
  in the line of user interface or persistent data.
• If you are using objects, design and document the
  classes, using class, state and activity
  diagrams.
• If you are using procedural code, use top-down
  structured programming, with modularity.

9
Documenting your methodology

• State the general methodology on which you are
  basing your methodology.
• Describe the steps and stages.
• You should either have
• Feasibility, analysis, design, coding,
  implementation, testing
• Or
• Inception, Elaboration, Construction, Transition
• I.e. NO stage should be omitted.

10
What diagrams should I draw?

• Deliverables from each stage should be of value
  in the development.
• Dont develop diagrams that lead nowhere.
• Diagrams are useful to illustrate or strengthen
  the case for an aspect of design.
• The diagrams you choose depend on the system you
  are building.

11
Possible diagrams OO

• Use Case Diagram
• Very few systems can do without at least one of
  these (see code-intensive systems)
• Class diagram
• No OO system can do without these.
• Depending on the number of tiers and classes,
  classes may need to be packaged for readable
  documentation.
• Class diagrams can develop over the lifecycle.

12
Activity diagrams

• Useful for showing workflow over several
  use-cases
• Useful for showing activity in complex operations
  (similar to a flowchart).
• Only use
• for the main workflow of the system or
• to illustrate complex workings in an operation
  (code-intensive system)

13
State diagram

• Shows how class instances change state over their
  lifetime.
• Only use for persistent classes or classes whose
  state changes frequently and is of importance to
  the system.

14
Interaction Diagram (OID/OCD)

• Object Interaction Diagram
• Shows sequentially the interactions between
  different objects when realising a use case.
• Object Collaboration Diagram
• Shows pictorially interactions between the
  different objects to realise a use case.
• Only use for complex use-cases.

15
Deployment Diagram

• These show how the system is physically deployed
  over different machines.
• Very useful in tiered systems where tiers are
  housed on different machines.
• Totally unnecessary on single-user machines.

16
SSADM function diagrams

• DFD
• in a DP system, these are necessary.
• Necessary where user interaction is a theme.
• Not necessary in code-intensive systems where
  there is not much data flow.
• HIPO charts / Flowcharts
• Necessary where coding is complex and data flow
  is low. Respect modularity rules.

17
LDS or ERD

• AN ERD IS NECESSARY IN ANY SYSTEM THAT USES A
  RELATIONAL DATABASE.
• It cannot be replaced by a class diagram.
• Ensure that you include attributes, keys and
  relationships in your diagram.
• Depending on your development structure, you may
  have a logical data structure and a physical data
  model.
• Data dictionary should be explicit.

18
ELH, ECD

• Entity Life History
• Necessary for entities which change state a lot
  during the system and which are central to the
  system.
• Not necessary for superficial or supporting
  entities that dont change state much.
• Effect Correspondence Diagram
• Only useful where a process handles several
  entity occurrences of multiple type.

19
Enquiry Access Path

• Enquiry access path
• Used to realise enquiries that require joins
  across relational entities.
• Useful to illustrate the need for relationships
  that are only necessary to facilitate queries -
  I.e. that are not necessary for updates.
• Not necessary as a standard feature.

20
Non-diagram issues

• Environment configuration.
• This should be introduced after requirements
  specification or inception.
• Hardware, networking and software options should
  be stated, giving pros and cons of each.
• Choice of each should be justified in terms of
  the project - not because
• I used it before
• It was on the network
• My friend got a free copy.

21
Functional Requirements

• Functional Requirements should be traceable.
• Through diagrams.
• Through specifications.
• Through other documentation
• Through code.
• Any change in functional requirement should be
  traceable back to the user who signed it off.

22
Testing

• At every stage of specification
• Testing criteria for functional requirements
• Testing criteria for non-functional requirements
• should be specified.
• Testing should be done against these criteria at
  all levels.

23
Imported code

• Component-based development requires that
  components be used that may not be original.
• The student is expected to
• Understand the component functionality
• be able to fix any bugs that result from the
  inclusion of the imported component
• state that the component is not an original part
  of the work carried out.
• Document the position of the component in the
  students design.
• Reference the source of the component.

24
Implementation / Transition

• Configuration of deployed system should be
  documented.
• Manuals and on-line help should be made available
  where applicable.
• HCI should be task-driven, not data-driven.
• e.g. I should not need to remember my account
  number to be able to do an order, even though the
  system identifies me by my account number.

25
Summary

• Decide on a methodology
• Document the methodology up front, giving steps
  and stages, stating the industry-standard
  methodology on which it is based.
• Each stage should have pre-requisites and
  deliverables.
• As your system develops, the deliverables that
  you listed up-front should be provided!

26
References

• For general paradigm information
• "Software Engineering A Practitioner's Approach",
  Roger S. Pressman, Darrel Ince, 5th Ed., McGraw
  Hill, 2000.
• Earlier editions have most of the relevant
  material also.
• Traditional structured system development
• "Software System Development a gentle
  introduction" Britton, Doake, McGraw Hill, 1996.

27
UML

• "Using UML Software Engineering with Objects and
  Components" Stevens, Pooley, Addison Wesley
  Object Technology series, Update Edition 2000.
• "UML distilled Applying the standard object
  modeling language" Fowler, Scott, Addison Wesley
  Object Technology series, Update Edition 2000.
• "Object-Oriented Systems Development a gentle
  introduction"  Britton, Doake, McGraw Hill, 2000.
• "Developing Applications with Visual Basic and
  UML" Reed, Addison Wesley Object Technology
  series, 1999.

28
Methodologies

• "Structured Systems Analysis and Design Method -
  Application and Context", Downs, Clare Coe, 2nd
  Ed. Prentice Hall, 1992.
• "The Rational Unified Process, an introduction",
  Philippe Kruchten, 2nd Ed.  Addison Wesley Object
  Technology series, 2000.
• The Select Perspective", Stuart Frost, Select
  Software Tools, 1995.
• "Object-Oriented and Classical Software
  Engineering", 5th Ed.  Stephen R. Schach, McGraw
  Hill, 2002.
• A good solid, all-round treatment of Software
  Engineering.  There is a good comparison of
  process models on page 310.