Software Project Management

Software Project Management

Course Description Catalog Strategic Objective
Process context of software development. Task decomposition. Size and schedule estimation. Risk management. Project planning and control mechanisms. Strategic Objective To study traditional and modern software project management methods and techniques. Tactical Objectives Understand the traditional process of software project management. Understand the basics for improving the traditional process. Know the disciplines for successful software project management. Look ahead to the future of software project management.

Topics Conventional Software Development – The Waterfall Model
Conventional Software Development Experience Typical progress profile Expenditures Risk profile Documents and Reviews Necessary Improvements to Waterfall Model Conventional Software Management Performance Barry Boehm’s “Top 10 List”

Typical Progress Profile – Conventional Project

The Software Development Experience
Development is highly unpredictable. Only 10% of projects on time and budget. Management discipline is more of a discriminator in success or failure than are technology advances. The level of software scrap and rework is indicative of an immature process.

Two Basic Steps

Classical Waterfall Model

Expenditures – Conventional Project
Management 5% Requirements 5% Design % Code and unit testing 30% Integration and test 40% Deployment 5% Environment 5%

Risk Profile – Conventional Project

Typical Software Project Documents and Control
The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval. 2. The customer was expected to provide comments {typically within 15 to 30 days). 3. The contractor incorporated these comments and submitted {typically within 15 to 30 days) a final version for approval.

Typical Program Experience
Early success via paper designs and thorough (often too thorough) briefings. Commitment to code late in the life cycle. Integration nightmares due to unforeseen implementation issues and interface ambiguities. Heavy budget and schedule pressure to get the system working. Late shoe-horning of non-optimal fixes, with no time for redesign. A very fragile, un-maintainable product delivered late

Summary of Problems in Conventional Practice……
1. Protracted integration and late design breakage . 2. Late risk resolution . 3. Requirements-driven functional decomposition. 4. Adversarial stakeholder relationships. 5. Focus on documents and review meetings.

Five Improvements for the Waterfall Model to Work
Complete program design before analysis and coding begin. Maintain current and complete documentation. Do the job twice, if possible. Plan, control, and monitor testing. Involve the customer.

Boehm’s Top Ten List Fixing after delivery costs 100 times as much as early fix. You can compress schedule 25%, but no more. For every $1 spent on development you will spend $2 on maintenance. Costs are primarily a function of source lines of code. Variations among people account for the biggest differences in productivity Ratio of software to hardware cost is 85:15 and still growing. Only about 15% of software development cost is due to programming. Software systems cost 3 times as much as software programs. Software system products cost 9 times as much. Walkthroughs catch 60% of the errors. 80% of the contribution comes from 20% of the contributors.

The 80/20 Rule 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 software scrap and rework is caused by 20% of the errors. 80% of the resources are consumed by 20% of the components. 80% of the engineering is accomplished by 20% of the tools. 80% of the progress is made by 20% of the people.

Summary Conventional software development process today is unreliable and and immature. The Waterfall Method needs improvements to work satisfactorily. Conventional practices provide a benchmark for future improvements and changes to software development methods.

Assignment for Next Class
Read Chapter 1, Conventional Software Management, of Royce’ book. Learn the seven steps of the waterfall model. Learn the five improvements needed for the approach. Learn the expenditures figures by activity for conventional software projects. Learn Barry Boehm’s Metric “Top Ten List” for the state of software development. Read Chapter 1, “The Tar Pit”, of Brook’s book. If assigned to you, prepare the “Brook’s Chapter 1” 20 minute report (for presentation to the class).

Evolution of Software Economics Improving Software Economics

Three Generations of Software Economics

The Predominant Cost Estimation Process

Five Software Cost Model Parameters
Size of the end product Usually the number of Source Lines of Code. Process used to produce the end product. Capabilities of the personnel. The environment – tools and techniques. Required quality of the end product.

Cost Estimation Formula
Effort = (personnel)(Environment)(Quality)(Size)(exp(Process))

Formula Use Example

Function Points Estimation
An alternative to Source Lines of Code basis for estimation. Use “Function Points” to estimate effort External user inputs External outputs Internal logical data groups External data interfaces External inquiries

Accuracy Overall accuracy of current software cost estimation models has been described as “…within 20% of actuals, 70% of the time….”

Attributes of a Good Estimate
Estimate is conceived and supported by all. Project manager, architecture team, development team, and test team accountable for the work. Estimate is accepted by all stakeholders as ambitious but realizable. Estimate is based on well-defined cost model with a credible basis. Estimate is based on relevant project experience. Estimate is detailed and key risks areas are understood.

Improving Software Economics
(Royce’ Chapter 3)

Software Economic Improvement Trends

Five Economy Improvement Dimensions
Reducing the size of the software. Improving the development process. Using more-skilled personnel and better teams. Using better environments (tools) for software development. Trading off, or backing off, on quality thresholds.

Reducing Software Size
Languages. Object-oriented methods and Visual Modeling. Reuse. Commercial Components.

Language Comparison

Example Function Point Comparison
1,000,000 lines of assembly language code. 400,000 lines of C 220,000 lines of Ada 83. 175,000 lines of Ada 95 or C++

Object-Oriented Methods and Visual Modeling
Better capture of software abstractions leads to better communications and better teamwork. Continuous integration leads to earlier risk recognition and less costly corrections. Object-oriented architectures provide better separation of disparate elements of a system and help create firewalls for less costly development. Object-oriented and visual modeling create a strong architectural vision for cleaner, less-costly products.

Reuse of Software Common architectures. Development environments.
Operating systems. Database management systems. Networking products. Office applications.

Reuse Cost and Schedule

Commercial Components

Summary Software estimation must be based on careful analysis and must be supported by all. Software economics improvements must come from reducing size, improving process and environments, using more- skilled personnel, and trading off software feature thresholds.

Assignment for Next Class
Read Chapters 2 and 3 of Royce’ book, on Software Economics. Learn the five major parameters in the software effort formula. Learn the software development effort formula. Learn the five attributes of a good software estimate. Learn the five software improvement dimensions. Read Chapter 2, “The Mythical Man-month” of Brook’s book. If assigned to you, prepare the “Brooks’ Chapter 2” 20 minute report (for presentation to the class next meeting).

Improving Software Economics

Five Economy Improvement Dimensions
Reducing the size of the software. Improving the development process. Using more-skilled personnel and better teams. Using better environments (tools) for software development. Trading off, or backing off, on quality thresholds.

Improving Software Development Processes
Productive activity Prototyping Modeling Coding Debugging Documentation Overhead activity Plan preparation Documentation Progress monitoring Risk assessment Financial assessment Configuration control Quality assessment Integration Testing Late scrap and rework Management Training Administration

Three Levels of Process

Three Dimensions for Schedule Improvement
In an N-step process, improve the efficiency of each step. In an N-step process, eliminate some steps to create an M-step process. In an N-step process use more currency in the activities.

Sequential Steps Every instance of rework introduces a sequential set of tasks. Start with analysis, design, coding, and testing of a feature. Suppose then a fault is found. Then we must repeat the analysis, design, etc… These rework task sequences are the primary obstacle to schedule compression.

Improving Team Effectiveness
Four Team Management Maxims. Five Project Staffing Principles. Five Attributes of Successful Software Managers.

Four Maxims of Team Management
A well-managed project can succeed with a nominal engineering team. A mismanaged project will fail, even with an expert team. A well-architected system can built by a nominal team. A poorly-architected system will flounder even with an expert team.

Five Attributes of Successful Software Project Managers
Hiring skills. Right persons in the right jobs. Customer-interface skills. Avoiding adversarial relationships. Decision-making skills. Timely decisions, objective, unbiased and reasoned. Team-building skills. Trust, motivating, nurturing, tolerant of prima-donnas, synthesizes diverse opinions into team direction. Selling skills. Sell stakeholders, decision-makers, job candidates, sell changes of status- quo to disbelievers, sell achievements toward objectives. Selling requires continuous negotiation, compromise, and empathy.

Five Staffing Principles
Principle of top talent. Use better and fewer people. Principle of job matching. Fit the tasks to the skills and motivations of the people. Principle of career progression. Help people to self-actualize. Principle of team balance. Select people who will complement and harmonize. Hire a mix of raw skills, intelligence, objectivity, creativity, analytical thinking, psychological makeup, leaders, followers, risk-takers, conservatives, visionaries and nitpickers, cynics and optimists, experience and youth. Principle of phase-out. Replace misfits early. Phase down without delay.

Improving Automation through Software Environments
Tools Planning tools, requirements management tools, visual modeling tools, compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces, configuration management tools. Round Trip Engineering Environment Forward engineering tools (compilers, linkers, etc. are common. Round trip engineering tools are needed to support iterative development processes. Requirements management, document automation, automated regression testing, continuous and integrated change management, and feature/defect tracking.

Achieving Required Quality
Five Key Practices Focus on driving requirements. Use of metrics and indicators to measure progress and quality of architecture. Provision of integrated life-cycle configuration control and change management. Use of visual modeling and higher level languages. Early and continuous insight into performance issues through demonstration-based evaluations.

Quality Improvements with a Modern Process

Performance Assessment in a Typical Project
Project inception. Proposed design is asserted to be low risk with adequate performance margin. Initial Design Review. Optimistic assessment based on paper analysis or rough simulation. Operating system overhead, database management overhead, etc., all underestimated. Mid-life-cycle Design Review. Initial tests whittle away at margins. Early optimism exposed. Integration and Test. Serious problems uncovered. Margins exceeded. Fundamental changes in software architecture needed. Additional hardware or reduced functionality often required.

Peer Inspections Inspections accelerate transferring skills and knowledge to junior programmers. Inspections are a good vehicle for holding authors accountable for quality projects. Inspections are usually less helpful than primary quality mechanisms. Major milestone demonstrations. Environment tools (compilers, analyzers, automated test suites) that ensure representation rigor, consistency, completeness, and change control. Inspections should focus on critical components only. Inspections usually do NOT uncover three types of serious problems. Performance bottlenecks. Serious control issues - deadlocks, races, resource contention. Architectural flaws – scalability, reliability, interoperability.

The Old Way and the New Way

Topics The Principles of Conventional Software Management
The Principles of Modern Software Management Transitioning to an Iterative Process

Review - Quality Improvements with a Modern Process

Thirty Principles for Conventional Process (Davis)
1. Make quality #1 Understand early the tradeoffs among features, quality, cost and schedule. 2. High quality software IS possible. Prototype, simplify, involve the customer. 3. Give products to the customer EARLY. Determines the REAL requirements. Use prototypes, demonstrators, alpha/beta releases.

Thirty Principles for Conventional Process – cont’d
4. Determine the problem BEFORE writing the requirements. Resist jumping to solution. 5. Evaluate design alternatives. Decouple architecture from requirements. 6. Use an APPRORIATE process model. Considerations include corporate culture, risk tolerance, and volatility of requirements.

7. Use different languages for different phases. 8. Minimize intellectual distance. Use real-world structures. 9. Put techniques before tools. 10. Get it right before you make it faster. It is far easier to make a working program run faster than it is to make a fast program work.

11. Inspect the detailed design and code early. 12. Good management is more important than good technology. The best technology will not compensate for poor management. 13. People are the key to success. The right people, even with insufficient tools, languages and processes will succeed. 14. Follow with care.

15. Take responsibility. It takes more than good tools, methods and components. It also takes good people and good management. 16. Understand the customer’s priorities. Although the customer may not always be right, the customer is always ready to understand. 17. The more the customer sees, the more the customer needs. Software manager needs to have objective data to argue change requests – to balance affordability, features, and risk.

18. “Plan to throw one away.” Rather, plan to evolve from prototypes to final product. 19. Design for change. Architecture must accommodate change. Think ahead! 20. Design without documentation is not design! However, engineering work should be largely self- documenting.

21. Use tools, but be realistic. Modern, iterative development methods require extensive automation. 22. Avoid tricks. However, be mindful and responsive to innovation. 23. Encapsulate. Think in terms of component-based and object-oriented design. 24. Use coupling and cohesion. Cohesive components with minimal coupling are easier to maintain and adapt to changes.

25. Use complexity measures. Royce recommends McCabe. 26. Don’t rely on testing your own software. 27. Analyze causes for failures. 28. Realize that software entropy increases. Software grows more complex and more disorganized over time.

29. People and time and NOT interchangeable. Read the Mythical Man-Month. 30. Expect excellence.

Modern Software Management

The First Top Five Principles for a Modern Process

First Five Improvement Principles
Architecture first approach. Balance driving requirements, architecture and design decisions, and life-cycle plans. Iterative life-cycle process to confront risk early. Refine problem and solutions over several iterations. Use component-based development. Move from “line-of-code” mentality to “component” mentality. Establish a change management environment. Important for iterative development. Use round-trip engineering. Automation of change management, documentation and testing across requirements, specifications, design models, source code, executable code, and test cases.

Remaining Five Improvement Principles
Capture design artifacts with model-based notation. Far more objective process than using human review and inspection processes. Use objective quality control and progress assessment. Assessment should be integrated with the development process, not ah- hoc when difficulties occur. Use a demonstration-based approach to assess intermediate artifacts. Apply to early prototypes, baseline architectures, early releases. Plan on intermediate releases with evolving levels of detail. Make early and continuous releases with realistic use cases and scenarios. Establish a good configurable process. Must be economy of scale and be scalable across a range of projects.

Modern Approaches for Solving Conventional Problems

Transitioning to a Modern Process
Modern process features – Early development of an initial version. High risk areas are addressed early. Several iterations are developed (called spirals, increments, generations, releases). Modern process characteristics- Extensive use of domain experience. Process flexibility and change management. Architecture risk resolution. Team cohesion. Software process maturity.

Summary – The Old Way and the New Way
Many “old way” principles still apply – make quality #1, determine the problem before writing the requirements, understand the customer’s priorities, etc… The “new way” principles feature architecture- first approaches, iterative development, and integrated change management. Transition from the “old” to the “new” requires early initial versions, addressing high risk areas early, evolving and refining the requirements, design and production, and involvement of the customer.

Framework for a Software Management Process –
Life Cycle Phases

Topics Engineering and Production Stages Inception Phase
Elaboration Phase Construction Phase Transition Phase

Review - The First Top Five Principles for a Modern Process

Review - First Five Improvement Principles
Architecture first approach. Balance driving requirements, architecture and design decisions, and life-cycle plans. Iterative life-cycle process to confront risk early. Refine problem and solutions over several iterations. Use component-based development. Move from “line-of-code” mentality to “component” mentality. Establish a change management environment. Important for iterative development. Use round-trip engineering. Automation of change management, documentation and testing across requirements, specifications, design models, source code, executable code, and test cases.

Review - Transitioning to a Modern Process
Modern process features – Early development of an initial version. High risk areas are addressed early. Several iterations are developed (called spirals, increments, generations, releases). Modern process characteristics- Extensive use of domain experience. Process flexibility and change management. Architecture risk resolution. Team cohesion. Software process maturity.

Development Activities
Two basic activities in software development - Research and development Production Unsuccessful projects mostly fail for one of two reasons – Overemphasis on research and development. Too many analyses and studies. Typical of conventional software development methods. Overemphasis on production. Too much “rush-to-design”, premature work by overeager coders, and much hacking.

Successful Projects Have a well-defined milestone that transitions from a research attitude to a production attitude. Early phases focus on functionality; later phases focus on a deliverable product (with robustness, performance, fit, and finish). Life-cycle balance is maintained throughout.

Modern Software Development Process
A modern process supports evolution of plans, requirements, architecture and design. A modern process supports pro-active risk management and objective measurement of progress and quality. A modern process supports evolution of system capabilities through demonstrations of increasing functionality.

Engineering and Production Stages
To achieve more economic software development we must move toward a software manufacturing mentality. Process automation. Component-based development. To achieve more economic benefits, w should use a two-stage life cycle process for development. Engineering stage, with smaller teams doing design and synthesis activities. Production stage, with larger teams doing construction, test and deployment activities.

Differences in Emphasis for Engineering and Production Stages

Four Phases for Development - Royce
Engineering Stage Inception phase Elaboration phase Production Stage Construction phase Transition phase

Phases of the Life-cycle Process

Inception Phase Objectives Activities
Establishing software scope, boundary conditions, operational concept, acceptance criteria. Critical use cases, scenarios. Demonstrating candidate architecture. Cost and schedule. Potential risks. Activities Formulating project scope. Capturing requirements Synthesizing architecture. Design tradeoffs, initial baseline for make/buy. Planning. Risk assessments, staffing, iteration plans, budgeting and scheduling, infrastructure tools selection.

Elaboration Phase Objectives Activities
Stable requirements, architecture, and plans. Executable architecture prototype(s). Baseline architecture, vision and plans. Completion of engineering for the project. Activities Elaborating the vision. Establishing the critical use cases. Elaborating the process and infrastructure. The construction process, the tools and automation support, and the intermediate milestones and evaluation criteria. Elaborating the architecture and selecting components. Complete component make/buy, component integration. Assessment against primary scenarios.

Construction Phase Activities Objectives
Transition from engineering to production mindset. Objective is to produce a product rather than developing intellectual property. Emphasis is on managing resources and controlling operations. Achieve quality as rapidly as practical. Achieve useful versions as rapidly as practical. Activities Complete component development and test. Assessment of product releases. Resource management, control and process optimization. Initiation of spawning activities.

Transition Phase Objectives Activities Deployment of a baseline.
Beta test completion. Conversion of operational databases. Training of users and maintenance personnel. Product acceptance by customer. Activities Synchronization of construction and integration of final increments. Deployment Cutover, commercial packaging, sales rollout, field personnel training. Assessment of deployment baselines.

Summary for A Framework for Software Project Management – Life-cycle Phases
Software development should move more toward a manufacturing type process. Engineering and Production Stages should be recognized and planned. Iterative development methods should be used. Inception, Elaboration, Construction and Transition Phases can be used to provide for modern software development.

Framework for a Software Management Process – Artifacts of the Process

Topics Artifact Sets Management Artifacts Engineering Artifacts
Pragmatic Artifacts

Review - Phases of the Life-cycle Process

Overview of the Artifact Sets

The Five Artifact Sets Requirements Set Design Set Implementation Set
Deployment Set Management Set

Management Set Captures “contracts” among project personnel.
Management, architects, designers, testers, marketers, administrators, …. Funding authorities, other management, regulators, customers, … Contains plans, resource requirements, budgets, costs, schedules, milestones, releases, ……

Requirements Set Forms the basis for evaluating the other three engineering artifact sets (design, implementation, deployment sets). Forms the basis for test cases.

Design Set Contain Future automation should support: Design model
Test model Architecture description Future automation should support: Complexity analysis Style analysis Consistency analysis

Implementation Set Contains Source code
Executables for stand-alone testing Custom components Application program interfaces Data files

Deployment Set Contains User deliverables Executable code
Target-specific data Run-time files User manual

Artifact Set Tools Management Set tools.
Scheduling, work flow, defect tracking, change management, documentation, resource management, presentation tools. Requirements Set tools. Requirements management tools. Design Set tools. Visual modeling tools. Implementation Set tools. Compiler/debugger tools, code analysis tools, test coverage analysis tools, and test management tool. Deployment Set tools. Test automation tools, network management, commercial components (operating systems, GUI’s DBMS’s, networks, middleware, and installation tools.

Life-cycle Focus on Artifact Sets

Life-cycle Evolution of the Sets

Management Artifacts Work Breakdown Structure (WBS) Business Case
Transforms the vision into economic terms. Release Specifications Includes evaluation criteria for intermediate and final releases. Software Development Plan (SDP) Schedules, releases, processes, resources, environments, organization, key personnel, manning, change management, quality control, standards and procedures.

Management Artifacts (cont’d)
Release Descriptions Functions, performance evaluations, test results, issues, follow-up action needs. Status Assessments Include review of resources, personnel/staffing actions, financial data, top issues, action items, technical progress, major milestone plans and results, customer issues, look-ahead.

Management Artifacts (cont’d)
Software Change Orders Software Problem Reports and Tracking Deployment Document Transition plans, marketing plans, sales plans, and training course plans. Environment Defines the development and maintenance environments. Includes requirements management, visual modeling, document automation, host and target programming tools, automated regression testing, integrated change management and defect tracking.

Artifact Sequences

Engineering Artifacts
Vision Document The source for capturing the expectations among stakeholders. Written from the users’ perspective. Focus is on essential features of the system, and the acceptable levels of quality. Includes the operational concept. Architecture Description Software Users Manual Contains installation procedures, usage procedures and guidance, operational constraints, and a user interface description. Written by the test team.

Artifacts Summary Artifacts of modern software development may be divided into five sets Management, Requirements, Design, Implementation and Deployment. Emphasis changes from the Engineering Stage to the Production Stage, but all artifacts should evolve as work progresses. Artifacts provide the basis for managing development of the products of the software project.

Model-based Software Architectures

Review - Overview of the Artifact Sets

Review - Life-cycle Evolution of the Sets

Review - Artifact Sequences

Topics Software Architectures Software Architecture Descriptions
Management perspective. Technical perspective. Software Architecture Descriptions Five views. Software Architecture Baselines

Software Architecture
“An architecture is the software system design”. But, unlike the architecture of a building, there are… No irrefutable first principles for developing the architecture. No stable laws of physics to rely on. There are only heuristic and fuzzy guidelines. However, like a building, your project will rise or fall on the quality of the architecture. So….emphasize and promote architecture evolution through prototyping and demonstrations.

Architecture: A Management Perspective (Royce)
Intangible design concept, system design as opposed to component design. Architecture Baseline Tangible artifacts across all engineering artifact sets that capture vision and basic design. Architecture Description Basic information extracted from the design models. Communicates how the intangible concept is realized in the tangible artifacts.

Architecture: A Management Perspective (cont’d)
A stable architecture represents a major milestone – the transition from engineering to production. A mature and demonstrable architecture forms the basis for predictable planning for project completion.

Architecture: A Technical Perspective
Software architecture encompasses: The elements and components of a system. Their collection into subsystems. Their functions. Their behavior. Their interactions. The overall control of the system.

Engineering Models Requirements Model Design Model
Addresses behavior of the system as seen by end users, analysts, and tester. Design Model Addresses architecture of the system and design of the components within the architecture Includes functional structure, concurrency structure, implementation structure, and execution structure. Design model shows the system as seen by the developers.

Architecture

Five Views of the System
Use Case view Shows how the system’s critical use cases are realized by elements of the design model. Design view Addresses basic structure and functionality. Process view Shows run-time interactions among elements, control, inter- process communication, and state management. Component view Describes the elements of the software system. Uses the perspective of the integrators and release management personnel. Deployment view Addresses the executable realization of the system. Shows the physical resources and physical topology.

Architectural Baseline
Conventional process Architectural baseline is same as architecture description. Realized as document, without rigorous design notation.no representation in other engineering design sets to validate the integrity of the description. Modern process Architecture evolves in iterative fashion. Baseline contains executable prototypes to demonstrate evolving capabilities. Stable, demonstrable architecture is transition point to production stage.

Architectural Baseline Contents
Requirements Critical use cases, system- level quality objectives, priority relationships among features and qualities. Design Names, attributes, structures, behaviors, groupings, and relationships of classes and components. Implementation Source component inventory and bill of materials of all primary components. Deployment Executable components sufficient to demonstrate the critical use cases and the risks in the project.

Workflows of the Process

Topics Software Process Workflows Iteration Workflows

Key Principles Revisited
Architecture-first approach Requirements, analysis, design, implementation and assessment activities performed before construction phase. Downstream focus on completeness and quality. Iterative life-cycle process Two or more iterations each workflow. Round-trip engineering Environment activities raised to a first-class workflow. Demonstration-based approach Implementation and assessment activities are initiated early, reflecting emphasis on constructing executable subsets of the evolving architecture.

Seven Software Process Workflows
Management Controlling the process. Environment Automating the process. Requirements Analysis and evolving requirements artifacts. Design Modeling and evolving the architectures and design artifacts. Implementation Programming and evolving the implementation and deployment artifacts. Assessment Assessing trends in process and product quality. Deployment Transitioning the end products to the use.

Activity Levels Across Phases

Artifacts Associated with Workflows

Not Carried Over from Conventional Process (Royce)
Documentation emphasis Most documentation should be a by-product. Quality assurance Quality assurance is worked into all activities, not accomplished as a separate workflow.

Management Workflows Environment Workflows

Iteration Workflows

Iterations An iteration is defined in terms of a set of allocated usage scenarios. Needed components are developed and integrated. Demonstrations are made. Assessments are made. Results are prepared for next iteration. Activities are carried on currently. An iteration workflow includes a sequence of seven elements.

Iteration Emphasis Inception and Elaboration Phases Construction Phase
Emphasis is on management, requirements, and design activities. Construction Phase Emphasis of in design, implementation, and assessment. Transition Phase Emphasis is on assessment and deployment.

Iteration Workflow Design
Evolving the architecture and baseline design, design and test models, updating design set artifacts. Implementation Developing and acquiring new components, integration and testing. Assessment Evaluating the results of the iteration: compliance, quality, performance. Change decisions. Deployment Transitioning the release to users, IV&V contractor, customer, regulators. Management element Planning for the release, use case selection, detail assignments. Environment Evolving the change order database for new baselines for product, test and environment components. Requirements Analyzing the requirements artifact set, elaborate use cases and evaluation criteria.

Iteration Workflow

Iteration Emphasis Across the Life Cycle

Iteration versus Increment
An iteration represents the state of the overall architecture and the complete deliverable system. An increment represents the current work in progress that will be combined with the preceding iteration to form the next iteration.

Typical Build Sequence

General Comments The preceding material is somewhat simplistic in three basic ways. Releases There is not just one basic release for an iteration. Also you may have different releases for the software development laboratory, possibly for different developmental hardware configurations, one for the hardware integration laboratory, one for the project test and evaluation laboratory, one for quality control or manufacturing organization, one for the customer’s evaluation and demonstration laboratory, etc… Hardware Development Support The hardware group may make almost insatiable demands on the software group for ancillary software – drivers, I/O routines, instrumentation programs, debuggers, small test programs, analyzers, etc… Environment, Test, and other Support Software The customer may require delivery also for development tools, design models, and test tools and cases. Releases of these software elements will also have to be managed and controlled, concurrently with the basic project software.

In Summary….. The Conventional Software Development Process
Uses Waterfall Model (sequential steps). Is relatively easy to understand and control, at least for a while early in project development. Generally doesn’t work very well in real life. The Modern Software Development Process Uses much concurrency and multiple iterations. Can be chaotic if not monitored and controlled very carefully. Requires very competent configuration management. Can be made to work well if the project is very well managed.

Checkpoints of the Process

Topics Major Milestones Minor Milestones Periodic Status Assessments

Review - Seven Software Process Workflows
Management Controlling the process. Environment Automating the process. Requirements Analysis and evolving requirements artifacts. Design Modeling and evolving the architectures and design artifacts. Implementation Programming and evolving the implementation and deployment artifacts. Assessment Assessing trends in process and product quality. Deployment Transitioning the end products to the use.

Review - Artifacts Associated with Workflows

Review - Iteration Workflow
Design Evolving the architecture and baseline design, design and test models, updating design set artifacts. Implementation Developing and acquiring new components, integration and testing. Assessment Evaluating the results of the iteration: compliance, quality, performance. Change decisions. Deployment Transitioning the release to users, IV&V contractor, customer, regulators. Management element Planning for the release, use case selection, detail assignments. Environment Evolving the change order database for new baselines for product, test and environment components. Requirements Analyzing the requirements artifact set, elaborate use cases and evaluation criteria.

Review - Typical Build Sequence

Management Reviews Major milestones Minor milestones
System-wide reviews at end of each of the four phases. Minor milestones Iteration-focused events to review iterations. Includes a release specification (release plan and evaluation criteria), and release description (results of the evaluation of the release.) Status assessments Periodic events to assess progress.

Checkpoints

Major Milestones Reviewers
Customers Schedules, budgets, feasibility, risk assessment, requirements, progress, compatibility. Users Requirements, usage scenarios, growth, quality. Architects Requirements changes, tradeoffs, completeness, balance. Developers Requirements details, consistency, resolution of risks, environment. Maintainers Sufficiency of product and documentation artifacts, understandibility, interoperability, environment. Others Regulators, IV&V contractor, subcontractors, associate contractors, sales, marketing.

Status Across Major Milestones

Life-Cycle Objectives Milestone
Occurs at end of Inception Phase. Includes: Plan, estimated cost and schedule, expected benefits, vision statement andcritical issues, operational concept. Contains draft architecture document. Contains a prototype architecture demonstration. Goal: Authorization to proceed to Elaboration Phase.

Life-Cycle Architecture Milestone
Goal: Demonstrate an executable architecture. Authorization to Proceed with the construction phase. Includes: Detailed plan for the construction phase, critical issues regarding requirements and the operational concept, baseline architecture, baseline vision, baseline software development plan, evaluation criteria for the initial operational capability milestone.

Readiness for Architecture Milestone
Critical use cases defined and scenarios prepared for evaluating architecture Stable architecture baselined and demonstrated. Risk profile is well understood. Common understanding of outstanding risks, and mitigation plans fully elaborated. Development plans for remaining phases are defined.

Architecture Milestone Contents
Presentation and Overview of the current state of the software project. A configuration-controlled set of all engineering data for the engineering artifacts. An executable demonstration of capability.

Architecture Milestone Artifacts

Architecture Milestone Agenda

Initial Operational Capability Milestone
Goals Assess readiness to begin transition into customer and user sites. Authorize beginning of acceptance tests. Items for Milestone Installation instructions and issues, software version descriptions, user and operator manuals, support for user sites, test environment, and test software.

Product Release Milestone
Goal Assess the completion of software and its transition. Milestone contents Results of acceptance testing, open issues, installation issues, support issues.

Minor Milestones Primarily, iteration readiness reviews and iteration assessment reviews. Early iteration focus Design and analysis, discovery, experimentations, risk assessment. Later iteration focus Completeness, consistency, usage, and change management. Other minor milestones. Test readiness reviews, test results, special issues.

Typical Minor Milestones

Periodic Status Assessments
Assessments are crucial for focusing management attention on the health of the project. Generally status assessments are held each month or each quarter during the project. Preparations ideally should include no more than one day’s effort by the software project manager. (Use day-to-day material to prepare the presentation.) Assessments also can be used for project-to- project comparisons, and dissemination of best practices within the organization.

Status Assessment Reviews

Summary for Checkpoints of the Process
Checkpoints provide for control of the development process. Major Milestones are the Objectives, Architecture, Initial Operational Capability, and the Product Release Milestones. Minor Milestones are for iteration readiness and iteration results reviews. Periodic Assessment Reviews are for focusing management attention on the health of the project.

Software Management Disciplines Iterative Process Planning

Review –The Four Parts of the Course
Software Management Renaissance The conventional software management process. Five improvements to make the waterfall process work. A Software Management Process Framework Phases Artifacts Workflows Checkpoints Software Management Disciplines Planning Organization Automation Process control and instrumentation Tailoring Looking Ahead Modern project profiles Next-generation software economics Modern process transitions

Software Management Disciplines Iterative Process Planning

Review - Typical Minor Milestones

Review - Checkpoints

Review - Summary for Checkpoints of the Process
Checkpoints provide for control of the development process. Major Milestones are the Objectives, Architecture, Initial Operational Capability, and the Product Release Milestones. Minor Milestones are for iteration readiness and iteration results reviews. Periodic Assessment Reviews are for focusing management attention on the health of the project.

Part III – Software Management Disciplines
Planning Organization Automation Process control and instrumentation Tailoring

Topics Iterative Process Planning
Work Breakdown Structures (WBS) Planning Guidelines The Cost and Schedule Estimating Process The Iterative Planning Process Pragmatic Planning

Conventional WBS

Problems With Conventional WBS
No way to track ratio of productive activities to overhead activities. No tracking of percentage of effort expended in rework. No tracking of percentage of cost expended in software capital equipment. Noo tracking of productive testing versus unproductive integration. No tracking of cost of release N as a basis for planning release N+1.

Recommended WBS First Level Second Level Third Level
Workflows for WBS elements. Can be allocated to single teams. Second Level Defined for each phase of the life cycle. Third Level Focus on the activities that produce the artifacts of each phase.

Work Breakdown Structure

WBS (cont’d)

Tailoring of the WBS Scale Larger projects have more levels.
Organizational Structure Subcontractors or associate contractors require additional management subelements. Degree of Custom Development Fully custom requires more in design and implementation to manage risks. Business Context Large contractual projects generally require additional levels for management and accounting purposes. Precedent Experience Projects should exploit existing work and WBS development.

WBS Budgeting

Effort and Schedule By Phase

Iterations Inception stage Elaboration stage Construction stage
Prototypes, critical use cases, existing components, custom component prototypes. Elaboration stage Architecture, initialization, scenarios, peak load conditions, worst case control flow, fault tolerance. Construction stage Alpha and beta releases, execution of all critical cases, 95% of capabilities demonstrated. Transition stage Resolve all defects, incorporate beta feedback, incorporate performance improvements.

Evolution of Planning

Cost and Schedule Estimating Steps – Top Down
1. Software project manager characterizes overall size, process, environment, people and quality. 2. Software manager makes a macro-level estimate of effort and schedule using software cost estimation model. 3. Software manager partitions the effort in top- level WBS. 4. Subproject managers decompose each WBS elemnt into lower levels.

Cost and Schedule Estimating Steps – Bottom Up
Lower level WBS elements are elaborating into detailed tasks by responsible WBS element managers. Estimates are combined and integrated into higher level WBS elements. Comparisons are made with the top down budgets and schedule milestones. Large differences are reconciled to converge on agreements.

Planning Balance Across Life-Cycle

General Observations Top down budgets and schedules tend to be overly optimistic. Bottom up budgets and schedules tend to be overly pessimistic. During Engineering Stages, top down estimates dominate. During Production Stages, bottom up estimates dominate.

Final Comments on Planning
The book emphasizes three perspectives: Planning, requirements, architecture. The end products with these perspectives are a software development plan, a requirements specification, and an architecture description document. On most successful projects, these thhree products are not very important once they have been produced. Rarely used by performers on a day-to-day basis, they are not very interesting to the end user, and the paper is just the tip of the iceberg with respect to the details that underlie them.

Topics Line-Of-Business Organizations Project Organizations
Evolution of Organizations

Final Comments on Planning (cont’d)
HOWEVER, The act of planning is extremely important to project success. It provides a framework and forcing function for making decisions. It ensures buy-in by stakeholders and performers. It transforms subjective, generic process frameworks into objective processes. Finally, plans are not just for managers. An open and visible planning process results in more ownership among all team members who execute the plan.

Software Management Disciplines
Project Organization and Responsibilities

Topics Line-Of-Business Organizations Project Organizations
Evolution of Organizations

Organization Line-of-Business Project both
Organize for return on investment, new business discriminators, market diversification, and profitability. Project Organize for cost, schedule and quality of specific deliverables. both Organize for career growth, job satisfaction, and opportunity for employees

Line of-Business Organization

Project Organization and Responsibilities

Infrastructure Project administration Engineering skill centers
Time accounting systems, contracts, pricing, terms and conditions, corporate information systems integration. Engineering skill centers Custom tools repository, bid and proposal support, research and development. Professional development Internal training, personnel recruitment, personnel skills database, library, technical publications.

Software Management Team Activities

Software Management Team
Primary concern: Balance for delivering to stakeholders – customers, higher management, users, developers. Main responsibilities: Planning, execution, adaptation, resource management, setting priorities, controlling, taking responsibility for quality.

Software Architecture Team Activities

Architecture Team Domain experience Software technology
To produce an architecture and design and a use case view. Software technology To produce a process view (concurrency and control, and component and deployment views.

Software Development Team Activities

Development Team Skill Set
Commercial component Specialists with detailed knowledge of commercial components. Database specialists Graphical user interfaces Display organization, user interactions, outputs, control needs. Operating systems and networking Specialists in execution of multiple software objects on a network of hardware resources; control issues for initialization, synchronization, resource sharing, and inter-object communications. Domain applications

Software Assessment Team Activities

Software Project Team Evolution

Team Emphasis Inception team Elaboration team Construction team
Planning. Elaboration team Architecture. Construction team Software development and assessment. Deployment team Customer focus

Software Management Disciplines
Process Automation

Topics Automation building blocks The project environment
Round-trip engineering Change management Infrastructures Stakeholder environments

Levels of Automation Meta-process Macro-process Micro-process
Organization’s policies, procedures, and practices for the line of business Inventory of preferred tools, artifact templates, guidelines, project repositories, skill sets, library. Macro-process Project’s policies, procedures, practices, project environment and collection of tools to produce artifacts. Micro-process Project team’s policies, etc., for achieving an artifact. Tools.

Topics Automation building blocks The project environment
Round-trip engineering Change management Infrastructures Stakeholder environments

Automation and Tools

Workflow Tools Management Environment Requirements Design
Project planning and control, on-line status assessments. Environment Configuration management and change control Requirements Integrate documents and visual representations for specifications and use cases. Design Visual modeling Implementation Integration of programming environment with change management tools, visual modeling tools, and test automation tools. Assessment and deployment Test automation, test management, and defect tracking tools.

The Three Project Environments
The Prototype Environment Architecture testbed Performance trade-offs Technical risk analysis Make/buy tradeoffs Fault tolerance trades Transitioning risks Test scenarios The Development Environment Development tools Round-trip engineering tools The Maintenance Environment Mature version of the development environment

Four Important Environment Disciplines
Integration of tools to support round-trip engineering for iterative development. Change management automation to manage multiple iterations AND change freedom. Infrastructure to enable environments derived from a common base. Promotes inter-project consistency, reuse of training, and reuse of lessons learned. Stakeholder environment extensions Provides cost savings for information exchange and approvals for engineering artifacts.

Round-trip Engineering
Primary reason: allow freedom in changing software engineering data sources. New needs for automation: Heterogeneous components, platforms, languages, complexity of building, controlling and maintaining large-scale webs of components.

Round-trip Engineering

Change Management Change management is more critical in modern processes. Artifacts are begun early, use rigor, and evolve over time. Software Change Orders (SCO) are used to create, modify, or obsolesce components. Change Orders are used to track status and performance.

Software Change Order

Configuration Control
Configuration Control Board Manages releases Makes change decisions Membership Software manager(s), system engineer (sometimes), key software architect (sometimes), customer representatives. General comment It’s never dull! Can be the most fun and exciting software management job of all.

Release History

Representative Changes

Infrastructure Organizational Policy Three Levels
Process definition – major milestones, intermediate artifacts, engineering repositories, metrics, roles and responsibilities. What gets done, when does it get done, who does it, how do we know that it is adequate (checkpoints, metrics and standards of performance. Three Levels Highest: long-term process improvement, general technology, education, mandatory quality control. Intermediate: domain- specific technology, reuse of components, processes, training, tools, and personnel. Lowest: efficiency items, project-specific training, compliance with customer requirements and business unit standards.

Organization Environment
Provides answers as to how things get done. Provide tools and techniques to automate the process. Standardized tool selections. Standard notations for artifacts. Tool adjuncts such as artifact templates (architecture description, evaluation criteria, release descriptions, status assessments Activity templates (iteration planning, major milestones, configuration control boards.

Organization Environment (cont’d)
Additional components Reference library for planning, etc. Existing case studies Project artifacts library Audit and compliance traceability frameworks.

Stakeholder Environment
Stakeholders will participate. Participation should be constructive and value-added to the development. On-line extension to stakeholder environment enables hands-on evaluations, use of same tools to manage and monitor the project, and minimizes customer travel and paper exchanges.

Extension to Stakeholder Domain

Software Management Disciplines Project Control and Process Automation

Extension Issues How much access freedom is supported?
Who pays for the environment and tool investments. How secure is the information exchange. How is change management synchronized. How to avoid abuse by customer. How to avoid disruption to the development.

Software Management Disciplines Project Control and Process Automation

Topics Seven Core Metrics Management Indicators Quality Indicators
Life Cycle Expectations Pragmatic Software Metrics Metrics Automation

Basic Themes for Modern Software Management
Getting design right by architecture first. Managing risk through iterative development. Reducing complexity with components-based techniques. Making progress and quality tangible through instrumented change management. Automating overhead and bookkeeping through use of round-trip engineering and integrated environment.

Goals of Software Metrics
An accurate assessment of progress to date. Insight into the quality of the evolving software product. A basis for estimating the cost and schedule for completion with increasing accuracy over time.

Seven Core Metrics

Metrics Characteristics
They are simple, objective, easy to collect, easy to interpret, and hard to misinterpret. Collection can be automated and non- intrusive. Assessment is continuous and non-subjective. They are useful to both management and engineering personnel for communicating progress and quality in a consistent format. Their fidelity improves across the life cycle.

Three Basic Management Metrics
Technical progress Financial status Staffing progress Financial and staffing metrics are easy. They always have been easy. The real problem is to measure technical progress with objectivity.

Typical Project Progress

Three Progress Metrics
Software architecture team: number of use cases demonstrated. Software development team: number of source lines of code under configuration management number of change orders closed Software assessment team: Number of change orders opened Test hours executed Evaluation criteria met Software management team: Milestones completed.

Earned Value System

Staffing Profile

Staffing and Team Dynamics
Metric: percent staffed. Metric: staffing momentum additions versus attrition. Glaring indicator of future trouble: Unplanned attrition. Usually due to personnel dissatisfaction with management, lack of teamwork, or high probability of failure to meet objectives.

Typical Project Progress

Four Quality Indicators
Change traffic and stability Provides insight into stability, convergence toward stability, predictability of completion Breakage and Modularity Breakage: extent of change needed. Modularity: average breakage trend over time. Rework and Adaptability Rework: amount of effort needed to fix. Adaptability: rework trend over time. Maturity Average time between faults.

Stability over Product Life Cycle

Modularity over Life Cycle

Adaptability over Life Cycle

Maturity over Life Cycle

Quality Indicator Characteristics
They are derived from the evolving products, not other artifacts. They provide insight into waste. They are dynamic for an iterative process. Focus is on trends and changes in time. Combination of current value and trends provide tangible indicators for effective management action.

Metrics Evolution over Life Cycle

Metrics Classes

Comment on Metrics Metrics usually display the effects of problems, not the underlying causes of problems. Reasoning and synthesis are required for solution. Although measuring is useful, it doesn’t do any thinking for the decision makers. Value judgments can not be make by metrics; they must be left to smarter entities such as software project managers. However, metrics can provide data to help ask the right questions, understand the context, and make objective decisions.

Metrics Automation – the Software Project Control Panel
On-line version of status of artifacts. Display panel that integrates data. A “dashboard”. Display for – project manager (overall values) test manager (status of an upcoming release) Configuration Manager (change traffic) etc.

Software Project Control Panel

Summary for Project Control and Instrumentation
Progress toward project goals and quality of products must be measurable. The most useful metrics are extracted from the evolving artifacts. Management and quality indicators must be used continuously as project proceeds. Trends and status measures must be used together. Technical progress is the most difficult item to measure.

Tailoring the Process

Topics Process Discriminants for Tailoring
Small-Scale Project versus Large-Scale Project

Two Primary Dimensions of Process Variability

Priorities for Tailoring

Project Scale Management is more important in the large projects than in the small projects. Large projects have numerous mundane jobs, especially in the overhead workflows, and more communications. The probability of recruiting, maintaining, and retaining a large number of exceptional people is small. The number of people needed is more important than the project cost for tailoring the project. Size is the most important parameter in the effort formula (generally, lines of source code) and in determining project scale and the number of people needed.

Process Discriminators – Project Size

Process Discriminators – Stakeholder Cohesion

Process Discriminators - Flexibility

Process Maturity

Architecture Risk

Domain Experience

Small Versus Large Projects

Workflow

Key Discriminators for Success
Design is key for both small and large projects. Small commercial projects – good design provides good marketability and good profits. Large projects – good design provides for predictable, cost-efficient construction. Management. Most important for large projects where consequences of planning and resource errors can be catastrophic. Deployment. Most important in small projects where there is a large and diverse customer base.

Artifacts

Review - Looking Forward

Topics Continuous Integration Early Risk Resolution
Evolutionary Requirements Teamwork Among Stakeholders Top Ten Software Management Principles

Modern Practice – Resolve These Issues
Protracted integration and late design changes. Late risk resolution. Analysis paralysis due to requirements- driven design. Adversarial stakeholder relationships. Focus on documents rather than product.

Basic Solution Continuous integration. Early risk resolution.
Evolutionary requirements. Teamwork among stakeholders.

Modern Project Profile

Conventional versus Modern Workflows

The 80/20 Rule 80% of engineering for 20% of requirements.
Understand the 20% before committing full resources. 80% of cost due to 20% of components. Do the 20% components first. 80% of errors caused by 20% of components. 80% of scrap and rework caused by 20% of changes. Do change-critical 20% first. 80% of resources for 20% components. Do 20% components first. 80% of progress by 20% of people. Make best possible initial team.

Risk Exposure

Evolutionary Requirements
Old Way Requirements were further subdivided, and again, until very lowest level. Then, the design was accomplished by making components to match the low level requirements. This leads to functional design which is traceable to requirements, but is brittle and non- optimal. New Way Use top-level requirements to derive an architecture first. Then develop design. Finally, do requirements traceability.

Software Component Organization

Teamwork Among Stakeholders
Old Way Distrust, lack of understanding regarding requirements and impact. Non-optimal products. New Way An iterative process, collaborative with stakeholders, so that balance between requirements and development is achieved. Depends on demonstrations, extension to stakeholder domains.

Major Milestone Results

Royce’ Top Ten Principles for a Modern Process
1. Architecture first. Iterative process. Component-based development. Change management environment. 5. Round-trip engineering. Use model-based notation for artifacts. Instrument the process for objective quality control. Demonstration-based approach. Release iterations with evolving level of detail. 10. Use a configuration process that is scalable for improved ROI.

Balanced Application of Modern Principles

Software Project Management

Similar presentations

Presentation on theme: "Software Project Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Project Management

Similar presentations

Presentation on theme: "Software Project Management"— Presentation transcript:

Similar presentations

About project

Feedback