A Method for Assembling a Project-Specific Software ... of the 29th Annual Hawaii International...

Proceedings of the 29th Annual Hawaii International Conference on System Sciences - 1996

A Method for Assembling a Project-Specific Software Process Definition

Richard M . Lobsitz TAX, Reading, MA

Abstract

A software process definition embodies a complex interac- tion of development and management activities, products, tools, and metrics. Establishing an initial process definition for any organization is a difficult and t ime-consuming effort. Modifying the initial definition also represents an in- tense effort that requires a well defined process of organizational coordination and communication. Orga- nizations could reduce much of the cost associated with the modification of a sofiare process if the initial definition in- cludeda viable planning methodfor tailoring a genericpro- cess to each project rather than forcing the project to fit a standard process. This paper is based on a planning method that has evolved within TAX, it describes the steps required to create a tailored process definition for specific projects based on the generic process definition.

1: The purpose of this paper

As organizations strive to become more process oriented in their approach toward Software Development Projects, the very process of defining standard methods and procedures can significantly reduce the organization’s ability to utilize new tools and methods. In a competitive marketplace, where the assimilation of rapid advances in technology is critical for survival, organizations are forced to decide between “doing it right” and reverting to ad hoc procedures just to “get the job done.” To avoid this conflict, the new tools and techniques have to be easily assimilated into an overall technical and project management approach that is adaptable without having to be reinvented each time. This paper describes a planning process that has evolved within our organization, which utilizes a “Build Process Model” (based on entity process modeling [ 1,2] ) to refine a quick turnaround project plan. This approach allows the planning team to understand the impact of new software engineering tools and techniques while retaining maximum reuse of pre- viously defined standard project processes.

2: Defiiing a project-specific process

TASC has developed alarge number of advanced technology systems for a broad range of government and commer- cial customers. In our process improvement work over the last five years, we have had to develop a highly tailorable software process model to meet the needs of these diverse projects. We have developed a set of standard process components that include development procedures, life cycle models, project phase descriptions, project milestones, and baselines. The method has been applied to both object-oriented and structured development paradigms. It incorpo- rates the process requirements for the waterfall, incremental, and spiral life cycle models.

In the competitive marketplace, we have found it necessary to plan a project in two passes. The objective of the first pass is to assess the project’s requirements, deliverable products, and milestones, to propose an initial technical solution, and estimate a rough build cost. The results of this process establishes the project’s high-level technical approach, risk factors, and cost targets. The rough build cost is an input to the management decision to pursue the project. Once a decision is made to pursue a project, a second, more thorough pass tailors the technical approach to add quality milestones, define the content of baselines, and tailor the content of the deliverables. The result is a project plan that contains enough detail to estimate each of the elements of project cost as well as to quantify the project risks prior to beginning the project.

The TASC Software Engineering Process Working Group (TSEPWG) started with the charter to institutionalize the best industry practices in our System Integration projects. To accomplish this we created a set of process components and other supporting tools that could be readily tailored to a project’s development requirements. Where practical, components have been designed to be used in a stand-alone mode, or easily modified to fit a project’s specific requirements. The TSEPWG makes these standard assets available to support project planning and execution. These assets include planning tools, costing models, definition of standard deliverables, development tools and environments, and

722 1060-3425/96 $5.00 0 1996 IEEE

Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE


training. In addition, TASC has captured best practice procedures for reuse and incorporation into the individual project plan. The four areas that currently have procedures are:

. Program Management (PM) -includes project planning, tracking, cost estimating, and requirements management

. Software Engineering (SE) - includes setting up the SE environment, buy-build decisions, software design, software coding, milestone, and peer reviews

. Configuration Management (CM) - includes establishing the CM approach, identifying configuration components, and establishing different types of configuration baselines

. Quality Assurance (QA) - includes establishing the QA approach, auditing quality reviews, tracking and re- porting QA status, and performing unscheduled audits.

It is expected that new components and procedures will be developed as new projects attempt to assimilate new tools and technology.

The five step process creates a project framework and a technical framework. The project framework identifies an appropriate life cycle model, major deliverables and

milestones. A corporate standard software development/ system integration Work Breakdown Structure (WBS) is used as a guide to structure the work packages and to estimate the completion cost of project tasks and products. The technical framework is based on the selection of a domain specific architecture and a test and acceptance strategy.

The first four steps in the process are intended to be completed rapidly to allow a management review to assess the potential for successfully completing the project by analyz- ing the project plan which includes a rough cost estimate, a schedule and an assessment of risks. If the project is ac- cepted, then the detailed technical approach is defined based on the project plan and the initial technical framework. It is in this final tailoring step that all the elements of new technology and tools must be woven together with established processes to create a complete technical approach and finally a bottom-up cost and risk assessment. For some projects, the tailoring process identifies problems with the initial project plan or technical framework, in which case the project will be reevaluated. Figure 1 is a graphical representation of this process. The dark boxes represent the use of standard process assets which will be described more fully in each section.

1) Analyze the Project Requirements

System -Operational -Interface -Safety -Security -Environment -Personnel-related -Training-related -Logistics-related

I Programmatic

-J

-Links -Tyves of H W -COTS -Types of S W -Reuse

t-4 -Integration -System

4) Outline the Project Plan

-Project Stages -Major Milestones -Deliverables -Top-level W B S -Risks -Schedule -Costs (Top Down)

f 5) Tailor the Project Plan

-PBS -Build Process Model -Custom Deliverables -Baselines -Quality Checks -Management Metrics -Costs (Bottom Up)

L

Figure 1. Process for establishing and tailoring the Software Development Approach

723


2.1: Step l- Analyze the project’s requirements This step takes many forms depending on the type of proj-

ect and the level of detail in the requirements specification. If no specification exists, then the fist phase of the project must define those requirements and the later phases of the project will be planned after the requirements are established. If specifications exist, the information needs to be or- ganized into a set of numbered lists (to allow for easy referencing) [3] that can be used to define the system architecture. These lists should include: . System Requirements -details of operational require-

ments, internal and external interfaces, safety and security requirements, environmental requirements, and personnel, training and logistics-related requirements

. Quality factors - reliability, maintainability, etc.

. Programmatic Requirements-how is the project expected to unfold, what are the major milestones and deliverables, what are the critical success factors and the cost and schedule constraints?

. Risks - what could go wrong? The purpose of the lists is to baseline the project require-

ments and to provide auditability to the initial project requirements for any proposed solution. 2.2: Step 2- Define the preliminary system

architecture Technology experts at TASC analyze the requirements

and define a preliminary system architecture to meet as many of the project requirements as possible, recognizing that the final system architecture will be further defined and refined as a part of the actual build process. They utilize their experience with similar domain specific architectures to define the specific types of system components (HWISWI Communications) that will be needed. They propose an architecture and create a high-level performance assessment model to help with the initial component sizing. Major reuse components are identified as well as components that will require buy vs. build assessments. Any requirements that cannot be met are identified and alternatives are evaluated. The result of this analysis is a set of architectural drawings and a list of potential system components, their origin, performance requirements, and approximate costs. In addition, a requirements compliance matrix is created that maps architecture components to requirements. The matrix will help identify architecture risks and voids. Technical risks are identified by the technology team and if possible quantified as to their cost and/or schedule impacts.

2.3: Step 3- Define the testing and acceptance strategy

This step analyzes the required quality factors as well as the safety, security, and environmental requirements for the system and proposes an appropriate test and acceptance strategy for the system [4]. This analysis draws from the set of standard Quality Assurance procedures that have been

Proceedings of the 29th Ann& Hawaii International Conference on System Sciences - 1996

used on prior projects that have developed software for similar domains. These would include standard procedures for conducting technical reviews, peer reviews, defect record- ing and analysis, and conducting quality audits. The identification of specific quality control activities is deferred until the detailed technical approach is defined in Step 5. At this stage, the concern is to identify what percent of the project resources will be dedicated to testing and the necessary se- quence of test events. We also explicitly address interactions with the system’s users related to acceptance so that the completion and success criteria are specified early in the project planning. Project quality risks are identified by the QA team and are quantified. 2.4: Step 4- Outline the project plan

Once the technical framework is in place and the project’s programmatic requirements have been identified, the Proj- ect Plan can begin to take shape. The first step in creating the plan is to identify the “best-tit” standard life cycle model for the project to use as a framework for developing the initial build approach. The selection of the life cycle model is driv- en by the stability and detail of the requirements and the ma- turity of the technical approach. The following table summarizes how TAX applies the different cycles. If a specific life cycle is already specified as a programmatic re- quirement, it will be adopted, but it will be evaluated for potential risks.

Table 1. TASC Standard Life Cycle Models LIFE CYCLE REQUIREMENTS TECHNICAL

APPROACH

Waterfall 1 Stable I Mature

Incremental

Prototvning

Stable

Unknown

Immature

Research

Spiral Unstable Mature/Immature

At TASC, a project starts with one of the four standard project life cycle definitions waterfall, incremental, proto- typing, or spiral. To customize the standard life cycle a project is divided up into visible stages, where each stage includes a set of standard work packages with associated products (these could be documents, databases, hardware, software, acquired products, etc.) bundled together to accomplish a major part of the development process; for example, in a Waterfall life cycle there could be a Requirements Verification stage, followed by a System De- sign stage, followed by a Software Design stage, etc. Each stage has entrance and exit criteria [5] and ends with a visible milestone. The relationship among the stages gets more complicated if the life cycle model iterates on or refines some set of deliverable products. In the incremental and spiral models the project needs to identify the number of build iterations and when completed portions of the system will be released for operation. The identification of project stages begins to reveal the details of the build process and

724



match the technical approach to the project’s programmatic requirements.

Once the stages are established, the major project milestones are inserted and the project deliverables are aligned with the appropriate stage. At this point the WBS begins to take shape and the major elements of cost have been identified. The management team will identify programmatic risks and quantify them. Typically a function point analysis is conducted at this time to provide a sanity check to a top- down cost estimate. The results of the architecture analysis, the QA analysis, and the management analysis is summa- rized in an outline of a Project Plan.

the BPM is shown by its ability to transition from a representation of the system requirements through a representation of the system design to the final built components.

2.5: Step 5- Tailor the Software Development Plan

The tailoring process is built around a “Build Process Model” (BPM) which is created by applying the standard (and non-standard) software engineering methods and techniques to the starting representation of the system requirements, transitioning through the various intermediate representations of the system (system architecture, system design, detailed component designs) to the final system components. It attempts to provide a comprehensive picture of how the project data is transformed to get from the beginning of the project to the end. It has to account for the cre- ation of all the deliverables associated with the standard life cycle definitions and show the content of each project baseline. The BPM helps to highlight the gaps between different SE methods and tools which may only tackle a part of the overall process needed for a complete development cycle (e.g., Upper CASE tools vs. Lower CASE tools, GUI design tools vs. Database Design tools, 00 analysis methods vs. 00 design methods). If a new technique or tool is planned, it can show where it fits in the overall build plan.

The Build Process Model is created as a directed graph. It is a short-hand version of a set of data flow diagrams that define the transformational process from inputs (e.g., Require- ments Specifications) through to the eventual outputs that implement the system components. The data flow concept of a data store is expanded to include any stand-alone aggre- gate of information about the system. Each of these information stores is considered a BPM Entity and is represented on the graph as a round corner block labeled with a description and a reference to the tool used to capture the information or just the form of the information if no special tools were used. The arrows between blocks represent the transformational process that would have been the bubbles and intermediate data stores on a data flow. Stan- dard design and analysis techniques can be represented within a build process model and whole pieces of a model can be reused if the inputs, outputs, and transformational techniques are applied the same way from project to project.

Our analysis of many published life cycle definitions has shown that each has an implicit BPM which is revealed only by an analysis of the deliverable set. The reason that many of these methodologies are awkward to use is that they are too specific in their internal BPM, the tailoring guidance in- volves only what to leave out of the deliverable set under certain conditions and doesn’t allow the underlying BPM to be changed. An example of this is the difficulty in tailoring these descriptions for client/server technology because it is not clear where to put the additional requirements and design information that needs to be created and controlled. It is not easy to add information to the standard deliverable specifications without a conceptual view of how the entire build process is designed.

The point of the Build Process Model is not to precisely define every data element in the entire build process, but rather to identify forms of data collection and methods to transform one representation of the system to another. It is a map of the build process from the perspective of data ag- gregates as they are transformed from requirements through design to the final end products [ 11. Figure 2 is an example project BPM. Notice that the entities are represented at a conceptual level and that the arrows between the entities reflect the transformational methods. Each entity belongs to a representation of the system being built and some combina- tion of entities is the complete representation of one of the intermediate development stages of the system (e.g., requirements, system design, detailed design, or product).

2.6: Defining the build process model

A project specific BPM is an integration map of the various information repositories created during the development of a system. The requirements that describe the system are captured in one representation and as analysis and design methods are applied, new representations of the system are created until the system itself is actually built. The com- bination of different analysis and design methods will yield different BPMs; however, the validity of a given version of

A BPM starts with the representation of the requirements, ends with the architecture components and has to define how to get from the start to the end. Figure 3 depicts a generic version of the mapping process. As a part of the first pass analysis, the project has baselined a list of minimum requirements. These information stores become the BPM starting points. The ending points are created from an analysis the of the proposed architecture that defines the initial Product Breakdown Structure (PBS). Obviously, a precise PBS will not be finished until the detailed design stage of the project has ended; but what is required for the build plan is the best projection as to the types of build products that will be required, not the specifics of what each build product would do. The reason for focusing on types of products is that for a particular type of product the build process is the same and flows through the same types of intermediate products. The type of products would include “custom designed applications programs,” “database tables,” “com- mercial products,” “reused software,” “User Interface

725



Structure Charts

Figure 2. A BPM for an Example Project

Layouts” and the like. The goal is to enumerate all the types of end products that will eventually have to be built for this system and put them as outputs on the BPM graph.

Once the starting and ending points are established, the planning team will collectively fill out the Build Process Model. The analysis technique that has been most success- ful is to start with each type of end product that has to be created and to follow the information trail back to the requirements. The path for C++ modules using 00 analysis and design techniques will be very different from relational database tables, As the BPM is built up, any automated CASE tool repository will be represented in the model and each analysis step should be separately shown. The point of the model is to show the process by which the information representing the requirements is transformed into the information necessary to build each type of end product. Each of the intermediate representations within the model present opportunities to control and evaluate the quality of the build process. Standard software engineering build procedures which have been used on previous projects are reused in new projects when the build process follows a similar path. As new paths are followed: the new build procedures are captured, examined and refined for use on future projects.

BPM entities and their attributes: Associated with each of the BPM entities is a separate list of the attributes of the data collected and represented by the entity. For example, in Figure 2 there is an entity called a Data Flow Diagram which is collected in graphical form and has the attributes of data flows, processes, data stores, data sources and data sinks. An analysis of the BPM transformation arrows by staff fa- miliar with the methodology would identify the source of the information used to populate the attributes for the Data- Flow Diagram. The predecessor entities ( e.g. Functional Requirements and Legacy FORTRAN Routines) could be examined to determine if there was sufficient information to create all the necessary data flows, processes, data stores, data sources and data sinks. If there is not enough information, then additional sources of information will have to be identified and added to the build model. In this manner, the BPM will identify voids and inconsistencies in the build process as the project team attempts to connect information in one representation to the next. Another example of how the BPM clarifies the build process is illustrated in Figure 2 where a system prototype feeds the GUI layout tool. If the intent of the build process was to use the exact format of the screen prototypes to generate the final system, then those

726



System Requirements Representation

Form C of Requirements

Form D of Requirements t

Product Breakdown Structure

Build Process Model

4 Type X Components 1

-( Co$Z&]

Figure 3. The Generic BPM Mapping Process

formats would be included as part of the design representation of the system. On the other hand, if the screens were only to be notional in their content, then the formats would not be considered part of the design representation, rather they would be inputs to another process that would in turn create the screen design. If no prototype was planned for the system, then there would be a void in the BPM for input to the screen design process.

The impact of development tools: Automated development tools play a very important role in the definition of the BPM; they force the BPM to include specific entities, with specific attributes. Any time a tool is incorporated into the build process, it forces the BPM to be structured around the tool’s data capture and transfer ability. The BPM is an excel- lent technique for identifying the source of all the necessary inputs to a tool and for identifying shortfalls in the tool’s ability to connect with downstream data requirements or make use of upstream data gathering. This allows the project team to evaluate the effectiveness of adevelopment tool, and the necessary rework or supplemental work to connect with the downstream processes. For example, most CASE design tools have ignored the screen layout aspect of design, choosing to leave that to the GUI tools. The problem is that the screen layout is highly leveraged information, impacting most of the final build products and yet, it cannot be con- nected in any meaningful way to the other design activities. The only alternative has been to maintain linkages between

the CASE design information and the screen design information by hand, which is a very risky and costly process.

2.7: Customizing the deliverables The initial version of the BPM is an idealized version and

it will have to be modified to produce any required deliverables that do not emerge naturally from the build process. Thus a “Design Specification” deliverable may be the consolidation of several CASE tool outputs as well as tex- tural “glue” that has to be created because the CASE tools do not capture all the necessary design elements. All of these additional assembly activities have to be accounted for in the project plan and are obvious from a well developed BPM. This is also the opportunity to adjust the content of standard deliverables to match the build process. Figure 4 shows how two deliverables (Operational Concept Descrip- tion and Requirements Specification) are added to the BPM as a shaded box under the entities included in the deliverable. Notice that a new entity (System Overview) had to be created to satisfy the full content of the deliverables. It is shared by both deliverables and will have to be controlled with the other entities that make up each deliverable.

Changing the BPM to account for deliverables can affect both the upstream and the downstream entities and can cause precedence problems within the work model. If a deliverable is compiled from a number of data entity sources, a great deal of attention must be paid to controlling the sources to keep the deliverable synchronized. If the sources

727



ystem Overview

Figure 4. A Part of the Example BPM Modified for Project Deliverables

are widely separated within the BPM, the deliverable may require the results of one analysis task to be linked to another task that cannot occur accurately until much later. In this case, it is better to split the deliverable into several pieces and deliver the results incrementally. In this complex information integration environment, version control of each of the data entities becomes critical. If a deliverable is as- sembled from multiple sources, each of the sources will have to be controlled along with the content of the deliverable.

2.8: Identifying the configuration baselines

Standard Configuration Baselines are usually created from a single deliverable or a set of related deliverables. These include among others, a Functional Baseline for system requirements, a Design Baseline for the software design, and an Operational Baseline for the delivered components. Using the BPM, there is an opportunity to customize the baseline timing and content to reflect the actual build process and to control a logically interrelated section of the BPM. Configuration Baselines are drawn on the BPM as heavy lines surrounding the shaded deliverable boxes included in that baseline. During the build process, there are three possible reasons for isolating a portion of the BPM and creating a configuration baseline [6, 71.

Synchronization points: In any build process, there are parallel lines of activity; a configuration baseline can be

created prior to splitting into parallel activities to ensure that each team works to the same prior specification and that any changes to that specification are carefully controlled. Anoth- er baseline possibility is at the end of parallel activities, where the team needs to reassemble and determine if the results of their activities have created a logical whole. The baselining process should be used carefully because there is significant expense associated with creating and maintaining a baseline. In the case of a synchronization baseline, it is important to recognize that the information needs to be controlled; however, the control mechanism may be informal.

Milestone Change Control: A baseline serves to control the change process to any of the intermediate representations ot the system. Milestone baselines are relatively for- mal since they are kept controlled throughout the rest of the project. The information content of these baselines is deter- mined from the content and purpose of the milestone and are usually linked in some way to deliverables. It is important to use the BPM to determine the information linkage within deliverables, because the linked information will have to be included in the baseline as well as the deliverables.

Auditing Potential: Baselines can be constructed to audit the contents of one set of BPM entities against another set of BPM entities. This may require special analysis of some or all of the affected BPM entities. An example of this might be the audit of test cases against the design components to ensure that each

728



Figure 5. Example Project BPM with Deliverables and Baselines

729



and every design component is covered by a test case. Audit- ing baselines represent a significant investment to determine if two sets of information are matched. This type of baseline in- volves two sets of information entities and any changes to ei- ther entity used in the audit needs to be tracked and reconciled if the baseline is to be accurately maintained. Again, the BPM will show the fill set of data entities that need to be controlled to completely control both sides of an audit.

Completing the project plan

The following steps use the BPM as an input, providing the planners with a project roadmap to define intermediate project milestones, quality control activities and management metrics.

Identifying intermediate milestones: Project milestones have three different purposes: . Recognize the completion of specific parts of the

BPM . Assess the quality of work in progress or completed

work l Reach an agreement between project participants.

A given milestone can have any or all of these purposes and the output of a major project milestone will usually be controlled by an associated configuration baseline. Using the BPM, milestones and their associated products are identified. Because there are many different standard milestones defined within government and industry, our method allows the project planners to select, based on their build process, the appropriate set of milestones.

Identifying Build Process Quality Checks: In addition to the product testing strategy, the BPM provides insight into the possible areas for build process quality control. Each data entity, deliverable, and transformational process is a potential candidate for a quality check of some form. The quality team identifies the appropriate BPM areas and care- ful review is given to the areas where the information is the most highly leveraged. The types of quality checks that are used at TASC include: . Verification of conformance with the original

requirements . Validation of a correct transformation of a prior inter-

mediate product . Peer review for the use of best practices and techniques . Inspection and testing for adherence to standards l Automated assessment for specific quality measures

like complexity or consistency.

In addition to these options, special QA activities or methods are identified when these standard techniques do not fit. The results of any QA activity is documented and any de- fects recorded and tracked to closure. Once all the QA activities have been identified, highlighting them on the BPM can show the QA coverage over the entire build process.

Identifying the Management Metrics and Reviews: The BPM also provides insight into the appropriate size management metrics to track for the project. Since the BPM data entities represent the work products at each stage of the project, scoping these for target values and then tracking progress and status of these products will provide insight into the progress and status of the project.

3: Results

At TAX!, the project planning process described above is supported by experts in the technology base, the applications domain, project management, and quality assurance. This group, along with the project manager, create a plan that balances the needs of each of these stake-holders and minimizes the project risks. A standard set of project metrics has been established by the corporation to measure Ef- fort, Cost, Schedule, Delivered Product Size and Delivered Product Quality. These metrics are required of each project and are kept in a corporate metrics and “lessons-learned” database.

Thus far, this method has been used by a number of projects for planning their initial technical approach. It has been effective in creating very detailed plans that are well tailored to the goals of the project. It has also helped the projects to identify areas of risk and potential voids in the build process. Using the BPM, projects have been able to estimate the impact of complying with external deliverable standards and to identify areas where productivity could be increased by harmonizing external deliverables to products already created as a result of the build process. Future work will fo- cus on building up the library of process components as projects use new and not yet standardized build techniques.

4: References

[ 11 Jackson, M.A. System Development, Prentice Hall, Englewood Cliffs, NJ, 1983.

[2] Humphrey, W.S., and M.I. Kellner, “Software process modeling: principles of entity process models,” Proceed- ings of the 1 lth International Conference on Software Engi- neering, IEEE, 1987.

[3] Martin, C.F., User-Centered Reauirements Analvsis Prentice Hall, Englewood Cliffs, N.J., 1988.

[43 Myers, G.J., The Art of Software Testing, John Wiley & Sons, New York, N.Y., 1979.

[5] Humphrey, W.S., Managing the Software Process, Addison-Wesley Publishing Co., Reading, MA, 1990.

[6] ANSI/IEEE Std 1092-1987 Guide to Software Con- figuration Management.

[7] Compton, S.B, and Conner, G.R., Configuration Management of Software, VanNostra and Reinhold, New York, N.Y., 1994.

730


A Method for Assembling a Project-Specific Software ... of the 29th Annual Hawaii International...

Documents

Transcript of A Method for Assembling a Project-Specific Software ... of the 29th Annual Hawaii International...