[attachment=14604]
Software Project ManagementRational Unified Framework
Part 1 Software Management RenaissanceIntroduction
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.
Part 1 Software Management Renaissance
Part 1Software Management RenaissanceTable of Contents (1)
The Old Way (Conventional SPM)
The Waterfall Model
Conventional Software Management Performance
Evolution of Software Economics
Software Economics
Pragmatic Software Cost Estimation
Part 1 Software Management RenaissanceTable of Contents (2)
Improving Software Economics
Reducing Software Product Size
Improving Software Processes
Improving Team Effectiveness
Improving Automation through Software Environments
Achieving Required Quality
Peer Inspections: A Pragmatic View
The Old Way and the New
The Principles of Conventional Software Engineering
The Principles of Modern Software Management
Transitioning to an Iterative Process
The Old Way
Part 1 The Old Way
Software crisis
“The best thing about software is its flexibility”
It can be programmed to do almost anything.
“The worst thing about software is also its flexibility”
The “almost anything ” characteristic has made it difficult to plan, monitor, and control software development.
Part 1 The Old WayThe Waterfall Model
Drawbacks
Protracted integration
and late design breakage
Late risk resolution
Requirements - driven
functional decomposition
Adversarial stakeholder relationships
Focus on document
and review meetings
Part 1 The Old Way Conventional Software Management Performance
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.
Part 1 Evolution of Software Economics
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-value-adding 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…)
Part 1 Evolution of Software EconomicsThree generations of software economics
Part 1 Evolution of Software EconomicsThe predominant cost estimation process
Part 1 Evolution of Software EconomicsPragmatic software cost estimation
A good estimate has the following attributes:
It is conceived and supported by the project manager, architecture team, development team, and test team accountable for performing the work.
It is accepted by all stakeholders as ambitious but realizable.
It is based on a well defined software cost model with a credible basis.
It is based on a database of relevant project experience that includes similar processes, technologies, environments, quality requirements, and people.
It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed.
Part 1 Improving Software Economics
Five basic parameters of the software cost model:
Reducing the size or complexity of what needs to be developed
Improving the development process
Using more-skilled personnel and better teams (not necessarily the same thing)
Using better environments (tools to automate the process)
Trading off or backing off on quality thresholds
Part 1 Improving Software EconomicsImportant trends in improving software economics
Cost model parameters Trends
Part 1 Improving Software EconomicsReducing 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.”
Part 1 Improving Software EconomicsReducing Software Product Size - Languages
Part 1 Improving Software EconomicsReducing 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.
Part 1 Improving Software EconomicsReducing Software Product Size – Reuse
Number of Projects Using Reusable Components
Part 1 Improving Software EconomicsReducing Software Product Size – Commercial Components
Part 1 Improving Software EconomicsImproving Software Processes
Part 1 Improving Software EconomicsImproving 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 self-actualize.
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 doesn’t benefit anyone.
Part 1 Improving Software EconomicsImproving 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 stake-holders 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.
Part 1 Improving Software EconomicsAchieving 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
Part 1 The Old Way and the New
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
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 don’t 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 industry’s 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 software’s 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. Don’t worry about optimization during initial coding.
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
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 customer’s 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.”
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
21.Use tools, but be realistic. Software tools make
Part 1 The Old Way and the NewThe Principles of Modern Software Management
The central design element
Part 2 A Software Management Process Framework
Part 2 A Software Management Process FrameworkTable of Contents (1)
Life-Cycle Phases
Engineering and Production Stages
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase
Artifacts of the Process
The Artifact Sets
Management Artifacts
Engineering Artifacts
Pragmatic Artifacts
Part 2 A Software Management Process FrameworkTable of Contents (2)
Model-based software Architectures
Architecture: A Management Perspective
Architecture: A Technical Perspective
Workflows of the Process
Software Process Workflows
Iteration Workflows
Checkpoints of the Process
Major Milestones
Minor Milestones
Periodic Status Assessments
Part 2 Life-Cycle PhasesEngineering and Production Stages
Part 2 Life-Cycle PhasesEngineering and Production Stages
Part 2 Life-Cycle PhasesInception Phase
Part 2 Life-Cycle PhasesElaboration Phase
Part 2 Life-Cycle PhasesConstruction Phase
Part 2 Life-Cycle PhasesTransition Phase
Part 2 Life-Cycle Phases
Part 2 Artifacts of the Process
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessEngineering Artifacts
Part 2 Artifacts of the ProcessEngineering Artifacts
Part 2 Artifacts of the ProcessPragmatic Artifacts
Part 2 Model-Based Software Architectures A Management Perspective
Part 2 Model-Based Software Architectures A Management Perspective
Part 2 Model-Based Software Architectures A Technical Perspective
Part 2 Model-Based Software Architectures A Technical Perspective
Part 2 Workflows of the Process Software Process Workflows
Part 2 Workflows of the Process Software Process Workflows
Part 2 Workflows of the Process Iteration Workflows
Part 2 Workflows of the Process Iteration Workflows
Part 2 Checkpoints of the Process
Part 2 Checkpoints of the Process
Part 3Software Management Disciplines
Part 3Software Management DisciplinesTable of Contents (1)
Iterative Process Planning
Work Breakdown Structures
Planning Guidelines
The Cost and Schedule Estimating Process
The Iteration Planning Process
Pragmatic Planning
Project Organizations and Responsibilities
Line-of-Business organizations
Project Organizations
Evolution Organizations
Process Automation
Tools: Automation Building Blocks
The Project Environment
Part 3 Software Management DisciplinesTable of Contents (2)
Project Control and Process Instrumentation
The Seven Core Metrics
Management Indicators
Quality Indicators
Life-Cycle Expectations
Pragmatic Software Metrics
Metrics Automation
Tailoring the Process
Process Discriminants
Example: Small-Scale Project Versus Large-scale Project
Part 3Iterative Process PlanningWork Breakdown Structures
Part 3Iterative Process PlanningPlanning Guidelines
Part 3Iterative Process PlanningThe Cost and Schedule Estimating Process
Part 3Iterative Process PlanningThe Cost and Schedule Estimating Process
Part 3Iterative Process PlanningThe Iteration Planning Process
Part 3Project Organizations and ResponsibilitiesLine-of-Business Organizations
Default roles in a software line-of-business organizations
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Management Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Architecture Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Development Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Assessment Team
Part 3Project Organizations and ResponsibilitiesEvolution of Organizations
Part 3Process 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.
Part 3Process 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.
Part 3Process 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.
Part 3Process Automation Functional Tool Classification
Part 3Process 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.
Part 3Process Automation Tools, Workbenches, Environments
Part 3Project Control and Process Instrumentation The Core Metrics
Part 3Tailoring the ProcessProcess Discriminants
The two primary dimensions of process variability
Part 3Tailoring the ProcessExample: Small-Scale Project vs. Large-Scale Project
Differences in workflow priorities between small and large projects
Part 4 Looking Forward
Part 4 Looking ForwardTable of Contents
Modern Project Profiles
Continuous Integration
Early Risk Resolution
Evolutionary Requirements
Teamwork Among Stakeholders
Top 10 Software Management Principles
Software Management Best Practices
Next-Generation Software Economics
Next-Generation Cost Models
Modern Software Economics
Modern Process Transitions
Culture Shifts
Denouement
Part 4 Modern Project ProfilesContinuous Integration
Part 4 Modern Project ProfilesContinuous Integration
Part 4 Modern Project ProfilesEarly Risk Resolution
Part 4 Modern Project ProfilesEvolutionary Requirements
Part 4 Modern Project ProfilesTeamwork among stakeholders
Part 4 Modern Project ProfilesTop 10 Software Management Principles
Part 4 Modern Project ProfilesTop 10 Software Management Principles
Part 4 Modern Project ProfilesSoftware Management Best Practices
Part 4 Next-Generation Software EconomicsNext-Generation Cost Models
Part 4 Next-Generation Software EconomicsNext-Generation Cost Models
Part 4 Next-Generation Software EconomicsModern Software Economics
Part 4 Next-Generation Software EconomicsModern Software Economics
Part 4 Modern Process TransitionsCulture Shifts
Part 4 Modern Process TransitionsDenouement
Appendix
AppendixUse Case Analysis
What is a Use Case?
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.
Appendix What’s in a Use Case?
Define the start state and any preconditions that accompany it
Define when the Use Case starts
Define the order of activity in the Main Flow of Events
Define any Alternative Flows of Events
Define any Exceptional Flows of Events
Define any Post Conditions and the end state
Mention any design issues as an appendix
Accompanying diagrams: State, Activity, Sequence Diagrams
View of Participating Objects (relevant Analysis Model Classes)
Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case
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.
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
Appendix Benefits of Use Cases
Use cases are the primary vehicle for requirements capture in RUP
Use cases are described using the language of the customer (language of the domain which is defined in the glossary)
Use cases provide a contractual delivery process (RUP is Use Case Driven)
Use cases provide an easily-understood communication mechanism
When requirements are traced, they make it difficult for requirements to fall through the cracks
Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.
Appendix Difficulties with Use Cases
As functional decompositions, it is often difficult to make the transition from functional description to object description to class design
Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult
Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)
Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious
Appendix Use Case Model Survey
The Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver.
Each Use Case in the system appears in the Survey with a short description of its main function.
Participants:
Domain Expert
Architect
Analyst/Designer (Use Case author)
Testing Engineer
Appendix Sample Use Case Model Survey
Appendix Analysis Model
In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details
Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer
Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer:
Boundary Classes
Entity Classes
Control Classes
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 ‘bird’s 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 developer’s 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.
Appendix Boundary Classes
Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems)
Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.)
Boundary classes can often be abstractions of external APIs (in the case of an external system actor)
Every boundary class must be associated with at least one actor:
Appendix Entity Classes
Entity classes are used within the Analysis Model to model persistent information
Often, entity classes are created from objects within the business object model or domain model
Appendix Control Classes
The Great Et Cetera
Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objects
In Smalltalk MVC mechanism, these are controllers
Control classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.
Literature
Software Project Management
A Unified Framework
Walker Royce
Software Processes
©Ian Sommerville 2004
Process and Method:
An Introduction to the Rational Unified Process