Project Build

Development methodologies

August 13

Project development methodologies

Outline

Why follow a structured methodology for building an application? What methodologies are suitable for student projects?

August 13

Software development

Source texts

Projects in Computing and Information Systems, C.W. Dawson, Addison Wesley, 2005. Extreme Programming Pocket Guide, chromatic, O'Reilly Media, Inc., 2003. The Unified Software Development Process, Jacobson et al, Addison-Wesley Professional, 1999. Managing Multimedia: Project Management for Web and Convergent Media : Book 1 England & Finney, Addison Wesley, 2001

August 13

Software development

Structuring Software Development

Divides a large problem into easy to control smaller tasks, at each stage Sharpens focus Supports planning and control Provides progress visibility Provides structure Leads to better coding and documentation
Software development 4

August 13

Development Life Cycle

Requirements capture Design Build Test Evaluate

In practice there is overlap and iteration between these stages

August 13 Software development 5

methodologies

Classical waterfall Incremental model Prototyping

Throw-away prototyping Evolutionary prototyping

Extreme programming (Test driven) Rational Unified Process (OO design)

August 13

Software development

Classical waterfall

Sequential processes You must be confident that you fully understand the problem and the requirements short projects (6 months) where the problem does not have time to evolve Each stage signed off before going to next stage. Good for tight deadlines
Software development 7

August 13

Incremental model

problem and requirements are well understood The required system is split up into 2/3 sub-systems to make it more manageable. What are sub-systems for yours? Each sub-system is designed and tested with its own SDLC.
Software development 8

August 13

Prototyping (Rapid Applications Development)

problem is not well understood then building and evaluating a prototype can help define the problem. Either to

Explore the requirements of the system Explore the technical feasibility of the system

Throw away prototyping vs evolutionary prototyping

Software development 9

August 13

Throw-away prototyping
create a prototype that can be critiqued, trashed and thrown away develop on a simpler/quicker system than the final product Mock up on paper / using Word / Photoshop Fireworks for a web page Use an emulator in place of a mobile device Write a prototype in a different language VBA + Excel for data analysis animatics Simplify something A GUI with little functionality underneath A simpler database just for testing Limited data handling and error checking
August 13 Software development 10

Evolutionary prototyping

The prototype is not discarded but evolves into the final product Should use a planned series of releases Components designed and implemented in Release 1 may change a little in Release 2 but should have settled down (converged) by Release 3. Feeds back into requirements capture
Software development 11

August 13

eXtreme Programming
code oriented not design oriented,

Focus on coding/design simplicity Simpler design is easier to explain Simpler code is easier to change Maintain by testing, cleaning, simplifying e.g. add a feature but remove more code than you add Re-factor mercilessly Goal to find the optimal design with the minimal simplest code and same external testably correct behaviour.
Software development 12

August 13

Test driven development

Write the code to set up the test before you have written the code to pass it! Then code to pass. Code is finished when the test is passed. Untested code does not exist! Run tests after every change the less time before introducing a defect and discovering it - the easier to fix
Software development 13

August 13

Unified Software Development Process

Uses full-strength UML Assumes a object model with classes, inheritance and message passing i.e. needs object oriented languages Java, C++, C#, Actionscript 3 Requirements translated into a set of Use Cases Each Use Case prompts new class designs, or extensions of existing classes.
Software development 14

August 13

Uses an iterative prototyping approach, with each iteration a new release. Class designs revised until optimal Including relational databases needs care and interface classes may be needed; ERDs are normalised but Class Diagrams are not.

August 13

Software development

15

Conclusion

Adopt a suitable development methodology NOW for your project Revise your objectives to fit in with this methodology Use the methodology in the final report on the design and implementation chapters.

August 13

Software development

16