1. The Software Development Process Chapter 2 Best Practices

2. 2 Software Development Activities DEFINE the Requirements ANALYSE Requirements DESIGN the Solution DEVELOP the Software TESTING the Software DEPLOY the Software MAINTAIN & MANAGE the Software

3. 3 Traditional Software Development Life Cycle

4. 4 The Waterfall model

5. 5 Disadvantages of Linear developments Rigidity Sometimes impractical

6. 6 Incremental Development Incorporates customer interaction Repetitive process that progresses in incremental stages Maintains focus on manageable tasks Earlier stages successful before later stages attempted Spiral model Prototype – working model of the intended system (or part of it) – useful to explore an idea Possible for prototype to develop into the actual solution over time

7. 7 Roles of Prototypes Evolutionary –software adapted gradually as requirements becomes clearer –prototype gradually evolves into end product Experimental –Used for evaluating a possible solution e.g. assessing performance, effectiveness –prototype discarded after evaluation Exploratory –Used to help clarify user requirements –Prototype discarded

8. 8 Incremental Development Process using a prototype

9. 9 Software Development Methods Further divides each stage of the SDLC into a set of steps and rules –Indication detail, nature and order of tasks –Documents needed as input / produced at each stage RAD – Rapid Application Development aim: –To shorten development life cycle –Produce systems quicker to respond to rapidly changing business requirements Relies on user involvement & extensively use prototypes to capture requirements

10. 10 Agile Methods Philosophy: –Individuals and interactions over processes and tools –Working software over comprehensive documentation –Customer collaboration over contract negotiation –Responding to change over following a plan Example RAD

11. 11 Extreme Programming (XP) agile SW development method Customer team member User stories Short cycles Pair Programming Test-driven development Collective ownership Continuous integration Sustainable pace Open workspace The planning game Simple design Refactoring Metaphor

12. 12 Choosing a Development Approach Avoid a linear (or sequential) approach unless: –requirements are well determined –design is straightforward and well understood –development team familiar with area –project poses little risk –Project has long-term predictability –A ‘longer’ delivery time is acceptable –Cost of changing requirements, design and code is high

13. 13 Choosing a Development Approach Incremental (or iterative) development: –Requirements not well understood / unstable –A need exists to demonstrate feasibility of an idea –Design is complex and/or challenging –Development team unfamiliar with area –Lot of risk –Long-term predictability NOT important –Cost of changing requirements, design & code is low –System evolves in response to developers perception

14. 14 Formal methods - Serious Disadvantages - Represents the designer’s understanding of requirements Encourage specialization, which lead to poor communication, wasted effort, isolated progress Lacks the ability to illustrate a system’s dynamic & adaptable nature

15. 15 Requirements Engineering Requirements elicitation –Developer determines client’s needs Requirements specification –Developer records requirements Requirements validation –Developer checks that requirements are correctly described and understood

16. 16 “Don’t gather requirements – dig for them!” Hunt & Thomas, 2000

17. 17 Examples of Requirements An employee record may be viewed only by a certain group of people. A computer-generated identifier must be used to identify each employee. The cylinder-head temperature must not exceed the critical value, which varies by engine The editor will highlight keywords, which will be selected according to the type of the file being edited.

18. 18 Examples of Requirements Instead of: Only personnel can view an employee record –“requirement” contains an embedded policy –Policies change regularly & should not be hardwired into requirements –Separate the policy from the requirement Rather change to: “Only authorized users may access an employee record” –Implement access control system where authorized users or groups can be selected and / or changed

19. 19 Examples of Requirements We need a list box to select the loan term –Is it absolutely necessary to use a list box, or –Is a list box used as an example –Discover why they do it rather than it just being the way that they do it

20. 20 Helpful practices for requirement elicitation Become a user –Observe –Build trust –Encourage communication Document the requirements –Capture all requirements –Construct use cases and use case diagrams

21. 21

22. 22

23. 23 Helpful practices for requirement elicitation Don’t overspecify Maintain a glossary Look to the future Manage “feature creep” Validate the requirements

24. 24 Helpful practices for requirements change control Formal change control board Formal change control requests Automated change control tools JAD (Joint Application Design) sessions Requirements inspection for major changes Application feature planning

25. 25 Change control considerations Evaluate change requirement carefully –Is it merely a nice feature –Does it offer business value Ensure everyone knows the cost of changing requirements High volume of change request indicates inadequate designs Some approaches accommodate changing requirements –Evolutionary-type approaches, e.g. prototypes

26. 26

27. 27 Using CASE Tools Choose carefully Consider the expense Consider the learning curve

28. 28 Changeover to the New System Direct changeover –Minimized duplication or work –Thorough planning is required –There are no comparable results Parallel Running –Risk is reduced –Results can be compared –Workload is increased

29. 29 Changeover to the New System Pilot Running Phased Implementation –The System can be released sooner –Client feedback can be obtained –Reduces pressure on the developer –Eases the burden of training-

30. 30 Review and Maintenance How satisfied are the clients, with the hardware and software supplied? Were the clients happy with their degree of involvement in the development of the system? How are staff of the client organization reacting to the new system? To what extent does the system fulfill the original client requirements? Etc. …

31. 31 Maintenance and Support Guidelines Implement change control procedures Test and document all changes Provide telephone or on-line maintenance support Provide on-site maintenance support

32. 32 Team-Oriented Principles and Practices Quality is a team issue A team should communicate effectively and as one personality A team should have an identity Don’t duplicate work. Monitor the environment for changes Organize teams around functionality not job functions

33. 33 Further Principles and Practices Define the problem Use the appropriate development process User appropriate methods Provide project leadership Manage the project well Etc. …