SE 470 Software Development Processes James Nowotarski 14 April 2003.

SE 470Software Development Processes

James Nowotarski

14 April 2003

Course Map

Overview. Introduction. History

Content. Rational Unified Process. Extreme Programming

Implementation. Tools, Training, Roles. CMM, Metrics. Selection & Evaluation

Briefings (Term Papers)

1 2 3 4 6 7 8 9 10 115

Assignments

Quizzes

Week

Mem

ori

al D

ay

• Understand the basics of the Rational Unified Process (RUP)– Structure

– Content

– Best practices

• In particular, understand how RUP enables iterative development

Today’s Objectives

Topic Duration

• Quiz #1 40 minutes

• RUP Overview 30 minutes

• *** Break 10 minutes

• RUP Overview (cont.) 45 minutes

• RUP and Iterative Development 60 minutes

Today’s agenda

Topic Duration






Today’s agenda

Think to yourself how many of the projects you have worked were:

On Time? On Budget?

High Quality?

The Bottom Line: Our Customers are upset with us.The Bottom Line: Our Customers are upset with us.

The Result is Often Referred to as the Software Crisis

• Schedule Overruns• Cost Estimate Overruns• Software Quality Problems• Software does not meet User Expectations• Productivity of Software Developers has not

been keeping up with demand

Why is This?

• Software is dynamic versus static• Software is complex• Software is difficult to conceptualize • Software is difficult to represent • Software is difficult to communicate• Software is difficult to evaluate and measure• Software developers have trouble learning what users

want:– Users do not know what they want – Software developers misunderstand the problem

• There is a tremendous demand for software

Symptoms and Root Causes

Some Symptoms:• Requirements in flux • Users needs not met• Poor quality• Schedule slips• Projects cancelled• Cost over runs• Difficulty in maintaining

software• Software that work in pilot

does not work in production• Business changes faster

than systems can keep up• Staff turnover

Some Root Causes:• Insufficient and misunderstood

requirement• Ambiguous communication• Lack of good software

architectures• Undetected inconsistencies• Poor testing• Overwhelming complexity• Uncontrolled changes• Manual practices• Exponentially increasing cost of

change

Best Practices

“An organized and documented set of principles, methods and processes that increase quality and productivity of software development.”

“An organized and documented set of principles, methods and processes that increase quality and productivity of software development.”

Source: Rational - “Principles of Managing Iterative Development v2.0”

Rational’s View of Best Practices

The Rational Unified Process

• Developed through the combined efforts of:– Grady Booch– Ivar Jacobson– James Rumbaugh

• Features– Based on the Unified Modeling Language– Iterative– Architecture-centric– Use-case driven– Risk driven

Rational Unified Process

Rational Objectory Process 4.1

Rational Approach

Rational Unified Process 5.5

Rational Unified Process 5.0

Rational Objectory Process 4.1

Rational Unified Process 2000

Objectory Process 3.8

The History of the Rational Unified Process

2000

1999

1998

1997

1996

1995

UML v1.0

UML v1.1

UML v1.3

RUP Model Notation

A role played by an individual or a

team.

A unit of work that a worker may

perform.

A piece of information that

is produced, modified or used

by a process.

Workers

• A Worker is a role played by an individual or a team.

• Example:– Stakeholder– Systems Analyst– Designer– Test Designer– Project Manager

A piece of information that is produced, modified or used by a process.

Artifacts are the intangible products of the project

Examples: A use-case model A document such as a

business case Source Code Executable code

Artifacts

Artifacts - Examples

Activities

• An Activity is a unit of work that a worker may perform.

• Examples:– Plan an interaction

performed by Project Manager

– Find use cases and actors– Review the design– Execute a performance

test

Additional Process Elements

• Guidelines - are rules, recommendations, or heuristics that support activities and steps.

• Templates - are models or prototypes of artifacts– Ex. Word template for Vision Document

• Tool mentors - are a means of providing guidance by showing you how to use a specific software tool (Similar to wizards)

• Concepts - Separate material that describe some of the reasons and background on a specific topic

Software Product

Rational’s Nomenclature of the Software Engineering Process

Requirements

User Team (Suppliers)Expectations• Features• Cost• Benefit• Delivery Dates• Quality

Users Team(Customer)Perceptions• Features• Cost• Benefit• Delivery Dates• Quality

SoftwareEngineering

Process(Workflows)

Software Development Team

Processes, Techniques & Tools

PerformanceMeasures(Activities)

Software is developed in Teams:

Workers

Workers

Workers

ArtifactsArtifacts

Artifacts

Activities


• Use Iterative Development• Manage Requirements• Use Component Architectures• Model Visually• Continuously Verify Quality• Control Change

Iterative Advantages/Disadvantages

Advantages• Resolves risks before

making large investments• Enables early user feedback• Makes testing and

integration continuous• Focuses project on short-

term objectives• Makes partial deployments

possible

Disadvantages• Waterfall life cycle is more

familiar since it is similar to hardware life cycle

• Iterative Life Cycles difficult to estimate and manage.

• Only recently used on real projects - therefore little track record

Iterative life cycle best used for problems that are not well understood. Iterative life cycle best used for problems that are not well understood.

Manage Requirements

A systematic approach to– eliciting

– organizing

– documenting

– and managing

the changing requirements of the software application

What’s the Difference?

• Requirements Analysis• Requirements Definition• Requirements Specification• Requirements Management

Managing Changing Requirements

• Establish a Baseline• Evaluate changes and determine their impact• Track and document tradeoffs and decisions

Software Components

Definition:

A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

Definition:

A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

Components

Airplane

Private Data

Object Operations

Airplane

Private Data

Object Operations

Engines

Private Data

Object Operations

Engines

Private Data

Object Operations

Wings

Private Data

Object Operations

Wings

Private Data

Object Operations

Fuselage

Private Data

Object Operations

Fuselage

Private Data

Object Operations

Tail

Private Data

Object Operations

Tail

Private Data

Object Operations

COMPONENTS - Are objects that are combined into new objects without the use of inheritance

Benefits of Component Architectures

• Resilient– Meets current and future requirements– Improves extensibility– Enables reuse– Encapsulates system dependencies

• Reuse proven solution elements– Reuse or customize components– Select from Commercially-available

components– Evolve existing software incrementally

Benefits of Architecture

• Intellectual control– Manage complexity– Maintain integrity

• Basis for reuse– Component reuse– Architecture reuse (patterns)

• Basis for project management– Focus on early iterations– Planning– Staffing

Model Visually - Use the UML

• Capture the structure and behavior of architectures and components

• Show how the elements of the system fit together

• Maintain consistency between a design and its implementation

• Promote unambiguous communication

The Unified Modeling Language

• Developed through the combined efforts of:– Grady Booch– Ivar Jacobson– James Rumbaugh

• Is a language for:– Visualizing– Specifying– Constructing– Documenting

the artifacts of a software-intensive system.

History of the UML

UML Components

• Multiple Views• Precise Syntax and semantics• Include

– Use-Case Diagrams– Class Diagrams– Object Diagrams– Component Diagrams– Deployment Diagrams– Activity Diagrams– State Chart Diagrams– Collaboration Diagrams– Sequence Diagrams

Continuously Verify Quality

• In the Rational Unified Process, quality is defined as:"The characteristic identified by the following:

– satisfies or exceeds an agreed upon set of requirements, and – assessed using agreed upon measures and criteria, and – produced using an agreed upon process."

• Therefore, achieving quality is not simply "meeting requirements" or producing a product that meets user needs, or expectations, etc.

• Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).

Test Each Iteration

• Start testing early• Continuously test• Test each iteration for functionality and

performance• Iterative development makes regression

testing necessary• Use automated tests whenever possible

Control Changes

• You must control, track and monitor changes to enable iterative development

• Control changes for all software artifacts:– Models

– Documents

– Source code

– Project plans

• Establish secure workspaces fore each developer• Automated integration and build management

Controlling Parallel Development

• Multiple developers• Multiple teams• Multiple sites• Multiple iterations• Multiple releases• Multiple projects• Multiple platforms

Configuration Management

Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products– Librarian like function– Manages the version number for each software product– Changes made are controlled by a Change Control Process– Can be managed manually or through the use of a

configuration management tool (Difficult to do manually, but it can be done.)

• Check In• Check Out• Read only for others

Change Control Process

Create InitialSections

Create/ModifyDraft

Review Draft(V&V)

Create Changes to Incorporate

Changes Needed In Document

DocumentApproved

Create Review Revise ReviewReview Approved

Time

...

Document in Production and Under Formal Change Control

Document in Production and Under Formal Change Control

Document Under Development and User Change Control

Document Under Development and User Change Control

Topic Duration






Today’s agenda

Core Concepts

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

A D IVersion 1

A D IVersion 2

A D IVersion 3

Anatomy of Terminology

Product

Development Cycle

Phase

Iteration

Activity

Core Concepts

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

Version 1

Development CycleVersion 2

Development CycleVersion 3

Development Cycle

Initial

Evolution

Evolution

Product delivered to users

Core Concepts

Inception Elaboration Construction Transition

Core Concepts

Iterationn Iterationn+1

Core Concepts

Development Cycle

Phase

Iterationn+1IterationnR

D

C

T

R

D

C

T

Core Concepts

Each iteration is a mini-waterfall

R

D

C

T

R

D

C

T

R

D

C

T

Importance of activities across one development cycle

One development cycle

Core Concepts

Milestones

• Exit criteria• Decide to proceed, abort, or change course• Measure progress, e.g.,

– use cases completed– features completed– performance requirements satisfied– risks eliminated– test cases passed

For each phase, one group fills out:

Key Question: Deliverables/Outcomes

Activities Exit Criteria

Guidelines

Key Question: Deliverables/Outcomes

Activities Exit Criteria

Look at the objectives and distill into one key question that needs to be answered by this phase

What are the major artifacts produced? Outcomes achieved?

What are the essential activities?

Predefined standards that must be met before exiting one development phase and entering another. A team handing work off to another part of the project must fully satisfy their exit criteria, while the receiving team verifies that the work meets their standard entry criteria.

• Kruchten, Chapters 3, 7, 17• Quiz (end of class):

– Kruchten

– RUP

Topics for April 21

Extra Slides

Summary Timeline

1960 1970 1980 1990 2000

Tech eraMainframe

Decentralized

Distributed Internet

Life cyclemodel

Stage wise

Waterfall

Iterative/Incremental

Methapproach

Structured Analysis/Design

Information Engineering

Object-Oriented A/DAgile

ContentUpdates

• Data mgmt • UI design• Bus process reengineering • Data/process distribution • CASE tools

• JAD• Prototyping • Multimedia content mgmt

• Network design/mgmt • Quality• Security

• OLTP

Protracted integration and late breakage

Conventional application of the waterfall model typically results in late integration and performance showstoppers

Dev

elop

men

t p

rogr

ess

(% c

oded

)

100%Late designbreakage

Original target date

Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).

Integrationbegins

SE 470 Software Development Processes James Nowotarski 14 April 2003.

Documents

Transcript of SE 470 Software Development Processes James Nowotarski 14 April 2003.