U.1.1 Perform an adaptation criteria analysis.
Intent: The intent of this task is to establish the basis from which the appropriate APM task set will be selected.
Mechanics: Selecting on the Task Set for a Project
Application of Formal Methods: Selection scheme described in Selecting on the Task Set for a Project
Application of CASE Tools: none
SQA Checklist: none
Do’s & Don’ts:
Do: Be as honest as possible in addressing the adaptation criteria questionnaire.
Do: Use common sense and experience to select the appropriate task set as well as the results of the adaptation criteria analysis.
Don’t: Eliminate the possibility of defining a boundary project (i.e., one that spans two project categories and uses tasks adapted from each).
Helpful Hints:
1. When addressing each of the adaptation characteristics, be certain to err on the side of a conservatism. That is, is you can’t decide between a grade of 2 or 3 for a particular criterion, it’s usually best to opt for the grade of 3.
2. Don’t abandon common sense! Even if the task set selector points to one level of software engineering rigor, other circumstances may mitigate toward the selection of a more or less formal approach. Consider the entire picture
Deliverables: The task set selector (TSS) grade
U.1.2 Select the software engineering task set.
U.1.2.1 Use the task set selector to guide the choice of task set.
U.1.2.1 Define specific subtasks for the project.
U.1.2.2 Define specific milestones and deliverables based on task set chosen.
U.1.2.3 Define SQA points throughout the project. See also Task U.3.
Intent: The intent of this task is to select the software engineering task set that is to be used on your project. The task set becomes your work breakdown structure&endash;the set of tasks that will be scheduled and tracked as the project proceeds.
Mechanics: Using the results of tasks U.1.1 and U.1.2, the appropriate task set is chosen.
Application of Formal Methods: none
Application of CASE Tools: none
SQA Checklist: none
Do’s & Don’ts
Helpful Hints
1. Always begin with one of the pre-defined task sets, and if at all possible, use it as the work breakdown structure for your project. However, you may decide that one aspect of your project demands more rigor than the task set implies, it is both permissible and recommended that you mix and match portions of two different task sets.
2. Be certain to identify specific deliverables (their outline, format and content) before leaving this task.
Deliverables: Task set for the project and list of project deliverables
U.1.3 Bound the scope of the software effort.
Intent: The intent of this task is to determine project scope after basic requirements have been identified.
Mechanics: Meeting with the customer (e.g., JAD meetings) may be conducted or a functional specification (if one already exists) can be examined.
Application of Formal Methods: joint application design can be used to elicit the project scope
Application of CASE Tools: none
SQA Checklist:
1. Does the statement of scope avoid ambiguity?
2. Are all quantitative references (e.g., "many, some, a few") bounded by an actual value?
3. Is the statement of scope consistent?
4. Does the statement of scope discuss the input, processing and output for the application?
5. Does it discuss the producers of input and the consumers of output?
6. Does it mention systems that must be interoperable with the application?
Do’s & Don’ts
Do: Try to meet face to face with the customer.
Do: Structure your meeting in a manner that will make it most effective.
Don’t: Allow ambiguous requirements to guide your planning effort.
Helpful Hints
1. Work closely with the customer during this task. If the customer "doesn’t have the time to meet with you," delay work until time can be scheduled.
2. The statement of scope should be written in a way that enables any reader to get a picture of what the application is supposed to accomplish. It should be capable of standing on its own.
Deliverables: Statement of scope
U.1.4 Decompose product functionality.
Intent: The intent of this task is to define major software functions. In essence, a "function tree" is created so that estimates can be generated in Tasks U.1.5, U.1.6, and U.1.7.
Mechanics: One way to accomplish decomposition is to perform a ‘grammatical parse’ on the statement of scope. All verbs in the statement of scope are candidate functions, at a first level of refinement.
Application of Formal Methods: grammatical parse on the statement of scope
Application of CASE Tools: none
SQA Checklist:
1. Does the decomposition from one level of the tree to the next expand by no more that five functions per node?
2. Are all functions noted at one level of the tree represented at the same level of abstraction?
3. Can you (or someone else on the project team) write a one paragraph description of each function?
4. Can you (or someone else on the project team) describe the data that flow into and out of each function?
5. Have functions been defined to manage interactions with the user? with the operating system? with the external environment?
Do’s & Don’ts:
Do: Maintain the same level of abstraction at every level of the function tree.
Do: Write a sentence or two that defines each function.
Don’t: Try to develop a comprehensive design of the system. You’re simply trying to establish a basis for estimation.
Helpful Hints:
Look at the functions and ask yourself: Can we transform all inputs into outputs using these functions?
Deliverables: Function tree and description
U.1.5 Estimate the size (in LOC or FP) of each product function.
Intent: The intent of this task is to estimate the size in LOC (lines of code) or function points for each function or subfunction defined in Task U.1.4.
Mechanics: Each function is selected from the hierarchy derived in Task U.1.4. Experienced technical staff estimate LOC or alternatively, use information domain characteristics of the function to estimate function points. If size cannot be determined, the function should be further decomposed until estimates are possible.
Application of Formal Methods: function point analysis
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Are staff members doing the estimates experienced with software development in this application area?
2. Does the estimate of size conform to actual size of similar applications already completed.?
3. Has a convention for LOC been established? Alternatively, have conventions for function point analysis been defined for the team?
Do’s & Don’ts
Do: Get a number of different people to generate the estimates independently.
Do: Use more than one data point in generating your final estimate.
Don’t: Expect +/- 1 percent accuracy. It is not achievable.
Helpful Hints
Create an historical table of functions developed for past projects. Note the size and/or function points for each function in the table. This will help you to estimate similar functions for the new project.
Deliverables: Estimate of size (in LOC or function points)
U.1.6 Acquire historical data from development efforts for similar projects/products.
Intent: The intent of this task is to use data acquired from past projects and develop values for production rate (LOC/person-month or FP/person-month). These data are used in the estimation approach defined in Task U.1.8 and U.1.9.
Mechanics: Past projects are revisited and applied effort for each is determined. In addition, the total LOC and/or function points are determined. Production rates are calculated. Average values may be categorized by application category and project type.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Is the standard deviation of average production rate for each value reasonably low?
2. Is the effort data collected from the projects derived from reliable sources?
Do’s & Don’ts
Do: Try to collect data over the past two or three years.
Do: Make note of significant environmental changes (e.g., new tools, new people) that may have had a pronounced effect on production rate.
Don’t: Expect little scatter in the data. There will be scatter.
Don’t: Rely on qualitative estimates. Get quantitative data.
Helpful Hints
1. Be sure you account for part time labor on projects. Not everyone working on the project worked full time. Also, be sure to account for contractors who may have worked on a project.
2. Account for any reused code that added to the total size produced.
Deliverables: Productivity rate table
U.1.7 Develop a project estimate using a task-function-effort table.
Intent: The intent of this task is to develop a matrix of software engineering tasks (determined after the appropriate task set has been selected) and product functions. Effort estimates are made for each cell in the matrix.
Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 229-235.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Is approximate 40 to 50 percent of all effort allocated to tasks that precede code generation tasks?
2. Does testing absorb at least 30 percent of overall effort?
Do’s & Don’ts
Do: Estimate APM major tasks only.
Don’t: Assume that all functions will require the same level of effort. Account for differing level of complexity.
Helpful Hints
Compare the estimate developed using this technique with an ‘experiential estimate’ (i.e., a gross estimate of effort using past experience on similar projects) made independently.
Deliverables: Estimate of effort in work-units (e.g., person-months)
U.1.8 Develop a project estimate using a size-oriented approach.
Intent: The intent of this task is to develop a table of product functions and then generate efforts estimates from the table.
Mechanics: Develop size estimates for each function using data derived from task U.1.5. Data derived in Task U.1.6 are used to compute estimated effort for each function. See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 225-229.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist: none
Do’s & Don’ts
Do: Adjust the average productivity rate to account for the complexity of a function or for the entire system.
Don’t: Force this estimate to conform to earlier estimate derived in Task U.1.7.
Helpful Hints
The results of Tasks U.1.5 and U.1.6 provide necessary input for this task. If productivity rates are unavailable for your organization a gross estimate may be derived by using the following values: 1000 LOC/person-month or approximately 8 - 10 function points/person-month.
Deliverables: Estimate of effort in work-units (e.g., person-months)
U.1.9 Develop a project estimate using an empirical model.
Intent: The intent of this task is to use an empirical estimation model (e.g., COCOMO II) to estimate project effort and duration.
Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 235-240.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the empirical model been calibrated to the local environment?
2. Has this and other estimates taken umbrella activities into account?
Do’s & Don’ts
Do: Use size value derived from Task U.1.5.
Do: Be sure that you understand the assumptions that form the basis of any empirical model.
Don’t: Assume that you can divide the estimated effort by the projected project duration and get an accurate estimate of the number of people required to staff the project team.
Helpful Hints: none
Deliverables:
1. Estimate of effort in work-units (e.g., person-months)
2. Project duration in months
U.1.10 Estimate all project resources (i.e., people, skills, hardware, facilities, etc.).
U.1.10.1 Define skills required for the project and windows when particular skills will be required. This may be delayed until U.1.15 is complete.
U.1.10.2 List special hardware and/or software tools required for this project. Check availability of these tools.
U.1.10.3 Determine whether special facilities or environments are required for the project.
U.1.10.4 Specify training needs for project staff and establish a training schedule that will deliver knowledge just-in-time.
Intent: The intent of this task is to define specific project resources. How many people? What special tools? What facilities? and other questions must be answered.
Mechanics: The results of tasks U.1.1 through U.1.9 are reviewed and estimated of project resources are developed.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has availability of specialized human skills or specialized hardware/software or other technology been taken into account?
2. Is training budgeted for all project staff.
Do’s & Don’ts
Don’t: Assume that resources will be available when you need them. Be sure to create contingency plans for resources that are unavailable when needed.
Helpful Hints: none
Deliverables: List of special skills, hardware/software resources, special facilities, and training needs
U.1.11 Reconcile estimates and develop a combined estimate.
Intent: The intent of this task is to reconcile the estimates developed in tasks U.1.7 through U.1.9 and derive a combined estimate that will be used for budgeting and scheduling.
Mechanics: The different estimation data points are evaluated, differences are reconciled, and a combined estimate is derived.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist: none
Do’s & Don’ts
Don’t: Assume that estimation data points will be within +/- 5 percent. In general, accuracy is within +/- 20 percent.
Helpful Hints
Emotion and past experience play a role in this activity. Assign each estimate a ‘degree of comfort’ and use this designation as an indicator as you work to come up with a combined estimate. You should give more weight to estimates with high degrees of comfort.
Deliverables: combined estimate of effort and duration
U.1.12 Perform risk analysis. [For more detail, see Tasks U.8]
U.1.12.1 Identify all project and technology risks.
U.1.12.2 Estimate risk probability and impact and establish "cut-offs."
U.1.12.3 Develop risk mitigation, monitoring and management plan for all high probability/impact risks.
Intent: The intent of this task is to develop a plan for mitigating risks so that they are avoided. Also identify ways to monitor the project so that potential problems become visible as early as possible. Finally, develop a plan for managing risks that do become real problems.
Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, p. 245 - 271.
Application of Formal Methods: formal risk analysis
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has an explicit risk mitigation, monitoring and management plan been defined for the project?
2. Have you provided contingency plans should a risk become real?
3. Have you provided realistic work-arounds for serious risks?
Do’s & Don’ts
Don’t: Assume that risks will remain static. A low probability risk at the beginning of a project may migrate to a high probability risk as the project progresses. Adjust your planning accordingly.
Helpful Hints
Create a risk table and revisit it on a regular basis
Deliverables:
1. Risk table
2. Risk Mitigation, Monitoring and Management Plan
U.1.13 Develop a detailed project schedule.
Intent: The intent of this task is to create a task network, a timeline chart, resource tables and other scheduling information.
Mechanics: See Pressman, R.S., A Manager’s Guide to Software Engineering, McGraw-Hill, 1993, Chapter 12.
Application of Formal Methods: critical path scheduling
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have task dependencies been defined?
2. Have umbrella tasks been scheduled, where appropriate?
3. Have formal technical reviews been scheduled?
4. Has time been scheduled for iteration?
5. Do you show milestones that are closely spaced?
6. Does each major task have a deliverable associated with it?
Do’s & Don’ts
Do: Be certain to consider task interdependencies.
Do: Keep your schedule progress up to date.
Do: Examine the critical path on a daily or weekly basis.
Don’t: Scratch out a schedule on a note pad. Use the tools provide to you.
Helpful Hints
If schedule risk is high, err on the side of micro-management. Define closely spaced milestones and small tasks. Track progress in small increments.
Deliverables:
1. Project schedule
2. Supplementary information generated by tools
U.1.14 Establish a SQA plan for the project.
For disciplined and rigorous projects, develop an SQA Plan that defined the quality assurance tasks required for the project.
U.1.15 Establish an SCM plan for the project
For disciplined and rigorous projects, develop an SCM Plan that defines the change management tasks required for the project.
U.1.16 Establish a project monitoring and tracking approach for use throughout the project.
Develop mechanisms for tracking progress and problems on a regular basis. Options include regularly scheduled status meeting; progress reports submitted by each team member; E-mail reports; informal meeting.
U.1.17 Integrate all planning information into a Project Plan.
Develop a Software Project Plan that integrates all information developed in Tasks U.1.1 through U.1.16.
U.1.18 Review the plan and modify as required.
Review the plan with management, the project requester and staff to determine its viability.
U.1.20 Conduct project monitoring and tracking on an on-going basis.
U.1.20.1 Collect progress report information from all project team members.
U.1.20.2 Flag problems and develop a mitigation strategy.
U.1.20.3 Monitor all formal technical reviews and use their status as a final indicator of progress.
U.1.20.4 Update project schedule as actual task completion dates are reported.
U.1.20.5 Track all change requests and assess their impact on schedule.
Intent: The intent of this task is to track progress and problems that are encountered as other software engineering work occurs..
Mechanics: Monitoring and tracking are by two mechanisms: (1) regular reporting and (2) human-to-human contact.
Application of Formal Methods: critical path scheduling
Application of CASE Tools: t.b.d.
SQA Checklist: none
Do’s & Don’ts
Do: Spend time with each project team members discussing accomplishments and problems. Do this frequently.
Do: Encourage team members to voice their concerns.
Do: Use the results of formal technical reviews as a good indicator of progress.
Don’t: Be macho or establish a unyielding "can-do" atmosphere that refuses to recognize problems.
Don’t: Discourage team members from reporting progress honestly by punishing people when schedules slip.
Helpful Hints
If schedule risk is high, err on the side of micro-management. Define closely spaced milestones and small tasks and track progress in small increments.
Deliverables:
1. Project progress reports
2. Updates to the project schedule and related information
U.1.21 Collect project and process metrics.
See Task U.7.
U.1.22 Modify project estimates/schedule based on real-time information obtained as part of monitoring and tracking.
Based on information obtained from Task U.1.20, update and analyze the project plan regularly.
Use Browser "back" arrow or return to APM Process Design Language Description
