Modern Software Engineering. Current State, Ugh (i) Some organizations are 10 (even 600) times more...
-
Upload
lewis-malone -
Category
Documents
-
view
213 -
download
0
Transcript of Modern Software Engineering. Current State, Ugh (i) Some organizations are 10 (even 600) times more...
Modern Software Engineering
Current State, Ugh (i)
Some organizations are 10 (even 600) times more productive than others(1)
Most Software Projects FailSome definitions for Failure:
Missed scheduleMissed functionalityMissed budgetToo fragile for usage demandsDefect 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
AnalysisAnalysis
DesignDesign
ImplementationImplementation
TestingTesting
MaintenanceMaintenancePostpones Confronting RiskLate Design Breakage
Can work on well-defined efforts
Can work in smaller effortsGreat 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 as the product is constructedWork occurs in “sprints” and is derived from a “backlog” of existing requirementsMeetings are very short and sometimes conducted without chairs“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 overheadProcess must be adaptable to both technical and business challenges to ensure best product producedProcess yields frequent increments that can be inspected, adjusted, tested, documented and built onDevelopment work and people performing it are partitioned into clean, low coupling partitionsTesting and documentation is performed as the product is builtAbility to declare the product done whenever required
Scrum - 1
Backlogprioritized list of requirements or features the provide business value to customer
items can be added at any time)
Sprintswork units required to achieve one of the backlog items
must fit into a predefined time-box
affected backlog items frozen
Scrum - 2
Scrum meetings15 minute daily meetingswhat was done since last meeting?what obstacles were encountered?what will be done by the next meeting?
Demosdeliver software increment to customer for evaluation
By Kevin Aguanno. (C) 2002 Element K Journals.
Feature 1
Feature 3
Feature 7
Feature 2
Feature 4
Feature 5
Feature 6
Grouped List of Features
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
Feature 7
Initial List of Features
Planning
Sprint #1
Sprint #2
Inte
gra
ted
Dem
on
stratio
n
Closure
Product Backlog
SCRUM Structure
SCRUM – Project Structure
(C) 2002 Kevin Aguanno.
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.
SCRUM – Management Controls
Text (C) 2002 Kevin Aguanno. Chart (C) 1997 Advanced Development Methods Inc.
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.
SCRUM – Management Controls
(C) 2002 Kevin Aguanno.
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.
SCRUM – Management Controls
A Solution
Feature-Driven DevelopmentClient-centricArchitecture-centricRepeatable processPragmatic, livable methodologyGreat for developersGreat for managersGreat for the application!
Feature Driven DevelopmentPractical 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• <action> the <result> <by | for | of | to> a(n) <object>
A features list is created and “plan by feature” is conductedDesign 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 modelcontains set of classes depicting business model of application to be built
Build features listfeatures extracted from domain model
features are categorized and prioritized
work is broken up into two week chunks
Plan by featurefeatures assessed based on priority, effort, technical issues, schedule dependencies
Feature Driven Design - 2
Design by featureclasses 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 featureclass 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
FDD #1Develop
anOverallModel
FDD #2 Build
aFeatures
List
FDD #3
Planby
Feature
FDD #4
Designby
Feature
5 Major Steps/Activities
FDD #5
Buildby
Feature
Requirements& Design
Design,SomeCode
Code,Initial
Testing
Test& Put
in Build
Sched.&
$$ Est.
Build
Promoteto
Build
Build
Promoteto
Build
Priorit
ized
Releas
es
#4#4
#1 & #2 are Reqt’s & Design throughModeling/Coding/ Prototyping to get it right#4 is very granular Detailed Design/Code
#5 is Detailed Code and Test in very,very granular
chunks of client-valued functionality
FDD & Typical SDLC Phases
AnalysisAnalysis
DesignDesign
ImplementationImplementation
TestingTesting
MaintenanceMaintenance
#1#1#2#2 #5#5
Reminder:
Why FDD #1 & #2 Processes’ Emphasis on Requirements & Design?
Studies have shown conclusively that it pays to do things right the first timeUnnecessary changes are expensiveTRW: 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 #1Develop
anOverallModel
FDD #2 Build
aFeatures
List
FDD #3
Planby
Feature
FDD #4
Designby
Feature
FDD #5
Buildby
Feature
An object model (more shape than content)
A categorized list of features
A Develop-ment Plan
FDD “Construction” Outputs
An object model (more shape than content)
FDD #1Develop
anOverallModel
FDD #2 Build
aFeatures
List
FDD #3
Planby
Feature
FDD #4
Designby
Feature
FDD #5
Buildby
Feature
A categorized list of features
A Develop-ment Plan
A design pack-age (sequences)(more content than shape)
A client-valued function
Dec 2001
Completion Percentage:
Completion Status:
Completed
Targeted Completion Month
Example:Feature Set:
Making Product Assess’ts – Work in Progress
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
Overall Status:
MY
Progress bar
Work in progress
Attention (ie, Behind)
Completed
MakingProduct
Assessments(14)
75%Not yet started
CP-1
FDD UML Extensions (iii)
Product Sale Management (PS)
InvoicingSales
(33)
Dec 2001
CP-1
Setting upProduct
Agreements(13)
Dec 2001
SellingProducts
(22)
Nov 2001
CP-1
ShippingProducts
(19)
Dec 2001
CP-1
10%
DeliveringProducts
(10)
Dec 2001
CP-3
30%
MakingProduct
Assessments(14)
Dec 2001
75%99% 3%
Customer A/C Mgmt (CA)
EvaluatingAccount
Applications(23)
Oct 2001
95%
LoggingAccount
Transactions(30)
Nov 2001
82%
OpeningNew
Accounts(11)
Oct 2001
100%
Inventory Mgmt (IM)
EstablishingStorage Units
(26)
Nov 2001
100%
MovingContent
(19)
Nov 2001
82%
CP-3
AcceptingMovementRequests
(18)
Nov 2001
97%
CP-3
KEY: Work In Progress Attention Completed Progress Bar Not Started
CP-2 CP-1
CP-2 CP-2 CP-2 CP-3
FDD Sample Feature Sets
FDD Plan View
FDD Feature View
FDD Weekly Summary
FDD Weekly Summary (ii)
Where/how does it fit into s/w development practicesIn modern software development methodologies, there is a large degree of iterative development.Productive modeling environments automatically synchronize source code and class diagramsThis implies that you take successive passes at the system, adding new information and capability along the way.
Fitting UML into Development
InceptionInception IterativeElaboration
IterativeElaboration
Iterative Construction
Iterative Construction TransitionTransition
The Utility of UML
Helps to promote standard communicationBut does not supplant human contact!
Class Diagrams are very useful
Sequence and Activity help with dynamics
Use CasesUseful 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)MS-RMS-R
<<major feature set>>
Cash Sale Management
Creating Cash Sales
Delivering Cash Sales
(2)
27%
Dec 1999
JKJK
<<major feature set>>
Product Sale Management
Selling Products
Shipping Products
Delivering Products
Accepting Payments
Ordering Products
Creating Orders
(6)
22%
Dec 1999
• These reflect UML extensionsmade in Together®
FDD UML Extensions (ii)
EdEd
<<feature set>>
Delivering Products
UseCase1
UseCase2
UseCase3
UseCase4
UseCase5
UseCase6
UseCase7
UseCase8
UseCase1
(8)
100%
Aug 1999
JonJon
<<feature set>>
Creating Orders
UseCase1(1)
%
DougDoug
<<feature set>>
Ordering Products
UseCase1
UseCase2
UseCase3
UseCase4
UseCase5
UseCase6
(16)
0%
Dec 2002
MikeMike
<<feature set>>
Shipping Products
UseCase1
UseCase2
UseCase3
UseCase4
(4)
22%
Jan 2000
MartyMarty
<<feature set>>
Selling Products
Calculate the Total of a Sale
Asses the Fulfillment Timeliness of a Sale
Feature1
Feature2
Feature3
Feature4
Feature5
Feature6
Feature7
Feature8
Feature9
Feature10
(12)
27%
Dec 1999
FreedyFreedy
<<feature set>>
Accepting Payments
Feature1
Feature2
(2)
22%
Jan 1999
Next level down (feature sets)
Chief Programmer
# Features % Complete(color too) Due Date
Overdue!