Software Engineering

Download Report

Transcript Software Engineering

Modern Software Engineering

Current State, Ugh (i)

Some organizations are 10 (even 600) times more productive than others (1) Most Software Projects Fail Some definitions for Failure: Missed schedule Missed functionality Missed budget Too fragile for usage demands Defect rates too high once in production (1) Steve McConnell,

After the Gold Rush.

Redmond, WA. Microsoft Press, 1999.

Ugh (ii)

In 1995, only 16% of software projects were expected to finish on time and on budget.

(1) Projects completed by the largest US organizations have only 42% of originally proposed functions.

(1) An estimated 53% of projects will cost nearly 190% of their original estimates.

(1) In large companies, only 9% of projects will be completed on time and on budget.

(1) (1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.

Ugh (iii) Canceled projects—$81 billion loss to US in 1995

(1)

Average MIS—1 year late, 100% over budget

(2) (1) Standish Group International Report, “Chaos”, as reported in March ‘95 Open Computing. Copyright 1995 SPC.

(2) Capers Jones,

Applied Software Measurement

, McGraw-Hill, 1991.

The Venerable Waterfall Process

Postpones Confronting Risk Late Design Breakage Testing Maintenance Implementation Analysis Design Can work on well-defined efforts Can work in smaller efforts Great for reporting apparent progress

SCRUM

Scrum

Scrum – an activity that occurs during a rugby match.

Scrum—distinguishing features Development work is partitioned into “ packets ” Testing and documentation are on-going is constructed as the product Work occurs in “ sprints ” and is derived from a “ backlog ” of existing requirements Meetings are very short without chairs and sometimes conducted “ demos ” are delivered to the customer with the time box allocated Scrum incorporates a set of process patterns that emphasize project priorities, compartmentalized work units, communication, and frequent customer feedback.

Scrum Principles

Small working teams used to maximize communication and minimize overhead Process must be adaptable to both technical and business challenges to ensure best product produced Process yields frequent increments that can be inspected, adjusted, tested, documented and built on Development work and people performing it are partitioned into clean, low coupling partitions Testing and documentation is performed as the product is built Ability to declare the product done whenever required

Scrum - 1

Backlog prioritized list of requirements or features the provide business value to customer items can be added at any time) Sprints work units required to achieve one of the backlog items must fit into a predefined time-box affected backlog items frozen

Scrum - 2 Scrum meetings

15 minute daily meetings what was done since last meeting?

what obstacles were encountered?

what will be done by the next meeting?

Demos

deliver software increment to customer for evaluation

SCRUM – Project Structure

SCRUM Structure Initial List of Features

Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature 7

Planning Grouped List of Features

Feature 1 Feature 3 Feature 7

Sprint #1

Feature 2 Feature 4 Feature 5

Sprint #2

Feature 6

Product Backlog Closure

By Kevin Aguanno. (C) 2002 Element K Journals.

SCRUM – Management Controls

SCRUM projects are not "Out of Control" and, in fact, have several good management and control elements:

Daily SCRUM Meeting.

This is a daily meeting attended by all team members for a Sprint. The call is generally very brief (15 mins.), the purpose of which is to update the project manager and other team members on progress and to raise any issues that the project manager or other team members can assist with. Three questions are answered by each participant:    What did I do in the last 24 hours? What do plan to do in the next 24 hours? What obstacles are standing in my way?

Visible Progress Demonstration.

At the end of each Sprint, the customer and all project team members get to see a visual demonstration of progress to date. Customer feedback can be obtained early in the process this way, and avoid costly changes late in the project lifecycle. Overall project progress is very visible and very easy to track in this way via a function/feature checklist, function points, or other similar means.

(C) 2002 Kevin Aguanno.

SCRUM – Management Controls

Sprint Burndown Charts.

During a Sprint, the team provides an updated estimate on the number of hours/days to complete their work during the daily SCRUM meetings. The project manager can use this data to build a Sprint Burndown Chart showing the progress within a Sprint. The total projected number of hours for a Sprint usually increases in the early days of the Sprint as nuances and additional work are uncovered, but then rapidly decline as work gets underway.

Text (C) 2002 Kevin Aguanno. Chart (C) 1997 Advanced Development Methods Inc.

SCRUM – Management Controls

Accelerated Customer Approval.

Because the customer reviews visible deliverables at the end of each Sprint and provides feedback at that time, coupled with the fact that subsequent Sprints build upon the work of earlier Sprints, the final output should not contain any surprises to the customer and will already include the bulk of his feedback. This should allow for a faster final customer approval/acceptance of the deliverables.

(C) 2002 Kevin Aguanno.

A Solution Feature-Driven Development

Client-centric Architecture-centric Repeatable process Pragmatic, livable methodology Great for developers Great for managers Great for the application!

Feature Driven Development

Practical process model for OO SW engineering.

Applicable to moderate sized and larger SW projects.

FDD—distinguishing features Emphasis is on defining “features” • a

feature

“is a client-valued function that can be implemented in two weeks or less.” Uses a feature template • the a(n) A features list is created and “ plan by feature ” is conducted Design and construction merge in FDD FDD puts a greater emphasis on project management guidelines and techniques than many other agile methods.

Defines 6 milestones during the design and implementation of a feature design walkthrough, design, design inspection, code, code inspection, promote to build.

Feature Driven Philosophy

Emphasizes collaboration among team members Manages problem and project complexity using feature based decomposition followed integration of software increments Technical communication using verbal, graphical, and textual means Software quality encouraged by using incremental development, design and code inspections, SQA audits, metric collection, and use of patterns (analysis, design, construction)

Feature Driven Design - 1

Develop overall model contains set of classes depicting business model of application to be built Build features list features extracted from domain model features are categorized and prioritized work is broken up into two week chunks Plan by feature features assessed based on priority, effort, technical issues, schedule dependencies

Feature Driven Design - 2

Design by feature classes relevant to feature are chosen class and method prologs are written preliminary design detail developed owner assigned to each class owner responsible for maintaining design document for his or her own work packages Build by feature class owner translates design into source code and performs unit testing integration performed by chief programmer

Why the FDD Process?

To enable and enforce

the

repeatable

delivery of

working

software in a

timely

manner with highly

accurate

and meaningful

reporting

to all key

stakeholders

inside and outside a project.

The FDD Process in Brief 5 Major Steps/Activities

FDD #1 Develop an Overall Model FDD #2 Build a Features List FDD #3 Plan by Feature FDD #4 Design by Feature FDD #5 Build by Feature Requirements & Design Sched.

& $$ Est.

Design, Some Code Code, Initial Testing Build Promote to Build Test & Put in Build

FDD & Typical SDLC Phases

#1 #1 & #2 are Reqt’s & Design through Modeling/Coding/ Prototyping to get it right #4 is very granular Detailed Design/Code #4 Implementation Testing Maintenance #2 #5 Design Analysis #5 is Detailed Code and Test in very,very granular chunks of client-valued functionality

Reminder:

Why FDD #1 & #2 Processes’ Emphasis on Requirements & Design?

Studies have shown conclusively that it pays to do things right the first time Unnecessary changes are expensive TRW: a change in requirements-analysis cost 50-200 times less than same change later in the cycle (construction-maintenance).

Boehm, Parpaccio 1988

IBM: removing an error by the start of design, code or unit test allows rework to be done 10-100 times less expensively than during unit test or functional test.

Fagan 1976

FDD “Engineering” Outputs

FDD #1 Develop an Overall Model FDD #2 Build a Features List FDD #3 Plan by Feature An object model (more shape than content) A categorized list of features A Develop ment Plan FDD #4 Design by Feature FDD #5 Build by Feature

FDD “Construction” Outputs

FDD #1 Develop an Overall Model FDD #2 Build a Features List FDD #3 Plan by Feature FDD #4 Design by Feature FDD #5 Build by Feature An object model (more shape than content) A categorized list of features A Develop ment Plan A design pack age (sequences) (more content than shape) A client valued function

FDD UML Extensions (iii)

Overall Status:

Work in progress Attention (

ie

, Behind) Completed Not yet started

Completion Percentage:

Progress bar

Completion Status:

Completed MY Targeted Completion Month CP-1 Making Product Assessments (14)

Example:

Feature Set: Making Product Assess’ts – Work in Progress 75% Dec 2001

CP-1

is the Chief Programmer’s initials

(14)

there are fourteen features that make up this feature set

75%

Feature Set is 75% complete Target is to complete in

Dec 2001

FDD Sample Feature Sets

CP-1

Selling Products (22) 99%

Nov 2001 CP-1

Shipping Products (19) 10%

Dec 2001

Product Sale Management (PS)

CP-3

Delivering Products (10)

CP-1

Invoicing Sales (33)

CP-2

Setting up Product Agreements (13) 30%

Dec 2001

3%

Dec 2001 Dec 2001 CP-1

Making Product Assessments (14) 75%

Dec 2001

Customer A/C Mgmt (CA)

CP-2

Evaluating Account Applications (23)

CP-2

Opening New Accounts (11)

CP-2

Logging Account Transactions (30) 95%

Oct 2001

100%

Oct 2001

82%

Nov 2001

KEY: Work In Progress Attention

CP-3

Establishing Storage Units (26) Inventory Mgmt (IM)

CP-3

Accepting Movement Requests (18)

CP-3

Moving Content (19) 100%

Nov 2001

97%

Nov 2001

82%

Nov 2001

Completed Progress Bar Not Started

FDD Plan View

FDD Feature View

FDD Weekly Summary

FDD Weekly Summary (ii)

Fitting UML into Development

Where/how does it fit into s/w development practices In modern software development methodologies, there is a large degree of iterative development.

Productive modeling environments automatically synchronize source code and class diagrams This implies that you take successive passes at the system, adding new information and capability along the way.

Inception Iterative Elaboration Iterative Construction Transition

The Utility of UML

Helps to promote standard communication But does not supplant human contact!

Class Diagrams are very useful Sequence and Activity help with dynamics Use Cases Useful if your organization has meaningful way to apply them—no silver bullet Can be replaced by other means of capturing features/requirements

FDD UML Extensions Report progress to management and clients Very high level (major feature sets)

<>

Product Sale Management Selling Products Shipping Products Delivering Products Accepting Payments Ordering Products Creating Orders

(6) 22% Dec 1999 <>

Cash Sale Management Creating Cash Sales Delivering Cash Sales

(2) 27% Dec 1999 • These reflect UML extensions made in Together®

FDD UML Extensions (ii)

Chief Programmer

Next level down (feature sets)

Feature1 Feature2 Feature3 Feature4 Feature5 Feature6 <>

Selling Products

UseCase2 (16) 0% UseCase3 <>

Shipping Products

<>

Delivering Products

Dec 1999 # Features UseCase1 (4) UseCase2 22% UseCase3 Overdue!

<>

Accepting Payments

UseCase1 UseCase2 (color too) UseCase5 UseCase6 UseCase7 UseCase8 UseCase1 <>

Creating Orders

Feature1 Feature2 (2) 22% UseCase1(1) % (8) 100% Due Date Jan 1999 UseCase5 UseCase6