76.3601 Introduction to Software EngineeringT–76.3601 — Introduction to Software Engineering ......

AB HELSINKI UNIVERSITY OF TECHNOLOGY

T–76.3601 — Introduction to Software Engineering

http://www.soberit.hut.fi/T-76.3601/

Casper [email protected]

Software Life-Cycle Models



AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius

Software Engineering?

1. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software

2. The study of approaches in (1).IEEE Computer Society


Software Process?• Process

• Webster: 1. A continuing development involving many changes. 2. A particular method for doing something, usually involving a number of steps or operations.

• IEEE: A sequence of steps performed for a given purpose.

• Software Process

• CMM(I): a set of activities, methods, practices and transformations that people use to develop and maintain software and the associated products

• Simply: the way an organization/team/individual develops software


Leavitt’s Organizational Diamond

Structure, Culture, Management,

Decision making

Tools, Methods, Facilities, Environment

PracticesProceduresInstructions

KnowledgeSkills, Needs,Motivation

Structure

Technology

Process People


Knowledge,Skills, Needs,Motivation

Tools, Methods, Facilities,

Environment

Practices,Procedures,Instructions

Structure,Culture,Management,

Decision making

Structure

Technology

Process People

Adapted from Leavitt, H.J. Applied organizational change in industry: Structural, technological and humanistic approaches. Handbook of Organizational. J.G. March. Chicago, Rand McNally. 1965


The Sandbox

Requirements managementDocumentation

Quality Control (V & V)Configuration Management

Specifi-cation

Defi-nition

Imple-men-tation

Testing

Instal-lation,

Mainte-nance

Project Management

Program management

Process management (Quality System)

Business ManagementCMM

RUP

USDP

Time Boxing

SPICE

CMM

UML

Z

SA/SD

eXtreme Programming

CleanRoom

Object Orientation

Basic activities

Support activities


Process: Adaptability• the framework activities will always be applied on

every project ... BUT

• the tasks and degree of rigor for each activity will vary based upon many factors, e.g.:

• the type project

• project characteristics

• team characteristics

• common sense judgement

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.


Prescriptive Models• Prescriptive process models advocate an orderly approach

to software engineering

• That leads to a few questions...

• If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?

• Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?


AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper LasseniusAB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius

• Problems

• No speci!cations

• No design

• Totally unsatisfactory

• Need life"cycle model

• #Game plan$

• Phases

• Milestones

• Problems

• lack of visibility

• easily leads to poorly structured systems

Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.

Build and Fix Model• Problems

• No specifications

• No design

• Lack of visibility

• Easily leads to poorly structured systems


• Need life-cycle model


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems





Waterfall Model

• Planning and control

• Documentation-driven

• “Doing the homework”

• Formal change management


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems



Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius

• Characterized by

• Feedback loops

• Documentation!driven

• "Doing the homework"

• Planning and control

• Advantages

• Documentation

• Maintenance easier

• Disadvantages

• In#exible partitioning

• Speci$cation changes expensive



The Waterfall Model• Strengths

• Easily manageable process (manager’s favourite?)

• Probably the most effective model, if you know the requirements

• Extensive documentation

• Weaknesses

• Inflexible partitioning of the project into distinct phases

• Difficult to respond to changing customer requirements

• Feedback on system performance available very late and changes can be very expensive

• Applicability

• Appropriate when the requirements are well understood

• Short, clearly definable projects (e.g. maintenance)

• Very large, complex system development that requires extensive documentation. Safety critical systems.


Cost to Detect and Correct a Fault


Rapid Prototyping Model

• Linear

• “Rapid”

• Exploratory vs. throw-away prototypes


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems





Incremental Model

• Divide project into builds

• Each build adds functionality

• Prioritized user requirements

• Requirements frozen during each build!


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems





Incremental Model• The concept of growing a system via iterations: iterative and incremental

development (IID)

• Divide the project into increments

• Each increment adds functionality

• Each iteration is a self-contained mini project composed of activities such as requirements analysis, design, programming and test

• At the end of the iteration an iteration release: a stable, integrated and tested partially complete system

• Most releases internal, final iteration release is the complete product

• Prioritize user requirements

• MOSCOW priorities: must, should, could, want

• High-priority requirements into early increments

• Freeze requirements during each increment


Incremental Development Advantages• Customer value can be delivered at the end of each increment making

system functionality available earlier

• Final product better matches true customer needs

• Early increments act as a prototype to help

• elicit requirements for later increments

• get feedback on system performance

• Lower risk of overall project failure

• Smaller sub-projects are easier to control and manage

• A meaningful progress indicator: tested software

• The highest priority features tend to receive the most testing

• Job satisfaction is increased for developers who can see early results of their work


Incremental Development Disadvantages

• Can be harder to plan and control than waterfall development

• Can be more expensive than waterfall development

• May require more experienced staff

• System architecture must be adaptive to change

• Software project contracts are still mostly drawn up according to the waterfall model and all changes cause renegotiations


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


Synch-and-Stabilize


Product vision

Functional specification

Development

subcycleDevelopment

subcycle

Development

subcycle

Buffer time Buffer time Buffer time

Alpha release Beta release Feature

complete

Beta release

UI freeze

Code complete

• Final test

• Final debug

• StabilizeFinal release


Sync-and-Stabilize

• At the end of the day—synchronize (test and debug)

• At the end of the build—stabilize (freeze build)

• Components always work together

• Get early insights into operation of product


Spiral Model

• Radial dimension: cumulative cost to date

• Angular dimension: progress through the spiral


• Radial dimension: cumulative cost to date

• Angular dimension: progress through the spiral


The Spiral Model• A meta-model -> other models can be derived

• Risk management is central

• Problems

• Hard to match to contract software

• Not enough flexibility and freedom in contract mechanisms

• Great deal of reliance on risk-assessment expertise

• Applicability

• Internal software development

• A framework for risk-driven application of other models


Still Other Process Models• Component based development—the process to

apply when reuse is a development objective

• Formal methods—emphasizes the mathematical specification of requirements

• AOSD—provides a process and methodological approach for defining, specifying, designing and constructing aspects

• Unified process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)



Rational Unified Process (RUP)



UP Work Products


These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

21

Inception phase

Elaboration phase

Construction phase

Transition phase

Vision document

Initial use-case model

Initial project glossaryInitial business case

Initial risk assessment.

Project plan, phases and iterations.

Business model, if necessary.

One or more prototypesInception

Use-case model

Supplementary requirements including non-functional

Analysis modelSoftware architecture

Description.

Executable architectural prototype.

Preliminary design model

Revised risk listProject plan including

iteration plan

adapted workflows milestones

technical work products

Preliminary user manual

Design model

Software components

Integrated software increment

Test plan and procedure

Test casesSupport documentation

user manuals

installation manuals description of current

increment

Delivered software increment

Beta test reportsGeneral user feedback


AB HELSINKI UNIVERSITY OF TECHNOLOGY

Questions?

76.3601 Introduction to Software EngineeringT–76.3601 — Introduction to Software Engineering ......

Documents

Transcript of 76.3601 Introduction to Software EngineeringT–76.3601 — Introduction to Software Engineering ......