Академический Документы
Профессиональный Документы
Культура Документы
In the past ten years, typical goals in the software process improvement of several companies are to achieve a 2x, 3x, or 10x increase in productivity, quality, time to market, or some combination of all three, where x corresponds to how well the company does now. The funny thing is that many of these organizations have no idea what x is, in objective terms.
"Software Project Management" Walker Royce 2/112
3/112
4/112
Reducing Software Product Size Improving Software Processes Improving Team Effectiveness Improving Automation through Software Environments Achieving Required Quality Peer Inspections: A Pragmatic View The Principles of Conventional Software Engineering The Principles of Modern Software Management Transitioning to an Iterative Process
"Software Project Management" Walker Royce 5/112
6/112
Part 1
The almost anything characteristic has made it difficult to plan, monitor, and control software development.
7/112
Drawbacks
Protracted integration and late design breakage Late risk resolution Requirements - driven functional decomposition Adversarial stakeholder relationships Focus on document and review meetings
2.
3.
4.
5.
6.
7.
8. 9.
Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. You can compress software development schedules 25% of nominal, but no more. For every $1 you spend on development, you will spend $2 on maintenance. Software development and maintenance costs are primarily a function of the number of source lines of code. Variations among people account for the biggest differences in software productivity. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15. Only about 15% of software development effort is devoted to programming. Walkthroughs catch 60% of the errors. 80% of the contribution comes from 20% of contributors.
9/112
10/112
Part 1
Evolution of Software Economics
Most software cost models can be abstracted into a function of five basic parameters:
Size (typically, number of source instructions) Process (the ability of the process to avoid non-valueadding activities) Personnel (their experience with the computer science issues and the applications domain issues of the project) Environment (tools and techniques available to support efficient software development and to automate process) Quality (performance, reliability, adaptability)
11/112
Part 1
Evolution of Software Economics
Three generations of software economics
Cost
Software size
1960s-1970s Waterfall model Functional design Diseconomy of scale Environments/tools: Custom Size: 100% custom Process: Ad hoc 1980s-1990s Process improvement Encapsulation-based Diseconomy of scale Environments/tools: Off-the-shelf, separate Size: 30%component-based, 70% custom Process: Repeatable 2000 and on Iterative development Component- based Return to investment Environments/tools: Off-the-shelf, integrated Size: 70%component-based, 30% custom Process: Managed/measured
12/112
Part 1
Evolution of Software Economics
The predominant cost estimation process
Software manager, software architecture manager, software development manager, software assessment manager
13/112
Part 1
Evolution of Software Economics
Pragmatic software cost estimation
15/112
Part 1
Improving Software Economics
Important trends in improving software economics Cost model parameters
Size Abstraction and component based development technologies
Trends
Higher order languages (C++, Java, Visual Basic, etc.) Object-oriented (Analysis, design, programming) Reuse Commercial components Iterative development Process maturity models Architecture-first development Acquisition reform Training and personnel skill development Teamwork Win-win cultures
Integrated tools (Visual modeling, compiler, editor, etc) Environment Open systems Automation technologies and tools Hardware platform performance Automation of coding, documents, testing, analyses Hardware platform performance Quality Demonstration-based assessment "Software Project Management" 16/112 V1 Performance, reliability, accuracy Statistical quality control Walker Royce
Part 1
Improving Software Economics
Reducing Software Product Size
The most significant way to improve affordability and return on investment is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material.
Reuse, object-oriented technology, automatic code production, and higher order programming languages are all focused on achieving a given system with fewer lines of human-specified source directives.
17/112
Part 1
Improving Software Economics
Reducing Software Product Size - Languages
Language
UFP -Universal Function Points The basic units of the function points are external user inputs, external outputs, internal logic data groups, external data interfaces, and external inquiries.
18/112
Part 1
Improving Software Economics
Reducing Software Product Size Object-Oriented Methods
An object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved.
Here is an example of how object-oriented technology permits corresponding improvements in teamwork and interpersonal communications.
The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort.
This aspect of object-oriented technology enables an architecture-first process, in which integration is an early and continuous life-cycle activity.
An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture.
This feature of object-oriented technology is crucial to the supporting languages and environments available to implement object-oriented architectures.
19/112
Part 1
Improving Software Economics
Reducing Software Product Size Reuse
1 Project Solution: $N and M months
Many-project solution: Operating with high value per unit investment, typical of commercial products
20/112
Part 1
Improving Software Economics
Reducing Software Product Size Commercial Components
APPROACH
ADVANTAGES
Predictable license costs Broadly used, mature technology Available now Dedicated support organization Hardware/software independence Rich in functionality
DISADVANTAGES
Frequent upgrades Up-front license fees Recurring maintenance fees Dependency on vendor Run-time efficiency sacrifices Functionality constraints Integration not always trivial No control over upgrades and maintenance Unnecessary features that consume extra resources Often inadequate reliability and stability Multiple-vendor incompatibility
Commercial components
Custom development
Complete change freedom Smaller, often simpler implementations Often better performance Control of development and enhancement
Expensive, unpredictable development Unpredictable availability date Undefined maintenance model Often immature and fragile Single-platform dependency Drain on expert resources
21/112
Part 1
Improving Software Economics
Improving Software Processes
Attributes
Subject Objectives
Metaprocess
Line of business Line-of-business profitability Competitiveness
Macroprocess
Project Project profitability Risk management Project budget, schedule, quality Software project managers Software engineers On budget, on schedule Major milestone success Project scrap and rework Quality vs. financial performance 1 to many years
Microprocess
Iteration Resource management Risk resolution Milestone budget, schedule, quality Subproject managers Software engineers On budget, on schedule Major milestone progress Release/iteration scrap and rework Content vs. schedule 1 to 6 months
Audience
Acquisition authorities, customers Organizational management Project predictability Revenue, market share
Metrics
23/112
Part 1
Improving Software Economics
Improving Team Effectiveness (1)
The principle of top talent: Use better and fewer people. The principle of job matching: Fit the task to the skills an motivation of the people available. The principle of career progression: An organization does best in the long run by helping its people to selfactualize. The principle of team balance: Select people who will complement and harmonize with one another. The principle of phase-out: Keeping a misfit on the team doesnt benefit anyone.
24/112
Part 1
Improving Software Economics
Improving Team Effectiveness (2)
Important Project Manager Skills: Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve. Customer-interface skill. Avoiding adversarial relationships among stakeholders is a prerequisite for success. Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition. Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction. Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy.
25/112
Part 1
Improving Software Economics
Achieving Required Quality
Key practices that improve overall software quality: Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on a balance between requirements evolution, design evolution, and plan evolution Using metrics and indicators to measure the progress and quality of an architecture as it evolves from a high-level prototype into a fully compliant product Providing integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automation Using visual modeling and higher level language that support architectural control, abstraction, reliable programming, reuse, and self-documentation Early and continuous insight into performance issues through demonstration-based evaluations
"Software Project Management" Walker Royce 26/112
27/112
Part 1
The Old Way and the New
The Principles of Conventional Software Engineering
1. 2. 3. 4. 5. 6. 7. Make quality #1. Quality must be quantified and mechanism put into place to motivate its achievement. High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people. Give products to customers early. No matter how hard you try to learn users needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it. Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and dont be blinded by the obvious solution. Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an architecture simply because it was used in the requirements specification. Use an appropriate process model. Each project must select a process that makes the most sense for that project on the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to which requirements are well understood. Use different languages for different phases. Our industrys eternal thirst for simple solutions to complex problems has driven many to declare that the best development method is one that uses the same notation through-out the life cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these phases? Minimize intellectual distance. To minimize intellectual distance, the softwares structure should be as close as possible to the real-world structure. Put techniques before tools. An undisciplined software engineer with a tool becomes a dangerous, undisciplined software engineer. Get it right before you make it faster. It is far easier to make a working program run than it is to make a fast program work. Dont worry about optimization during initial coding.
8. 9. 10.
28/112
Part 1
The Old Way and the New
The Principles of Conventional Software Engineering
11. 12. 13. 14. Inspect code. Inspecting the detailed design and code is a much better way to find errors than testing. Good management is more important than good technology. The best technology will not compensate for poor management, and a good manager can produce great results even with meager resources. Good management motivates people to do their best, but there are no universal right styles of management. People are the key to success. Highly skilled people with appropriate experience, talent, and training are key. The right people with insufficient tools, languages, and process will succeed. The wrong people with appropriate tools, languages, and process will probably fail. Follow with care. Just because everybody is doing something does not make it right for you. It may be right, but you must carefully assess its applicability to your environment. Object orientation, measurement, reuse, process improvement, CASE, prototyping-all these might increase quality, decrease cost, and increase user satisfaction. The potential of such techniques is often oversold, and benefits are by no means guaranteed or universal. Take responsibility. When a bridge collapses we ask, what did the engineers do wrong? Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the best methods can be used to produce awful designs, and the most antiquated methods to produce elegant design. Understand the customers priorities. It is possible the customer would tolerate 90% of the functionality delivered late if they could have 10% of it on time. The more they see, the more they need. The more functionality (or performance) you provide a user, the more functionality (or performance) the user wants. Plan to throw one away .One of the most important critical success factors is whether or not a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms rarely work the first time. Design for change. The architectures, components, and specification techniques you use must accommodate change. Design without documentation is not design. I have often heard software engineers say, I have finished the design. All that is left is the documentation.
29/112
Part 1
The Old Way and the New
The Principles of Conventional Software Engineering
21. 22. 23. 24. 25. 26. 27. 28. 29. 30. Use tools, but be realistic. Software tools make their users more efficient. Avoid tricks. Many programmers love to create programs with tricks- constructs that perform a function correctly, but in an obscure way. Show the world how smart you are by avoiding tricky code. Encapsulate. Information-hiding is a simple, proven concept that results in software that is easier to test and much easier to maintain. Use coupling and cohesion. Coupling and cohesion are the best ways to measure softwares inherent maintainability and adaptability. Use the McCabe complexity measure. Although there are many metrics available to report the inherent complexity of software, none is as intuitive and easy to use as Tom McCabes. Dont test your own software. Software developers should never be the primary testers of their own software. Analyze causes for errors. It is far more cost-effective to reduce the effect of an error by preventing it than it is to find and fix it. One way to do this is to analyze the causes of errors as they are detected. Realize that softwares entropy increases. Any software system that undergoes continuous change will grow in complexity and become more and more disorganized. People and time are not interchangeable. Measuring a project solely by person-months makes little sense. Expert excellence. Your employees will do much better if you have high expectations for them.
30/112
Part 1
The Old Way and the New
The Principles of Modern Software Management
Architecture-first approach
Part 2
A Software Management Process Framework
32/112
Part 2
A Software Management Process Framework
Table of Contents (1)
Life-Cycle Phases
Engineering and Production Stages Inception Phase Elaboration Phase Construction Phase Transition Phase The Artifact Sets Management Artifacts Engineering Artifacts Pragmatic Artifacts
"Software Project Management" Walker Royce 33/112
Part 2
A Software Management Process Framework
Table of Contents (2)
PRODUCTION STAGE EMPHASIS Cost Product release baselines Implementation, testing Testing Exploiting economics of scale Operations
35/112
Engineering Stage
Inception Elaboration
Production Stage
Construction Transition
Idea
Architecture
Beta Releases
Products
36/112
Overriding goal to achieve concurrence among stakeholders on the life-cycle objectives Essential activities :
Formulating the scope of the project (capturing the requirements and operational concept in an information repository) Synthesizing the architecture (design trade-offs, problem space ambiguities, and available solutionspace assets are evaluated) Planning and preparing a business case (alternatives for risk management, iteration planes, and cost/schedule/profitability trade-offs are evaluated)
37/112
During the elaboration phase, an executable architecture prototype is built Essential activities :
Elaborating the vision (establishing a high-fidelity understanding of the critical use cases that drive architectural or planning decisions) Elaborating the process and infrastructure (establishing the construction process, the tools and process automation support) Elaborating the architecture and selecting components (lessons learned from these activities may result in redesign of the architecture)
38/112
During the construction phase : All remaining components and application features are integrated into the application All features are thoroughly tested Essential activities :
Resource management, control, and process optimization Complete component development and testing against evaluation criteria Assessment of the product releases against acceptance criteria of the vision
39/112
The transition phase is entered when baseline is mature enough to be deployed in the end-user domain This phase could include beta testing, conversion of operational databases, and training of users and maintainers Essential activities :
Synchronization and integration of concurrent construction into consistent deployment baselines Deployment-specific engineering (commercial packaging and production, field personnel training) 1. Assessment of deployment baselines against the complete vision and acceptance criteria in the requirements set
"Software Project Management" Walker Royce 40/112
Part 2
Life-Cycle Phases
Evaluation Criteria : Is the user satisfied? Are actual resource expenditures versus planned expenditures acceptable?
Each of the four phases consists of one or more iterations in which some technical capability is produced in demonstrable form and assessed against a set of the criteria The transition from one phase to the nest maps more to a significant business decision than to the completion of specific software activity.
41/112
Part 2
Artifacts of the Process
Requirements Set
1.Vision document 2.Requirements model(s)
Design Set
Implementation Set
1.Source code baselines 2.Associated compile-time files 3.Component executables
Deployment Set
1.Integrated product executable baselines 2.Associated run-time files 3.User manual
Operational Artifacts
5.Release descriptions 6.Status assessments 7.Software change order database 8.Deployment documents 9.Enviorement "Software Project Management" Walker Royce 42/112
Part 2
Artifacts of the Process
Management Artifacts
43/112
Part 2
Artifacts of the Process
Management Artifacts Release Specifications
Typical release specification outline : I. II. Iteration content Measurable objectives A. Evaluation criteria B. Follow-through approach III. Demonstration plan A. Schedule of activities B. Team responsibilities IV. Operational scenarios (use cases demonstrated) A. Demonstration procedures B. Traceability to vision and business case
Two important forms of requirements : vision statement (or user need) - which captures the contract between the development group and the buyer. evaluation criteria defined as management-oriented requirements, which may be represented by use cases, use case realizations or structured text representations.
"Software Project Management" Walker Royce 44/112
Part 2
Artifacts of the Process
Management Artifacts Software Development Plan the defining document for the projects
process. It must comply with the contract, comply with the organization standards, evolve along with the design and requirements.
Part 2
Artifacts of the Process
Engineering Artifacts
46/112
Part 2
Artifacts of the Process
Engineering Artifacts
Typical architecture description outline :
I. Architecture overview A. Objectives B. Constraints C. Freedoms Architecture views A. Design view B. Process view C. Component view D. Deployment view III. Architectural interactions A. Operational concept under primary scenarios B. Operational concept under secondary scenarios C. Operational concept under anomalous scenarios Architecture performance Rationale, trade-offs, and other substantiation
II.
IV. IV.
usage procedures and guidance, operational constraints, and a user interface description. It should be written by members of the test team, who are more likely to understand the users perspective than the development team. It also provides a necessary basis for test plans and test cases, and for construction of automated test suites.
"Software Project Management" Walker Royce 47/112
Part 2
Artifacts of the Process
Pragmatic Artifacts
Over the past 30 years, the quality of documents become more important than the quality of the engineering information they represented.
48/112
Part 2
Model-Based Software Architectures
A Management Perspective
49/112
Part 2
Model-Based Software Architectures
A Management Perspective
Part 2
Model-Based Software Architectures
A Technical Perspective
The model which draws on the foundation of architecture developed at Rational Software Corporation and particularly on Philippe Kruchtens concepts of software architecture :
An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, and behaviors.
Design View
Process View
Component View
Deployment View
51/112
Part 2
Model-Based Software Architectures
A Technical Perspective
The use case view describes how the systems critical use cases are realized by elements of the design model. It is modeled statically using case diagrams, and dynamically using any of the UML behavioral diagrams.
The design view addresses the basic structure and the functionality
of the solution. The process view addresses the run-time collaboration issues involved in executing the architecture on a distributed deployment model, including the logical software network topology, interprocess communication and state management. The component view describes the architecturally significant elements of the implementation set and addresses the software source code realization of the system from perspective of the project's integrators and developers. The deployment view addresses the executable realization of the system, including the allocation of logical processes in the distribution view to physical resources of the deployment network.
"Software Project Management" Walker Royce 52/112
Part 2
Workflows of the Process
Software Process Workflows The term workflow is used to mean a thread of cohesive and most sequential activities.
There are seven top-level workflows: 1. Management workflow: controlling the process and ensuring win conditions for all stakeholders 2. Environment workflow: automating the process and evolving the maintenance environment 3. Requirements workflow: analyzing the problem space and evolving the requirements artifacts 4. Design workflow: modeling the solution and evolving the architecture and design artifacts 5. Implementation workflow: programming the components and evolving the implementation and deployment artifacts 6. Assessment workflow: assessing the trends in process and product quality 7. Deployment workflow: transitioning the end products to the user
"Software Project Management" Walker Royce 53/112
Part 2
Workflows of the Process
Software Process Workflows
Part 2
Workflows of the Process
Iteration Workflows
An iteration consist of sequential set of activities in various proportions, depending on where the iteration is located in the development cycle.
An individual iterations workflow: Allocated usage scenarios Results from the Previous iteration
Part 2
Workflows of the Process
Iteration Workflows
Inception and Elaboration Phases Construction Phase
Part 2
Checkpoints of the Process
It is important to have visible milestones in the life cycle , where various stakeholders meet to discuss progress and planes. The purpose of this events is to:
Synchronize stakeholder expectations and achieve concurrence on the requirements, the design, and the plan.
57/112
Part 2
Checkpoints of the Process
Three types of joint management reviews are conducted throughout the process:
1. Major milestones provide visibility to systemwide issues, synchronize the management and engineering perspectives and verify that the aims of the phase have been achieved.
2. Minor milestones iteration-focused events, conducted to review the content of an iteration in detail and to authorize continued work.
3. Status assessments periodic events provide management with frequent and regular insight into the progress being made.
"Software Project Management" Walker Royce 58/112
Part 3
Software Management Disciplines
59/112
Part 3
Software Management Disciplines
Table of Contents (1)
Work Breakdown Structures Planning Guidelines The Cost and Schedule Estimating Process The Iteration Planning Process Pragmatic Planning Line-of-Business organizations Project Organizations Evolution Organizations Tools: Automation Building Blocks The Project Environment
"Software Project Management" Walker Royce 60/112
Process Automation
Part 3
Software Management Disciplines
Table of Contents (2)
The Seven Core Metrics Management Indicators Quality Indicators Life-Cycle Expectations Pragmatic Software Metrics Metrics Automation Process Discriminants Example: Small-Scale Project Versus Large-scale Project
61/112
Part 3
Iterative Process Planning
Work Breakdown Structures
The development of a work breakdown structure is dependent on the project management style, organizational culture, customer preference, financial constraints and several other hard-to-define parameters. A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A WBS provides the following information structure:
A delineation of all significant work A clear task decomposition for assignment of responsibilities A framework for scheduling, budgeting, and expenditure
tracking.
"Software Project Management" Walker Royce 62/112
Part 3
Iterative Process Planning
Planning Guidelines
Two simple planning guidelines should be considered when a project plan is being initiated or assessed.
FIRST-LEVEL WBS ELEMENT DEFAULT BUDGET
10% 10%
DOMAIN Effort
INCEPTION 5%
ELABORATION 20%
CONSTRUCTION 65%
TRANSITION 10%
The second guideline prescribes the allocation of effort and schedule across the life-cycle phases
The first guideline prescribes a default allocation of costs among the first-level WBS elements "Software Project Management" Walker Royce 63/112
Part 3
Iterative Process Planning
The Cost and Schedule Estimating Process
Part 3
Iterative Process Planning
The Cost and Schedule Estimating Process
Backward-looking:
1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets and schedules are estimated by the responsible WBS element manager. 2. Estimates are combined and integrated into higher level budgets and milestones. 3. Comparisons are made with the top-down budgets and schedule milestones. Gross differences are assessed and adjustments are made in order to converge on agreement between the top-down and the bottom-up estimates.
65/112
Part 3
Iterative Process Planning
The Iteration Planning Process
Engineering Stage Inception
Feasibility iterations
Elaboration
Architecture iterations
Transition
Product releases
66/112
Part 3
Project Organizations and Responsibilities
Line-of-Business Organizations
Default roles in a software line-of-business organizations
Organization Manager
Software Engineering Process Authority Process definition Process improvement Project Review Authority Project compliance Periodic risk assessment
Infrastructure
Project administration Engineering skill centers Professional development
Project A Manager
Project B Manager
"Software Project Management" Walker Royce
Project N Manager
67/112
Part 3
Project Organizations and Responsibilities
Project Organizations
Responsibilities
Resource commitments Personnel assignments Plans, priorities, Stakeholder satisfaction Scope definition Risk management Project control
Transition
Customer satisfaction Contract closure Sales support Next-generation planning
Business case Vision Software development plan Work breakdown structure Status assessments Requirements set
Life-Cycle Focus
Inception
Elaboration phase planning Team formulating Contract base lining Architecture costs
Elaboration
Construction phase planning Full staff recruitment Risk resolution Product acceptance criteria Construction costs
Construction
Transition phase planning Construction plan optimization Risk management
68/112
Part 3
Project Organizations and Responsibilities
Project Organizations
Responsibilities
Requirements trade-offs Design trade-offs Component selection Initial integration Technical risk solution
Life-Cycle Focus
Inception
Architecture prototyping Make/buy trade-offs Primary scenario definition Architecture evaluation criteria definition
Elaboration
Architecture base lining Primary scenario demonstration Make/buy trade-offs base lining
Construction
Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements
Transition
Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements
69/112
Part 3
Project Organizations and Responsibilities
Project Organizations
Artifacts
Design set Implementation set Deployment set
Responsibilities
Component Component Component Component Component design implementation stand-alone test maintenance documentation
Life-Cycle Focus
Inception
Prototyping support Make/buy trade-offs
Elaboration
Critical component design Critical component implementation and test Critical component base line
Construction
Component Component Component Component design implementation stand-alone test maintenance
Transition
Component maintenance Component documentation
70/112
Part 3
Project Organizations and Responsibilities
Project Organizations
Responsibilities
Project infrastructure Independent testing Requirements verification Metrics analysis Configuration control Change management User deployment
Transition
Infrastructure maintenance Release base lining Change management Deployment to users Requirements verification
Deployment set SCO database User manual Environment Release specifications Release descriptions Deployment documents
Inception
Infrastructure planning Primary scenario prototyping
Life-Cycle Focus
Construction
Elaboration
Infrastructure base lining Architecture release testing Change management Initial user manual
Infrastructure upgrades Release testing Change management User manual base line Requirements verification
71/112
Part 3
Project Organizations and Responsibilities
Evolution of Organizations
Software management 50% Software architecture 20% Software development 20% Software assessment 10% Software architecture 50%
Inception Transition
Software management 10% Software architecture 5% Software development 35% Software assessment 50%
Elaboration Construction
Software management 10% Software architecture 10% Software development 50% Software assessment 30%
72/112
Part 3
Process Automation
Computer-aided software engineering
Computer-aided software engineering (CASE) is software to support software development and evolution processes. Activity automation
Graphical editors for system model development; Data dictionary to manage design entities; Graphical UI builder for user interface construction; Debuggers to support program fault finding; Automated translators to generate new versions of a program.
73/112
Part 3
Process Automation
Computer-aided software engineering (CASE) Technology
Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted
Software engineering requires creative thought this is not readily automated; Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.
"Software Project Management" Walker Royce 74/112
Part 3
Process Automation
CASE Classification
Classification helps us understand the different types of CASE tools and their support for process activities. Functional perspective
Tools are classified according to their specific function.
Process perspective
Tools are classified according to process activities that are supported.
Integration perspective
Tools are classified according to their organisation into integrated units.
75/112
Part 3
Process Automation
Functional Tool Classification
Tool type Planning tools Editing tools Change management tools Configuration management tools Prototyping tools Method-support tools Language-processing tools Program analysis tools Testing tools Debugging tools Documentation tools Re-engineering tools Examples PERT tools, estimation tools, spreadsheets Text editors, diagram editors, word processors Requirements traceability tools, change control systems Version management systems, system building tools Very high-level languages, user interface generators Design editors, data dictionaries, code generators Compilers, interpreters Cross reference generators, static analysers, dynamic analysers Test data generators, file comparators Interactive debugging systems Page layout programs, image editors Cross-reference systems, program re-structuring systems
76/112
Part 3
Process Automation
CASE Integration
Tools
Support individual process tasks such as design consistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or design, Normally include a number of integrated tools.
Environments
Support all or a substantial part of an entire software process. Normally include several integrated workbenches.
"Software Project Management" Walker Royce 77/112
Part 3
Process Automation
Tools, Workbenches, Environments
CASE technolo g y
T ools
Wor kbenches
Environments
Editors
Compilers
Pr ocess-centr ed en vironments
Pro gramming
T esting
Single-method workbenches
78/112
Part 3
Project Control and Process Instrumentation
The Core Metrics
METRIC
Work and progress
PURPOSE
Iteration planning, plan vs. actuals, management indicator Financial insight, plan vs. actuals, management indicator Resource plan vs. actuals, hiring rate, attrition rate Iteration planning, management indicator of schedule convergence Convergence, software scrap, quality indicator Convergence, software rework, quality indicator
PERSPECTIVES
SLOC, function points, object points, scenarios, test cases, SCOs Cost per month, full-time staff per month, percentage of budget expended People per month added, people per month leaving Software changes
Reworked SLOC per change, by type, by release/component/subsystem Average hours per change, by type, by release/component/subsystem
79/112
Part 3
Tailoring the Process
Process Discriminants
80/112
Part 3
Tailoring the Process
Example: Small-Scale Project vs. Large-Scale Project
Differences in workflow priorities between small and large projects
Rank
Small Commercial Project Design Implementation Deployment Requirements Assessments Management Environment
"Software Project Management" Walker Royce
Large Complex Project Management Design Requirements Assessment Environment Implementation Deployment
81/112
1 2 3 4 5 6 7
Part 4
Looking Forward
82/112
Part 4
Looking Forward
Table of Contents
Continuous Integration Early Risk Resolution Evolutionary Requirements Teamwork Among Stakeholders Top 10 Software Management Principles Software Management Best Practices Next-Generation Cost Models Modern Software Economics Culture Shifts Denouement
83/112
Part 4
Modern Project Profiles Continuous Integration
Differences in workflow cost allocations between a conventional process and a modern process
SOFTWARE ENGINEERING WORKFLOWS
Management Environment Requirements Design Implementation Assessment Deployment Total
84/112
Part 4
Modern Project Profiles Continuous Integration The continuous integration inherent in an iterative development process enables better insight into quality trade-offs. System characteristics that are largely inherent in the architecture (performance, fault tolerance, maintainability) are tangible earlier in the process, when issues are still correctable.
85/112
Part 4
Modern Project Profiles Early Risk Resolution
Conventional projects usually do the easy stuff first, modern process attacks the important 20% of the requirements, use cases, components, and risks. The effect of the overall life-cycle philosophy on the 80/20 lessons provides a useful risk management perspective.
80% of the engineering is consumed by 20% of the requirements. 80% of the software cost is consumed by 20% of the components. 80% of the errors are caused by 20% of the components. 80% of the progress is made by 20% of the people.
"Software Project Management" Walker Royce 86/112
Part 4
Modern Project Profiles Evolutionary Requirements
Conventional approaches decomposed system requirements into subsystem requirements, subsystem requirements into component requirements, and component requirements into unit requirements. The organization of requirements was structured so traceability was simple. Most modern architectures that use commercial components, legacy components, distributed resources and object-oriented methods are not trivially traced to the requirements they satisfy. The artifacts are now intended to evolve along with the process, with more and more fidelity as the life-cycle progresses and the requirements understanding matures.
"Software Project Management" Walker Royce 87/112
Part 4
Modern Project Profiles Teamwork among stakeholders
Many aspects of the classic development process cause stakeholder relationships to degenerate into mutual distrust, making it difficult to balance requirements, product features, and plans. The process with more-effective working relationships between stakeholders requires that customers, users and monitors have both applications and software expertise, remain focused on the delivery of a usable system It also requires a development organization that is focused on achieving customer satisfaction and high product quality in a profitable manner. The transition from the exchange of mostly paper artifacts to demonstration of intermediate results is one of the crucial mechanisms for promoting teamwork among stakeholders.
"Software Project Management" Walker Royce 88/112
Part 4
Modern Project Profiles Top 10 Software Management Principles
1. Base the process on an architecture-first approach rework
rates remain stable over the project life cycle.
2. Establish an iterative life-cycle process that confronts risk early 3. Transition design methods to emphasize component-based development 4. Establish a change management environment the dynamics
of iterative development, including concurrent workflows by different teams working on shared artifacts, necessitate highly controlled baselines
Part 4
Modern Project Profiles Top 10 Software Management Principles
6. Capture design artifacts in rigorous, model-based notation 7. Instrument the process for objective quality control and progress assessment 8. Use a demonstration-based approach to asses intermediate artifacts 9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail 10. Establish a configurable process that is economically scalable
90/112
Part 4
Modern Project Profiles Software Management Best Practices
There is nine best practices:
1. Formal risk management 2. Agreement on interfaces 3. Formal inspections 4. Metric-based scheduling and management 5. Binary quality gates at the inch-pebble level 6. Program-wide visibility of progress versus plan. 7. Defect tracking against quality targets 8. Configuration management 9. People-aware management accountability
91/112
Part 4
Next-Generation Software Economics Next-Generation Cost Models
Software experts hold widely varying opinions about software economics and its manifestation in software cost estimation models: source lines of code productivity measures Java object-oriented function points quality measures C++ functionally oriented
VERSUS
It will be difficult to improve empirical estimation models while the project data going into these models are noisy and highly uncorrelated, and are based on differing process and technology foundations.
"Software Project Management" Walker Royce 92/112
Part 4
Next-Generation Software Economics Next-Generation Cost Models
Some of todays popular software cost models are not well matched to an iterative software process focused an architecture-first approach Many cost estimators are still using a conventional process experience base to estimate a modern project profile A next-generation software cost model should explicitly separate architectural engineering from application production, just as an architecture-first process does. Two major improvements in next-generation software cost estimation models:
Separation of the engineering stage from the production stage will force estimators to differentiate between architectural scale and implementation size. Rigorous design notations such as UML will offer an opportunity to define units of measure for scale that are more standardized and therefore can be automated and tracked.
"Software Project Management" Walker Royce 93/112
Part 4
Next-Generation Software Economics Modern Software Economics
Changes that provide a good description of what an organizational manager should strive for in making the transition to a modern process: 1. Finding and fixing a software problem after delivery costs 100 times more than fixing the problem in early design phases 2. You can compress software development schedules 25% of nominal, but no more. 3. For every $1 you spend on development, you will spend $2 on maintenance. 4. Software development and maintenance costs are primarily a function of the number of source lines of code.
"Software Project Management" Walker Royce 94/112
Part 4
Next-Generation Software Economics Modern Software Economics
5. Variations among people account for the biggest differences in software productivity. 6. The overall ratio of software to hardware costs is still growing in 1955 it was 15:85; in 1985 85:15. 7. Only about 15% of software development effort is devoted to programming. 8. Software systems and products typically cost 3 times as much per SLOC as individual software programs. 9. Walkthroughs catch 60% of the errors. 10. 80% of the contribution comes from 20% of the contributors.
"Software Project Management" Walker Royce 95/112
Part 4
Modern Process Transitions Culture Shifts
Several culture shifts must be overcome to transition successfully to a modern software management process:
Lower level and mid-level managers are performers Requirements and designs are fluid and tangible Good and bad project performance is much more obvious earlier in the life cycle Artifacts are less important early, more important later Real issues are surfaced and resolved systematically Quality assurance is everyones job, not a separate discipline Performance issues arise early in the life cycle Investments in automation is necessary Good software organization should be more profitable
"Software Project Management" Walker Royce 96/112
Part 4
Modern Process Transitions Denouement
Good way to transition to a more mature iterative development process that supports automation technologies and modern architectures is to take the following shot: Ready.
Do your homework. Analyze modern approaches and technologies. Define your process. Support it with mature environments, tools, and components. Plan thoroughly.
Aim.
Select a critical project. Staff it with the right team of complementary resources and demand improved results.
Fire.
Execute the organizational and project-level plans with vigor and follow-through.
97/112
Appendix
98/112
A sequence of actions a system performs that yields a valuable result for a particular actor.
What is an Actor?
A user or outside system that interacts with the system being designed in order to obtain some value from that interaction
Use Cases describe scenarios that describe the interaction between users of the system and the system itself. Use Cases describe WHAT the system will do, but never HOW it will be done.
"Software Project Management" Walker Royce 99/112
Appendix
Use Cases Describe Function not Form
Use Cases describe WHAT the system will do, but never HOW it will be done. Use Cases are Analysis Products, not Design Products.
101/112
Appendix
Use Cases Describe Function not Form Use Cases describe WHAT the system should do, but never HOW it will be done Use cases are Analysis products, not design products
102/112
106/112
Appendix
Why spend time on the Analysis Model, why not just face the cliff?
By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system By providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a birds eye view, without having to get bogged down with implementation details. The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By speaking the developers language, comprehension is improved and by abstracting, simplicity is achieved Nevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along.
"Software Project Management" Walker Royce 108/112
109/112
110/112
111/112
Literature
Software Project Management A Unified Framework Walker Royce Software Processes Ian Sommerville 2004 Process and Method: An Introduction to the Rational Unified Process
112/112