�Software Project Management�(SPM)

Course Objectives

• This course is centered on unique aspects of software project management at three levels: Organizational management, Infrastructure management and project management and measurement of the Project, and how these are applied to actual software projects.

​

• Understand the fundamental principles of Software Project management & will also have a good knowledge of responsibilities of project manager and how to handle these.�
• Be familiar with the different methods and techniques used for project management. �

Course Outcomes

At the end of this course, the student will be able to

• Identify the process of Conventional Software Management the Evolution and Improvement of Software Economics.
• Describe the basic s/w processes, Cost estimation and improvement in s/w Economics.
• Summarize Life cycle phases and Artifacts of the process in Software project management.
• Apply Workflows and checkpoints in Iterative Process planning.
• Illustrate Project Organizations, process automation building blocks and metrics in assessing Software Quality.

​

Introduction

• Software Engineering
• Software Testing Methodologies
• Object Oriented Analysis and Design

​

• What is Software Project Management?

What is Software?

• Software is a set of instructions, data or programs used to operate computers and execute specific tasks.
• Software is a set of programs (sequence of instructions) that allows the users to perform a well-defined function or some specified task.

​

• System Software
• Programming Software
• Application Software

What is Project?

• A Project is a group of tasks that need to complete to reach a clear result. A project also defines as a set of inputs and outputs which are required to achieve a goal.�
• Projects always begin with a problem. The project is to provide the solution to this problem.�
• When the project is finished it must be evaluated to determine whether it satisfies the objectives and goals.

​

Project Characteristics

• One clear objective
• A well defined set of end results
• Goal oriented
• End product or service must result�
• Finite
• Fixed timeline, start date, end date, milestone dates�
• Limited
• Budget, Resources, Time�
• Life Cycle
• Recognizable sequence of phases

​

What is Management?

• Management can be defined as all activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of others in order to achieve objectives or complete an activity.
• Management functions can be categorized as
• Planning
• Organizing
• Staffing
• Directing
• Controlling

​

​

Management Functions

• Planning�Predetermining a course of action for accomplishing organizational Objectives
• Organizing�Arranging the relationships among work units for accomplishment of objectives and the granting of responsibility and authority to obtain those objectives
• Staffing�Selecting and training people for positions in the organization
• Directing�Creating an atmosphere that will assist and motivate people to achieve desired end results
• Controlling�Establishing, measuring, and evaluating performance of activities toward planned objectives

​

What is Software Project Management?

• Software project management is an art and discipline of planning and supervising software projects.
• It is a sub-discipline of software project management in which software projects planned, implemented, monitored and controlled.

There are three needs for software project management. These are:

• Time
• Cost
• Quality

Unit-I Syllabus

• Conventional Software Management: The waterfall model, conventional software management performance.
• Evolution of Software Economics: Software Economics, pragmatic software cost estimation.
• Improving Software Economics: Reducing Software product size, improving software processes, the principles of conventional software Engineering, principles of modern software management, transitioning to an iterative process.

Conventional Software Management

• The waterfall model.

​

• Conventional software management performance.

CONVENTIONAL SOFTWARE MANAGEMENT�

Conventional Software Management

• Conventional software management practices are sound in theory, but practice is still tied to archaic (outdated)technology and techniques.
• Conventional software economics provides a benchmark of performance for conventional software management principles.
• 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, monitors, and control software development.

​

Conventional Software Management

Three important analyses of the state of the software engineering industry are

• Software development is still highly unpredictable. Only about 10% of software projects are delivered successfully within initial budget and schedule estimates.
• 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.

The three analyses provide a good introduction to the magnitude of the software problem and the current norms for conventional software management performance.

The Waterfall Model

• Most software engineering texts present the waterfall model as the source of the "conventional" software process.

In Theory

• It provides an insightful and concise summary of conventional software management.

The Waterfall Model

Three main primary points are

1. There are two essential steps common to the development of computer programs: analysis and coding.

​

​

​

​

​

​

Analysis and coding both involve creative work that directly contributes to the usefulness of the end product.

Analysis

Coding

The Waterfall Model

2. In order to manage and control all of the intellectual freedom associated with software development, one must introduce several other "overhead" steps, including system requirements definition, software requirements definition, program design, and testing. These steps supplement the analysis

and coding steps.

The Waterfall Model

• Below Figure illustrates the resulting project profile and the basic steps in developing a large-scale program.

The Waterfall Model

3. The basic framework described in the waterfall model is risky and invites failure. The testing phase that occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. The resulting design changes are likely to be so disruptive that the software requirements upon which the design is based are likely violated. Either the requirements must be modified or a substantial design change is warranted.

The Waterfall Model

• Five necessary improvements for waterfall model are:

The Waterfall Model

• Five necessary improvements for waterfall model are:-
• Program design comes first: Insert a preliminary program design phase between the software requirements generation phase and the analysis phase. By this technique, the program designer assures that the software will not fail because of storage, timing, and data flux (continuous change).

The Waterfall Model

• Document the design: The amount of documentation required on most software programs is quite a lot, certainly much more than most programmers, analysts, or program designers are willing to do if left to their own devices.
• Do it twice: If a computer program is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations are concerned.

The Waterfall Model

• Plan, control, and monitor testing: Without question, the biggest user of project resources-manpower, computer time, and/or management judgment-is the test phase. This is the phase of greatest risk in terms of cost and schedule.
• Involve the customer: It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. These include a "preliminary software review" following the preliminary program design step, a sequence of "critical software design reviews" during program design, and a "final software acceptance review".

In Practice

• Some software projects still practice the conventional software management approach.
• It is useful to summarize the characteristics of the conventional process as it has typically been applied.
• Projects destined for trouble frequently exhibit the following symptoms:
• Protracted integration and late design breakage.
• Late risk resolution.
• Requirements-driven functional decomposition.
• Adversarial(conflict or opposition)stakeholder relationships.
• Focus on documents and review meetings.

Protracted Integration and Late Design Breakage

• For a typical development project that used a waterfall model management process, Figure 1-2 illustrates development progress versus time. Progress is defined as percent coded, that is, demonstrable in its target form.
• The following sequence was common:
• Early success via paper designs and thorough (often too thorough) briefings.
• Commitment to code late in the life cycle.
• Integration nightmares (unpleasant experience) due to unforeseen implementation issues and interface ambiguities.
• Heavy budget and schedule pressure to get the system working.
• Late shoe-homing of no optimal fixes, with no time for redesign.
• A very fragile, unmentionable product delivered late.

In the conventional model, the entire system was designed on paper, then implemented all at once, then integrated. Table 1-1 provides a typical profile of cost expenditures across the spectrum of software activities

Late Risk Resolution

• A serious issue associated with the waterfall lifecycle was the lack of early risk resolution. Figure 1.3 illustrates a typical risk profile for conventional waterfall model projects.
• It includes four distinct periods of risk exposure, where risk is defined as the probability of missing a cost, schedule, feature, or quality goal. Early in the life cycle, as the requirements were being specified, the actual risk exposure was highly unpredictable.

Requirements-Driven Functional Decomposition

• This approach depends on specifying requirements completely and unambiguously before other development activities begin.
• Specification of requirements is a difficult and important part of the software development process.
• Another property of the conventional approach is that the requirements were typically specified in a functional manner.
• Built into the classic waterfall process was the fundamental assumption that the software itself was decomposed into functions; requirements were then allocated to the resulting components.

Figure 1-4 illustrates the result of requirements-driven approaches: a software structure that is organized around the requirements specification structure.

Adversarial Stakeholder Relationships

• The conventional process tended to result in adversarial stakeholder relationships.
• The following sequence of events was typical for most contractual software efforts:
• The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval.
• The customer was expected to provide comments (typically within 15 to 30 days).
• The contractor incorporated these comments and submitted (typically within 15 to 30 days) a final version for approval.

Focus on Documents and Review Meetings

• The conventional process focused on producing various documents that attempted to describe the software product.
• Contractors were driven to produce literally tons of paper to meet milestones and demonstrate progress to stakeholders.
• Typically, presenters and the audience reviewed the simple things that they understood rather than the complex and important issues.
• Most design reviews therefore resulted in low engineering value and high cost in terms of the effort and schedule involved in their preparation and conduct.

Table 1-2 summarizes the results of a typical design review.

�Conventional Software Management Performance

• Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective characterization of the state of software development.
• 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.

​

​

​

Conventional Software Management Performance

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. Software-system products (i.e., system of systems) cost 9 times as much.
9. Walkthroughs catch 60% of the errors.
10. 80% of the contribution comes from 20% of the contributors.
• 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 software scrap and rework is caused by 20% of the errors.
• 80% of the resources are consumed 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.

​

​

​

����Evolution of Software Economics

Evolution of Software Economics

• Software Economics

​

• Pragmatic Software Cost Estimation

Software Economics

• Software Economics is mature research area that generally deals with most difficult and challenging problems and issues of valuing software and determining or estimation costs usually involved in its production.
• Software economics is the field that seeks to enable significant improvements in software design and engineering through economic reasoning about product, process, program, and portfolio and policy issues.

Software Economics

• Most software cost models can be abstracted into a function of five basic parameters: size, process, personnel, environment, and required quality.
• The size of the end product (in human-generated components), which is typically quantified in terms of the number of source instructions or the number of function points required to develop the required functionality.
• The process used to produce the end product, in particular the ability of the process to avoid non- value-adding activities (rework, bureaucratic delays, communications overhead).
• The capabilities of software engineering personnel, and particularly their experience with the computer science issues and the applications domain issues of the project.

​

Software Economics

4. The environment, which is made up of the tools and techniques available to support efficient software development and to automate the process.
5. The required quality of the product, including its features, performance, reliability, and adaptability.

​

The relationships among these parameters and the estimated cost can be written as follows:

Effort = (Personnel) (Environment) (Quality) ( Size^process)

• One important aspect of software economics (as represented within today's software cost models) is that the relationship between effort and size exhibits a diseconomy of scale.
• The diseconomy of scale of software development is a result of the process exponent being greater than 1.0.

​

Software Economics

• Figure 2-1 shows three generations of basic technology advancement in tools, components, and processes. The required levels of quality and personnel are assumed to be constant.
• The three generations of software development are defined as follows:
• Conventional: 1960s and 1970s, craftsmanship. Organizations used custom tools, custom processes, and virtually all custom components built in primitive languages. Project performance was highly predictable in that cost, schedule, and quality objectives were almost always underachieved.

​

​

​

Software Economics

2. Transition: 1980s and 1990s, software engineering. Organizations used more-repeatable processes and off- the-shelf tools, and mostly (>70%) custom components built in higher level languages. Some of the components (<30%) were available as commercial products, including the operating system, database management system, networking, and graphical user interface.

3. Modern practices: 2000 and later, software production. This book's philosophy is rooted in the use of managed and measured processes, integrated automation environments, and mostly (70%) off-the-shelf components. Perhaps as few as 30% of the components need to be custom built

Software Economics

• Organizations are achieving better economies of scale in successive technology eras-with very large projects (systems of systems), long-lived products, and lines of business comprising multiple similar projects. Figure 2-2 provides an overview of how a return on investment (ROI) profile can be achieved in subsequent efforts across life cycles of various domains.

​

Pragmatic Software Cost Estimation

• One critical problem in software cost estimation is a lack of well-documented case studies of projects that used an iterative development approach.
• Software industry has inconsistently defined metrics or atomic units of measure, the data from actual projects are highly suspect in terms of consistency and comparability.
• It is hard enough to collect a homogeneous set of project data within one organization; it is extremely difficult to homog- enize data across different organizations with different processes, languages, domains, and so on.

​

Pragmatic Software Cost Estimation

• There have been many debates among developers and vendors of software cost estimation models and tools.
• Three topics of these debates are of particular interest here:
• Which cost estimation model to use?
• Whether to measure software size in source lines of code or function points.
• What constitutes a good estimate
• There are several popular cost estimation models (such as COCOMO, CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20), COCOMO is also one of the�most open and well-documented cost estimation models.

Pragmatic Software Cost Estimation

• Figure 2-3 illustrates the predominant practice: The software project manager defines the target cost of the software, and then manipulates the parameters and sizing until the target cost can be justified.
• The process described in Figure 2-3 is not all bad. In fact, it is absolutely necessary to analyze the cost risks and understand the sensitivities and trade-offs objectively.
• It forces the software project manager to examine the risks associated with achieving the target costs and to discuss this information with other stakeholders.

​

​

Pragmatic Software Cost Estimation

• Good software cost 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, similar technologies, similar environments, similar quality requirements, and similar people.
• It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed.

​

Improve Software Economics

Improving Software Economics

• Five basic parameters of the software cost model are
1. Reducing the size or complexity of what needs to be developed.
2. Improving the development process.
3. Using more-skilled personnel and better teams (not necessarily the same thing).
4. Using better environments (tools to automate the process).
5. Trading off or backing off on quality thresholds.

​

These parameters are given in priority order for most software domains.

​

​

Table 3-1 lists some of the technology developments, process improvement efforts, and management approaches targeted at improving the economics of software development and integration.�

Reducing Software Product Size

• The most significant way to improve affordability and return on investment (ROI) is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material.
• Component-based development is introduced as the general term for reducing the "source" language size to achieve a software solution.
• 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 (statements).

​

Reducing Software Product Size

• Size reduction is the primary motivation behind improvements in higher order languages (such as C++, Ada 95, Java, Visual Basic), automatic code generators (CASE tools, visual modeling tools, GUI builders), reuse of commercial components (operating systems, windowing environments, database management systems, middleware, networks), and object-oriented technologies (Unified Modeling Language, visual modeling tools, architecture frameworks).
• The reduction is defined in terms of human-generated source material. In general, when size-reducing technologies are used, they reduce the number of human-generated source lines.

Languages

• Universal function points (UFPs) are useful estimators for language-independent, early life-cycle estimates.
• The basic units of function points are external user inputs, external outputs, internal logical data groups, external data interfaces, and external inquiries.
• SLOC metrics are useful estimators for software after a candidate solution is formulated and an implementation language is known.
• Some of these results are shown in Table 3-2.

Object-oriented Methods And Visual Modeling

• Object-oriented programming languages appear to benefit both software productivity and software quality.
• The fundamental impact of object-oriented technology is in reducing the overall size of what needs to be developed.
• People like drawing pictures to explain something to others or to themselves.
• When they do it for software system design, they call these pictures diagrams or diagrammatic models and the very notation for them a modeling language.

Object-oriented Methods And Visual Modeling

• Booch also summarized five characteristics of a successful object-oriented project.
• A ruthless focus on the development of a system that provides a well understood collection of essential minimal characteristics.
• The existence of a culture that is centered on results, encourages communication, and yet is not afraid to fail.
• The effective use of object-oriented modeling.
• The existence of a strong architectural vision.
• The application of a well-managed iterative and incremental development life cycle.

​

Reuse

• Reusing existing components and building reusable components have been natural software engineering activities since the earliest improvements in programming languages.
• With reuse in order to minimize development costs while achieving all the other required attributes of performance, feature set, and quality.
• Most truly reusable components of value are transitioned to commercial products supported by organizations with the following characteristics:
• They have an economic motivation for continued support.
• They take ownership of improving product quality, adding new features, and transitioning to new technologies.
• They have a sufficiently broad customer base to be profitable.

The cost of developing a reusable component is not trivial. Figure 3-1 examines the economic trade-offs. The steep initial curve illustrates the economic obstacle to developing reusable components.

Commercial Components

• A common approach being pursued today in many domains is to maximize integration of commercial components and off-the-shelf products.
• While the use of commercial components is certainly desirable as a means of reducing custom development, it has not proven to be straightforward in practice.
• Table 3-3 identifies some of the advantages and disadvantages of using commercial components.

​

Improving Software Processes

• Process is an overloaded term. Three distinct process perspectives are
• Metaprocess: an organization's policies, procedures, and practices for pursuing a software-intensive line of business. The focus of this process is on organizational economics, long-term strategies, and software ROI.
• Macroprocess: a project's policies, procedures, and practices for producing a complete software product within certain cost, schedule, and quality constraints. The focus of the macro process is on creating an adequate instance of the Meta process for a specific set of constraints.

​

​

Improving Software Processes

• Microprocess: a project team's policies, procedures, and practices for achieving an artifact of the software process. The focus of the micro process is on achieving an intermediate product baseline with adequate quality and adequate functionality as economically and rapidly as practical.
• Although these three levels of process overlap somewhat, they have different objectives, audiences, metrics, concerns, and time scales as shown in Table 3-4.

​

Improving Team Effectiveness

• Teamwork is much more important than the sum of the individuals. With software teams, a project manager needs to configure a balance of solid talent with highly skilled people in the leverage positions.
• Some maxims of team management include the following:
• A well-managed project can succeed with a nominal engineering team.
• A mismanaged project will almost never succeed, even with an expert team of engineers.
• A well-architected system can be built by a nominal team of software builders.
• A poorly architected system will flounder even with an expert team of builders.

​

Improving Team Effectiveness

• Boehm five staffing principles are
• The principle of top talent: Use better and fewer people.
• The principle of job matching: Fit the tasks to the skills and 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.

​

Improving Team Effectiveness

• Software project managers need many leadership qualities in order to enhance team effectiveness.
• The following are some crucial attributes of successful software project managers that deserve much more attention:
• Hiring skills
• Customer-interface skill
• Decision-making skill
• Team-building skill
• Selling skill

Improving Automation Through Software Environments

• The tools and environment used in the software process generally have a linear effect on the productivity of the process.
• Planning tools, requirements management tools, visual modeling tools, compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces provide crucial automation support for evolving the software engineering artifacts.
• Tools and automation generally allows improvements of 20% to 40% in effort.
• Tools and environments must be viewed as the primary delivery vehicle for process automation and improvement, so their impact can be much higher.

​

Improving Automation Through Software Environments

• Automation of the design process provides payback in quality, the ability to estimate costs and schedules, and overall productivity using a smaller team.
• Round-trip engineering describes the key capability of environments that support iterative development.
• Forward engineering is the automation of one engineering artifact from another, more abstract representation.
• Reverse engineering is the generation or modification of a more abstract representation from an existing artifact.

​

For example, it is easy to find statements such as the following from companies in a particular tool.

• Requirements analysis and evolution activities consume 40% of life-cycle costs.
• Software design activities have an impact on more than 50% of the resources.
• Coding and unit testing activities consume about 50% of software development effort and schedule.
• Test activities can consume as much as 50% of a project's resources.
• Configuration control and change management are critical activities that can consume as much as 25% of resources on a large-scale project.
• Documentation activities can consume more than 30% of project engineering resources.
• Project management, business administration, and progress assessment can consume as much as 30% of project budgets.

​

Achieving Required Quality

• Key practices that improve overall software quality include the following:
• 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.

​

​

​

Achieving Required Quality

• Using visual modeling and higher level languages that support architectural control, abstraction, reliable programming, reuse, and self-documentation
• Early and continuous insight into performance issues through demonstration-based evaluations
• Software best practices are derived from the development process and technologies. Table 3-5 summarizes some dimensions of quality improvement.

​

Achieving Required Quality

• Conventional development processes stressed early sizing and timing estimates of computer program resource utilization.
• Project inception
• Initial design review
• Mid-life-cycle design review
• Integration and test

Peer Inspections: A Pragmatic View

• Peer inspections are frequently over hyped as the key aspect of a quality system.
• In my experience, peer reviews are valuable as secondary mechanisms, but they are rarely significant contributors to quality compared with the following primary quality mechanisms and indicators, which should be emphasized in the management process:
• Transitioning engineering information from one artifact set to another, thereby assessing the consistency, feasibility, understandability, and technology constraints inherent in the engineering artifacts
• Major milestone demonstrations that force the artifacts to be assessed against tangible criteria in the context of relevant use cases

​

Peer Inspections: A Pragmatic View

• Environment tools (compilers, debuggers, analyzers, automated test suites) that ensure representation rigor, consistency, completeness, and change control.
• Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria, and requirements compliance.
• Change management metrics for objective insight into multiple-perspective change trends and convergence or divergence from quality and progress goals.
• Inspections are also a good vehicle for holding authors accountable for quality products.
• Therefore, the coverage of inspections should be across all authors rather than across all components.

​

​

The Principles of Conventional Software Engineering

1.Make quality #1.

2.High-quality software is possible.

3.Give products to customers early.

4.Determine the problem before writing the requirements.

5.Evaluate design alternatives.

6.Use an appropriate process model.

7.Use different languages for different phases.

8.Minimize intellectual distance.

9.Put techniques before tools.

10.Get it right before you make it faster.

11.Inspect code.

12.Good management is more important than good technology.

The Principles of Conventional Software Engineering

13.People are the key to success.

14.Follow with care.

15.Take responsibility.

16.Understand the customer's priorities.

17.The more they see, the more they need.

18.Plan to throw one away.

19.Design for change.

20.Design without documentation is not design.

21.Use tools, but be realistic.

22.Avoid tricks.

23.Encapsulate.

24.Use coupling and cohesion.

The Principles of Conventional Software Engineering

25.Use the McCabe complexity measure.

26.Don't test your own software.

27.Analyze causes for errors.

28.Realize that software's entropy increases.

29.People and time are not interchangeable.

30.Expect excellence.

 �The Principles of Modern Software Management

• Top 10 principles of modern software management. (The first five, which are the main themes of an iterative process, are summarized in Figure 4-1.)
• The principles are in priority order and the bold-faced italicized words are used as shorthand for these expanded definitions.
• Base the process on an architecture-first approach.
• Establish an iterative life-cycle process that confronts risk early.
• Transition design methods to emphasize component-based development.
• Establish a change management environment.
• Enhance change freedom through tools that support round-trip engineering.

​

The Principles of Modern Software Management

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 assess 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.
11. Table 4-1 maps top 10 risks of the conventional process to the key attributes and principles of a modern process.
12. Although the table contains gross generalities at a high level it provides an introduction to the principles of a modern process.

Transitioning to an Iterative Process

• The economic benefits inherent in transitioning from the conventional waterfall model to an iterative development process are significant but difficult to quantify.
• As one benchmark of the expected economic impact of process improvement, consider the process exponent parameters of the COCOMO II model.
• This exponent can range from 1.01 (virtually no diseconomy of scale) to 1.26 (significant diseconomy of scale).
• The parameters that govern the value of the process exponent are application precedentedness, process flexibility, architecture risk resolution, team cohesion, and software process maturity.

​

The following paragraphs map the process exponent parameters of COCOMO II to my top 10 principles of a modern process.

• Application precedentedness. For unprecedented systems, one of the key goals is to confront risks and establish early precedents, even if they are incomplete or experimental. This is one of the primary reasons that the software industry has moved to an iterative life-cycle process. Early iterations in the life cycle establish precedents from which the product, the process, and the plans can be elab-orated in evolving levels of detail.
• Process flexibility. Development of modern software is characterized by such a broad solution space and so many interrelated concerns that there is a paramount need for continuous incorporation of changes. These changes may be inherent in the problem understanding, the solution space, or the plans. A configurable process that allows a common framework to be adapted across a range of projects is necessary to achieve a software return on investment.

​

Transitioning to an Iterative Process

• Architecture risk resolution. Architecture-first development is a crucial theme underlying a successful iterative development process. An architecture-first and component-based development approach forces the infrastructure, common mechanisms, and control mechanisms to be elaborated early in the life cycle and drives all component make/buy decisions into the architecture process.
• Team cohesion. Successful teams are cohesive, and cohesive teams are successful. Advances in technology (such as programming languages, UML, and visual modeling) have enabled more rigorous and understandable notations for communicating software engineering information. These model- based formats have also enabled the round-trip engineering support needed to establish change freedom sufficient for evolving design representations.

​

Transitioning to an Iterative Process

• Software process maturity. The Software Engineering Institute's Capability Maturity Model (CMM) is a well-accepted benchmark for software process assessment. One of key themes is that truly mature processes are enabled through an integrated environment that provides the appropriate level of automation to instrument the process for objective quality control.

​