Cmm
CMM review process
Organize standard software flow
WBS
Estimate
plan
risk
PR
Software process tracking and monitoring
SCM
Allocate
CMM Capability Maturity Model
CMM is an abstract model that describes the goals you have to achieve in a maturity level, which expounds the requirements and does not guide how to do it. Certification through the CMM is a set of suitable for the actual situation and past project development experience. The system simultaneously meets this level of CMM, including all KPA targets asking for the following levels. CMM is a software process management improvement framework, initial grade, reasseparable, defined, manageable, optimized.
LevelFocusKay Process AreasLevel 5OptimizingContinuous process improvement-Defect Prevention-Technology Change Management-Process Change ManagementLevel 4ManagedProduct and Process quality-Quantitative Process Management-Software Quality ManagementLevel 3DefinedEngineering Processes and organizational support-Organization Process Focus-Organization Process Definition-Training Program-Integrated Software Management- Software Product Engineering-Inter group Coordination-Peer ReviewLevel 2RepeatableProject management processes-Requirements Management-Software Project Planning-Software Configuration Management-Software Quality Assurance-Software Project Tracking and Oversight-Software Subcontract ManagementLevel 1InitialCompetent people (and heroics)
A special name based on CMM's formal assessment: CBA IPI
CMM Based Appraisal for Internal Process IMPROVEMENT
CMM-based assessment for internal process improvement
KP: Key Practice
aims
Similarity:
1 execution agreement
2 execution capability
3 execution activities
4 measurement and analysis
5 verification implementation
The continuous process improvement can take the Ideal model recommended by the SEI to refer to 5 phases of the organization software process improvement cycle: initialization, Diagnosing, Establishing, Action, Expansion, Expansion .
1 CMM as an improved framework for software process management, all of which are characterized in each stage of the software process in each of the maturity levels to satisfy these features to make capacity maturity assessments.
2 Each KPA specifies the goal that software organizations to meet the KPA must be implemented.
3 The organization implements a level of KPA objectives, and the ability of the project management has reached the corresponding maturity level.
Reason elaboration:
The opacity of software development has caused great difficulties to the management and control of software, so software products cannot be completed on time, software productivity budget overrun, and a large number of errors that cannot be overcome in the product are common, and a project success is often Relying on personal outstanding capabilities, such production methods are obviously not suitable for large and medium-sized organizations. Although new software development methods and technologies are constantly increasing, software productivity and quality are not effectively improved, so people have begun to realize that the success or failure of software production processes can make the success or failure of a project or enterprise. For the reuse of successful software processes, summarize the analysis of the previous experience or lessons, the archive of all developed documents has become a complete and mature software process, establishing a unordered to order, from others In order to objective standards, from qualitative to quantitative and perfect processes, the software development process has enabled software development to develop in discipline, standard, and predictable direction.
benefit:
Provided to managers' visibility to project status and performance, relying on the entire team's cooperation, achieve resource sharing, dispatch order, process monitoring. Make the entire software development work in an orderly, controlled case.
In implementing CMM standards, software personnel must fill in a large number of documents, which undoubtedly adds a lot of workload, but the sharpener is not mishering, which has also brought great advantage, increase the visibility of the process, ensuring software The quality of the product, strengthens the team's cooperation and coordination, accumulating a lot of experience, many defects can be found in the beginning, reduce losses and to compensate for the loss of the loss, more importantly, in software frequent sports Industry, the company does not move the flow of people, because a good software process has saved the software development in the form of document, and people have left the experience, and the next workman is also very easy to get started. No need to come back from the beginning, this saves the company for time and cost, and an organization that has no good software development process is likely to suffer huge losses in personnel flow.
Software Project Management Analysis Based on CMM System
Although the focus of CMM focuses is the process improvement, but from the nature of the process, it can be broken down into different types of processes: management process, organizational procedures and engineering processes.
Management Process Organization Process Engineering Process Optimization Level Technology Change Management Handled Level Procedure Change Management Quantitative Process Management Defect Prevention Software Quality Management has defined the integrated software management IMF Coordination Organization process focus organization process definition training outline software product engineering peer review can be reused Demand Management Software Project Planning Software Project Tracking and Monitoring Substructure Management Software Quality Management Software Configuration Management Initial Case
Ossp: Organization Standard Software Process
Organization standard process corresponds to CMM KPA
Processes KPARDPRequirement Development Process requirements development process RMRCMPRequirement Change Management Process requirements change management process RMRTRequirement Tracking Requirements Tracking RMPPPProject Plan Process project planning process SPPPEPProject Estimation Process project estimation process SPPDPDesign Process design process SPEITPImplementation and Test Process implementation and testing process SPEATDPAcceptance Test and Delivery Process Acceptance Testing and delivery processes SPEDTPDefect tracking process defect tracking process SPEPIPProject Initial process project filing process SPTOPCPProject Close process project closed process SPTOPTOPProject tracking and Oversight process project tracking and monitoring process SPTOSCMPSoftware configuration management process configuration management process SCMBPPBaseline Promotion process baseline upgrade process SCMSQAPSoftware Quality Assurance process software Quality Assurance Process SQAAPAudit Process Audit Process Sqanchpnc Handling ProcessNC Process SQAPRPEER REVIEW UV Reviews Pricinter-Group Coordination Leisure Coordination ICTRAINING PROGRAM Training Outline TP Estimation
Delphi method
1 role and responsibilities
Conference coordinator: Develop Delphi Estimation Activity Plan
Call an estimated expert and provide an estimation of basic information
host a meeting
Record the results of the meeting and inform this result
Estimation expert: Familiar with the estimated basic information obtained before the meeting
Participate in the meeting
Provide and revise your own estimation
2 process description
Plan: The first step in performing Wide-Delphi estimation must formulate a plan, require:
Determine the estimation type
Choose a coordinator
Select an expert to estimate
Develop a conference schedule
Organization needs to consult (detailed description, task order or WBS to be estimated)
Estimation meeting: The coordinator will provide the following estimated advice to the estimated expert:
Detailed description of the product WBS to be estimated
Estimate the goal to achieve
Assumption
Estimating experts want:
Review existing information
Determine unified metrics
Estimation begins: Estimator uses the following unified estimation criteria to estimate:
Suppose one person completes all tasks
Suppose all tasks are completed in order
Assume that there is no interference in the implementation task
Experts independently make initial estimates for each task
Record the estimation result to the Delphi estimate table and indicate the assumptions used.
Example: Experts estimates the five tasks as follows:
Statistics Estimation Result: Conference coordinator collects estimates of each expert
Discussion: Coordinator organizes discussing estimated object, assumptions, and other related any differences and issues, the time limit for discussion is 10-20 minutes
Adjust the estimation result:
1 After discussion, the experts modify individual estimates based on new information obtained in the product update and new information obtained, and record them into the Delphi estimation table.
2 The coordinator collects amendment to estimate, and records in the same estimation statistics table, complete a round of estimation
3 Continue this process until four rounds of estimation; or estimated distribution ranges have been small to acceptable processes; or have arrived time (usually 2 hours); or experts do not want to change their estimates.
The method you can select by the last estimated result is as follows:
take the average
Take in
Give a range
Give a average (optimism and pessimism)
After the estimated results are determined, the estimated coordinator must make everyone consensus, and assume that the document 3 has been formed: the process can last multiple times according to the needs, generally 3 ~ 5 rounds; or the estimated distribution range is already acceptable The degree; or have arrived at the meeting; or experts do not want to change their estimates.
Pert method
1 role and responsibilities
Estimation coordinator: Familiar with the project
Assign the task to the estimated responsible person according to the already implemented WBS
Squiring and notifying the estimation result, summarizing the estimation result into the process database
Estimator: Responsible for submitting an estimation result of an estimation unit
Estimator: It is the responsibility main body of a task of WBS, responsible for the development of the task
Estimate the development experience and refer to the historical process library, estimate the assigned task.
Description
1.1 Program and Preparation
The estimation coordinator should ensure that the project work decomposing structure WBS has decomposed into a suitable and uniform estimate of particle size. Suitable, uniform granularity, for example, for the scale Kloc, each sub-task generally does not exceed 1 kloc; for a small scale, it is generally not more than
300L
OC; for progress estimation, each child is generally no more than 2 weeks. (This scale is for reference only)
1.2 Assignment Estimation Task
Estimating coordinators assign each estimated unit to the estimated responsible person. Each estimation unit has at least one element estimate, it is recommended that 2 estimates participate in estimates. For scale estimates, it should be noted that an estimator should not be estimated at the same time, unless the person in charge of multiple modules.
1.3 to estimate
Estimate the responsible person is responsible for organizing the estimation of this estimation unit. Give the minimum scale, maximum size, and most likely size estimation information, the gap between the three should be within a suggestion limit, (maximum scale-minimum) / most likely <40%, record estimation limitations and assumptions .
Minimum scale: the most smoothly affected;
Maximum size: Estimation in the worst case;
Most like size: The most likely estimate.
1.4 statistical results
Estimating coordinators collect estimates, summarize each sub-task to a table. This table automatically accumulates the scale of the entire project.
Expectation value = (Minimum scale maximum size 4 * most likely size) / 6;
Standard difference = (maximum scale - minimum) / 6;
Their meaning is:
The expected value e, calculates the estimated value that is most likely to access the actual situation according to the three values given;
Standard deviations SD, [E-SD, E SD] are the range of acceptable scale estimates. If the final actual value is within this range, it is considered that the estimation is successful. In the early stage of the organization, this range may be relatively large, but as estimated, this range should be consciously reduced to make more accurate estimates.
1.5 correction estimation result
Estimation The coordinator issues the last result to all estimates person in charge and estimates, allowing them to confirm their estimates, and if there is no deviation, this is estimated to be. If the original estimate is not appropriate, it can be proposed, and the sub task is re-estimated, repeating the above steps until the estimation result is acceptable.
WBS
Role: Provide a view that clearly indicates the activities and outputs to complete the project, define the scope of work, and provide the basis for the estimation. According to the system or by phase.
System / Subsystem / Module / Task / Work Package / ACT / LOE
PR Peer Review
Objective: Discover defects and find an improvement opportunity.
Quality is not free, the review does not slow down progress, defects, and later discovery defects will pay expensive consideration. PR Classification:
Inspection review
Team REVIEW team review
Walk throughhave
Pass Around Steel
Quality problem focus: find DEFECT
PR Purpose: Find DEFECT
Benefits: Team Exchange, Technology Progress
Method: Author finds a key part
For high-risk working products, large products with high risk parties, as well as the baselined work products, using inspection. Those who have smaller the incompetence of unrecognized errors, time-to-time, quality, and functional objectives, can adopt more informal review methods.
Participate in roles
1 Author of the front file or specifications
2 Must build their subsequent work in this work product
3 author's colleagues
4 Particular person in charge related to this work product interface
Work Product Types Recommendations Participate in role architecture or profile design Architect, Ra, SA, PM, integrated test engineers detailed design SA, Architect, programs, integrated test engineer process file SEPG team leader, management level Process Owner, process executor project Planning PM, Business Sponsor, Marketing or Sales representative, technical team leader, QA manager demand specification RA, PM, Architect, SA, system test engineer, QA manager, user or Marketing representative, file writing personnel, content expert, technical support representative Source code programmer, SA, unit test engineer, MAINTAINER, RA, programming standard expert system technical file author, PM, MAINTAINER, programs test file test engineer, programmer (unit test) or Architect (integrated test) or RA (system Test), QA represents user interface design user interface designers, RA, users, application sector experts, availability or people's engineering experts, system test engineers using manual file writing staff, RA, user or Marketing representative, system test engineer, maintainainer, SA, educational training designer and lecturer, technical support representative
Inspection
Character:
1 author
2 arbitrator
3 reader
4 recorder
5 reviewer
6 verifier
7 peer review coordinator
Stage steps:
Plan the author proposes PR to deliver review work products and related documents to arbitrator
Select the reviewer, allocate roles, and confirm the agreement
Planning a review meeting and content overview meeting, and issued a meeting notice
At least three working days before the review meeting, will be reviewed to the participants
Overview Report an important feature of work products. Description Review Goals
Prerequisite the study of work products, history this article
Prepare the defects found to be discovered, delivered to the author in the review meeting or before. Including the typesetting error or the style is inconsistent.
The arbitrator of the review meeting explained the role and review objectives, concentrated on defects.
Read work products
Reviewers put forward defects and problems
Record of records, defect recordings (messages for each defect: source, type, severity, location, description)
The reviewer decided to evaluate the evaluation of work products (accepted by the original, the acceptance conditions, re-examined after heavy work, review unfinished)
Accident signed a summary report to witness the results of this review
Arbitrators collect review feedback
Change the author correction defect
Arbitrator record workload
Follow-up tracking verifier verification defect processing
Way the product baseline
Peer review coordinator collects data, find and correct the number of defects, review summary report
Delivery-based baseline work products
Complete the review summary report
Complete the defect record
Complete typographic issues
Discover the number of defects and corrections
TEAM REVIEW, Walk THROUGH and INSPECTION
common:
1 need to prepare beforehand
2 is initiated by the author
difference
Team REVIEW
The reviewer sent back to the Issue log to the author if there is a dispute to adjust the meeting.
Concentrate on Issue, do not need to read a line
Walk THROUGH
Short preparation time, author and arbiter
risk
Risk is an uncertain event or condition that will cause positive or negative impact if it happens.
Risk properties:
1 event
2 happening probability
3 cause effect (range, time span)
4 frequency
The risk of risk is generally the quality problem or cost of the final product or the project delay, or even the overall project failed.
Risk management is a systematic process for identifying, analyzing and responding to project risks
1 Risk management plan
2 risk identification
3 risk qualitative analysis
4 risk quantitative analysis
5 Risk response
6 risk monitoring
Participate in risk recognition:
Risk management team members, customers, end users, project doors, other project managers, experts
When to identify risks
1 Risk identification at the beginning of the project, and at each stage, especially at the beginning of each stage, risk identification
2 re-execution
Risk identification method
1 Historical information or similar items
2 expert
3 Brainstorm Delphi
4 Preparation Risk List
Risk occurrence probability (high / medium / low)
Evaluation of the impact (large / medium / small)
Risk Score Risk Score = Probability X Impact
Risk types that need to be managed
1 has a big impact / high probability
2 There is little influence / have a high probability
3 There is a big impact / have a very probability
Risk response
1 risk avoidance: re-establish plan, change the project, etc., eliminate risk causes, have evade risks
2 Risk transfer: Through responsibility allocation, insurance, development contract, outsourcing, etc., etc., the people are responsible for the risk.
3 Risk mitigation: try to reduce the negative impact of risks or reduce its probability
4 Risk Accepted: If the risk is happening, what measures do not take, accept it; or take an emergency plan.
Risk response strategy
1 Insurance: Transform unknown risk to knowing risks and cost
2 Sign Contract: If the other person is more experience, it is risky, if the other party accepts risks through the contract, it is risk transfer.
3 Emergency Reserve: It can be time or funds for reservation at risk.
Regarding risk often
Q: How do you deal with very serious risks?
A: List in the risk list, often reassessment
Q: Will you only use a risk management strategy?
A: No, you should make a reasonable combination according to the actual situation.
Q: What is the risk management activities you have to do in the project execution phase?
A: Monitoring risk (including non-serious risks) and implementing risk management plans
Q: What is the most important issue for project conference?
A: Risk
Q: How to consider risks at the meeting
A: Ask each of the identified risks, the problem is answered by the owner, and when you ask if there is no new risk
Software process tracking and monitoring
Tracking and monitoring purposes: Timely reactive project progress, cost, risk, scale, critical computer resources and workload, through analysis of tracking results, based on tracking and monitoring strategies, effective action can be established Equal cases of time, cost, quality requirements, etc. have completed the project.
Steps: Code, execution, comparison, correction deviation
1 six major tracking elements
2 tracking frequency
3 Determine the deviation calculation formula, the deviation range (actual value - estimate) / actual value
4 Clear data collection method (email or installment), clarify the provider of each tracking data.
5 Clear deviation processing measures, in general, if the deviation exceeds the range of domain values, responds to scale, workload, and cost, the project should be re-adjusted, re-cast the task, redistribute the task of the project; the risk should be followed Risk management strategy is performed; for critical computer resources, the resource plan should be adjusted according to the actual situation.
Special case: In order to track the tracking results of the top six tracking items of the project and the review project. Before the meeting, the training of last week's project will be discussed, and the work will be discussed next week, the work summary will be reported to the regular report. As the basic content discussed as a special case. In addition to confirming the project tracking information, the special case will also discuss the contents of the discussion: average issue / motion, SQA report, PM related report, Issue log, risk, NC, demand change, control information change .
Milestone meeting
Hand in an important period of important delivery of important delivery or project
Meeting Purpose: Review Project Process Activities and Its Delivery Products, Project Manager Checking the Technical Review Results of the Milestone Products, Evaluate Project Risk, and Judgment Projects Continued and reviews the next stage.
Submit a conference information: Project Manager submit a project-related plan (such as a project plan, development plan), milestone report, milestone delivery product technical review result; SQA personnel submitted SQA report.
