4.2 The Principles of Modern Software Management 63
4.2 The Principles of Modern Software Management 63
I haveusedsomeprovocativewords in my comments. My purposewas neither to endorsenor to refute specificallyDavis'sprinciples,but rather to exposemy biases and provoke thought. While I seetremendous merir in about half of the principles,the other half either needa changein priority or have beenobsolesced ,r.- t..h.rology. by
4.2
) n
t-
!
ls I'
Although the current sofrwaremanagement principlesdescribed Section4.1 evolved in from and improved on conventionaltechniqu.r, th.y still do not emphasize modthe ern principleson which this book is based. Building on Davis,sformar, hereare my rop 10 principles of modern soffware management.(The first five, which are the main themesof my definition of an iterative process,are summarizedin Figure4-1.) The principlesare in priority orde5 and the bold-faced italicized words are usedrhrouehout the book as shorthandfor theseexpandeddefinitions. 1. Base the processon an architecture-firstapproach. This requires that a demonstrable balancebe achievedamong the driving requiremenrs, the a.rchitecturally significant designdecisions, and the life-cyJe plans before the resources committed for full-scaledevelopment. are 2. Establish an iterative life-cycleprocess that confronrs risk early. 'sfith today'ssophisticated sofrwaresystems, is not possibleto definethe entire it problem, designthe entire soludon, build the sofrware,then test the end product in sequence. Instead,an iterativeprocess that refinesthe problem understanding, effectivesolution, and an effectiveplan over severaliteran ations encourages balanced treatment of all stakeholderobiectives. a Major risks must be addressed early ro increase predictabiliryand avoid expensive downstreamscrapand rework. 3. Tiansition designmethods to emphasizecomponent-baseddevelopment. Moving from a line-of-code mentalityro a component-based mentalityis necessary reducethe amount of human-generated to sourcecode and custom development. componentis a cohesive of preexistinglines of A set code, either in sourceor executablr: format, with a definedinterfaceand behavior. 4. Establisha change management environment The dynamics of iterative development,including concurrenrworkflorvs by different teams working on shared artifacts, necessitates objectivelv controlledbaselines.
----lT=:--
64
. Architecture firct ne Compo nt'b ased deveIoPment Chahge management Round-triP engineering
Planningand
F.)""''**,;-1.
Systemtest
element The risk management qualitY ' Performance' 6^pon.nt'based development The technologyelement |_} visualmodeling
I
The control element on m i tre Inffir'rcs, nds, processnstru entati I Round-triq engineering ts
process of 4-L. The top fiueprinciples a modern Ftcuna 5.EnhancechangefreedomthroughtoolsthatSupportround.tripengineerto necessary autois lng. Rouncl-trip engineering the environmentslrpport information in different formats (suchas mate and ,yn.hron[. engirieering ' designmodels' sourcecode''executablecode' requlrementsspecificatio.,s, automation of this bookkeeping,change Without substantial test cases). management'documentation,andtesting,itisdifficulttoreduceiteration is encouragedrather cycles to manageabletime frames in which change and iterativeprocess, in than avoided.ihnng. freedomis a necessity an an establishing integratedenvironmentis crucial'
element Theautomation
65
6. capture design artifacts in rigorous, model-based notation_ A modelbasedapproach (suchas UML) supportsthe evolution of semanticallyrich graphical and textual design norations. visual modeling with rigorous notations and a formal machine-processable languageprovides for far more objecive measures than the traditional approach of human review and inspection ad hoc design of representations paperdocuments. in 7. Instrument the processfor objective quality control and progressassessment. Life-cycleassessment the progressand the quality of all intermediof ate products must be integratedinto the process. The best assessment mechanismsare well-definedmeasures derived directly from the evolving engineering artifactsand integratedinto all activitiesand teams. 8. Use a demonstration-based approach to assessintermediate artifacts. Transitioning the'current state-of-the-producr artifacts(whetherthe artifact is an early prototype,a baseline architecture, a beracapability)into or an executable demonstration relevantscenarios of stimulates earlier convergence integration,a more tangibleunderstanding designtradeon of offs, and earlier elimination of architecturaldefects. 9. Plan intermediatereleases groupsof usagescenarios in with evofvrng levels of detail. It is essential that the softwaremanagement process drive toward early and continuous demonstrations within the operationalcontext of the system, namely its usecases. The evolution of project increments and generations must be commensurate with the current level of understanding the of requirementsand architecture.cohesive usagescenarios are then the primary mechanismfor organizing requirements,defining iteration content, assessing implementations, and organizingacceptance testing. 10. Establish a configurable proce.ss that is economicallyscalable.No single processis suitable for all software developments. pragmatic process A framework musr be configurableto a broad specrum of applications.The process must ensurethat there is economyof scaleand return on investment by exploiting commonprocess a spirit,exrensive process auromation! and common architecture patternsand components. My top 10 principleshaveno scientific basis.They do, however,caprurea balancedview of the recurringthemes presented throughoutthis book. Tabie4-1 maps what I consider be the top 10 risksof the convenrional to process the key attributes to and principlesof a modernprocess. Although the table containsgrossgeneralities, at a high levelit providesan introductionto the principles a modernprocess. of
56
Tnsrr4-l.ModernprocessapproachesforsoluingconuentionalProblems
CONVENTIONAL PROCESS: TOP 10 RISKS 1. Late breakage and scrap/rework excessive TMPACT Quality, cos[, schedule INHERENT RISK MODERN PROCESS: RESOLUTIONFEATURES Architecture-6rst apProach Iterative development Automated change management Risk-confronting process 2. Attrition of keY Personnel Quality, cost, schedule early iterations Successful, Trustworthy managementand planning Environments as first-classartifacts of the process Industrial-strength, integrated environments Model-based engineeringartifacts Round-trip engineering 4. Adversarialstakeholders Cost, schedule Cost, schedule Cost, schedule Demonstration-basedrevtew requirements/testing Use-case-oriented
3. InadequatedeveloPment resources
Cost, schedule
paraiysis 7. Analysis
8. [nadequate performance
Schedule
Quality
9. Overemphasison artifacts
Schedule
Quality
4.3
have moved away from the conventional Modern sofrware developmentprocesses on is process dependent comof the development waterfallmodel,in which eachstage variations' modern approachesgenpletion of the previousstage.Althlugh there are early in the erally require thar an initi;l version of ,tt. systembe rapidly constructed