Understanding Software Development Life Cycle Models, Slides of Software Development Methodologies

Download Understanding Software Development Life Cycle Models and more Slides Software Development Methodologies in PDF only on Docsity! Software Construction & Development (SE-345 ) Lecture 01 Software Processes Question ◼ Suppose you get a set of requirements to develop a product from customer. What should you do? How should you start? How to make sure that the product is delivered in the given cost and time estimates? Department of Software Engineering (UOM) 2 A software life cycle is a process ◼ A process involves activities, constraints and resources that produce an intended output. ◼ Each process activity, e.g., design, must have entry and exit criteria—why? ◼ A process uses resources, subject to constraints (e.g., a schedule or a budget) ◼ A process is organized in some order or sequence, structuring activities as a whole ◼ A process has a set of guiding principles or criteria that explain the goals of each activity Department of Software Engineering (UOM) 5 Earliest Software Process: Code & Fix The earliest approach ◼ Write code ◼ Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features ◼ Source of difficulties and deficiencies  impossible to predict  impossible to manage Department of Software Engineering (UOM) 6 Models are needed ◼ Symptoms (signs) of inadequacy (lack/shortage): the software crisis scheduled time and cost exceeded user expectations not met poor quality ◼ The size and economic value of software applications required appropriate "process models" Department of Software Engineering (UOM) 7 Problems ◼ The assumption is that requirements can be fully understood prior to development ◼ Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) ◼ Unfortunately the assumption almost never holds Department of Software Engineering (UOM) 10 Process as a "white box" Product Process Informal Requirements feedback 11 Advantages ◼ Reduce risks by improving visibility ◼ Allow project changes as the project progresses based on feedback from the customer Department of Software Engineering (UOM) 12 Waterfall Model Department of Software Engineering (UOM) 15 Waterfall Model ◼ Cascades (flow) from one stage down to the next, in stately, lockstep, glorious order. Gravity only allows the waterfall to go downstream;  it’s very hard to swim upstream ◼ US Department of Defense contracts prescribed this model for software deliverables for many years, in DOD Standard 2167-A. Department of Software Engineering (UOM) 16 Why would corporate manager types like the waterfall life cycle model? ◼ Minimizes change, maximizes predictability ◼ Costs and risks are more predictable ◼ Each stage has milestones and deliverables: project managers can use to gauge how close project is to completion ◼ Sets up division of labor: many software shops associate different people with different stages:  Systems analyst does analysis,  Architect does design,  Programmers code,  Testers validate, etc. Department of Software Engineering (UOM) 17 V Model ◼ Developed by the German Ministry of Defense ◼ What does this model highlight?  Unit and system testing verify the program design, ensuring that parts and whole work correctly  Acceptance testing, conducted by the customer rather than developers, validates the requirements, trying each system function meets a particular requirement in the specification ◼ How does this model account for cycles?  If problems are found during verification or validation, then re- execute left side of V to make fixes and improvements  While the waterfall emphasizes documents and artifacts, the V model emphasizes activities and correctness Department of Software Engineering (UOM) 20 Prototyping Preliminary design build evaluate requirements prototype prototype prototype Specify full requirements design code: test integrate Figure 3: The prototyping cycle Department of Software Engineering (UOM) Prototyping ◼ This model adds prototyping as sub-process ◼ A prototype is a partially developed product that enables customers and developers to examine some aspect of a proposed system and decide if it is suitable for a finished product ◼ Why add prototypes to the life cycle? ◼ Used to explore the risky aspects of the system:  Risk of developing the “wrong” system (what customer doesn’t want), can be a user interface without functionality  Other technical risks – e.g. performance, using a new technology, alternative algorithms, etc. ◼ Prototype may be thrown away or evolve into product Department of Software Engineering (UOM) 22 Iterative Model rsion 1 reqts design code test integrate OaM lessons tefrnr on 2 , reqt: design code test integrate OSM fessons jegrar version 3 regts | design code | test | integrate | \ Figure 3: Evolutionary development. Each version incorporates lessons learned from earlier versions Department of Software Engineering (UOM) Iterative and Incremental Process ◼ Incremental development partitions a system by functionality  Early release starts with small, functional subsystem, later releases add functionality  Top part of this figure shows how incremental development builds up to full functionality ◼ Iterative development improves overall system in each release  Delivers a full system in the first release, then changes the functionality of each subsystem with each new release ◼ Suppose a customer wants to develop a word processing package  Incremental approach: provide just Creation functions in Release 1, then both Creation and Organization in Release 2, finally add Formatting in Release 3, …  Iterative approach: provide primitive (prehistoric) forms of all three functions in Release 1, then enhance (making them faster, improving the interface, etc.) in subsequent releases  Pros and cons of these two approaches? ◼ Many organizations combine iterative and incremental approaches Department of Software Engineering (UOM) 26 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 Department of Software Engineering (UOM) 27 Spiral model… ◼ Identifies probable risks in advance and tries to minimize them  e.g. if it is decided to use a new programming language, the compilers available may not be reliable ◼ Occurrence of a risk item could result in project delay, exceeding cost or even failure ◼ Different processes maybe used for different loops in the spiral Department of Software Engineering (UOM) 30 Rational Unified Process (RUP) ◼ Developed by “three amigos” at Rational Software (IBM)  Grady Booch, Ivar Jacobson, and Jim Rumbaugh  Unified Modeling Language (UML) is a set of graphical and linguistic notations for modeling systems, not a process or method  The three amigos also developed Rational Unified Process (RUP)  You don’t have to use RUP to use UML  Interestingly different from the traditional waterfall model ◼ Highly iterative and incremental process  Software product is not released in one big bang at end of project  Instead, developed and released in pieces (prototypes, partial releases, beta, etc.) Department of Software Engineering (UOM) 31 How do traditional stages iterate? Workflows look traditional, but they iterate in four phases Department of Software Engineering (UOM) 32 Choose RUP When.. ◼ …you need a process framework that has everything ever possible already in it ◼ …you can resist the temptation (pull/attraction) to adopt too much of it ◼ …you want well-defined roles ◼ …it’s important to have a well-documented process that new hires may be familiar with ◼ …you do not have emergent requirements Department of Software Engineering (UOM) 35 Assignment 1 ◼ Which model (or combination of models) might you use in a project? Why? Due Date: Monday, March 28, 2022 Before Class time Department of Software Engineering (UOM) 36