Software Methodologies

How to pick it

How to document it

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.

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

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

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.

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.

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.

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.

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.

What diagrams should I draw?

• Deliverables from each stage should be of value in the development.

• Don’t 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.

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.

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)

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.

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.

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.

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.

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.

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 don’t change state much.

• Effect Correspondence Diagram– Only useful where a process handles several

entity occurrences of multiple type.

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.

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.

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.

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.

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

student’s design.– Reference the source of the component.

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.

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!

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.

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.

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.