1. CSC 480 Software Engineering Lecture 2 August 23, 2004

2. CSC 480 Software Engieering2 8/26/2002 Topics Overview Process models Iterative models

3. CSC 480 Software Engieering3 8/26/2002 Process A software process is a set of activities that leads to the production of a software system.  It consists of partially ordered steps to achieve a goal In software engineering, your goal is to  Efficiently and predictably deliver a software product that meets the need of your business  What are the steps?  In what order? There is not one single answer to all cases

4. CSC 480 Software Engieering4 8/26/2002 Some Application Types Stand-alone  residing on a single computer  e.g., word processor Distributed  consist of parts interacting across a network  e.g., Web-based video game Embedded  part of unique application involving hardware  e.g., automobile controller Real-time  functions must execute within small time limit (typically micro- sec)  e.g., radar software

5. CSC 480 Software Engieering5 8/26/2002 Trends & Influences Structured programming Object-Orientation Reuse and components Formal methods

6. CSC 480 Software Engieering6 8/26/2002 Structured Programming  Use control constructs, avoid using goto  A hierarchy of functions, with those in higher levels calling those at lower levels  Modules tend to couple with each other, making change difficult

7. CSC 480 Software Engieering7 8/26/2002 Illustration – Structured Programming

8. CSC 480 Software Engieering8 8/26/2002 Object-Orientation  Encapsulate data and functionality in objects  Mapping to real-world entities Both congregation and inheritance hierarchies  Easier to modify and add components

9. CSC 480 Software Engieering9 8/26/2002 Illustration – Object Orientation

10. CSC 480 Software Engieering10 8/26/2002 Class & Object Hierarchies

11. CSC 480 Software Engieering11 8/26/2002 Reuse & Components  Reuse can reduce cost and improve quality  Reuse at component level is more effective COM JavaBeans  Example – a JClass chart by sitraka.com

12. CSC 480 Software Engieering12 8/26/2002 Formal Methods  SE methods that rely on mathematics as their base are called formal methods. The logical, not the computational aspects are used  Requirements and design can be express more precisely Domain element A Range element A(x) 14 26 33 44 56 68 t, t´ : N N dom(t´) = dom(t)  rng(t´) = rng(t)   x, y  dom(t), x  y  t´(x)  t´(y)   x  rng(t´), card[ t´ -1 (x) ] = card[ t -1 (x) ] Sort Partial function Range of t Number of elements in the set... Set of elements mapped onto x by t “implies”

13. CSC 480 Software Engieering13 8/26/2002 A Typical S.E. Roadmap 1. Understand nature & scope of proposed product 2. Select the development process, and create a plan 4. Design and build the product 6. Deliver and maintain the product 3. Gather requirements 5. Test the product Activities commonly found in all projects

14. CSC 480 Software Engieering14 8/26/2002 Five Key Expectations (Humphrey) Influenced by people Used for process development Part of the project Aspect of the product 3. Keep all work visible 5. Measure quality 4. A. Design only against requirements B. Program only against designs C. Test only against requirements and designs 1. Predetermine quantitative quality goals 2. Accumulate data for subsequent use

15. CSC 480 Software Engieering15 8/26/2002 Software Process Models A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective

16. CSC 480 Software Engieering16 8/26/2002 Process Models  The waterfall model Separate and distinct phases of specification and development  Evolutionary development Specification and development are interleaved  Formal systems development A mathematical system model is formally transformed to an implementation  Reuse-based development The system is assembled from existing components

17. CSC 480 Software Engieering17 8/26/2002 The Waterfall Model Requirements analysis Design Implementation Integration & Test Produces … specification... diagrams & text... code & comments... test report for entire code Operation & Maintenance... user manual & enhancements

18. CSC 480 Software Engieering18 8/26/2002 Waterfall Model Problems Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood The customer cannot see how the system works until the end of the project

19. CSC 480 Software Engieering19 8/26/2002 Process Iteration (iterative models) System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems Iteration can be applied to any of the generic process models

20. CSC 480 Software Engieering20 8/26/2002 Spiral Development Process is represented as a spiral rather than as a sequence of activities with backtracking Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required Risks are explicitly assessed and resolved throughout the process

21. CSC 480 Software Engieering21 8/26/2002 The Spiral Model

22. CSC 480 Software Engieering22 8/26/2002 Incremental Development Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality  User requirements are prioritised and the highest priority requirements are included in early increments  Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

23. CSC 480 Software Engieering23 8/26/2002 Incremental Development

24. CSC 480 Software Engieering24 8/26/2002 Iteration No. Analyze requirements Test whole Implement Design Test units Integrate 123867868 Update SRS 3 Update SDS 2 Update source code Update Test documentation Update SPMP 1 1 Software Project Management Plan; 2 Software Design Specification; 3 Software Requirements Specification

25. CSC 480 Software Engieering25 8/26/2002 Incremental Development Advantages  Customer value can be delivered with each increment so system functionality is available earlier  Early increments act as a prototype to help elicit requirements for later increments  Lower risk of overall project failure  The highest priority system services tend to receive the most testing

26. CSC 480 Software Engieering26 8/26/2002 USDP : Classification of Iterations Inception iterations: preliminary interaction with stakeholders  primarily customer  users  financial backers etc. Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline Construction iterations : results in initial operational capability Transition iterations : completes product release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. CSC 480 Software Engieering27 8/26/2002 ElaborationInceptionConstructionTransition Requirements Analysis Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. ….. Prelim. iterations USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh) Design Implemen- tation Test USDP calls these “core workflows” (Classically called “phases”) Classification of iterations Individual iteration

28. CSC 480 Software Engieering28 8/26/2002 Requirements Analysis USDP vs. Standard Terminology 2 of 2 Design Implementation Test Requirements analysis Implementation USDP Terminology Classical Terminology Integration Design Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. CSC 480 Software Engieering29 8/26/2002 Elaboration Unified Process Matrix InceptionConstructionTransition Requirements Analysis Jacobson et al: USDP Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k ….. Design Implemen- tation Test.. Amount of effort expended on the requirements phase during the first Construction iteration

30. CSC 480 Software Engieering30 8/26/2002 The Six USDP Models (Views of the Application) Use-case model Analysis model Design model Deployment model Implementation model Test model Graphics reproduced with permission from Corel.

31. CSC 480 Software Engieering31 8/26/2002 Identify the Process You Will Use 1. Decide which of waterfall, spiral, and incremental processes is appropriate. Usually a spiral for a semester project. Combining parts is OK e.g. start with spiral, end with incremental 2. Decide how many iterations. Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration). Three provides lots of practice -- but this is a challenge; make the first increment as minor as possible Three promotes the collection and use of metric data -- use metric data collected from each iteration on next. 3. Rough out a weekly schedule. Coordinate with course assignments. (The next chapter discusses scheduling.) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

32. CSC 480 Software Engieering32 8/26/2002 Extreme Programming New approach to development based on the development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pairwise programming Visit www.extremeprogramming.org for detailswww.extremeprogramming.org

33. CSC 480 Software Engieering33 8/26/2002 Process Trade-offs FactorPure Waterfall Iterative Spiral Iterative Incremental Ease of doc control EasierHarderHarder/ Medium Enabling of customer interaction HarderEasier Promotion of good design Medium/ Easier Harder Leverage of metric data HarderMedium/ Easier Medium/ Easier

34. CSC 480 Software Engieering34 8/26/2002 Additional Info

35. CSC 480 Software Engieering35 8/26/2002 More Detailed Waterfall Version Design Implementation & unit testing Integration System testing Concept analysis Analysis Maintenance

36. CSC 480 Software Engieering36 8/26/2002 Evolutionary Development Exploratory development  Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements Throw-away prototyping  Objective is to understand the system requirements. Should start with poorly understood requirements

37. CSC 480 Software Engieering37 8/26/2002 Evolutionary Development

38. CSC 480 Software Engieering38 8/26/2002 Evolutionary Development Problems  Lack of process visibility  Systems are often poorly structured  Special skills (e.g. in languages for rapid prototyping) may be required Applicability  For small-/medium-size interactive systems  For parts of large systems (e.g. the UI)  For short-lifetime systems

39. CSC 480 Software Engieering39 8/26/2002 Formal Systems Development Based on the transformation of a mathematical specification through different representations to an program Transformations are ‘correctness-preserving’ so it is straightforward to show that a program conforms to its specification Embodied in the ‘Cleanroom’ approach to software development

40. CSC 480 Software Engieering40 8/26/2002 Formal Systems Development

41. CSC 480 Software Engieering41 8/26/2002 Formal Transformations

42. CSC 480 Software Engieering42 8/26/2002 Formal Systems Development Problems  Need for specialised skills and training to apply the technique  Difficult to formally specify some aspects of the system such as the user interface Applicability  Critical systems especially those where a safety or security case must be made before the system is put into operation

43. CSC 480 Software Engieering43 8/26/2002 Reuse-Oriented Development Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems This approach is becoming more important but still limited experience with it

44. CSC 480 Software Engieering44 8/26/2002 Reuse-Oriented Development Process stages  Component analysis  Requirements modification  System design with reuse  Development and integration

45. CSC 480 Software Engieering45 8/26/2002 The Spiral Model

46. CSC 480 Software Engieering46 8/26/2002 Spiral Model Sectors Objective setting  Specific objectives for the phase are identified Risk assessment and reduction  Risks are assessed and activities put in place to reduce the key risks Development and validation  A development model is chosen Planning  The project is reviewed and the next phase of the spiral is planned