Cl Overview

My approach to metrics is similar to that of DeMarco, who proposes to measure software quality through the absence of spoilage DeMarco, 1982 . To remain technology- and project-independent, his definitions are purposely vague mine are quite explicit. Consistency of application is important for accurate interpretation, just as it is with cost estimation techniques. Software cost estimation has subjective inputs and objective outputs. My approach will define objective inputs, which may require...

Culture Shifts

Several culture shifts must be overcome to transition successfully to a modern software management process. For some of these adjustments, it will be difficult to distinguish between objective opposition and stubborn resistance. Nevertheless, there are general indications of a successful transition to a modern culture. This section discusses several of the rough indicators to look for in order to differentiate projects that have made a genuine cultural transition from projects that have only...

The Waterfall Model

Most software engineering texts present the waterfall model as the source of the conventional software process. I regard it more as a benchmark of that process. This section examines and critiques the waterfall model theory, then looks at how most of the industry has practiced the conventional software process. In reality, although the industry has ignored much of the theory, it has still managed to evolve many good practices (and some not-so-good practices), especially when they are used with...

Cco

+ Skilled people precedent domain experience - Stringent performance requirements unstable external interface Large scale, high performance, high reliability The CCPDS-R software process was tailored to exploit Ada and reusable middleware components in order to construct a distributed architecture rapidly. The NAS CSCI provided these primitive components and was initially developed on independent research and development funding before the CCPDS-R contract was awarded. These components were a...

Architectures Chapters Workflows Of The Process chapter Checkpoints Of The Process

Standardizing on a common process is a courageous undertaking for a software organization, and there is a wide spectrum of implementations. The process framework recommended in this book comprises only a handful of specific standards life-cycle phases, life-cycle artifacts, life-cycle workflows, and life-cycle checkpoints. These elements are key discriminators in making the transition from the conventional approach to an iterative, line-of-business approach. I have seen organizations attempt to...

Info

Although the overall test requirements were extremely complex, the CCPDS-R build structure accommodated a manageable and straightforward test program. Substantial informal testing occurred as a natural by-product of the early architecture demonstrations and the requirement that all components be maintained in a compilable format. Because compilable Ada was used as the primary format throughout the life cycle, most conventional integration issues such as data type consistency, program unit...

Transition design methods to emphasize componentbased development

The complexity of a software effort is mostly a function of the number of human-generated artifacts. Making the solution smaller reduces management complexity. 4. Establish a change management environment. The dynamics of iterative development, including concurrent workflows by different teams working on shared artifacts, necessitate highly controlled baselines. 5. Enhance change freedom through tools that support round-trip engineering. Automation enables teams to spend more time on...

Key Points

The progress toward project goals and the quality of software products must be measurable throughout the software development cycle. Metrics values provide an important perspective for managing the process. Metrics trends provide another. The most useful metrics are extracted directly from the evolving artifacts. Objective analysis and automated data collection are crucial to the success of any metrics program. Subjective assessments and manual collection techniques are likely to fail. 5....

Stakeholder Environment Development Environment

Workflow automation, metrics automation Change management, document automation Requirements management Visual modeling- Editor-compiler-debugger 1 I Test automation, defect tracking Configuration control board participation Artifact reviews, analyses, audits Independent alpha and beta testing Figure 12-6. Extending environments into stakeholder domains Environment Tools and Process Automation Technical artifacts are not just paper. Electronic artifacts in rigorous notations such as visual...

Evolution Of Organizations

The project organization represents the architecture of the team and needs to evolve consistent with the project plan captured in the work breakdown structure. Figure 11-7 illustrates how the team's center of gravity shifts over the life cycle, with about 50 of the staff assigned to one set of activities in each phase. A different set of activities is emphasized in each phase, as follows Inception team an organization focused on planning, with enough support from the other teams to ensure that...

Lineofbusiness Organizations

Figure 11-1 maps roles and responsibilities to a default line-of-business organization. This structure can be tailored to specific circumstances. The main features of the default organization are as follows Responsibility for process definition and maintenance is specific to a cohesive line of business, where process commonality makes sense. For example, the process for developing avionics software is different from the process used to develop office applications. Responsibility for process...

Pragmatic Planning

Even though good planning is more dynamic in an iterative process, doing it accurately is far easier. While executing iteration N of any phase, the software project manager must be monitoring and controlling against a plan that was initiated in iteration N - 1 and must be planning iteration N + 1. The art of good project-management is to make trade-offs in the current iteration plan and the next iteration plan based on objective results in the current iteration and previous iterations. This...

Planning Guidelines

Software projects span a broad range of application domains. It is valuable but risky to make specific planning recommendations independent of project context. It is valuable because most people in management positions are looking for a starting point, a skeleton they can flesh out with project-specific details. They know that initial planning guidelines capture the expertise and experience of many other people. Such guidelines are therefore considered credible bases of estimates and instill...

Disciplines

Chapter 10 ITERATIVE PROCESS PLANNING chapter u PROJECT ORGANIZATIONS AND RESPONSIBILITIES chapter 12 PROCESS AUTOMATION chapter is PROJECT CONTROL AND PROCESS INSTRUMENTATION chapter i4 TAILORING THE PROCESS Software management efforts span a broad range of domains. The chapters in Part III discuss the major disciplines necessary for an effective management workflow planning, organization, automation, and project control. These disciplines of software project management are not easy to define...

Periodic Status Assessments

Managing risks requires continuous attention to all the interacting activities of a software development effort. Periodic status assessments are management reviews conducted at regular intervals (monthly, quarterly) to address progress and quality indicators, ensure continuous attention to project dynamics, and maintain open communications among all stakeholders. The paramount objective of these assessments is to ensure that the expectations of all stakeholders (contractor, customer, user,...

Pragmatic Artifacts

Conventional document-driven approaches squandered incredible amounts of engineering time on developing, polishing, formatting, reviewing, updating, and distributing documents. Why There are several reasons that documents became so important to the process. First, there were no rigorous engineering methods or languages for requirements specification or design. Consequently, paper documents with ad hoc text and graphical representations were the default format. Second, conventional languages of...

Vision Document

The vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Whether the project is a huge military-standard development (whose vision could be a 300-page system specification) or a small, internally funded commercial product (whose vision might be a two-page white paper), every project needs a source for capturing the expectations among stakeholders. A project vision is meant...

Nextgeneration Cost Models

If none of the value propositions is an acceptable solution to the problem, further candidate solutions need to be pursued or the problem statement needs to change. The debate between function point zealots and source line zealots is a good indicator of the need for measures of both scale and size. I think function points are more accurate at quantifying the scale of the architecture required, while SLOC more accurately depicts the size of the components that make up the...

Tailoring the Process

Software management efforts span a broad range of domains. While there are some universal themes and techniques, it is always necessary to tailor the process to the specific needs of the project at hand. A commercial software tool developer with complete control of its investment profile will use a very different process from that of a software integrator on contract to automate the security system for a nuclear power plant. There is no doubt that a mature process and effective software...

Metrics Derivation

This section defines and describes in detail the necessary statistics to be collected, the metrics derived from these statistics, and some general guidelines for their interpretation. Appendix D provides detailed examples of a real-world application to illustrate further how such metrics can be used to manage and control a project. The derivations are not an obvious top-down progression rather, they resulted from substantial trial and error, numerous empirical analyses, intuition, and...

Iterative Process Planning

Like software development, project planning requires an iterative process. Like software, a plan is an intangible piece of intellectual property to which all the same concepts must be applied. Plans have an engineering stage, during which the plan is developed, and a production stage, when the plan is executed. Plans must evolve as the understanding evolves of the problem space and the solution space. Planning errors are just like product errors The sooner in the life cycle they are resolved,...

Modern Process Transitions

Successful software management is hard work. Technical breakthroughs, process breakthroughs, and new tools will make it easier, but management discipline will continue to be the crux of software project success. New technological advances will be accompanied by new opportunities for software applications, new dimensions of complexity, new avenues of automation, and new customers with different priorities. Accommodating these changes will perturb many of our ingrained software management values...

Minor Milestones

The number of iteration-specific, informal milestones needed depends on the content and length of the iteration. For most iterations, which have a one-month to six-month duration, only two minor milestones are needed the iteration readiness review and the iteration assessment review. For longer iterations, more intermediate review points may be necessary. For example, on projects with very formal test procedures that must be witnessed by other stakeholders, a test readiness review may be held...

Peer Inspections A Pragmatic View

Peer inspections are frequently overhyped 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...

Puk

CCPDS-R first demonstration activities and schedule The basic scope of the IPDR demonstration was defined in the CCPDS-R statement of work The contractor shall demonstrate the following capabilities at the NORAD Demo 1 system services, system initialization, system failover and recovery, system reconfiguration, test message injection, and data logging. These capabilities were fairly well understood by the customer and TRW. They represented the key components and use cases necessary...

Q

Risk profile of a conventional software project across its life cycle exposure was highly unpredictable. After a design concept was available to balance the understanding of the requirements, even if it was just on paper, the risk exposure stabilized. However, it usually stabilized at a relatively high level because there were too few tangible facts for a software manager to achieve an objective assessment. As the system was coded, some of the individual component risks got...

The Iteration Planning Process

So far, this discussion has dealt only with the application-independent aspects of budgeting and scheduling. Another dimension of planning is concerned with defining the actual sequence of intermediate results. Planning the content and schedule of the major milestones and their intermediate iterations is probably the most tangible form of the overall risk management plan. An evolutionary build plan is important because there are always adjustments in build content and schedule as early...

Maturity Questionnaire

The remainder of this section provides an SEI CMM perspective of the process framework presented in this book. I have used the SEI Maturity Questionnaire SEI, 1998 as a scenario for evaluating the completeness of the process framework from a well-accepted benchmark of process maturity. In the pages that follow, each quoted question is presented in italics, followed by my generic response with references to the artifacts, activities, and checkpoints of the process framework. In some responses,...

List Of Figures Xv

FIGURE 13-8 Maturity expectation over a healthy project's life FIGURE 13-9 Examples of the fundamental metrics FIGURE 13-10 Example SPCP display for a top-level project FIGURE 14-1 The two primary dimensions of process FIGURE 14-2 Priorities for tailoring the process FIGURE 15-1 Progress profile of a modern FIGURE 15-2 Risk profile of a typical modern project across its life FIGURE 15-3 Organization of software components resulting from a modern FIGURE 15-4 Balanced application of modern...

Management Artifacts

The management set includes several artifacts that capture intermediate results and ancillary information necessary to document the product process legacy, maintain the product, improve the product, and improve the process. These artifacts are summarized next and discussed in detail in subsequent chapters, where the management workflows and activities are elaborated. Although the following descriptions use the word document to describe certain artifacts, this is only meant to imply that the...

O

Automotive Commercial application compiler Straightforward automation, single thread Interactive performance, single platform Many precedent systems, application re-engineering Straightforward automation, single thread Interactive performance, single platform Many precedent systems, application re-engineering Figure 14-1. The two primary dimensions of process variability A process framework is not a project-specific process implementation with a well-defined recipe for success. Judgment must be...

Pragmatic Change Metrics

Section 13.1 describes some goals of a successful metrics program. These goals are reiterated next and discussed in terms of whether the metrics described here meet these goals. Metrics must be simple, objective, easy to collect, easy to interpret, and hard to misinterpret. The number of statistics to be maintained in an SCO database to implement this metrics approach is small fewer than 10. They are simple counts and can have simple definitions, although in practice many of the units of these...

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 here as the general term for reducing the source language size necessary 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...

Process Discriminants

In tailoring the management process to a specific domain or project, there are two dimensions of discriminating factors technical complexity and management com-pJexity. Figure 14-1 illustrates these two dimensions of process variability and shows some example project applications. The formality of reviews, the quality control of artifacts, the priorities of concerns, and numerous other process instantiation parameters are governed by the point a project occupies in these two dimensions. Figure...

Software Subcontract Management Level

While subcontracting is not specifically addressed by the process framework, all the techniques, tools, and mechanisms are assumed to be flowed down to subcontractors so that the process remains homogeneous. If this cannot be done, or if the prime contractor cannot define a well-partitioned piece of work to be performed by a mature subcontractor, subcontracting should be avoided. To manage risks effectively, the number and complexity of organizational interfaces must be managed. All...

Lifecycle Expectations

There is no mathematical or formal derivation for using the seven core metrics. However, there were specific reasons for selecting them The quality indicators are derived from the evolving product rather than They provide insight into the waste generated by the process. Scrap and rework metrics are a standard measurement perspective of most manufacturing processes. They recognize the inherently dynamic nature of an iterative development process. Rather than focus on the value, they explicitly...

The Artifact Sets

To make the development of a complete software system manageable, distinct collections of information are organized into artifact sets. Each set comprises related artifacts that are persistent and in a uniform representation format (such as English text, C++, Visual Basic, Java, a standard document template, a standard spreadsheet template, or a UML model). While a set represents a complete aspect of the system, an artifact represents cohesive information that typically is developed and...

Software Economics

Most software cost models can be abstracted into a function of five basic parameters size, process, personnel, environment, and required quality. 1. 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 2. The process used to produce the end product, in particular the ability of the process to avoid non-value-adding activities...

Iteration Workflows

An iteration consists of a loosely sequential set of activities in various proportions, depending on where the iteration is located in the development cycle. Each iteration is defined in terms of a set of allocated usage scenarios. The components needed to implement all selected scenarios are developed and integrated with the results of previous iterations. An individual iteration's workflow, illustrated in Figure 8-2, generally includes the following sequence Management iteration planning to...

Ih

Activity levels across the life-cycle phases development and testing of all the components and must precede the downstream focus on completeness and quality of the entire breadth of the product features. 2. Iterative life-cycle process. In Figure 8-1, each phase portrays at least two iterations of each workflow. This default is intended to be descriptive, not prescriptive. Some projects may require only one iteration in a phase others may require several iterations. The point is...

Workflows of the Process

Most process descriptions use sequences of a The activities of the process are organized into seven major workflows management, environment, requirements, design, implementation, assessment, and deployment. A These activities are performed concurrently, with varying levels of effort and emphasis as a project progresses through the life cycle. a The management workflow is concerned primarily with three disciplines planning, project control, and organization. I activities as their primary...

Foreword

This book blazes the way toward the next generation of software management practice. Many organizations still cling to the waterfall model because, even with its shortfalls, it provides the most fully elaborated management guidelines on how to proceed in a given software situation. It has been difficult to find a fully articulated alternative management approach for dealing with such issues as commercial component integration, software reuse, risk management, and evolutionary incremental spiral...

Pragmatic Software Metrics

Measuring is useful, but it doesn't do any thinking for the decision makers. It only provides data to help them ask-tne right questions, understand the context, and make objective decisions. Because of the highly dynamic nature of software projects, these measures must be available at any time, tailorable to various subsets of the evolving product (release, version, component, class), and maintained so that trends can be assessed (first and second derivatives with respect to time). This...

Process Automation

Many software development organizations are focused on evolving mature processes to improve the predictability of software management and the performance of their software lines of business (in terms of product quality, time to market, return on investment, and productivity). While process definition and tailoring are necessary, a significant level of process automation is also required in order for modern software development projects to operate profitably. Automation needs grow depending on...

List of Figures

FIGURE 1-1 The waterfall FIGURE 1-2 Progress profile of a conventional software FIGURE 1-3 Risk profile of a conventional software project across its life cycle 14 FIGURE 1-4 Suboptimal software component organization resulting from a requirements-driven FIGURE 2-1 Three generations of software economics leading to the target FIGURE 2-2 Return on investment in different FIGURE 2-3 The predominant cost estimation FIGURE 3-1 Cost and schedule investments necessary to achieve reusable FIGURE 4-1...

Software Process Workflows

Previous chapters introduced a life-cycle macroprocess and the fundamental sets of artifacts. The macroprocess comprises discrete phases and iterations, but not discrete activities. A continuum of activities occurs in each phase and iteration. The next-level process description is the microprocesses, or workflows, that produce the artifacts. The term workflow is used to mean a thread of cohesive and mostly sequential activities. Workflows are mapped to product artifacts as described in Chapter...

Early Risk Resolution

The engineering stage of the life cycle (inception and elaboration phases) focuses on confronting the risks and resolving them before the big resource commitments of the production stage. Conventional projects usually do the easy stuff first, thereby demonstrating early progress. A modern process attacks the important 20 of the requirements, use cases, components, and risks. This is the essence of my most important principle architecture first. Defining the architecture rarely includes simple...

Common Subsystem Overview

The CCPDS-R project produced a large-scale, highly reliable command and control system that provides missile warning information used by the National Command Authority. The procurement agency was Air Force Systems Command Headquarters, Electronic Systems Division, at Hanscom Air Force Base, Massachusetts. The primary user was US Space Command, and the full-scale development contract was awarded to TRWs Systems Integration Group in 1987. The CCPDS-R contract called for the development of three...

Next Software Economic S In Software Project Management

Next-generation software economics is being practiced by some advanced software organizations. Many of the techniques, processes, and methods described in this book's process framework have been practiced for several years. However, a mature, modern process is nowhere near the state of the practice for the average software organization. This chapter introduces several provocative hypotheses about the future of software economics. A general structure is proposed for a cost estimation model that...

Architectures

An architecture is the software system design. The ultimate goal of the engineering stage is to converge on a stable architecture baseline. An architecture baseline is not a paper document it is a collection of information across all the engineering sets. Architectures are described by extracting the essential information from the design models. Software architecture is the central design problem of a complex software system, in the same way that architecture is the central design problem of a...

Management Indicators

There are three fundamental sets of management metrics technical progress, financial status, and staffing progress. By examining these perspectives, management can generally assess whether a project is on budget and on schedule. Financial status is very well understood it always has been. Most managers know their resource expenditures in terms of costs and schedule. The problem is to assess how much technical progress has been made. Conventional projects whose intermediate products were all...

Pragmatic Process Improvement

This section contains some descriptive and prescriptive thoughts about the general themes of process improvement. My goal is to instill a proper balance of hope and fear about the promises of process improvement. Process maturity. Compliance with quality process frameworks such as the SEI CMM does not necessarily result in the development of quality products. However, a truly high-quality process that produces quality products will be assessed as mature. One drawback of most process frameworks...

Lower Technical Complexity

More emphasis on existing assets Shorter inception and elaboration phases More-predictable costs and schedules Figure 14-2. Priorities for tailoring the process framework My project experience has demonstrated that five people is an optimal size for an engineering team. Many studies indicate that most people can best manage four to seven things at a time. A simple extrapolation of these results suggests that there are fundamentally different management approaches needed to manage a team of 1...

Continuous Integration

Iterative development produces the architecture first, allowing integration to occur as the verification activity of the design phase and enabling design flaws to be detected and resolved earlier in the life cycle. This approach avoids the big-bang integration at the end of a project by stressing continuous integration throughout the project. Figure 15-1 illustrates the differences between the progress profile of a healthy modern project and that of a typical conventional project, which was...

Dl Context For The Case Study

I worked full time on the CCPDS-R project for 6 years, so this appendix is written from firsthand experience. My responsibilities included managing the development of the foundation technologies, developing the technical and cost proposals, conducting the software engineering exercise, and managing the software engineering activities through the early operational capability milestone. I have tried to provide an accurate portrayal of the CCPDS-R project. While the data presented are mostly...

Major Milestones

The descriptions in this section closely follow the life-cycle anchor points approach described in Anchoring the Software Process Boehm, 1996 . The four major milestones occur at the transition points between life-cycle phases. They can be used in many different process models, including the conventional waterfall model. In an iterative model, the major milestones are used to achieve concurrence among all Iteration 4 Iteration 5 ( Iteration 6 Initial Operational Capability Milestone

Software Product Engineering Level

Are the software work products produced according to the project's defined software process a The software project manager is responsible for compliance with the software development plan. Any deviations from plan or standards (or both) are reviewed periodically through status assessments and are accommodated as appropriate in subsequent iterations or product baselines. 2. Is consistency maintained across software work products (e.g., is the documentation tracing allocated requirements through...

Economics Chapter Modern Process Transitions

Part I presented several perspectives on conventional software management. It objectively described a conventional project profile, conventional software economics, and conventional principles of software management. Parts II and III described a process framework and the management disciplines necessary to make a state change to a modern software process. Part IV completes the presentation of a modern software management framework. It revisits three of the Part I descriptions of conventional...

Artifacts of the Process

Conventional software projects focused on the sequential development of software artifacts build the requirements, construct a design model traceable to the requirements, build an implementation traceable to the design model, and compile and test the implementation for deployment. This process can work for small-scale, purely custom developments in which the design representation, implementation representation, and deployment representation are closely aligned. For example, a single program...

Achieving Required Quality

Many of what are accepted today as software best practices are derived from the development process and technologies summarized in this chapter. These practices have impact in addition to improving cost efficiency. Many of them also permit improvements in quality for the same cost. Table 3-5 summarizes some dimensions of quality improvement. Table 3-5. General quality improvements with a modern process Table 3-5. General quality improvements with a modern process Still a quality driver, but...

Quality Indicators

The four quality indicators are based primarily on the measurement of software change across evolving baselines of engineering data (such as design models and source code). These metrics are developed more fully in Appendix C. Overall change traffic is one specific indicator of progress and quality. Change traffic is defined as the number of software change orders opened and closed over the life cycle (Figure 13-5). This metric can be collected by change type, by release, across all releases,...

Esloc Conversion Factors

The rationale for these conversion factors included many factors Commercial off-the-shelf components do not result in any contribution to the ESLOC count. The integration of these components scales up with the amount of newly developed interfacing software. New software must be developed from scratch. It requires complete design, implementation, and test efforts, and has an ESLOC multiplier of 100 (one-for-one conversion). Reused components represent code that was previously developed for a...

Glossary

Adaptability The rework trend over time Architecture The significant structure and behavior of a system, including all engineering specifications necessary to determine a complete bill of materials with a high level of confidence Architecture first An approach that requires a demonstrable balance to be achieved among the driving requirements, the architecturally significant design decisions, and the life-cycle plans before the resources for full-scale development are committed Artifact A...

Reusable Components Of A System Project Management

Reusing existing components and building reusable components have been natural software engineering activities since the earliest improvements in programming languages. Software design methods have always dealt implicitly with reuse in order to minimize development costs while achieving all the other required attributes of performance, feature set, and quality. Reuse achieves undeserved importance within the software engineering community only because we don't do it as well as we should. In all...

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. Above all, configuration management environments provide the foundation for executing and instrumenting the process. At first...

Transitioning To An Iterative Process

Modern software development processes have moved away from the conventional waterfall model, in which each stage of the development process is dependent on completion of the previous stage. Although there are variations, modern approaches generally require that an initial version of the system be rapidly constructed early in the development process, with an emphasis on addressing the high-risk areas, stabilizing the basic architecture, and refining the driving requirements (with extensive user...

Architecture A Technical Perspective

Although software architecture has been discussed at length over the past decade, convergence on definitions, terminology, and principles has been lacking. The following discussion draws generally on the foundations of architecture developed at Rational Software Corporation and particularly on Philippe Kruchten's concepts of software architecture Kruchten, 1995 . Software architecture encompasses the structure of software systems (the selection of elements and the composition of elements into...

Late Risk Resolution In Waterfall Model

Waterfall Model Royce Definition

In 1970, my father, Winston Royce, presented a paper titled Managing the Development of Large Scale Software Systems at IEEE WESCON Royce, Winston, 1970 , This paper, based on lessons he had learned managing large software projects, remains the most quoted source of the waterfall model. It provides an insightful and concise summary of conventional software management philosophy circa 1970, and most of its 30-year-old advice has stood the test of time in the face of immense technology turnover....

The Addison Wesley Object Technology Series

Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors For more information check out the series web site Armour Miller, Advanced Use Case Modeling, Volume Binder, Testing Object-Oriented Systems Models, Patterns, and Tools Blakley, CORBA Security An Introduction to Safe Computing with Objects Booch, Object Solutions Managing the Object-Oriented Project Booch, Object-Oriented Analysis and Design with Applications, Second Edition Booch Rumbaugh Jacobson, The Unified Modeling Language Box...

Modern Software Economics

Chapter 1 introduced Boehm's top 10 software metrics Boehm, 1987 as an objective presentation of the current state of the software management practice. That framework can be used to summarize some of the important themes in an economic context and speculate on how a modern software management framework should perform. There are not enough project data to prove my assertions, but I believe that these expected changes provide a good description of what an organizational manager should strive for...

The Old Way and the

I Conventional software engineering has numerous well-established principles. Many are still valid others are obsolete. A modern software management process will incorporate many conven- tional principles but will also transition l to some substantially new approaches. software features produced more rapidly under more competitive pressure to reduce cost. In the commercial software industry, the combination of competitive pressures, profitability, diversity of customers, and rapidly changing...

The Cost And Schedule Estimating Process

Project plans need to be derived from two perspectives. The first is a forward-looking, top-down approach. It starts with an understanding of the general requirements and constraints, derives a macro-level budget and schedule, then decomposes these elements into lower level budgets and intermediate milestones. From this perspective, the following planning sequence would occur 1. The software project manager (and others) develops a characterization of the overall size, process, environment,...

Fpq Project Management

Assessments Periodic synchronization of stakeholder expectations Figure 9-1. A typical sequence of life-cycle checkpoints stakeholders on the current state of the project. Different stakeholders have very different concerns Customers schedule and budget estimates, feasibility, risk assessment, requirements understanding, progress, product line compatibility Users consistency with requirements and usage scenarios, potential for accommodating growth, quality attributes Architects and systems...

Improving Team Effectiveness

It has long been understood that differences in personnel account for the greatest swings in productivity. The original COCOMO model, for example, suggests that the combined effects of personnel skill and experience can have an impact on productivity of as much as a factor of four. This is the difference between an unskilled team of amateurs and a veteran team of experts. In practice, it is risky to assess a given team as being off-scale in either direction. For a large team of, say, 50 people...

Metrics Automation

There are many opportunities to automate the project control activities of a software project. For managing against a plan, a software project control panel (SPCP) that maintains an on-line version of the status of evolving artifacts provides a key advantage. This concept was first recommended by the Airlie Software Council Brown, 1996 , using the metaphor of a project dashboard. The idea is to provide a display panel that integrates data from multiple sources to show the current status of some...

Project Organizations

Figure 11-2 shows a default project organization and maps project-level roles and responsibilities. This structure can be tailored to the size and circumstances of the specific project organization. Figure 11-2. Default project organization and responsibilities The main features of the default organization are as follows The project management team is an active participant, responsible for producing as well as managing. Project management is not a spectator sport. The architecture team is...

List of Tables

TABLE 1-1 Expenditures by activity for a conventional software TABLE 1-2 Results of conventional software project design TABLE 3-1 Important trends in improving software TABLE 3-2 Language expressiveness of some of today's popular languages 34 TABLE 3-3 Advantages and disadvantages of commercial components versus custom TABLE 3-4 Three levels of process and their TABLE 3-5 General quality improvements with a modern TABLE 4-1 Modern process approaches for solving conventional problems 66 TABLE...

Personnel Accountability Level

One important goal of controlled software management is clear delineation of responsibility and mechanisms for accountability. Consequently, the following questions should also be asked in an assessment of an organization's process implementation 1. Does the organization define a role for maintaining its process description and assets 2. Does the SEPA role have a track record of influencing projects and corporate strategy 3. Do software project managers author their development plans 4. Do...

Overall Software Acquisition Process

The CCPDS-R acquisition included two distinct phases a concept definition (CD) phase and a full-scale development (FSD) phase. The CD phase proposal was competed for by five major bidders, and two firm-fixed-price contracts of about 2 million each were awarded. The winning contractors also invested their own discretionary resources to discriminate themselves with the best-value FSD phase proposal. Figure D-l summarizes the overall acquisition process and the products of each phase. Competitive...

Cocomo Ii

Rough Order Magnitude Estimate

The COCOMO II project Boehm et ai, 1995 Horowitz, 1997 is an effort being performed by the USC Center for Software Engineering, with the financial and technical support of numerous industry affiliates. (They include AT& T Bell Labs, Bellcore, DISA, EDS, E-Systems, Hewlett-Packard, Hughes, IDA, IDE, JPL, Litton Data Systems, Lockheed Martin, Loral, MDAC, Motorola, Northrop-Grumman, Rational, Rockwell, SAIC, SEI, SPC, TASC, Teledyne, Texas Instruments, TRW, USAF Rome Labs, US Army Research...

Software Management Best Practices

Many software management best practices have been captured by various authors and industry organizations. One of the most visible efforts has been the Software Acquisition Best Practices Initiative, sponsored by the U.S. Department of Defense to improve and restructure our software acquisition management process. Brown summarized the initiative Brown, 1996 , which has three components the Airlie Software Council composed of software industry gurus , seven different issue panels Round-trip...

Airlie Software Council

Ada COCOMO, 26, 269-274 Ada 83, 34-36 Ada 95, 34-36 Adaptability metric, 197-198, 286-287, 292,296, 344-345 Adversarial stakeholder relationships, 15-16, 225 nine best practices, 233-235 Architectural risk, 217 Architecture baseline, 110,114-115 management perspective, 110-111 team, 161-162 technical perspective, 111-115 Architecture-first approach, 63, 64, 68, 118, 119, 231,233,234 Artifacts, 83-107 artifact sets, 84-95 associated with each workflow, 120 deployment set, 88-92 design set, 87...

Transition Phase

The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain. This typically requires that a usable subset of the system has been achieved with acceptable quality levels and user documentation so that transition to the user will provide positive results. This phase could include any of the following activities 1. Beta testing to validate the new system against user expectations 2. Beta testing and parallel operation relative to a legacy system it is...

Elaboration Phase

It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase, the engineering is considered complete and the project faces its reckoning The decision is made whether or not to commit to the production phases. For most projects, this decision corresponds to the transition from a nimble operation with low cost risk to an operation with higher cost risk and substantial inertia. While the process must always accommodate changes, the elaboration...

Inexperienced Team

Less scrap and rework in requirements and design sets More scrap and rework in requirements and design sets Lower levels of requirements and design Higher levels of requirements and design Less-frequent status assessments needed More-frequent status assessments required

The Project Environment

The project environment artifacts evolve through three discrete states the prototyping environment, the development environment, and the maintenance environment. 1. The prototyping environment includes an architecture testbed for prototyping project architectures to evaluate trade-offs during the inception and elaboration phases of the life cycle. This informal configuration of tools should be capable of supporting the following activities Performance trade-offs and technical risk analyses Make...

Tools Automation Building Blocks

Many tools are available to automate the software development process. This section provides an overview of the core environment necessary to support the process frame- Management Environment Requirements Design figure 12-1. Typical automation and tool components that support the process workflows work. It introduces some of the important tools that tend to be needed universally across software projects and that correlate well to the process framework. Many other tools and process automation...

Conventional Software Management Performance

Barry Boehm's one-page Industrial Software Metrics Top 10 List Boehm, 1987 is a good, objective characterization of the state of software development. There is very little evidence of significant changes in the past decade. Although many of the metrics are gross generalizations, they accurately describe some of the fundamental economic relationships that resulted from the conventional software process practiced over the past 30 years. In the following paragraphs, quotations from Boehm's top 10...

The Principles Of Modern Software Management

Although the current software management principles described in Section 4.1 evolved from and improved on conventional techniques, they still do not emphasize the modern principles on which this book is based. Building on Davis's format, here are my top 10 principles of modern software management. The first five, which are the main themes of my definition of an iterative process, are summarized in Figure 4-1. The principles are in priority order, and the bold-faced italicized words are used...

Teamwork Among Stakeholders

Many aspects of the classic development process cause stakeholder relationships to degenerate into mutual distrust, making it difficult to balance requirements, product features, and plans. A more iterative process, with more-effective working relationships Figure 15-3. Organization of software components resulting from a modern process between stakeholders, allows trade-offs to be based on a more objective understanding by everyone. This process requires that customers, users, and monitors...

Core Metrics

The CCPDS-R metrics approach was first developed solely to manage the project and meet the needs of the contract. While it achieved these goals, it also resulted in a great case study. CCPDS-R was nowhere near perfect numerous mistakes were made all along the way. This was true of the metrics program, too It measured some of the wrong things, measured some things in the wrong way, struggled with early interpretations, and used some manual methods where automation was needed. Nevertheless, these...

Work Breakdown Structures

A good work breakdown structure and its synchronization with the process framework are critical factors in software project success. Although the concept and practice of using a WBS are well established, this topic is largely avoided in the published literature. This is primarily because the development of a work breakdown structure is dependent on the project management style, organizational culture, customer preference, financial constraints, and several other hard-to-define, project-specific...

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. Although cost model vendors claim that their tools are suitable for estimating iterative development projects, few are based on empirical project databases with modern iterative development success stories. Furthermore, because the software industry has inconsistently defined metrics or atomic units of measure, the data from actual projects are...

The Principles Of Conventional Software Engineering

There are many descriptions of engineering software the old way. After years of software development experience, the software industry has learned many lessons and formulated many principles. This section describes one view of today's software engineering principles as a benchmark for introducing the primary themes discussed throughout the remainder of the book. The benchmark I have chosen is a brief article titled Fifteen Principles of Software Engineering Davis, 1994 , The article was...

Demonstrationbased Assessment

Conventional design reviews define standards for review topics that result in tremendously broad reviews, only a small portion of which is really important or understood by a diverse audience. For example, reviewing all requirements in equal detail is inefficient and unproductive. All requirements are not created equal some are critical to design evolution of the architecture, while others are critical only to a few components. The CCPDS-R software review process improved the efficiency of...

Checkpoints of the Process

It is always important to have visible milestones in the life cycle where various stakeholders meet, face to face, to discuss progress and plans. The purpose of these events is not only to demonstrate how well a project is performing but also to achieve the following Synchronize stakeholder expectations and achieve concurrence on three evolving perspectives the requirements, the design, and the plan Synchronize related artifacts into a consistent and balanced state Identify the important risks,...

Improving Software Processes

For software-oriented organizations, there are many processes and subprocesses. I use three distinct process perspectives. 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 a software ROI. Macroprocess a project's policies, procedures, and practices for producing a complete software product within certain cost,...

D Dodstda Artifacts

CCPDS-R software development was required to comply with DOD-STD-2167A, which is now obsolete. Without going into detail about the documentation required, this section summarizes the basic documentation approach used on the project. Data item descriptions in 2167A specified document format and content. Substantial tailoring was allowed to match the development approach and to accommodate the use of Ada both as a design language and the implementation language. Primary tailoring included the...

Ccpdsr Case Study

This appendix presents a detailed case study of a successful software project that followed many of the techniques presented in this book. Successful here means on budget, on schedule, and satisfactory to the customer. The Command Center Processing and Display Sys-tem-Replacement CCPDS-R project was performed for the U.S. Air Force by TRW Space and Defense in Redondo Beach, California. The entire project included systems engineering, hardware procurement, and software development, with each of...

Denouement

In summary, the conventional software process was characterized by the following Sequentially transitioning from requirements to design to code to test Achieving 100 completeness of each artifact at each life-cycle stage Treating all requirements, artifacts, components, and so forth, as equals Achieving high-fidelity traceability among all artifacts at each stage in the life cycle A modern iterative development process framework is characterized by the following Continuous round-trip...