ISE_Lecture Week 2-SW Process Models.ppt
- 1. “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” Yogi Berra
- 2. The objective of software engineering is to get software with high quality. Process is a framework for the tasks that are required to build high-quality software. A software process is a set of activities and associated results, which produces a software product. Software engineers carry out the activities. Chapter 2 Software Processes 2
- 3. The common activities ca be categorized into: 3 • The functionality of the software and constraints on its operation must be defined. Software specification • The software to meet the specification must be produced. Software development • The software must be validated to ensure that it does what the customer wants. Software validation • The software must be evolved to meet the changing requirements of customers. Software evolution
- 4. Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. In practice, most practical processes include elements of both plan-driven and agile approaches. There are NO right or wrong software processes. Chapter 2 Software Processes 4
- 5. A framework that describes the activities performed at each stage of a software development project.
- 6. 6
- 7. Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing.
- 8. Test – check if all code modules work together and if the system as a whole behaves as per the specifications. Installation – deployment of system, user-training. Maintenance – bug fixes, added functionality (an on-going process).
- 9. Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule
- 10. All requirements must be known upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
- 11. Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.
- 12. A variant of the Waterfall that emphasizes the verification and validation of the product. Testing of the product is planned in parallel with a corresponding phase of development
- 13. Project and Requirements Planning – allocate resources Product Requirements and Specification Analysis – complete specification of the software system Architecture or High-Level Design – defines how software functions fulfill the design Detailed Design – develop algorithms for each architectural component Production, operation and maintenance – provide for enhancement and corrections System and acceptance testing – check the entire software system in its environment Integration and Testing – check that modules interconnect correctly Unit testing – check that each module acts as expected Coding – transform algorithms into software
- 14. Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use
- 15. Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities
- 16. Excellent choice for systems requiring high reliability – hospital patient control applications All requirements are known up-front When it can be modified to handle changing requirements beyond analysis phase Solution and technology are known
- 17. Two ways: System prototyping Incremental delivery Chapter 2 Software Processes 17
- 18. What is software Prototyping? ◦ Prototype is working model of software with some limited functionality. Stepwise approach to develop software prototype ◦ Basic Requirement identification ◦ Developing the initial prototype ◦ Review of the prototype ◦ Revise and enhance the prototype
- 20. Objective - Derive end system requirements Throw away prototyping is one type of approach where an initial prototype is built mainly focusing on the poorly understood requirements. • Once the requirements are understood, prototype is discarded. Requirements document is updated. • Actual system is developed (i.e. a conventional development process) with clear understanding of requirements.
- 21. Used to reduce requirements risk. Initial prototype is developed from outline requirements, delivered for experiment, and modified until risk is acceptably low. Examples of throwaway prototypes include screen mock-ups and story boards.
- 22. Developers may be pressurized to deliver a throw-away prototype as the final system. This is problematic... It may be impossible to meet non-functional requirements. The prototype is almost certainly undocumented. The system may be poorly structured and therefore difficult to maintain. Normal quality standards may not have been applied.
- 23. Air Tank Developer User Mgmt No, no, no! I won’t deliver the prototype to you! Pressurizing the Developer
- 24. Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
- 25. A preliminary project plan is developed An partial high-level paper model is created A prototype is built with basic and critical attributes The designer builds the database user interface algorithmic functions The designer demonstrates the prototype, the user evaluates for problems and suggests improvements. This loop continues until the user is satisfied
- 26. Customers can “see” the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality
- 27. Tendency to discard structured program development for “code-and-fix” development Bad reputation for “quick-and-dirty” methods Overall maintainability may be overlooked Process may continue forever (scope creep)
- 28. Requirements are unstable or have to be clarified Develop user interfaces Short-lived demonstrations New, original development
- 29. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. In Incremental Model, Project requirements are divided into multiple modules and each module is developed separately. Finally developed modules are integrated with other modules. During development of each module, waterfall model is followed for each module development separately. Each developed module in Incremental Model is standalone feature and could be delivered to the end users to use it.
- 30. Chapter 2 Software Processes 30
- 31. Chapter 2 Software Processes 31
- 32. Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses “divide and conquer” breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced
- 33. Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower
- 34. Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology
- 35. The CBD Solution Systems should be assembled from existing components. Chapter 2 Software Processes 35
- 36. A software component is a program module that can be used independently, or can operate in conjunction with other components. Components should be executable to allow independence. Chapter 2 Software Processes 36
- 37. What is CBSE? Component-based software engineering is the idea of building software from established software components, as opposed to building the software from the ground up. Chapter 2 Software Processes 37
- 38. Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. Reuse is now the standard approach for building many types of business system Chapter 2 Software Processes 38
- 39. Advantages: reducing cost and risk. faster delivery of software Disadvantages: Requirement compromises Chapter 2 Software Processes 39
- 40. Similar to the incremental model, with more emphasis placed on risk analysis. Process is represented as a spiral, rather than as a sequence of activities. Software project repeatedly passes through these phases in iterations. Risks are explicitly assessed and resolved throughout the process. Incremental releases of the product, or incremental refinement through each iteration around the spiral. Spiral model is an evolutionary software process model which is a combination of an iterative nature of prototyping and systematic aspects of traditional waterfall model.
- 41. Development cycles through multiple (3-6) task regions
- 42. Figure 2.13
- 43. •The objectives, alternatives and constraints of the project are determined and are documented. Planning Phase •All possible alternatives, which can help in developing a cost effective project are analyzed •This phase identify and resolve all the possible risks in the project development. Risk assessment and reduction •The actual development of the project is carried out. •The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same. Development and validation •Developed product is passed on to the customer in order to receive customer’s comments and suggestions. •This phase is very much similar to TESTING phase. •And the next phase of the spiral is planned. Customer Evaluation (Planning)
- 44. Provides early indication of unsolvable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently
- 46. When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)
- 47. Speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods
- 48. Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross- functional teams. 48
- 49. 49