The Software Life Cycle

Outline Review Life cycle models Improving the SE process

Review What is the software process? the activities, techniques, tools, and individuals to produce software Documentation important for each phase. Why? people & products change Testing is essential throughout life cycle traceability? tying a piece of doc/design back to previous doc Why are there no “silver bullets”? software is inherently hard because of complexity, conformity, changeability, invisibility

Software Life-Cycle Model Definition The series of steps through which the product progresses The models specifies the various phases of the process e.g., requirements, specification, design… the order in which they are carried out

Importance of Lifecycle Models Provide guidance for project management what major tasks should be tackled next? milestones! what kind of progress has been made? The necessity of lifecycle models character of software development has changed early days: programmers were the primary users modest designs; potential of software unknown more complex systems attempted more features, more sophistication  greater complexity, more chances for error heterogeneous users

Lifecycle Models Build-and-fix Why doesn’t build-and-fix scale? develop system without specs or design modify until customer is satisfied Why doesn’t build-and-fix scale? changes during maintenance most expensive!

Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and Running a new development project.

Hundreds of different kinds of models are known and used. Many are minor variations on just a small number of basic models. In this section we: survey the main types of model, and consider how to choose between them.

Planning with Models SE projects usually live with a fixed financial budget. (An exception is maintainance?) Additionally, time-to-market places a strong time constraint. There will be other project constraints such as staff.

Examples of Project Constraints designers programmers managers money staff Project constraints Computing resources time Examples of Project Constraints

Project planning is the art of scheduling the necessary activities, in time, space and across staff in order to optimise: project risk [low] (see later) profit [high] customer satisfaction [high] worker satisfaction [high] long-term company goals

Questions: 1. What are these necessary activities? (besides programming) 2. Are there good patterns of organisation that we could copy?

A project plan contains much information, but must at least describe: resources needed (people, money, equipment, etc) dependency & timing of work (flow graph, work packages) rate of delivery (reports, code, etc) It is impossible to measure rate of progress except with reference to a plan.

In addition to project members, the following may need access to parts of the project plan: Management, Customers Subcontractors Suppliers Investors Banks

Project Visibility Unlike other engineers (e.g. civil, electronic, chemical … etc.) software engineers do not produce anything physical. It is inherently difficult to monitor an SE project due to lack of visibility.

additional deliverables (artifacts) This means that SE projects must produce additional deliverables (artifacts) which are visible, such as: Design documents/ prototypes Reports Project/status meetings Client surveys (e.g. satisfaction level)

What is a Lifecycle Model? Definition. A (software/system) lifecycle model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities.

It provides a fixed generic framework that can be tailored to a specific project. Project specific parameters will include: Size, (person-years) Budget, Duration. project plan = lifecycle model + project parameters

There are hundreds of different lifecycle models to choose from, e.g: waterfall, code-and-fix spiral rapid prototyping unified process (UP) agile methods, extreme programming (XP) COTS … but many are minor variations on a smaller number of basic models.

By changing the lifecycle model, we can improve and/or tradeoff: Development speed (time to market) Product quality Project visibility Administrative overhead Risk exposure Customer relations, etc, etc.

Normally, a lifecycle model covers the entire lifetime of a product. From birth of a commercial idea to final de-installation of last release i.e. The three main phases: design, build, maintain.

Note that we can sometimes combine lifecycle models, e.g. waterfall inside evolutionary – onboard shuttle software We can also change lifecycle model between releases as a product matures, e.g. rapid prototyping  waterfall

Code-and-Fix This model starts with an informal general product idea and just develops code until a product is ”ready” (or money or time runs out). Work is in random order. Corresponds with no plan! (Hacking!)

Code-and-Fix Model The easiest way to develop software No design No specifications Maintenance nightmare The easiest way to develop software The most expensive way

Advantages No administrative overhead Signs of progress (code) early. Low expertise, anyone can use it! Useful for small “proof of concept” projects, e.g. as part of risk reduction.

Disadvantages Dangerous! 2. Impossible for large projects, No visibility/control No resource planning No deadlines Mistakes hard to detect/correct 2. Impossible for large projects, communication breakdown, chaos.

Lifecycle Models Staged models successive stages of development e.g., waterfall model Requirements Phase Specification Design Implementation & Integration Description Design Docs Product (What needs to be done) (How to do)

Lifecycle Models Rapid prototyping build something users can understand & assess often focuses on the interface waterfall model follows the prototype Incremental (aka Evolutionary) development incrementally expand the system can be used to do a “phased delivery” to users more expectation management needed! build-and-fix revisited?

Waterfall Model Verify Flaw? Design Phase output of stages Feasibility Study Phase Requirements Analysis & Specification Phase Design Phase Verify output of stages The major flaw with the original model is that it didn’t support iteration… what if there was an incompleteness, contradiction, or ambiguity in the specification? Implementation & Unit testing Phase Flaw? original model didn’t let you go back! Integration & System testing Maintenance

Advantages of Waterfall Model Enforced discipline through documents no phase is complete until the docs are done & checked by SQA group concrete evidence of progress makes which costly phase easier? Testing is inherent in every phase continuously as well as at end of phases

Advantages Easy to understand and implement. Widely used and known (in theory!) Reinforces good habits: define-before- design, design-before-code Identifies deliverables and milestones Document driven, SRS … etc.. Works well on mature products and weak teams.

Disadvantages I Idealised, doesn’t match reality well. Doesn’t reflect iterative nature of exploratory development. Unrealistic to expect accurate requirements so early in project Software is delivered late in project, delays discovery of serious errors.

Disadvantages II 5. Difficult to integrate risk management Difficult and expensive to make changes to documents, ”swimming upstream”. Significant administrative overhead, costly for small teams and projects.

Drawbacks of Waterfall Model Document-driven model customers cannot understand these imagine an architect just showing you a textual spec! first time client sees a working product is after it has been coded. Problem here? leads to products that don’t meet customers needs Assumes feasibility before implementation re-design is problematic works best when you know what you’re doing when requirements are stable & problem is well-known

Rapid Prototyping Rapid prototyping as a requirements tool allow users to “see” & use proposed solutions develop specification from the prototype/requirements proceed with rest of stages in waterfall model Prototype must be constructed & changed quickly do not spend a lot of time perfecting the code/structure plan to throw it away! because you will! put in front of customer ASAP user interface prototyping & other rapid dev tools make this easier

Rapid Prototyping Model Linear model “Rapid” Figure 2.9

Rapid Prototyping Key idea: Customers are non-technical and usually don’t know what they want/can have. Rapid prototyping emphasises requirements analysis and validation, also called: customer oriented development, evolutionary prototyping

The Rapid Prototype Workflow Requirements Capture Iterate Quick Design Build Prototype Customer Evaluation of Prototype The Rapid Prototype Workflow Engineer Final Product

Advantages Reduces risk of incorrect user requirements Good where requirements are changing/uncommitted Regular visible progress aids management Supports early product marketing

Disadvantages I An unstable/badly implemented prototype often becomes the final product. Requires extensive customer collaboration Costs customers money Needs committed customers Difficult to finish if customer withdraws May be too customer specific, no broad market

Disadvantages II 3. Difficult to know how long project will last 4. Easy to fall back into code-and-fix without proper requirements analysis, design, customer evaluation and feedback.

Assessment of RP Model Advantages ? Disadvantages process proceeds linearly (less need for feedback loops) easier to take technology risks with the prototype Disadvantages expectation management delivering “everything” properly takes time turning prototypes into production code quite controversial... will turn into build-and-fix

Incremental Model Divide project into builds Advantages ? Verify Requirements phase Specification Architectural design Operations mode Development Maintenance Retirement Perform detailed design, imple- mentation, and integration. Test. Deliver to client. For each build: Divide project into builds each adds new functions each build integrated w/ structure & product tested as a whole Advantages ? operation product in weeks less traumatic to organization smaller capital outlay Disadvantages ? need an open architecture a big advantage come maintenance! too few builds  build-and-fix too many builds  overhead

Other Incremental Models Advantages ? more parallelism saves lots of time! Risks ? no overall design at start  pieces might not fit together

Synchronize & Stabilize Model (Microsoft) Requirements analysis interview potential customers Draw up overall product specifications Divide project into 3 or 4 builds each adds new functionality (1st gives base) each build carried out by small parallel teams At the end of day – synchronize (test & debug) At end of build – stabilize (fix & freeze build) Who has worked for MS?

Lifecycle Models Spiral Model OO Models risk-driven approach assess risks before each phase what is the difficulty here? re-assess in frequent cycles OO Models more interaction between phases more iteration within phases assessing risk takes skill and lots of things can’t easily be accessed costs of assessing risk may be higher than development

Spiral Model Always some risk involved in software development people leave… other products not delivered on time… Key idea minimize risk e.g., building prototypes & simulations minimizes risks Precede each phase by looking at alternatives risk analysis Follow each phase by evaluation planning of next phase

Spiral Model Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: e.g. Build some software See if it meets customer requirements If no goto 1 else stop.

iterative lifecycle models. This loop approach gives rise to structured iterative lifecycle models. In 1988 Boehm developed the spiral model as an iterative model which includes risk analysis and risk management. Key idea: on each iteration identify and solve the sub-problems with the highest risk.

Each cycle follows a waterfall model by: Determining objectives Specifying constraints Generating alternatives Identifying risks Resolving risks Developing next-level product Planning next cycle

Spiral Model

Risk Assessment Risk-driven approach; in each spiral: identify potential risks plan next step based on risk analysis refine design in highest-risk areas Explicitly attempts to identify potential problems not just in initial stages of design also later, when more has been learned about the problem and the design What are the “risky” parts of the system relies on developer experience

Spiral Model

Assessing the Spiral Model Risk assessment how does one do it? how is it known that “proper” risks have been identified? “experience” is a critical factor what if a new software system is being attempted? model fails if risks are inaccurately assessed Not clear it works for contract projects how do you cancel a contract in the middle? Mainly for very large projects risk assessment could cost more than development!

Advantages Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements Flexible: incoporates the advantages of the waterfal and rapid prototyping methods Comprehensive model decreases risk Good project visibility.

Disadvantages Needs technical expertise in risk analysis to really work Model is poorly understood by non-technical management, hence not so widely used Complicated model, needs competent professional management. High administrative overhead.

Extreme Programming and Agile Processes Somewhat controversial new approach Stories (features client wants) Estimate duration and cost of each story Select stories for next build Each build is divided into tasks Test cases for a task are drawn up first Pair programming Continuous integration of tasks

Unusual Features of XP The computers are put in the center of a large room lined with cubicles A client representative is always present Software professionals cannot work overtime for 2 successive weeks No specialization Refactoring (design modification)

Agile Processes A collection of new paradigms characterized by Less emphasis on analysis and design Earlier implementation (working software is considered more important than documentation) Responsiveness to change Close collaboration with the client

Evaluating Agile Processes and XP XP has had some successes with small-scale software development However, medium- and large-scale software development is very different The key decider: the impact of agile processes on postdelivery maintenance Refactoring is an essential component of agile processes Refactoring continues during maintenance Will refactoring increase the cost of post-delivery maintenance, as indicated by preliminary research?

Evaluating Agile Processes and XP (contd) Agile processes are good when requirements are vague or changing It is too soon to evaluate agile processes There are not enough data yet Even if agile processes prove to be disappointing Some features (such as pair programming) may be adopted as mainstream software engineering practices

Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis — interview potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in parallel

Synchronize-and Stabilize Model (contd) At the end of the day — synchronize (test and debug) At the end of the build — stabilize (freeze the build) Components always work together Get early insights into the operation of the product

Comparison of Life cycle models Classical waterfall model is the basic. However, it cannot be used in practical development projects– no method to handle error Iterative model overcomes this problem. Simple to use and understandable. However, it is suitable for well-understood problems and is unsuitable for large projects and projects subject to many risks. Prototyping model suitable for projects where user requirements or the underlying technical aspects are not well-understood. Popular for user-interface part of the projects Evolutionary model suitable for large projects which can be decomposed into modules for incremental development and delivery. Also widely used for OO development projects. Spiral model also called meta model since it encompasses all other life cycle models. Risk handling is inherently built into it. Suitable for technically challenging s/w projects that are prone to several kinds of risks. However, it is more complex.

Comparison of Life-Cycle Models Different life-cycle models have been presented Each with its own strengths and weaknesses Criteria for deciding on a model include: The organization Its management The skills of the employees The nature of the product Best suggestion “Mix-and-match” life-cycle model

Comparison of Life-Cycle Models (contd)

Perils & Promises of Lifecycles Managers love ‘em defines a set of “deliverables” sound bites – can tell upper management that “stage so-and-so is completed” formally mandated by many government agencies Programmers find them inadequate not representative of what happens in the “trenches” customers can’t adequately state requirements up-front stages become intermixed w/ others e.g., design reveals that part of specification can’t be cost-effectively implemented

Next Time Questions? Next lecture on The Software Project Management