Document1
What IT things can be developed and do they need
special tools?
Hardware?
Microelectronics
CAD (Computer Aided Design) applications
specialising in VLSI (Very Large Scale Integration)
Electronics
CAD applications specialising in PCB (Printed Circuit
Board) layout
Networks
Diagramming applications, eg MS Visio
Software?
Embedded systems, operating systems and applications
IDE (Integrated Development Environment) which
incorporates, eg MS Visual Studio
Text editor for entering source code
Compiler for translating source to machine code (in one go),
eg for C++
Debugger for finding code errors
Scripts and macros
Interpreter for translating source to machine code (on
the fly), eg for VBS (Visual Basic Script)
A “tool” could be a piece of hardware, software, or a
technique used by developers
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
1
Document1
Are there tools common to all developments?
Documentation
Contracts
Functional (requirements) specifications
Test specifications
Usage guides
Version control
Complex systems, are made from more than one
source, and each source keeps changing, eg CVS
Change management
Making the implementation of the new system a smooth
as possible for the target users, eg user training
Project management
Coordinating the elements for the quickest, least cost
development, eg MS Project
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
2
Document1
With all these established tools, what could
possibly go wrong?
31% of IT projects get cancelled before completion, and
52.7% will cost 189% of budget! (Standish Group, 1994)
Why? Biggest contributors were:
13% lack user input
12% have incomplete requirements and specifications
12% change the requirements and specifications
The earlier an error is introduced into a project, the
more it costs to fix
Requirements errors cost 100 times more than
maintenance errors
Since they are most common and most expensive
errors, there is a dire need to manage requirements:
Elicit, get requirements from users and stakeholders
Organise, there can be a large number of requirements
Document, too many requirements to keep in each
stakeholder’s head
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
3
Document1
So what’s the best way to develop something?
No simple answer, mainly depends on
Scale, the number of developers
If it is small enough to all fit in one person’s head,
just go for it
Otherwise, need a development method
Criticality, how precise the product needs to be
An electronic game would be non-critical
A heart pacemaker would be critical
Recent years have seen the “method wars”
The large risks and way people like to work can cause
some to be emotionally involved in the decision to follow
one method rather than another
No one method fits all projects
Methods tend to focus on software but could apply to
any type of development
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
4
Document1
Why would you use the Waterfall method?
Started out as code-fix cycle
Then extended to more steps
Finally added feedback loops between every step
Requirements
Design
Coding and
unit test
System
integration
Operation and
maintenance
Good points
Forces the requirements to be completed before more
work is done
Medium to large scale projects
Bad points
Fixed and rigid, change is difficult
Can lose touch with changes in market or users
If the scope (collection of functions) is too large, by the
deadline nothing works
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
5
Document1
Why would you use the Spiral method?
Introduced the idea of creating throw-away prototypes
Each evaluated by stakeholders to minimise risks
Development cycles through the steps
Rapidly for prototypes
Prototype N
Evaluate
System
integration
Prototype 1
Operation and
maintenance
Coding and
unit test
Requirements
Design
Good points
Recognises that requirements change during
development
Allow multiple feedback opportunities
Medium scale projects
Bad points
There may not be enough time to develop multiple
throw-aways
Tempting to hang onto poor prototype code
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
6
Document1
Why would you use the Agile method?
No throw-away prototypes, only quality code
Many releases, reworked after each stakeholder
evaluation, means less documentation
Can have multiple releases during each project “phase”
Tries to unlock the component development steps from
the growing knowledge of user requirements
Phases
Releases
Good points
Recognises that requirements change during
development
Each release can be evaluated as a realistic product, no
corners cut
Small to medium scale projects
Bad points
More effort to produce each release than a prototype
Less reliance on documentation can mean more
information falling through the cracks, a problem for
critical projects
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
7
Document1
Why would you use the Extreme method?
Frequent releases
User representative(s) onsite giving continuous feedback
Designers work in pairs (share a console)
To improve code quality
Test their own work
Minimises documentation
No attempt to document future requirements
Design is reworked for every requirement the user
currently needs
Maybe communicated verbally
Good points
Fast development
High productivity
Recognises that requirements change during
development
Very small scale projects, less than 10 developers
Bad points
Keeping development team and user representative(s)
at one site
Less reliance on documentation can mean more
information falling through the cracks, a problem for
critical projects
The latest user requirement might mean a complete
change of architecture
“This is working great. Now we want it to work over
the Internet.”
Based on “Managing Software Requirements”, 2nd Ed. By Leffingwell & Widrig ISBN 032112247X
8