VIEWS: 10 PAGES: 28 POSTED ON: 10/2/2011
Successful Software Management Style: steering and Balance By: Walker Royce Presentation by: Sergey Melderis and Brian Merritt Who is Walker Royce? • Walker Royce is vice president of IBM’s Worldwide Rational Services Organization • Working in software development for 16 years • Active project manager for 7 years • Also a principal contributor to the management philosophy inherent in Rational’s Unified Process Overview of his paper • Is software development a rigorous engineering process? • Royce compares software development with a movie production • An iterative approach to software development • Four patterns for successful steering • Economic benefits of a leadership style According to Royce • No, software development is not a rigorous engineering process – No laws of physics to constrain the problems or solutions – Almost anything can be changed during a software project • Plans, people, funding, etcetera – Economic performance has proven to be the best measure for software success • Royce describes software management as a discipline of software economics rather than software engineering • This is based on the decisions of a software manager: – Cost trade-offs – Human factors – Market strength – Timing • He recommends using a steering leadership style Steering leadership style • Comprised of: – Active management involvement – Frequent course correction • Royce advocates that this styles is better than the traditional project management approaches • This is known as an iterative development method IBM Rational Unified Process • An accepted benchmark of modern iterative development process • It’s life cycle has four phases – Inception – Elaboration – Construction – Transition • Each phase is a project state, not a sequential-activity-based progression Iterative management style • Results-rather than activity-based – Real results are executable programs – Everything developed, requirement documentation, use case models, plans, etcetera, is just a way to get to the final result • In a movie production – Real result is motion picture on a screen – Scripts, storyboards, set mockups, costume designs, etcetera is not tangible enough to judge its effect until you commit it to film Precision vs. Accuracy • Software managers must accurately forecast estimates, risks, and the effects of change • Unjustified precision in requirements or plans is a recurring obstacle Four patterns for successful steering • Scope management • Process rigor • Progress honesty • Quality control Scope Management • Conventional life cycle is usually presented as a sequential thread of activities: requirements, analysis, design, code, test, delivery • Successful projects implement this, however, the boundaries are not strictly defined or enforced • They don’t use “requirements” Requirements • The most misused word in our industry • Required means nonnegotiable, but in every successful project we see changed, negotiated requirements • Use word specification instead • Specifications are changeable and are understood as the current state of our understanding Form of user specification • Vision statement captures the contrast between the development group and user. (text, mockups, use cases) • Evaluation criteria - glimpses of objectives for a given intermediate lifecycle checkpoint like a demo of some sort Process rigor • More rigorous processes are appropriate when – the teams are distributed – many stakeholders are involved – the quality specifications are extreme – the constraints are externally imposed – the project is later in the lifecycle phases. • Process rigor should act like gravity Process Rigor (cont.) • Successful software development processes show well-defined transitions in all phases • Software projects fail because of the lack of emphasis on process rigor • Another reason software projects fail is – Over-engineering early in the life-cycle – Under-engineering during the production phase Progress Honesty • Stakeholder relationships deteriorate during the classical development process • Trust is essential • Using a more iterative model coupled with communication will allow everyone to focus on the project rather than the contract • Must deliver value but in a profitable way Iterative process • The transition to a demonstration-driven life cycle results in a very different project profile • Instead of a linear progression, which was said to be dishonest, an honest sequence of developments will promote a healthy project More on progress honesty • There shouldn’t be a negative reaction if flaws are found during the early life cycle demonstrations • Initial deliveries will not perform like a final delivery • Must provide honest indicators of progress Quality Control • Completing early testing can help resolve architectural issues at the beginning of the life cycle • Can also serve as a way for continuous progress and performance • Using an iterative development will allow integration testing to come before component testing Testing and testers • Conventional approach – Testers come up with plans, procedures, and papers that work under the analysis and design artifacts – They do not predict project success • Iterative approach – Testers responsible for effective “analysis” activities and results Documentation problems • Testers use a documentation driven approach by developing – System-test-plan documents – System-test-procedure documents – Integration-test-plan documents – To name a few.. • This can lead into problems: – Rework – Scrapping parts of the project to start over Testing defined • The author defines testing as – “the explicit evaluation by executing some set of components under a controlled scenario with an expected and objective outcome” Economic benefits of a leadership style • Three projects profiles were measured in executable (testable) code completed • Modern • Conventionally • Future How did they do? Conventional • Sequence of conventional project – Early success on paper – Code commitment late in the life cycle – Unforeseen implementation issues – Heavy budget and schedule pressure – Late fixes – Unmaintainable product that was delivered late Modern • Provided a progression of demonstrable releases – Avoided late patches – Robust and maintainable product delivered Little statistics from Royce • Conventional – Still the norm, about half of the projects today resemble this • Modern profile – About 1 in 4 projects today The End • Questions? • Comments?
Pages to are hidden for
"Successful Software Management Style steering and Balance By "Please download to view full document