1. Software Design and Development Development Methodoligies Computing Science

2. Learning Objectives By the end of this topic you will be able to: understand the iterative nature of the software development process; understand the iterative nature of the software development process; describe the seven stages in the traditional software development process, analysis, design, implementation, testing, documentation, evaluation, and maintenance; describe the seven stages in the traditional software development process, analysis, design, implementation, testing, documentation, evaluation, and maintenance; describe the Top-Down Design / Stepwise Refinement process; describe the Top-Down Design / Stepwise Refinement process;

3. Learning Objectives By the end of this topic you will be able to: understand when Rapid Application Development would be an appropriate development methodology; understand when Rapid Application Development would be an appropriate development methodology; understand when Agile Development is an appropriate development methodology understand when Agile Development is an appropriate development methodology

4. Iterative nature of software development Software Development is a process where there is constant revision and evaluation of what is being produced. This will often require returning to earlier stages of development to change them – an iterative process

5. Traditional Waterfall Model Analysis Design Implementation Testing Documentation Evaluation Maintenance

6. Analysis Carried out by Systems Analyst Extract the client’s needs: – Interviewing – Observing, Clarifying, Modeling – Inspection of information sources Document the client’s needs Communicate these to the designers

7. Analysis The Software Specification is a legal document which accurately describes exactly what the software will be able to do, and will often also describe how long it will take to build and how much it will cost. The Software Specification is a legally binding document which can be used by either party to resolve possible disputes in the future.

8. Design The design stage is where the software specification is turned into a design that can be used by the programmers Problem broken down into smaller sub-problems Process called Top Down Design with Stepwise Refinement

9. Design Notations Techniques to show design of program include Structure Diagram Data Dictionary Data Flow Diagram Pseudocode

10. Structure Diagram

11. Data Flow Diagram

12. Data Dictionary A data dictionary details all the data structures which the software will use and how they are related.

13. Pseudocode 1.Display information 2.Get details 3.Do calculation 4.Display answer 2.1 2.2RECEIVE value FROM KEYBOARD 2.3DO WHILE 2.4 2.5RECEIVE value FROM KEYBOARD 2.6END WHILE Top level design

14. Implementation Implementation stage involves using the detailed design to create the code Choice of high level language will depend on Type of problem OS being used Hardware program will run on Programmers expertise

15. Implementation Good practice in implementation includes Meaningful variable and procedure names Internal Commentary Indented code and white space Modular code Use of local variables

16. Testing Testing should check that the program Meets the specification Is robust Is reliable Testing can only demonstrate the presence of errors, it cannot demonstrate their absence.

17. Testing Types of error – Design Errors – requires return to Design stage – Coding Errors Syntax errors Semantic errors Run-time errors

18. Testing Testing should be systematic and include Normal Operation Extreme (Boundary) Testing Exception Testing Alpha testing Beta Testing

19. Testing Testing should be systematic and include Alpha testing – this is done by the developers Beta Testing – testing by target users

20. Documentation Software specification Test data and results User Guide Technical Guide

21. Evaluation The finished program must be: Correct (Fit for Purpose) Readable Maintainable Robust Reliable Efficient Suitable user interface

22. Maintenance Corrective (Fixing errors) Adaptive (Adapting to new OS or hardware) Perfective (Changes by user request)

23. Factors affecting Maintenance The application being supported Staff mobility Too many versions Not enough documentation Dependence on external environment Hardware and software stability

24. Weaknesses in Waterfall Model Real projects are not linear It is difficult to correctly state all the requirements at the beginning of a project Developers work in isolation from the clients

25. Alternative models Rapid Application Development (RAD) Agile Software Development

26. Rapid Application Development Based on prototyping and iterative development No specific planning stages Involves developers and clients at every stage Easier to incorporate changes

27. Rapid Application Development The Requirements Planning phase Similar to analysis stage in traditional methods Do not necessarily produce legally binding software specification

28. Rapid Application Development The User design phase Developers work with clients to create prototypes Continually modify prototypes until working version produced

29. Rapid Application Development The Construction phase Similar to implementation and testing stage but users still involved and can introduce changes

30. Rapid Application Development Cutover phase Software installed and tested User training and maintenance starts

31. Rapid Application Development Should only be used when a system can be modularized There is high availability of designers for modeling budget permits use of automated code generating tools. domain experts are available with relevant business knowledge

32. Agile Software Development Development of RAD ideas Emphasis on small-scale developments Uses teams of developers with flexible approach to change Prototypes tried out and tested throughout process

33. Agile Software Development Benefits Reduced development time Increased responsiveness to changing circumstances More reduced costs due to the efficiency of using small groups of developers