II.8.1 Ensure that scope is defined adequately.
Intent: The intent of this task is ensure that software scope has been adequately defined and bounded. If scope remains uncertain, tasks associated with Task II.7 should be revisited.
Mechanics: See Tasks II.7
Application of Formal Methods: a formal technical review can be used if scope is particularly complex
Application of CASE Tools: none
SQA Checklist:
1. Does the statement of scope define the application in an unambiguous fashion?
2. Is the statement of scope complete at this level of abstraction?
3. Can the statement of scope be easily understood by the customer and end-user?
4. Is the statement of scope bounded?
5. Is all terminology contained in the statement of scope understood by all readers?
Deliverables: Revised Software Scope document, if necessary
II.8.2 Research or reassess the availability of existing software that can achieve part of all of the defined scope.
Intent: The intent of this task is determine whether existing software - available from in-house sources or to be acquired from a third part - can meet part of all of the scope as defined in Task II.7 and revised in Task II.8.1.
Mechanics: Using software scoping tasks already completed, develop an outline of requirements for the software. Use internal information sources and external directories to conduct a search. Research any candidate software that is found.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Do's and Don'ts
Do: Assess the source of the software. Does the source have a reputation for developing high quality software?
Don't: Acquire software that has not been proven in similar application areas.
Don't: Acquire software from universities, unless there is no other option. Such software is notoriously difficult to modify.
Don't: Assume that "a few simple modifications" will be either simple or few.
SQA Checklist:
1. Is there tangible evidence of all SQA procedures that have been applied for all reusable software?
2. Do test suites exist for all reusable components or applications?
3. Is documentation for reusable components complete and up-to-date?
Helpful Hints
1. Use information developed in earlier tasks to develop a mini-spec for your search.
2. Be certain to "check references" for any candidate software package.
3. Be certain to assess the difficulty of integrating "alien" software with software that you'll be developing in-house.
4. Avoid mixed-language systems - they are generally more difficult to maintain.
Deliverables: List of potentially useful applications or software components
II.8.3 Develop the project plan.
Intent: The intent of this task is to develop a preliminary project plan that addresses the software scope developed in Task II.7.
Mechanics: This task is accomplished by applying Umbrella Activity Tasks U.1.1 through U.1.21.
II.8.4 Consider viability of subcontracting software development to a third party.
Intent: The intent of this task is to assess the project effort, duration and resources estimated in earlier tasks and determine whether subcontracting software development to a third party would be a more effective way to get the job done.
Comment: This task is initiated only when local resources are projected to be unavailable.
Mechanics: The project scope is presented to an outside software developer and a fixed price quote for software development is requested. The third party quote is compared to internal costs.
Application of Formal Methods: none
Application of CASE Tools: none
Do's & Don'ts
Do: Provide the third party contractor with a complete description of the work to be done.
Don't: Forget to get a detailed breakdown of "change costs."
Helpful Hints:
1. Be certain to define SQA mechanisms that will be used for the project.
2. Be certain to understand all deliverables and milestones.
3. Be sure to specify penalties for missed deadlines.
Deliverables: Third party quote for software development with a comprehensive project plan that includes deliverables and milestones.
II.8.5 Review the project plan with management and customer.
In general, this review is an informal walkthrough with interested stakeholders. Be sure to address risks that may have an impact on the project.
II.8.6 Make revisions as required.
Intent: The intent of these tasks is to review the plan with management and the customer and make necessary revisions to the plan.
Mechanics: Information developed in Tasks II.8.1 &emdash; II.8.4 is gathered and organized into a Project Plan document. The document is then reviewed internally for consistency. If management approves the plan, it is next sent to the customer for review and comment. At each stage of review, modifications are made as required.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have estimated developed for the project plan been generated using at least two different techniques?
2. Have risks been considered formally?
3. Has a risk mitigation, monitoring and management plan been developed?
4. Is the schedule clearly defined? Have milestones been placed at controllable intervals? Have deliverables been identified?
5. Can the project team defend its choice of task set?
Do's and Don'ts
Do: Be sure that the plan has a detailed section on project risks.
Do: Be sure that estimates have taken risk into account.
Do: Be sure that effort allocation is 'front-loaded.' That is, more effort is allocated to analysis and design than to coding.
Don't: Accept 'insane' delivery dates without formally indicating why such dates are unrealistic.
Helpful Hints
1. Compare the plan developed for this project with plans developed for similar projects in the past. Look for significant variations in risk, effort and schedule. Understand why these variations exist.
2. Develop a risk mitigation, monitoring and management plan for the project. This can be a separate section of your project plan.
Deliverables:
Use Browser "back" arrow or return to APM Process Design Language Description
