CS 551 Development Process. Engineering via Lambda Protocol l Prospectus l Measurable Operational Value l Prototyping then Modeling l Quality Function

CS 551 Development Process

Engineering via Lambda Protocol

Prospectus Measurable Operational Value Prototyping then Modeling Quality Function Deployment Schedule & Staffing Estimates ICED-T Trade-off Analysis

Universal Software Engineering Equation

Reliability (t) = ℮ -a

t

for constant error rate

Universal Software Engineering Equation

Reliability (t) = ℮ -a t

for constant error rate a is a productivity constant

= complexity/ [effectiveness x staffing] ≡ 1/ MTTF

effectiveness ≡ code expansion

t ≡ is the time the software is running

Boundary Conditions

Reliability (0) = 1

Reliability (T) = ℮ - a T

Reliability (∞) = 0

Top Ten Software Risk Items

Category Risk Item

People 1. Personnel Shortfalls

2. Unrealistic Schedules and Budgets

Requirements 3. Developing the Wrong Software Functions

4. Developing the Wrong User Interface

5. Gold Plating

6. Continuing Stream of Requirements Changes

Externalities 7. Shortfalls in Externally-Furnished Component

8. Shortfalls in Externally-Performed Tasks

Technology 9. Real-Time Performance Shortfalls

10. Straining Computer Science Capabilities

From Boehm (1988), p. 6From Boehm (1988), p. 6

Risk Analysis

Risk ≡ Probability that an event will happen = 1- Prob (event happens)

= 1- event/number of events possible

Business cost = the cost of recovering from the event or avoiding the event

Risk Exposure = Prob( event) x Business Cost

How Soon to Define Interfaces?- Loss due to rework with ill defined & validated architecture

Time spent defining & validating architecture

Risk Exposure

(RE )=P(L) * C(L)

Many interface defects: high P(L)Critical IF defects: high C(L)

Few IF defects: low P(L)Minor IF defects: low C(L)

How Soon to Define Interfaces?- Loss due to rework with ill defined & validated architecture

- Loss due to delayed implementation start


RE =P(L) * C(L)

Few delays: low P(L)Short Delays: low C(L)

Many delays: high P(L)Long delays: high C(L)




RE =P(L) * C(L)

Many delays: high P(L)Long delays: high C(L)

SweetSpot



How Soon to Define Interfaces?- Sum of Risk Exposures

Few delays: low P(L)Short delays: low C(L)

Organizational Structure

SYSTEM BASELINEREQUIREMENTS

ALGORITHMS

TRAFFICPROJECTIONS

FEATUREENGINEERING

ARCHITECTUREENGINEERING

TRAFFICENGINEERING

ENGINNERINGREPORTS SUPPORT AND OPERATIONS

- COMPUTER CENTER - DEVELOPMENT MACHINE - TEST MACHINE

SOFTWAREDEVELOPMENT

HUMAN FACTORSDEVELOPMENT

SOFTWAREMANUFACTURING INTEGRATION

TO SITES

Development Cycle with Feedback

DEFINE DESIGN DEVELOP MANUFACTURE& DELIVER

TEST

OPERATE,MAINTAIN &EVALUATE

TO SITES

Project Trouble Indicators

No periodic project meetings No project manager No active problem list No software architect Testing starts after development No risk assessment No independent test team

System Performance Resulting from Robust Requirements

Performance

Dynamic Range

Ideal

Discrete Specifications

RobustRequirements

Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Organization Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes9. Responses to the unexpected10. Measurements11. Glossary12. References

MeasurableOperational Value

Release Schedule Targeted Reduction Over PMO

If Release Does Not Reach Target Range Vendor Pays Customer

If Release Exceeds Target Range Customer Pays Vendor

1.0 Target $ 0 ± $5 $ 250K $ 250K

2.0 T+ 6 mo. $10 ± $5 $ 500K $ 500K

3.0 T+ 12 $25 ± $5 $ 1M $ 1M

4.0 T+18 $38 ± $5 $ 2.5M $ 2.5M

5.0 T+24 $50 ± $5 $ 5M $ 5M

GANTT Chart see http://www.mne.psu.edu/me415/resources/docs/gantt%20chart.pdf

CS SENIOR DESIGN CITIGROUP PROJECT

CS SENIOR DESIGN CITIGROUP PHASES

Software Requirements Process

Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype Requirements Management

Develop Use Cases• Focus on Goals

• Identify Actors

• Identify Main Tasks

Use Case Concept• Complete, orthogonal, externally

visible functionality

• Initiated by an actor

• Identifiable value to the actor

OrderingSystem

Customer

<<actor>>AccountSystem

<<actor>>Inventory

Shipping Clerk

ViewStatus

Create & Submit Orders

Role of Software Architect

Assures that the Requirements are valid- use Prototypes in Requirements Stage

Assures that Requirements are quantitative Defines Non Functional Requirements and

Software Trustworthiness. Defines 4+1 views Defines Components and Interface Structures

Kruchten’s “4 + 1”Model for Developing Software Architecture

View + 1 Business Scenarios:

CustomersAll Stakeholders

View 1

Logical:End Users

View 2

Process:System

Integrators

View 3

Physical:Engineers

View 4

Execution:Programmers

Role of Project Manager

Defines and documents Development Process Makes trade-offs among features, schedule,

development cost and quality Chairs Project Meetings Assigns and tracks action items Communicates to Project Members

Waterfall ModelSystem feasibility

Validation

Validation

Software plans &Requirements

Product design

Verification

Verification

Detailed design

Code

Unit test

Integration

Quality assurance

Implementation

Certification

Operations &maintenance Operation

al Reviews

Focus: Control

Emphasis: Documentation

Figure 2: Boehm’s Spiral Model of the Software Process

RqtsAnal.

Proto-Type 1

Concept ofOperation

Risk Analysis

Proto-Type 2

Proto-type 3

OperationalPrototype

Risk Analysis

Risk Analysis

Evaluate Alternatives:

Identify, Resolve Risks

RequirementsValidation

SoftwareRqts

Design Validationand Verification

SoftwareProductDesign

Implemen-tation

AcceptanceTest

Integra-tion & Test

UnitTest

Code

DetailedDesign

Develop & VerifyNext - Level Product

Integrationand Test

Develop-ment Plan

Rqts. PlanLife Cycle

Plan

Commitment

Partition

Plan NextPhases

Determines ObjectivesAlternatives, Constraints

Cumulative Cost

Progress through steps

Focus: Risk

Emphasis: Contingency Planning

Role of Software Developers

Designs Software Components Implements Software Documents with code commentary prefaces and

in-line narratives. Unit Tests Checks Interfaces

Development Plan-an evolving document

Name of Project (issue 1 due 6Nov) Purpose and MOV Team members & their roles, Feature Packages Gantt Chart Current Estimate Table QFD ICED-T

Making a System

ComputerHardware

Binary

Assembler

C Level

FORTRAN, ADA

4GL

JAVA

SOURCE LIBRARIES

DevelopmentComputer

EXECUTABLELIBRARIES

….

DEVELOPERS,PROGRAM ADMINISTRATORS

& SOFTWARE MANUFACTURERS

PRODUCT

…

ProductionComputer

Application

Middleware

UNIX

APPLICATIONDATA BASE

USERS

Source Library

Tools

BUILDING BLOCKS

Role of Testers

Restates requirements quantitatively and from a tester’s view

Creates test bed for developers Designs and executes:

• Scenario Tests from Use Cases• Integration Tests• Reliability Tests • Stress Tests

Factors Affecting ProductivityCirca 1975

• Competent Management• Quality of people• Level of testing before shipping• Consistency of requirements• Sophistication of programming tools• Modularity of design• Reasonableness of commitments

Development Cycle Circa 1970

Define Requirements

Design Programs, Data Base &

User Documentation

Code andTest Modules

IntegrationTest

SystemTest

InstallSoftware

Verify SystemOperation Live

Operation

TargetSite

Development Cycle for Multiple Sites Circa 1975-80

Define Requirements


User Documentation

Code andTest Modules

IntegrationTest

SystemTest

InstallSoftware


Operation

Site 1

Site Peculiar Tests

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

Define Requirements


User Documentation

Code andTest

Modules

IntegrationTest

SystemTest

InstallSoftware


OperationSite 1

Site Peculiar Tests

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

SoftwareManufactureControls & Builds

SoftwareManufactureBuilds and Ships

Development Cycle with Software Manufacturing Circa 1980-90

Define Requirements

Agile‘Test then Code’

Approach

Quality Assurance

InstallSoftware


OperationSite 1

InstallSoftware


OperationSite N

.

.

.

.

.

.

.

.

.

Daily SoftwareBuilds

SoftwareManufactureBuilds and Loads Server

Development Cycle with Software Manufacturing Circa 1990-2000

Agile Software Development

Agile methods Extreme programming Agile application development Software prototyping

Focus: Time-to-Market

Emphasis: Minimum Appropriate Process, a Humanistic Approach

Technologies used in agile development

.NET and J2EE Web Design Visual Basic Databases

An iterative development process

Define system deliverables

Integrate increment

Define system deliverables

Specify system increment

Build systemincrement

Validate increment

Validate systemDone?

No

Deliver systemYes

Advantages of incremental development

Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.

User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

Agile methods

Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods: Focus on the code rather than the design; Are based on an iterative approach to software development; Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements.

Agile methods are probably best suited to small/medium-sized business systems or PC products.

Principles of agile methods

Principle Description

Customer involvement The customer should be closely involved throughout the development process. Their role is provide and priorities new system requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and exploited. The team should be left to develop their own ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

Problems with agile methods

It can be difficult to keep the interest of customers who are involved in the process.

Team members may be unsuited to the intense involvement that characterises agile methods.

Prioritising changes can be difficult where there are multiple stakeholders.

Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to

iterative development.

Extreme programming

Perhaps the best-known and most widely used agile method.

Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only

accepted if tests run successfully.

The XP release cycle

Break downstories to tasks

Select userstories for this

releasePlan release

Releasesoftware

Evaluatesystem

Develop/integratetest software

Extreme programming practices

Iincremental planning Requirements are recorded on Story Cards and the Stories to beincluded in a release are determined by the time available andtheir relative priority. The developers break these s tories intodevelopment tasks .

Small Releases The minimal useful set of functionality that provides businessvalue is developed first. Releases of the system are frequent andincrementally add functionality to the first release.

Simple Design Enough design is carried out to meet the current requirementsand no more.

Test first development An automated unit test framework is used to write tests for a newpiece of functionality before that functionality itself isimplemented.

Refactoring All developers are expected to refactor the code continuously assoon as possible code improvements are found. This keeps thecode simple and maintainable.

Extreme programming practices

Pair Programming Developers work in pairs, checking each otherÕs work andproviding the support to always do a good job.

Collective Ownership The pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own all thecode. Anyone can change anything.

Continuous Integration As soon as work on a task is complete it is integrated into thewhole system. After any such integration, all the unit tests in thesystem must pass.

Sustainable pace Large amounts of over-time are not considered acceptable as thenet effect is often to reduce code quality and medium termproductivity

On-site Customer A representative of the end-user of the system (the Customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.

XP and agile principles

Incremental development is supported through small, frequent system releases.

Customer involvement means full-time customer engagement with the team.

People not process through pair programming, collective ownership and a process that avoids long working hours.

Change supported through regular system releases. Maintaining simplicity through constant refactoring of

code.

Testing in XP

Test-first development. Incremental test development from scenarios. User involvement in test development and

validation. Automated test harnesses are used to run all

component tests each time that a new release is built.

Pair programming

In XP, programmers work in pairs, sitting together to develop code.

This helps develop common ownership of code and spreads knowledge across the team.

It serves as an informal review process as each line of code is looked at by more than 1 person.

It encourages refactoring as the whole team can benefit from this.

Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

Agile Practices for Distributed Teams

Cohesive components with interface structures XP for small development teams Scrum as management structure Frequent builds Inter-team trust and work hour overlap Experienced staff Leverage collaborative tools – wikis, PM,…

Back-to-back testing

TTest data

Resultscomparator

System

prototypeApplication

system

Differencereport

Software Factory

DESIGNERS

- CODE- DOCUMENT- FIX BUGS

CONTROL PROGRAMS& PROCEDURES

SourceControl

ChangeManagement

TrackingSystem

SupportPrograms

SourceLib.

ChangeRequests

Doc.Library

ReleaseArchives

Build System

ShippingUtilities

BaseLibraries

Application

Files

Released ProductTo TestTeam

Reports

ModificationRequests

Released

Product

To SitesMiddleware, Tools and Operating System

Source Code Management

• Store, update and retrieve all versions • Manage code ownership• Control updating privileges• Identify accurate version of retrieved source• Track changes• Maintain build database, tools and machine

Purpose of Release Documents

• Describe features• Describe corrections to troubles• Cross reference software dependencies• Specify limitations or deficiencies• Provide special installation instructions and provide data conversion instructions• Specify training• Identify new, changed or deleted documents• Provide software source code• Maintain product lists

Software Change

Cultural Technical

Business

Innovation

&

Investment