Startup phase
Figure 3-1 tasks and artifacts in the startup phase
Study the status of the product field to provide a basis for project demonstration. The study covers:
-
- Current Situation and Prospects in the product Field
- Business models and business processes in the product Field
- Product value and Profitability
- Product Features and complexity
- Technical feasibility study
Study the product implementation technology and summarize the technical feasibility. The study covers:
-
- Current implementation technology and technology trends of similar products
- Technical candidates
- Advantages, costs, and risks of each solution
- Matching of development teams and implementation technologies
The feasibility of the project is demonstrated based on business and technology to determine whether the project is carried out. If the project is launched, the overall plan of the Project is further demonstrated.
The arguments include:
-
- Commercial feasibility
- Technical feasibility
- Comparison between current products and similar products
- Project Benefits and prospects
- Project costs and risks
- Overall project plan
- Determine the project objectives and scope
At the beginning of the project, all relevant personnel must reach a consensus on the project's objectives and scope to form a common project vision. The vision is described as the Project Development Outline and communicated to relevant personnel.
The project development outline includes:
OverviewDescription |
Use three to five charts to describe product objectives, functions, platforms, customers, schedules, and development responsibilities |
Advanced functions |
Use a paragraph to review the product, and use a paragraph to describe each important function |
Unimplemented Functions |
Use a paragraph to describe each function that is useful to the product but not implemented in this project. |
RelatedPublic |
Use a paragraph to clarify each important stakeholder group and their risky share capital |
Project requirements |
Use a paragraph to describe each important project requirement |
Project risks |
A section is used to discuss the risks of each important project based on the exposure of risks. |
Project return |
Use a paragraph to review the product's return, and then use a paragraph to discuss the return of each important project. |
EndTheory |
Use one or three paragraphs to link all the above sections, clarify the project's needs and risks, and use arguments and arguments to summarize why the project succeeded. |
Table 3-1 Project Development Outline
PLANNING PHASE
Figure 4-1 tasks and artifacts in the planning phase
- Scale and workload evaluation
The project scale and workload are evaluated based on the preparation of various plans. The evaluation includes:
-
- Number and complexity of modules
- Number and complexity of input, output, and external interfaces
- Sloc and functions
- Non-productive support workload
- Development workload (man-month)
- Progress and milestones
- Progress risk
- Customize the Project Development Plan
The project development plan reflects the project team's expectations for the entire development cycle and specifies the overall project development policy. Like other plans, the project development plan is not fixed. During the execution process, the plan should be monitored, and the plan may be modified and re-released according to the actual situation.
The project development plan includes:
OverviewDescription |
Use three to five charts to describe the product objectives, functions, platforms, customers, schedules, and development responsibilities. (The overview section of the project development plan should be a copy of the overview section in the project development outline. When the project plan changes, revise the overview section of the project development plan instead of the project development outline. In this way, we can see how the project changes by comparing the Project Development Outline and project development plan in the future project evaluation) |
Advanced functions |
The product features are outlined on one to five pages, including additional information about these features (developers need such information to understand the implementation requirements ). |
Project Member |
Determine the software engineering functional roles and the number of people assigned to these roles. |
Software Process |
This section describes the software processes used in this project. (The specific content can be defined in the quality assurance plan) |
Software Engineering Method |
This section describes the software engineering methods and technologies used in this project. (The specific content can be defined in the quality assurance plan) |
Progress and workload |
This part expresses the estimation of the progress and workload of the entire project. Including:
- Explanations of fixed milestones and synchronization points
- Assumptions in the evaluation and possible sources of inaccuracy in the evaluation
- How to update the evaluation as the project progresses
(The specific schedule content can be defined in the development schedule) |
Risk Management Plan |
An overview of the risk management plan in this project. (The specific content can be defined in the risk management plan) |
TestQuantity |
An overview of the measurements to be collected in this project. |
Software Tools |
List each software tool to be used and the tasks supported by the tool. |
Project support |
Hardware SupportSpecify the required hardware, including the hardware that needs to be moved, obtained, or upgraded. Software SupportSpecify the required software, including software that needs to be obtained, installed, or upgraded. Manpower supportWhich person, department, or team provides support for the tasks of the development team. |
Table 4-1 Project Development Plan
- Customize risk management plan
Risk management tasks include risk identification, risk analysis, risk priority determination, custom risk resolution scheme, Risk Resolution, and risk monitoring, as shown in Figure 4-2 ].
Figure 4-2 risk management task
The Risk Management Plan defines the execution process and personnel allocation of these tasks.
The risk management plan includes:
OverviewDescription |
Use text and charts to describe the overall execution process of risk management tasks. |
Risk identification |
Describes in detail the implementation details of the "risk identification" task and the person in charge of each task. |
Risk Analysis |
Describes in detail the implementation details of the "risk analysis" task and the person in charge of each task. |
Determine risk priority |
Describes in detail the implementation details of the "determining risk priority" task and the person in charge of each task. |
Customize Risk Resolution Solutions |
Describes in detail the implementation details of the "Custom risk Handling Scheme" task and the person in charge of each task. |
Risk mitigation |
When a risk occurs, appropriate measures must be taken to resolve the risk. This part describes the operational specifications and procedures for risk mitigation. |
Risk Monitoring |
Describes in detail the implementation details of risk monitoring tasks and the owners of various tasks. |
Table 4-2 risk management plan
The Top N risks list is usually used in risk management. The risk list lists the main n risks in the current project by risk exposure. The Top N risks list includes:
Weekly ranking |
This week's ranking (if this week has been completely resolved, "---" indicates) |
Ranking last week |
Last week ranking (if it is a newly recognized risk, it is represented) |
Weekly data in the preceding table |
The number of weeks in the preceding table for this risk |
WindRisks |
Risk name or description |
ClassType |
Risk Type (only for progress-related risks ):
- Plan preparation
- Organization and management
- Design and Implementation
- Customers and needs
- Contractor
- Product
- Personnel
- Process
- Technology
- External Environment
- Development Environment
|
Occurrence probability |
Percentage probability of risk occurrence |
Loss degree |
Progress of loss when risk occurs (workday or workweek) |
Exposure volume |
Occurrence probability x loss degree |
StatusStatus |
Current risk status: not occurring, occurred, resolved |
Solution |
Briefly describe the risk resolution scheme. If there is a specific resolution Scheme document, link it to the relevant documentation |
Resolution progress |
Briefly describe the progress of resolving existing risks ("---" is used to indicate unused risks) |
Table 4-3 risk list
- Customized quality assurance plan
An important step to ensure the quality of work is to develop and implement a reasonable quality assurance plan.
The quality assurance plan includes:
overview description |
describes the purpose, applicability, and requirements for relevant personnel |
Software Process |
describes the software processes used in this project. |
software engineering method |
describes in detail the software engineering methods and technologies used in this project. |
Work specifications |
standardizes various tasks in engineering methods, and clarifies the implementation time, procedures, and guidelines. These tasks include: regular development activities (requirement analysis, architecture design, and detailed design) coding and testing, release and implementation) Meeting (work meeting, progress meeting, review meeting, etc) review (solution review, technical review, and Quality Review) measurement (product scale measurement, progress measurement, defect rate measurement, and test coverage measurement) Other activities (skill training, data collection, internal stream, and customer communication) |
Table 4-4 work specifications
- Custom development schedule
Based on the current evaluation of the project scale and workload, the initial development schedule is customized as part of the project development plan.
The development schedule includes:
-
- Project start and end time
- Start Time and end time of each stage of the project
- Task and start and end time of each stage
- The start and end time of each subtask.
- Milestones and synchronization points
- Role Definition and task allocation
As an important basis for tracking the project progress, the progress table must be continuously refined during the project promotion process. In addition, when the actual progress is different from the planned progress, you need to modify the schedule and re-release it.
Coming soon:General Software Project Development Process Specification (3)-implementation stage
Codeproject