Five stages of the project life cycle

1. Project startup phase

(1) Project feasibility analysis

A successful product should be observed and evaluated from the following three aspects:

Designing products: commercial behavior
- Before product design, market research and evaluation must be done, and the timeliness of the product, market demand and technical feasibility must be considered;
- After the product design is finished, write down detailed product specifications (technical level, human resources, development costs, product costs)
- Try to avoid changing product specifications midway;
- Everything is subject to the needs or experience of the end user.
Management Project: Management Behavior
- The project manager must clearly understand its tasks to complete product development of acceptable quality within the specified time limit. Under this premise, it must measure manpower and other related resources, only do what should be done, and be able to act accordingly.
Development system: technical behavior
- Don't pursue perfection, only need to design and develop "good enough" products that meet the needs within the prescribed time limit and limited resources.
- The design work must be carried out accurately and absolutely documented. You cannot skip the design and write the program directly for the sake of progress.

Demand manager determination -> Demand analysis &Review -> Project scale estimation -> Project risk analysis -> Preliminary project execution plan &Review

(2) Project authorization letter

Clearly state the project objectives and management direction

Clearly authorize PM

Any information related to the project

(3) Clarify the necessary constraints

Confirm product specifications (cost/performance/quality/... demand)

Confirm product restrictions

Initially confirm the companies and units that will participate in the project

Confirm development mode (S/W Development Life Cycle)

Waterfall Model

Prototype Model (the initial requirements are not clear)

Spiral Model (Multiple iterations of Waterfall + Prototype)

。。。

2. Project planning stage

Initial planning: Should this project be accepted?

No plan, it must hang! Before deciding on the project, you must have done a very careful analysis.
Complete impossible missions! Because the project delivered by the customer is certainly not too simple.

（1）Scope/Time/Cost/Quality Plan

（2）Resource/Communication Plan

（3）Risk Plan

（4）Configuration Plan

(1) Scope management

The Art of Compromise: Progress vs. Specifications

The principle of quality and energy balance, if the customer repeatedly compresses the schedule, it can only reduce the specifications; if the customer repeatedly changes the specifications, it can only delay the schedule.

When the project is started, the first thing is to spend time to manage the scope of the project (what should be done and what should not be done). Only when the correct scope is defined, can the schedule, cost and manpower planning made afterwards be meaningful.

Project management tools- Work Breakdown Structure, WBS and change management

WBS
- Work breakdown, the most important basis for other project plans
- Decomposition criteria:
- Break down by "functional composition"
- Break down by "project life cycle"
- Decompose according to "system architecture"
- The minimum decomposition unit (Work Package) of WBS should be very specific, at least split into a week or 40HRs workload.
- Representation method (tree diagram + list)
Change management
- All changes must be approved by CCB (Change Control Board, that is, a meeting where the stakeholders involved in the change participate in decision-making), and a new plan must be created. It is strictly forbidden to accept the request of the customer to change the specification privately.

(2) Project progress (Time/Schedule) management

Time is different from other resources in that it is unidirectional, non-repeatable, and irreplaceable.
Planning the "schedule plan":
- Get all the smallest active units (leaf in the tree diagram) from WBS
- Confirm the relationship between tasks (duration, order relationship)
- FS (Finish to Start): After task A ends, task B can start;
- FF (Finish to Finish): After task A ends, task B can end;
- SF (Start to Finish): After task A ends, task B can end;
- SS (Start to Start): After task A starts, task B can start;
- Progress management chart (Gantt chart + network chart)
- Gantt chart describes the start and end time of each task, and can also be used to perform "progress tracking";
- The network diagram describes the sequence of tasks (nodes represent tasks, arrows indicate the order of tasks, and the numbers on the sides of the arrows represent the required time), which is used to find the critical path CPM (the path with the longest time in the graph), and only shorten the critical path The time required for the task can shorten the cycle of the entire project.
Manage reservations
- Set aside time for the entire project (usually 10-15% of the entire project cycle). Don’t use it unless you have to.
- According to Parkinson's law, no matter how much time you give an employee, he always tends to use up the time allotted to him.
Principles to know
- The schedule is for compliance rather than modification. When a delay occurs, the PM and supervisor should actively try to solve the problem and try to catch up with the schedule instead of revising the schedule.
- When planning the schedule, you should coordinate and integrate the opinions of various units from the rough to the detailed, and remember to work behind closed doors.
- Progress and cost are inversely proportional.
- The decomposition of WBS directly affects the project schedule
- During the execution period, we must constantly check whether there is any deviation between the project plan and the actual progress, and track and deal with it in time.

(3) Project cost (Cost) management

Project cost estimates for software systems will never be very accurate, and can only rely on experience or industry consensus to improve accuracy.
Projects are commercial activities, and it is better not to develop a product that is not profitable. Everything must be compromised for cost.
The main sources of cost:
- Management cost
- Hardware/structure design cost
- Production & material cost
- Software development costs (code lines, function points, man-months...)
- COCOMO model cost estimation
Sources of cost estimation errors:
- Insufficient basic data, there are still many uncertain factors in the project
- Project cost is sensitive to demand
- Inexperienced or poor cost estimation techniques
- Inconsistent before and after signing
Only after the WBS is made, and the more detailed the work is divided, the estimation can be closest to the actual situation. But it is often impossible to do actual work until you finish the WBS before quoting. Recommend "Man-Month Myth: The Way of Software Project Management". In the embedded software project, the labor cost is the most important part of the total cost;
Earned value management

Mainly used for project cost and progress monitoring. It compares the work done so far with the estimated value in the project plan to provide an estimate of how far the project is from completion. PM can get the cost of the project. How many resources.

(4) Project quality (Quality) management

Basic idea
- Quality is planned, not checked. Prevention is more important than treatment. A "quality plan" must be prepared during the planning stage and announced in plain text; the baseline can be set with thick lines before detailed rules are formulated.
- The quality of the project is the product of the work quality of all developers ;
- Quality management is not a one-time activity, but runs through the entire project life cycle;
- The quality level is relative and depends on customer demand and price;
- Quality management is a spirit, and quality products can not be made through ISO9000 or CMM.
- Quality management system: ISO9000 or CMMI
QA（Quality Assurance）

Focusing on the correctness of the process is a management function . The main purpose of QA is to ensure that the product can achieve the expected quality level and reliability target under the established schedule and budget. The tool of QA is audit , which must be audited at all stages from plan formulation, module design, code review, test plan, production process, and material preparation plan. The work product of the planning stage is to formulate a quality plan , clarify the quality standards adopted by the project, and determine how to meet the requirements of the standards. especially:
- Completed a certain milestone
- Request for change
- When the project is about to enter the next stage
QC（Quality Control）

Focusing on finding and tracking process bugs is an inspection function . QC must determine whether the project results are in compliance with the quality standards, and at the same time find the reasons for the discrepancies (bugs) and track whether they are properly resolved (the process of handling each bug must be recorded). The work product of the planning phase is to develop a test plan .

(5) Project human resource (Human Resource) management

The proper organization and management of personnel is a decisive factor affecting software projects.
MS has a clear rule-no more than 10 people in the project team.
Organization structure:
- Functional organization (the interest of the organization and the project may conflict)
- Project organization (duplicate resources, unable to implement company strategy)
- Matrix organization (conflict between functional or department manager and project manager)
- Strong matrix organization
Team management
- Create a project team with actual presence
- Establish reward mechanism
- Establish good interpersonal relationships
- Set up work authorization system
- Motivation theory: suit one's talents to suit one's best

(6) Project communication (Communication) management

70% of errors in management are caused by poor communication, and more than 80% of PM's time is spent on communication.
Communication plan:
- Communication needs: who, when, and what needs are needed?
- Communication content: communication format, content, level of detail, etc.
- Communication methods: clear communication methods and communication channels (conferences, bug management software, work reports)
- Communication responsibilities: who sends messages and who receives them
- Communication arrangement: A schedule of important communication events must be included in the project plan. (E.g. review meeting)
Communication channel calculation: If there are N people in the project, then N(N-1)/2 communication channels need to be established, which is equivalent to high communication costs.

(7) Project risk (Risk) management

Risk three elements:
- Is an event
- Probability of occurrence
- Will have a certain impact on the project
Risk management is the most overlooked and most difficult to manage
Risk management process (recurring):
- Risk identification: list the risks
- Project lacks visibility
- The appeal of new technologies
- Technology compatibility risk
- Performance risk: increase the intensity of the implementation of the design phase, make prototypes (Prototype), etc.
- Risk of rush online
- Usability issues
- Lack of material, price increase of parts
- Contract risk: check the content of the contract in detail with the legal affairs
- Demand change risk: agree on the change handling process in writing in advance
- Poor communication risk: development and announcement of project communication plan
- Lack of high-level support risk
- Schedule risk: If the Schedule cannot be adjusted, try to obtain as much resources and budget as possible, or deliver products in stages.
- Quality risk: carefully formulate project quality strategies and establish a quality control team.
- Team member ability risk: training or changing members in advance.
- Teamwork risks: clear goals and fair performance system.
- Personnel turnover risk: core tasks are assigned to multiple people for execution.
- Assist manufacturers in risk: formulate review and acceptance procedures before cooperation.
- Risk assessment
- Qualitative analysis
  - List probability/severity matrix
  - Have a certain understanding of the weak links of the project
- Quantitative analysis: mathematical processing and expression based on the results of qualitative analysis
- List the risk rankings (probability X severity)
- Risk planning (treatment)
- Avoid risks: actively give up or refuse to use the plan that causes the risk, and look for alternatives
- Transfer risk: transfer the risk to the outsourcing company
- Loss control: mitigating the degree of harm when the risk occurs
- Take risks: you can choose not to deal with risks with low probability of occurrence or low impact
- risk control

(8) Project procurement/contract management

Software outsourcing: actually 15% to 20% more than the net investment in own development
The management of outsourcing projects is more complicated than self-development:
- technical difficulty
- Communication complexity
- Outsourcing cost
Note for outsourcing projects:
- Communication problem
- Make a detailed plan
- Avoid delays
- Clear acceptance criteria (software specifications and API...)

(9) Project configuration (Configuration) management

Carry out the whole development process, the purpose is to establish and maintain the integrity and traceability of the product
Corresponding to the mature version control process in software development projects
Software configuration management-simply means project asset management, the process of identifying, tracking, and controlling products in the development process, including:
- The overall picture of the project, including product specifications and design specifications.
- The original plan of the project and all the changes that have been made during the project's operation.
- Any major turning points in the design phase and major technological breakthroughs during project operation.
- What problems did you encounter during software development and what was the solution? What is the corresponding program code?
- Significance of important software versions or project milestones, and a snapshot of the project status at that event
- The problem history in the hardware design and production phase is the solution.

3. Project execution/control stage

How do software engineering and project management work together?

Software engineering includes three cyclic processes:

Development process definition: including software requirements, software development process, software configuration management SCM
Software development: including software design, software construction, testing, maintenance and update
Software quality assurance: software quality

The project management process consists of three cyclic processes:

Project planning
Project implementation
Project monitoring

(1) Product specification design

After the product specifications are written, the customer must confirm and sign again at the end! All future design work must use this as a template. Once a customer wants to turn a new requirement into a "specification", it must change the formal document that has passed the review, and this must be approved by the quality management system.

Generally speaking, product specifications include the following aspects:

Introduction to hardware specifications
Product design concept, limitation and application scope
User Function Manual
Operation flow chart
User interface and artwork
Performance regulations
Special considerations

(2) Hardware design

The work of the hardware design stage is as follows. In addition to the appearance and structure design, the firmware engineer should participate as much as possible:

CPU selection
Main chip selection
Circuit design
Layout
Parts and materials management
Product shape design
Structural design
Model making before mold opening

The files output at this stage are:

Hardware design specification
GOOD 表
3D appearance
Structure diagram
Schematic diagram
Layout diagram

(3) System design

According to the size of the project or the hardware environment, select the appropriate design method. If the CPU frequency is only tens of M, and the memory is small, it is recommended to choose a structured method design and choose C language for development. If the project is large, the CPU frequency is several hundred M, and the storage resources are abundant, then the object-oriented method is selected, and the language can be C++ or Java.

(4) Test plan design

There are also standards for software testing. IEEE 829 describes in detail the provisions and precautions of the test plan, but the actual situation is that the ideas and spirit of the standard should be inherited according to the characteristics of the project. Before testing, it is necessary to focus on understanding more complex functions, new features, customer special requirements or vague areas described in the specifications, and then design test cases and plans.

(5) Risk assessment

The most common risks are the following :

Delay in progress
Demand inflation
Staff turnover
Specification collapse
Poor performance
Technology gap
cultural difference
Software and hardware integration
Manufacturing issues

Risk identification process :

Risk identification flowchart

4 ways to deal with risks :

Avoid: Don't touch the risky part
Restraint: prepare enough time and money to drop the risk when it takes shape
Mitigation: Take certain measures before the risk takes shape
Escape: Do nothing, pray for God's blessing

(6) Write design documents before coding

From the beginning of the project, a server should be prepared to store and manage all the files of the project, and all project members can easily obtain the required files or records.

The files that should be recorded include:

Product specifications
schedule
Hardware design related documents (CPU PIN configuration diagram, schematic diagram, layout diagram, etc.)
Technical documents-chip datasheet, 3rd party software library API, etc.
System architecture design specification (including API of each module)
Test plan
Test report and bug sheets
Quality document
Important meeting minutes
Important email backup
Other documents to be recorded

(7) Design review

Principles of design review:

Design review must be progressive. And run through the whole process of design
Invite the client of the design to participate in the design review
The larger the design, the more all project personnel must be called to participate.

(8) Implementation stage

When all design documents have passed the review, you can enter the implementation stage. It contains the following:

Program development and debugging
Hardware (electronics, structure) development
Software and hardware testing
Same quality execution
Factory trial production

Each stage of the project should be cycled according to PDCA (Plan, Do, Chick, Act). When a design problem is discovered during program compilation, you must not modify it yourself. You must temporarily stop the implementation, find countermeasures, confirm the scope of influence, and pass the design review of the relevant unit before you can continue the implementation. Which is the "design change" process

The results of the same embedded development will eventually be commercialized, so it is inevitable to deal with the factory.

The items that software engineers must deliver to the factory are:
- Binary File for burning
- Automatic test program and manual for production line
- Test procedures dedicated to environmental testing
The items that hardware and electronic engineers must deliver to the factory are:
- electronic circuit
- Electrical engineering specifications
- Special specification test instructions (functions not produced by the factory before)
The items that the structural engineer must deliver to the factory are:
- Combination diagram (expand all parts one by one)
- Outline drawing of special parts
- Special processing combination diagram

4. Project closing stage

(1) Closing of external contracts

(2) Closing of internal projects

Project data archive

Technical data archive

Record experience and accumulate the company’s project assets

close meeting, personnel disbanded

During the execution of the project, develop processes and use automated tools to record the track of project development (including programs, files, bug management, issue management, change management, etc.), and back them up regularly.

Clearly stipulate the start and end time for the implementation of the project closing process, preferably no more than one week, and communicate and coordinate with the department heads of the project members and the current project manager, and ask these colleagues to help the project in a certain period of time.

General approach to embedded project management