1.1 Scope
The definition of a software process is embodied in how a software organization does business; that is, how management and engineering practices are implemented to support software development and/or maintenance. This view of software process assumes that an organization has a set of building blocks that defines the general way it does business and that some subset of those building blocks is implemented for each software project.
The building blocks that define how a software organization does business are called the organization's standard software process. The subset of the building blocks tailored to and implemented for each project is referred to as the project's defined software process. Then, the project's software development plan is developed based on the project's defined software process and used to manage the software project.[1]
Software project requirements (both technical and management requirements) drive the specifics of tailoring the organization's standard software process, documenting the software development plan, and managing the project according to the plan. Figure 1-1 is a simplified diagram that shows the transitions from the organization's standard software process to software project implementation and where feedback can be used to support project and process improvement.
Figure 1-1. Organizational process to project performance transitions.
This report presents a brief introduction to the concept of an organization's standard software process and then focuses on tailoring that process for a specific project, i.e., creating the project's defined software process. A method for documenting the project's defined software process in a software development plan also is discussed. Together, these concepts provide the foundation to fulfill the process tailoring and project planning activities associated with Level 3 of the Software Engineering Institute (SEI) developed software Capability Maturity Model (CMM) [PAUL93].
The scope of the report is focused specifically on tailoring an organization's standard software process to the needs of a project, documenting the tailoring as the project's defined software process, and finally documenting the project's defined software process in a software development plan. The concepts presented are based on experience and are adaptable to many different types of organizations.
1.2 Audience
This report was prepared for organizations that need to tailor a standard software process to the needs of specific software projects. Specifically, this includes software organizations that are planning to fulfill the requirements of the SEI CMM Level 3.[2] Other organizations that have had limited successes implementing a "standard" software process on diverse software projects also should benefit from the report.
The primary audience for this report is as follows:
a. Members of a Software Engineering Process Group (SEPG) (or other Software Process Improvement (SPI) contributors) in a Level 2 organization who need to understand how to tailor the organization's standard software process to the needs of each software project, specifically:[3]
1. Contributors responsible for building the organization's standard software process.
2. Contributors responsible for developing the tailoring rules that will help members of the organization prepare a project's defined software process from the organization's standard software process.
3. Contributors who need to define how to document the project's defined software process in a software development plan.
b. All contributors who need to understand the process-specific features of the Integrated Software Management (ISM) KPA of the CMM regardless of the organization's current software process maturity.
The second major audience for this report includes:
a. The software project managers who need to tailor the organization's standard software process for their projects and document the tailored process in software development plans.
b. The organization's managers who need to approve defined (tailored) software processes for specific projects.
1.3 Introduction to the Report
This report has been developed to address the most obvious issues that arise when tailoring a set of building blocks to the unique aspects of a software project. The report discusses the concept of software processes at the organization and project levels and how these processes are implemented through software development plans. An example is used to show how an organization's standard software process can be tailored and implemented as a project's defined software process. The report presents information on available automated tool support for documenting a project's defined software process and providing inputs to a project plan based on the chosen software process. Specifically, the following topics are addressed:
a. Section 2 provides a brief introduction to an organization's standard software process; why the building blocks that comprise the process are needed, how they are used, and items they could contain.
b. Section 3 discusses how to tailor the organization's standard software process to the needs of a specific software project.
c. Section 4 presents an example of tailoring an organization's standard software process to the needs of a specific project.
d. Section 5 contains conclusions.
e. Appendix A discusses automated tool support for describing a project's defined software process and implementing that process in the software development plan.
2. AN ORGANIZATION'S STANDARD SOFTWARE PROCESS:
AN OVERVIEW
An organization's standard software process documents "the way it does business." It is a compendium of information that describes how a software organization plans for, manages, builds, qualifies, and maintains software. In other words, the organization's standard software process consists of a number of building blocks that are used in different ways to support software projects.
The organization's standard software process may be described in a number of ways, e.g., through Data and Control Flow Diagrams (DFDs and CFDs), flow charts, etc. Most often, the organization's standard software process is a book or notebook arranged in topic areas with text descriptions of processes and procedures, lists of standard tools, and some form of process diagrams to describe the way the organization operates using these building blocks. Figure 2-1 shows an organization's standard software process as an inventory of building blocks (or process pieces and support tools) that needs to be assembled and fitted to fulfill each project's needs. The organization's software process could be structured by topic area (e.g., all processes dealing with project management, product engineering, testing, etc., could be grouped together), it could be a simple inventory with the building blocks listed in alphabetical or numerical order, or it could take some other form. The goal of the organization's standard software process is to document how the organization does business; the form is not really important.
Figure 2-1. Example building blocks.
The organization's standard software process is not magic. It's not simply an oversized set of instructions to do the impossible or an imposing tome of unreadable, incomprehensible diagrams. It's a basic description of how an organization does business. Ideally, it is a living document that exists both in hard copy and easily accessible on-line formats.
For example, the organization's standard software process contains Software Configuration Management (SCM) processes and practices. Most often, the processes and practices are supported with procedures and tools. The procedures and tools need to be consistent with the processes and practices; they are part of the organization's software process building blocks.
Each organization needs to develop and maintain building blocks that fit its particular requirements. Although the CMM provides goals that need to be fulfilled and activities that need to be performed to prove conformance with the requirements of a given CMM level, the contents of the organization's standard software process do not need to be limited to the requirements of the CMM nor organized to reflect the organization of the CMM's KPAs. The organization's standard software process should contain the processes and practices required to fulfill the organization's software-related technical and business goals.
Usually, the contents of an organization's standard software process are chosen to cover the needs of software projects considered to be large or complex for that organization; the organization's standard software process contains the building blocks that will cover the needs for the worst-case software project. Examples of sets of practices within the organization's standard software process are:
a. Software engineering, e.g., requirements management, requirements engineering and design, software life cycles, development methodologies.
b. Software engineering support techniques/disciplines, e.g., Software Quality Assurance (SQA), SCM, product inspections (or peer reviews).
c. Software management, e.g., software development planning, ongoing project management, software metrics, software cost estimation techniques, multi-disciplinary team coordination.
The development of an organization's standard software process is not trivial. Many organizations spend three or more years developing a standard software process, and the development and approval effort is just the beginning of software process improvement. Software process improvement can only happen when the processes and practices are institutionalized and used routinely throughout the organization.
3. TAILORING THE ORGANIZATION'S STANDARD SOFTWARE PROCESS
3.1 Introduction to Tailoring
Software projects have unique requirements. The products (or modifications to products) that result from a project generally are unique. Traditionally, the unique aspects of a project rather than a common set of building blocks has been the driving force behind software development planning. This focus often translates to using different sometimes conflicting processes for projects within a single organization, which means that the lessons learned in how to "do business better" for a given project can be very difficult to apply to new projects.
One of the factors that supports developing and using an organization's standard software process is that using common building blocks for all projects within the organization will help make planning and management easier through supporting the use of materials, methods, lessons learned, etc., from previous projects. Still, given the unique nature of most software projects, some tailoring needs to be made to the organization's standard software process to apply it to almost any new project. The steps used to tailor the organization's standard software process to the needs of a specific project will be somewhat different for each organization. In general, however, the following concepts can be used to help think through how to develop a project's defined software process.
New software project definitions often include the following information:
a. Project goals.
b. Project technical work requirements.
c. Performance requirements and standards.
This information is combined with the organization's inputs and external inputs, such as:
a. The organization's business goals,
b. The organization's standard software process,
c. Rules for tailoring the organization's standard software process,
d. Acquisition regulations, and
e. The acquisition organization's management philosophy,
to develop the project's defined software process. In its simplest form, tailoring an organization's standard software process to a specific software project can be thought of as shown in Figure 3-1.
Figure 3-1. Tailoring an organization's standard software process (overview).
Previous work in tailoring processes and standards has identified "axes for tailoring" organization's standard software processes [GINS95] that include formality, accuracy, scope, precision, and complexity and "key areas to tailor" for DOD-STD-2167A [MAIB94] that include documentation, product requirements, formal reviews, testing, and customer approval.
This report confines tailoring to a small, focused set of areas that have a high payoff in terms of cost and schedule. The areas that provide a focus for the tailoring method described in this report are:
a. Project Size and Complexity.
b. Formality.
c. Control.
3.2 Identifying Project Characteristics
Often, the answers to the questions in Table 3-1 can help define the characteristics of a project to the level of detail required to make informed tailoring decisions. Table 3-1 is roughly divided into three groups of questions to correspond with the three high payoff areas.[4] The development manager is expected to answer all the questions with rough order of magnitude answers before proceeding to the next tailoring step.
Once the project's characteristics are quantified at this level, the next step in tailoring the organization's standard software process to the needs of a project is to choose and tailor the process building blocks that will be used for the project.
3.3 Choosing and Tailoring the Building Blocks
Choosing and tailoring building blocks for a specific project is a two-step process. Step one involves selecting the appropriate building blocks from the inventory. This step involves adherence to some basic options for using individual building blocks, usually based on organizational policy, such as the ones that follow:
a. Some building blocks are always implemented as is.
b. Some building blocks may be tailored according to a set of guidelines. (Specific rules need to be documented for each tailorable building block. Generally, the guidelines will state whether the building blocks may be altered or whether only parts of the building blocks may be used.)
c. Some building blocks may be waived with appropriate approval.[5]
d. Some building blocks may be replaced with appropriate approval.
e. New building blocks may be added with appropriate approval.[6]
In all cases, the customer's needs and management philosophy provide major inputs to the tailoring decisions.
Step two involves tailoring the individual building blocks. The project characteristics, including technical and acquisition requirements, are the primary inputs needed to choose and tailor the correct set of building blocks for the project. Paragraph 3.3.1 defines the general approach to tailoring, and Paragraph 3.3.2 discusses making detailed tailoring decisions based on the project characteristics identified inTable 3-1.
Table 3-1. Sample project characteristics.
| Characteristic | Quantification |
| Size and Complexity: | |
| Software Product (estimated SLOC or FP) | . |
| Documentation (estimated # of pages) | . |
| Development Team (estimated # of people) | . |
| System Product Mix: | |
| Number of HWCIs | . |
| Number of CSCIs | . |
| Number of Interfaces (External) | . |
| Type of Software (Command & Control, Embedded, MIS, ATE) | . |
| Type of System (Centralized, Distributed, etc.) | . |
| Intent (Feasibility study, research, operational system, incrementally developed operational system, upgrade to an existing system, etc.) | . |
| Criticality (Life Critical, Safety Critical, etc.) | . |
| Users | |
| Number of Users | . |
| Type of Users | . |
| Local or Distributed | . |
| Number of Installations | . |
| Life of Product (Number of months or years) | . |
| Upgrade Interval | . |
| Formality | |
| Development requirements | . |
| Formal reviews and audits | . |
| Formal approval of deliverables and baselines | . |
| Control | |
| Management visibility level required | |
| Development Organization | . |
| Acquirer Organization | . |
| Project Risk Management | |
| Cost | . |
| Schedule | . |
| Technical | . |
| Key: ATE - automatic test equipment CSCI - computer software configuration item FP - function points HWCI - hardware configuration item MIS - management information system SLOC - source lines of code | |
3.3.1 The Tailoring Process
Tailoring rules are part of the organization's standard software process building blocks as shown in Figure 2-1. These rules provide directions on how to tailor the specific building blocks that comprise the organization's standard software process to the needs of a project. As previously mentioned, some of the building blocks always will be used, e.g., project management, SCM, etc. Other building blocks may be used only as required, e.g., peer reviews may only be required for projects with greater than three developers. Figure 3-2 expands on Figure 3-1 to show the basic steps required to tailor an organization's standard software process to the needs of a specific software process.
As shown in Figure 3-1, project information, organization inputs, and external inputs are all needed to tailor a software process for a specific project. Figure 3-2 shows that these inputs are required to identify the characteristics of the project. Then, in addition to the project characteristics identified during the first step of tailoring, subsets of the information shown in Figure 3-1 are needed as inputs to choose and tailor the correct set of building blocks for the project.
Figure 3-2. Tailoring a process for a software project.
For example, the building blocks that comprise the organization's standard software process and the rules for tailoring the building blocks to the needs of a project are the organization inputs required to help derive the project's defined software process.
3.3.2 Making Tailoring Decisions
Tailoring an organization's standard software process takes guidance from the organization's tailoring rules, information about the incoming project, knowledge of the requirements used by the acquisition organization, and software project management experience to make informed decisions. As an organization begins tailoring its standard software process, it is important to use experienced individuals to help mold the tailoring process and provide guidance as new project managers become involved with incoming projects. This will help reduce the amount of confusion and rework that often accompany an organization's first attempts at modifying/tailoring their processes for the needs of a project.
Table 3-2 provides examples of tailoring guidance based on the information obtained by filling out the project characteristics form identified in Table 3-1. The tailoring process for individual building blocks (Step 2) is as follows:
a. Quantify the project characteristics identified in Table 3-1.
b. Interpret the quantification of the project characteristic using the heuristics identified in Table 3-2 (or locally defined tailoring rules).
c. Identify the set of building blocks to modify (or use part of), waive, or replace.
d. Decide on the exact tailoring decisions for each selected building block.
It is assumed that the building blocks that are not identified in the tailoring process will be used for the project without change.
When the tailoring process is complete, the project's defined software process is first documented as an agreement between the project team and the organization regarding how the organization's standard software process will be tailored for this project. Second, the software development plan is developed to reflect the process to be implemented on the project. These two topics are addressed in Paragraph 3.4.
Table 3-2. Example tailoring guidance.
| Key Area | Quantification | Heuristics | Examples of Affected Building Blocks |
| Size and Complexity | Large and complex. Many hardware and software elements that need to interact. Generally built by many distinct organizations. | · Formalize requirements traceability and cross-organization communication. · Use standardized documents. · Where possible combine documentation and testing across organizations. · Share SEEs and tools across organizations. | · Software Lifecycles · Support Tools · Risk Management · Technical Documentation · Software System Test |
| Application or installation critical. | · If additional safety requirements, plan a safety program using MIL-STD-882C Safety Standard as a guide. · Use reliability modeling and testing. · Use secure development and test environments (as applicable). | · Software Lifecycles · Reviews · Metrics · Technical Documentation · Unit Test · Software System Test | |
| Medium size and complexity. Some interfaces with other software. Coordination with other software projects required. | · If interim software but still operational, need to worry about reliability, availability, testing, etc. | · Requirements Management · Software Lifecycles · Technical Documentation · Reviews · Metrics · Unit Test · Software System Test | |
| Special purpose. Limited application. Small number of users. Essentially an independent prototype. | · If a throw-away, minimize documentation; use engineering notes only. · If small team, limit inspections. · No formal, independent testing. · No specific language requirements. · Still need SCM control, but with limited formality. | · Requirements Management · Software Configuration Management · Inspections · Software Lifecycles · Unit Test · Technical Documentation · Reviews · Metrics · Software System Test · Programming Languages · Project Management | |
| Formality | Military Standards | · If a system upgrade or existing system replacement, should you change standards for the new software, e.g., from DOD-STD-2167A to MIL-STD-498? | · Risk Management · Reviews · Technical Documentation · Software Lifecycles · Software Configuration Management · Support Tools · Project Management |
| Commercial Standards | · Know what to expect in advance. | · Possibly All Available for Tailoring | |
| Subcontractor Defined Standards | · Don't do it without fully understanding the subcontractor's standards and ensuring they meet the project's needs. | · Only the Building Blocks Affected by other Project Criteria | |
| Traditional Acquisition Requirements | · Use traditional reviews (e.g., PDR, CDR, etc.) using MIL-STD-1521B as a guide. · Use traditional project management rather than IPTs. | · Reviews · Software Lifecycles · Software Configuration Management · Project Management | |
| Integrated Products Teams | · Use in-process reviews and open developer/ acquirer relations and agreements. | · Reviews · Software Lifecycles · Technical Documentation · Software Configuration Management · Project Management | |
| Loose | · Don't do it, except for throw-away prototypes. | · Software Lifecycles · Metrics · Building Blocks Affected by Other Criteria | |
| Control | Cost Risk(s) | · Minimize deliverable documents, formality of reviews. | · Reviews · Software Lifecycles · Technical Documentation · Project Management · Risk Management |
| Schedule Risk(s) | · Choose simplest adequate life cycle. · Use parallel implementations. · Language choices e.g., 4GL/rapid prototyping. · Reduce documentation. | · Reviews · Software Lifecycles · Programming Languages · Technical Documentation · Project Management · Risk Management | |
| Technical Control and Risks | · If the problem and solution not well understood, choose either rapid prototyping, incremental deliveries, or evolutionary model. · If requirements expected to be unstable, plan for rework, provide metrics for requirements stability. · If the project will reuse legacy or reusable software, ensure strong SCM. · If the project is expected to produce reusable code, enforce coding standards and ensure strong SCM. · If technical risks, use prototyping or COTS as risk mitigation. | · Possibly All Available for Tailoring | |
| Key: CDR - Critical Design Review COTS - Commercial-Off-The-Shelf 4GL - Fourth-Generation Language PDR - Preliminary Design Review SEE - Software Engineering Environment | |||
3.4 Documenting the Project's Defined Software Process
3.4.1 Documenting the Tailoring Decisions in a Compliance Agreement
A compliance agreement typically is used within an organization to document a project's defined software process. This agreement documents the tailoring decisions derived through the process described in Paragraph 3.3. In general, compliance statements document tailoring decisions by exception using statements of the form: "Project X will conform with the organization's standard software process except for the following provisions."
A waiver is generated when required building blocks are deleted from the project's defined software process, when the contents of any building block(s) are modified in significant ways (as defined for each organization), or when new or previously unapproved building blocks are used in a project's defined software process.[7] When reviewing waiver requests, it is important to ensure that measurement is not deleted from the project's defined software process. Measurement helps ensure that the organization will have visibility into the software project for project oversight, product tracking, and process compliance.
The compliance agreement is reviewed and approved by managers who have the authority to grant tailoring decisions for the organization's standard software process and/or, typically, the SEPG. The compliance agreement then forms the process-related foundation for the software development plan.
3.4.2 Documenting the Project's Defined Software Process in a Plan
The final step in documenting the project's defined software process is to record the process in a software development plan. Both military and commercial standards provide templates for software development plans. An organization usually chooses (or develops) a software development plan template and uses the template as a standard outline.[8]
Three items that help with the plan are Work Breakdown Structures (WBSs), schedules, and activity networks. These items support the evolution of the plan, and ultimately become part of it. When the work is identified and defined in the WBS, schedule, and activity network, the software development plan can be completed based on the work definitions, the process to be implemented, and the resource plan for project completion.
3.4.2.1 Organizing the Work
The work to be done usually is organized into work packages that are mapped into a WBS [LAKE93]. A WBS traditionally was used as a cost-reporting structure, but it is more effective when used as a road map for managing a project. A WBS has two parts: a product part and a process part. The product part is defined through the breakdown of a system into subsystems, configuration items, and other subelements of the system. The product is usually defined top down through the WBS. Processes are defined to support each level of the product breakdown. The processes usually are shown as an activity-based decomposition of the product at a level that will be defined and managed as a project. Each level of the WBS shows more detail concerning parts of the product and the processes that will be executed to produce (or support) the product (from the system level down to the smallest subelement identified on the WBS). When shown as a block diagram, as in the simplified example in Figure 3-3, the WBS can provide a decomposition of the products and processes at whatever level is required to develop, produce, and support a system. Guidelines for building a software project WBS follow (derived from [LAKE93]):
a. Show all software project work at a level that can be used for software project tracking and reporting. The WBS must provide the information that allows the project manager to extract progress measurement (technical, cost, and schedule) for the project's required status reporting.
b. Include products, events (e.g., reviews and audits), and processes (e.g., software qualification) that will show visibility into software development, testing, deployment, training, and life cycle support (as required).
c. Assign WBS elements so that they can support risk assessment, engineering change proposal evaluation, contract change evaluation, interface management, data management, and configuration control.
d. Provide the ability to extract costs for separate types of software work effort (e.g., prototype, full scale development, maintenance).
e. Ensure that the WBS is compatible with the available project resources (e.g., staff) and organization (e.g., independent qualification testing).
Additional guidance on constructing and using a WBS can be found in MIL-STD-881B.
Figure 3-3. Simplified example software WBS.
3.4.2.2 Documenting the Schedule
The most popular representation of a project schedule is in the form of a Gantt chart. This form provides a visual description of the duration and sequence of project activities. (Figure 3-4 shows a Gantt chart that reflects the WBS presented in Figure 3-3.) Schedules like this one depict the time ordering of events but lack the ability to show interrelationships and dependencies explicitly. When kept updated with progress information, the project schedule provides inputs for specific forms of project tracking such as earned value and the Cost and Schedule Status Report (CSSR).
Figure 3-4. Example software schedule with WBS elements.
3.4.2.3 Developing the Activity Network
When the schedule is related to the WBS, as in Figure 3-4, the schedule sequence begins to show possible relationships and dependencies among project activities. These relationships and dependencies are shown explicitly in an activity network like the one shown in Figure 3-5. Activity networks are an outgrowth of the Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) which, in addition to showing time dependencies, highlight sequence dependencies on a critical path. The value of showing an activity network with the critical path is that activities that rely on other activities for completion and/or have special time or resource limitations are highlighted for management tracking and oversight.
3.4.2.4 Completing the Software Development Plan
Section 3.3 identified four options for using individual process building blocks for a specific project. For each option, the following rules should be applied to document the project's defined software process in the software development plan:
a. When using a building block as is, reference it from the plan rather than repeating it to ensure the project's consistency with the organization's standard software process.
b. When a building block needs to be tailored, apply the specific guidance from the compliance agreement, and either
1. Document the exceptions to the building block in the plan, or
2. Rewrite the building block in the plan and explicitly mark the modifications.
Also, reference the compliance agreement in the plan.
Figure 3-5. Example activity network.
c. When a building block is waived, note in the applicable paragraph of the plan that the building block is "not applicable" and reference the compliance agreement.[9]
d. When a building block is replaced by a nonstandard building block, write the replacement building block in the plan at the applicable paragraph or reference the replacement building block.[10] Also, reference the compliance agreement in the plan.
The project's defined software process is documented or referenced in the software development plan. In general, software development plans present software process information in a logical order. Table 3-3 is a two-level table of contents for a software development plan based on the requirements of MIL-STD-498. This software development plan is organized as follows:
a. An introduction to the system and the document. (Section 1)
b. References. (Section 2)
c. Project information, constraints, and external requirements. (Section 3)
d. An overview of the software process and general plans for the project. (Section 4)
e. Detailed process descriptions for the software project, i.e., the project's defined software process. (Section 5)
f. Details of the schedule and activity network. (For clarity, the schedule and activity networks should be tied to the WBS.) (Section 6)
g. Project organization and resource information, e.g., organization charts, personnel, facilities, etc. (Section 7)
Table 3-3. Example SDP Table of Contents.
1. SCOPE 1.1 Identification 1.2 System Overview 1.3 Document Overview 1.4 System Overview 2. REFERENCE DOCUMENTS 2.1 Government Documents 2.2 Non-Government Documents 3. OVERVIEW OF REQUIRED WORK 3.1 System and Software Requirements and Constraints 3.2 Project Documentation Requirements and Constraints 3.3 Project Position in the System Life Cycle 3.4 Selected Program/Acquisition Strategy or Associated Requirements and Constraints 3.5 Project Schedule and Resource Requirements and Constraints 3.6 Other Requirements and Constraints 4. PLANS FOR PERFORMING GENERAL SOFTWARE DEVELOPMENT ACTIVITIES 4.1 Software Development Process 4.2 General Plans for Software Development 5. PLANS FOR PERFORMING DETAILED SOFTWARE DEVELOPMENT ACTIVITIES 5.1 Project Planning and Oversight 5.2 Establishing a Software Development Environment 5.3 System Requirements Analysis 5.4 System Design 5.5 Software Requirements Analysis 5.6 Software Design 5.7 Software Implementation and Unit Testing 5.8 Unit Integration and Testing 5.9 CSCI Qualification Testing 5.10 CSCI/HWCI Integration Testing 5.11 System Qualification Testing 5.12 Preparing for Software Use 5.13 Preparing for Software Transition 5.14 Software Configuration Management 5.15 Software Product Evaluation 5.16 Software Quality Assurance 5.17 Corrective Action 5.18 Joint Technical and Management Reviews 5.19 Other Software Development Activities 6. SCHEDULES AND ACTIVITY NETWORK 7. PROJECT ORGANIZATION AND RESOURCES 7.1 Project Organization 7.2 Project Resources |
The WBS, schedule, and activity network show the process relationships and the implementation sequence to be used for the project, as shown in Figures 3-3 through 3-5; they provide the basis for measuring project progress in relationship to the project plans. In its totality, the software development plan provides the foundation for measuring project progress, processes, and products.
4. TAILORING AN ORGANIZATION'S STANDARD SOFTWARE PROCESS - AN EXAMPLE SOFTWARE PROJECT
APPENDIX A. PROCESS & PLANNING TOOL SUPPORT
No comments:
Post a Comment