1. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 1 Software Engineering 1A/1B/1C1M Week 1 Lecture 2 Software Process Models

2. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 2 The Meaning of Process When we build products or solve problems we tend to use a sequence of steps or activities. Often use same steps to solve similar problems. A process is a series of steps involving activities, constrains and resources that produce an intended output. A process has characteristics: –prescribes all the major activities –uses resources, subject to constraints, and produces intermediate and final products. –may be composed of subprocess that are linked in some way. May be defined as a hierarchy of processes, each with its own process model. –each activity has entry and exit criteria –activities organised in a sequence –have guiding principles that explain the goal of each activity. –constraints or controls may apply to activities, resources and products.

3. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 3 The Meaning of Process /2 When process is for building a product, often called a life-cycle. When building a software product, called a software life-cycle. Processes impose consistency and structure to a set of activities, and helps maintain consistent level of quality in outputs. A process is not simply a procedure or recipe for producing a product. A process usually provides alternative procedures for performing a task. A process structure allows us to examine, understand, control and improve the activities that comprise the process. Processes allow capture of past experience. Processes allow us to organise our knowledge about software development

4. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 4 Software Process Models Why should software developers use process models? –writing down a description of the development process provides a common understanding within the organisation of the activities, resources and constraints involved in software development. –Enables a development team to identify inconsistencies and omissions in how they are developing software. The starting point for process improvement. –A process model makes explicit the goals of development (such as building high quality software) and activities used can be evaluated for appropriateness against the goals. –Usual to tailor the development process for different projects. A process model helps in understanding where this tailoring can occur. Many process models have been developed. We will look at a few of the more popular software process models.

5. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 5 Waterfall Model One of the first process models REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

6. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 6 Waterfall Model /2 Strict waterfall model requires each stage to be completed before the next begins. Was required for US DoD standard 2167-A Milestones and deliverables associated with each process activity. Advantages –Simple to implement and manage. –Well used. Disadvantages –Real projects are not sequential –Can not state requirements completely early –Customer does not see system until after testing –Development often results in parts of project being ‘blocked’. –Emphasis is on ease of project management. –Method does not scale up to large projects well.

7. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 7 Waterfall Model /3 Modified waterfall models do exit. One way to improve the model is to use prototyping to explore aspects of the problem before starting the model. REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODINGUNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE PROTOTYPING Verify Validat e

8. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 8 Waterfall Model /4 Prototyping is also useful for validation: ensuring system has implemented all of the requirements, (or ensuring the developer is building the right product - according to specification), and verification: ensuring that each function works correctly (or checking the quality of the system) both verification and validation can occur during other parts of the process. Related to this is the German V model which explicity links: –unit testing and integration with verification of program design, –system testing with system design –acceptance testing with requirements analysis. See next slide

9. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 9 Waterfall Model /5 The V model REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE Verify design Validate requirements

10. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 10 Prototyping Model Prototyping can be used as the basis for a process model without the need to link it explicitly to the waterfall model. LIST OF REVISIONS LIST OF REVISIONS LIST OF REVISIONS PROTOTYPE REQUIREMENTS PROTOTYP E DESIGN PROTOTYP E SYSTEM TES T DELIVERED SYSTEM REQUIREMENTS (sometimes informal or incomplete) revise prototyp e user/ custome r review

11. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 11 Phased Development One problem of the waterfall model is that the software falls out at the end of the process (or sometimes, falls over at the end of the process) Phased development methods have working subsets of the proposed systems early in the development process. Each phase add additional functionality to the system. Allows early review and feedback of the system. Can do this by: –incremental development: partition system and design and implement parts one at a time. –iterative development: begin with limited functionality (but all major system componets present) and add or improve functionality with each iteration

12. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 12 Phased Development /2 Most projects using phased development will combine iterative and incremental development - each phase will likely include new and enhanced functionality. Advantages: –Useful system early in process, giving good feedback from customer. –Frequent releases allow early fixes for problems in previous releases. –Development team can usually focus on less than the whole system during a development phase - reduces complexity. –Final system will have had more testing than a system without early releases.

13. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 13 Spiral Model Developed by Boehm in ‘88. Combines development activities with risk management. Is iterative but with each ‘stage’ of developoment being an iteration of a cylce of planning, determining goals and alternatives, evaluation and risk analysis, and development and testing.

14. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 14 Additional Material #1 These are some additional notes base on material in last years text book. –Generic view of software engineering –The software Process –RAD Model –Concurrent Development model –Formal Methods Models

15. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 15 1.1.2 Generic View of Software Engineering Engineering is the analysis, design, construction, verification, and management of technical (and social) entities. An Engineering approach considers the following: What is the problem to be solved? What are the characteristics of the entity that are used to solve the problem? How will the entity (and solution) be realised? What approach will be used to uncover errors in the design and construction of the entity? How will the entity be maintained - corrections, adaptations and enhancements requested by users of the entity?

16. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 16 1.1.2 Generic View (Continued) Three generic ‘phases’ Definition phase - focus on ‘what’. –Systems engineering –Project planning –Requirements analysis Development phase - focus on ‘how’ –Software Design –Code generation –Testing Maintenance Phase - focus on change –Correction, Adaptation, Enhancement and Prevention

17. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 17 1.1.2 Generic View (continued) In addition, there are ‘umbrella activities’ which occur throughout the process. These include: Project tracking and control. Formal technical reviews Software quality assurance Software Configuration management. Document preparation and production Reusability management. Measurement. Risk management.

18. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 18 1.2 The Software Process Can characterise a software process using a Common Process Framework model: Common Process Framework Umbrella Activities Framework Activities Task Sets Tasks Milestones, deliverables SQA points

19. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 19 1.6 The RAD Model The Rapid Application Development (RAD) model is a ‘high-speed’ adaptation of the linear sequential model which uses a component based construction approach. Requirements must be well understood and project scope constrained. Attempts to create full functional systems in 2-3 months. Primary application domain is information systems. Phases –Business modeling what information drives the business process. What information is generated? Who generates it? Where does the information go? Who processes it?

20. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 20 1.6 RAD (continued) –Data Modeling Define a set of data objects needed to support the application, and the relationships between these objects. –Process Modeling Data objects and transformations defined to implement business functions. Provide Add, modify, delete, retrieve for all data objects. –Application Generation. Use 4GL techniques. Use components. –Testing and turnover Test new components and combination of components in the application. For larger application, can use RAD model if system can be decomposed and teams apply the RAD model to each component.

21. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 21 1.6 RAD (continued) Advantages –Rapid development. –high level of reuse. Disadvantages –Need commitment to process by both customer and developer. –Restricted application domain.

22. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 22 1.7 The Concurrent Development Model Also called ‘concurrent engineering’. Process represented by a network of activities. Each activity has a ‘state’. Each activity exists simultaneously with other activities. Events from activities can trigger changes of state in other activities. DoneBaselined Under Revision Awaiting Changes none Under Development Under Review

23. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 23 1.8 Formal Methods Model A formal methods are used to develop mathematical specifications of software. An example of a formal method model is cleanroom software engineering (developed by IBM). Formal methods can discover ambiguity, incompleteness, inconstancies and errors in a specification or design. Current problems: –Time consuming and expensive –Few software engineers have a background in formal methods –Not a good tool to communicate a specification or design to a technically unsophisticated customer. Important in safety critical applications. Will grow in more general usage.

24. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 24 Additional Material #2 This is material which is not from the text book or from Pressman. Software System Size Lehman’s Laws Moore’s Law Best Practice

25. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 25 Software System Size Some examples of system size: Small Telephone Exchange - 500,000 lines of code Space shuttle on-board system - 1,000,000 loc Large Telephone Exchange - 2,000,000 loc Telephone Network S/W - 3,000,000 loc If print code of a s/w system (ignore documentation!) 100,000 loc 400m of printout 1,000,000 loc 4km of printout

26. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 26 Lehman’s Laws Software systems always need to be maintained as they evolve. Observations (‘laws’) by Lehman: –Continual Change A program must change in a real-world environment or become less and less useful. –Increasing Complexity Changing a program will increase the complexity of the program (unless active efforts are made to avoid this) –Program Evolution Program evolution is self-regulating - can use metrics (such as size, # errors) to find statistically significant trends. –Conservation of Organisational Stability Over the lifetime of a system: The rate of development is approximately constant and independent of resources used to develop the system. –Conservation of Familiarity Over the lifetime of a system: the rate of change to the system is approximately constant.

27. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 27 Moore’s Law MIPS/$ and Memory/$ relationships double approximately every two years. Has been true for two decades and expected to continue for at least another 2 decades. Has enabled the size and complexity of systems being developed to continue to increase. This increase in size and complexity has forced development of new SE methods as old methods fail to scale up. The new area of rapid development is in distributed networked environments with many embedded applications.

28. Software Engineering 1A/1B/1C/1M School of Computer and Information Science, University of South Australia Week 1, Lecture 2, Page 28 Best Practice What are some of concepts or methods which most Software Engineers would consider important in detailing what constitutes ‘best practice’ in Software Engineering? Abstraction and information hiding Decomposition and Composition Architecture and Modularity Process models Metrics Software Quality Configuration Management Project Management Analysis and design methods and notations. Prototyping Tool and Environments