76.3601 introduction to software engineering...software engineering? 1. the application of a...

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?


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?• 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 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?






• 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 design



• #Game plan$

• Phases

• Milestones

• Problems




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

• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems




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


• 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



Waterfall Model


• 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"


• Advantages

• Documentation

• Maintenance easier

• Disadvantages

• In#exible partitioning

• Speci$cation changes expensive



The Waterfall Model


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






• 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


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems





Rapid Prototyping Model

• Linear

• “Rapid”

• Exploratory vs. throw-away prototypes


• Problems


• No design



• #Game plan$

• Phases

• Milestones

• Problems





Incremental Model


• 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



Agile Software Development


The Manifesto for Agile Software Development

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have

come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”


Kent Beck et allii


What is “Agility”

• Effective (rapid and adaptive) response to change

• Effective communication among all stakeholders

• Drawing the customer onto the team

• Organizing a team so that it is in control of the work performed

• Yielding...

• Rapid, incremental delivery of software



An Agile Process

• Is driven by customer descriptions of what is required (scenarios)

• Recognizes that plans are short-lived

• Develops software iteratively with a heavy emphasis on construction activities

• Delivers multiple software increments

• Adapts as changes occur



From Waterfall to Agility


Time

Specification

Design

Implementation

Test

Waterfall Iterative/Incremental XP


Extreme Programming (XP)• The most widely used agile process, originally proposed

by Kent Beck

• XP Planning

• Begins with the creation of user stories

• Agile team assesses each story and assigns a cost

• Stories are grouped for a deliverable increment

• A commitment is made on the delivery date

• After the first increment, projct velocity is used to help define subsequent delivery dates for other increments



Extreme Programming (XP)



Extreme Programming (XP)• XP Design

• Follows the KIS principle

• Encourage the use of CRC cards (Chapter 8)

• Difficult solutions prototyped using spike solutions

• Encourages refactoring—an iterative refinement of the internal program design








• XP Coding

• Recommends the construction of unit tests before coding commences

• Encourages pair programming








• XP Coding

• Recommends the construction of unit tests before coding commences

• Encourages pair programming

• XP Testing

• All unit tests are executed daily

• “Acceptance tests” are defined by the customer and executed to assess customer visible functionality



Scrum• Originally proposed by Schwaber and Beedle

• Distinguishing features

• Development work partitioned into packets

• Testing and documentation on-going as the product is constructed

• Work occurs in sprints and is derived from a backlog of existing requirements

• Meetings are very short and sometimes conducted without chairs (scrums)

• Demos are delivered to the customer within the time-box allocated



Scrum



Challenges and Solutions for a Flexible Process

• Challenges

• Detailed design work must be started before the product architecture is fully defined

• Buffering need

• The system must be integrated before the completion of all its modules

• Design work partitioned

• The development team must be able to respond to new information even at a late stage of the project

• Flexibility in architecture

• Solutions

• Greater investment in architectural design

• Earlier feedback on a product’s system level performance

• Development team with a grater amount of “generational” experience


A Flexible Process• IS

• Iterative

• Based upon rapid, frequent, intense, systematic iterations, starting early in the process and involving customers

• NEEDS

• A modular and scaleable product architecture

• An experienced team

• Early customer/user involvement

• IS NOT

• Cheaper than a traditional process

• Fire-fighting

• Unmanaged ad-hoc hacking


Two Different Project Types


Two Different Project Types• Functionality driven

• Example: a new operating system

• Certain functionalities must be in place

• They are well-known in advance

• The schedule is allowed to slip so that the required functionality can be developed







• Schedule driven

• Example: consecutive releases of a word processor

• Release deadline set and fixed

• Product released on schedule

• Final configuration of features unknown until late in the project

• Features must be prioritized for this to work







• Schedule driven

• Example: consecutive releases of a word processor

• Release deadline set and fixed

• Product released on schedule

• Final configuration of features unknown until late in the project

• Features must be prioritized for this to work

A one-size process d

oes not fit all!


Process Choice• There is not uniformally applicable process which is

applicable to any type and size of project

• High costs may occur if you force an inappropriate process on a development team

• However, one organization cannot have a vast number of different processes in use

• Sometimes you don’t have a possibility to choose

• A chosen process model can be tailored to suit the project


Process Choice• For large systems, management is usually the principal

problem, so you need a strictly managed process

• For smaller systems, more informality is possible

• Hybrid models:

• Large systems are usually made up of several sub-systems

• The same process model need not be used for all subsystems

• Prototyping or agile development for high-risk specifications

• Waterfall model for well-understood developments


Dimensions Affecting Process Model SelectionDimensions Affecting Process Model

Selection (Boehm & Turner 2003)


Plan-driven vs. Agile• Neither plan-driven nor agile methods provide a silver

bullet

• Both have home grounds where one clearly dominates the other

• Both agility and disciplines are critical

• Increasingly rapid pace of change

• E.g., larger projects using agile methods need plan-driven process aspects to be integrated to be successful

• Build your method up—don’t tailor it down


Questions?

76.3601 introduction to software engineering...software engineering? 1. the application of a...

Documents