Introduction to software engineering course Lecture 2 - Process Models, Slides of Introduction to Software Engineering

Download Introduction to software engineering course Lecture 2 - Process Models and more Slides Introduction to Software Engineering in PDF only on Docsity! Lecture 02 Process Models 1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Software Process ■ Software Process is a framework for the activities, actions, and tasks that are required to build high-quality software. ■ When you work to build a product or system, it’s important to go through a series of predictable steps—a road map that helps you create a timely, high-quality result. The road map that you follow is called a software process. 2 What is the work product? ■ From the point of view of a software engineer, the work products are the programs, documents, and data that are produced as a consequence of the activities and tasks defined by the process. 5 A Generic Process Model Software process Process framework Umbrella activities framework activity # 1 software engineering action #1.1 work tasks work products quality assurance points project milestones Task sets software engineering action #1.k work tasks work products quality assurance points project milestones Task sets framework activity # n software engineering action #n.1 work tasks work products quality assurance points project milestones Task sets software engineering action #n.m work tasks work products quality assurance points project milestones Task sets  A Generic Process Model (cont…) ■ Referring to last figure, each framework activity is populated by a set of software engineering actions. ■ Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress. 7 Process Flow —+| Communication Planning Modeling + Construction Deployment (a) Linear process flow —+| Communication Planning Modeling Construction Deployment (b) Iterative process flow Planning lL — +] Communication Increment z Prey! ——{ Deployment Construction (c) Evolutionary process flow a Communication |= Plonning | L| Modeling |} Time —~ t——} Construction LK Deployment |- (d) Parallel process flow 10 Process Flow a. A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment. b. An iterative process flow repeats one or more of the activities before proceeding to the next. c. An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software. d. A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software). 11 Identifying a Task Set ■ A task set defines the actual work to be done to accomplish the objectives of a software engineering action. ■ Example: For example, elicitation (more commonly called “requirements gathering”) is an important software engineering action that occurs during the communication activity. The goal of requirements gathering is to understand what various stakeholders want from the software that is to be built. 12 Prescriptive/Traditional Models ■ Prescriptive process models advocate an orderly approach to software engineering. ■ All software process models can accommodate the generic framework activities but in a different manner. ■ These models prescribe a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. ■ Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which the process elements are interrelated to one another. 15 Brief History of Development Methodologies WATERFALL (Royce) Communication, Planning Modeling, Construction & Deployment 1985 199119801970 V-MODEL (Anon) Aligns testing to Waterfall development SPIRAL MODEL (Barry Boehm) Incremental Iterative AGILE e.g. XP (Kent Beck) Incremental, user driven, low process 1999 Waterfall V-Model Spiral Model Increment al Agil e Waterfall Model | Communication project initiation requirements gathering Plannin : ie Modeling analysis Construction ; code oe joyment el test livery scheduling , tracking design support feedback 17 V Model ■ V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage. This means that for every single phase in the development cycle there is a directly associated testing phase. This is a highly disciplined model and next phase starts only after completion of the previous phase. V Model Requirement |. Acceptance testing Sy fv | System testing Specification YY ] Design high-level » ——————— Integration testing Design low-level Unit testing Implementation Spiral Model an Ayman Cost Progress 3. Construct or Build 2. Design Review Release 4. Evaluation and Risk Analysis Lldentification Prototyping Model ■ It is an evolutionary software process model in which a prototype (an early approximation of a final product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. ■ This model works best in scenarios where not all of the project requirements are known in detail ahead of time. Prototyping Model (Cont…) 1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system. 2. A first prototype of the new system is constructed. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 3. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users. Prototyping Model (Cont…) 5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed. 6. The second prototype is evaluated in the same manner as was the first prototype. 7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired. 8. The final system is constructed, based on the final prototype. 9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. Evolutionary Prototyping ■ The idea behind this is that an initial prototype is presented to the user. They provide feedback and suggestions for improvements. ■ These are actioned by the developer who then presents a more refined prototype. The user once more provides feedback. The process is repeated. ■ So at each stage the prototype 'evolves' towards the final system. Incremental Development Build 1 i y | Design & —| Testing | nt Development 4 Build 2 i | ui Design& | Testing || Implementation Development J Build3 Design & esign Testing "| Implementation Development A Incremental Development (cont…) ■ It is a method of software development where the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. ■ The product is decomposed into a number of components, each of which is designed and built separately (termed as builds). ■ Each component is delivered to the client when it is completed. Difference between Incremental & Iterative Approach ■ Take the example of the beginnings of the two dominant mobile operating systems. ■ Google went for time to market with Android, they released an unpolished, yet feature rich, operating system quickly and made it better by iterating again and again over time. ■ Apple took the opposite approach: they released iOS with highly polished features relatively slowly (it took three major iOS releases to get MMS and copy & paste!) but focused on getting things right from the start. The Unified Process (UP) Elaboration software increment Production 36 The Unified Process (UP) Inception phase ■The inception phase of the UP encompasses both customer communication and planning activities. ■By collaborating with stakeholders, business requirements for the software are identified; a rough architecture for the system is proposed and a plan for the iterative, incremental nature of the ensuing project is developed. Elaboration phase ■The elaboration phase encompasses the planning and modeling activities of the generic process model. ■Elaboration refines and expands the preliminary use cases that were developed as part of the inception phase and expands the architectural representation. 37 The Unified Process (UP) Production phase ■The production phase of the UP coincides with the deployment activity of the generic process. ■During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated. 40 UP DAARAcC Workflows Requirements Analysis Design Implementation Test Support iterations UP Phases Inception Elaboration Construction Transition Production —oal fits. ano #1 #2 aot 11Th #n-1 #n Al Assignment # 1 1. Provide a number of examples (both positive and negative) that indicate the impact of software on our society. 2. What process adaptations are required if the prototype will evolve into a deliverable system or product? 3. Is it possible to combine process models? If so, provide an example. 42