This is the 12th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge
A 🌻 scope management
The scope management determines what work is included and what work is not included in the project. The project scope defined by this may change due to various reasons during the whole life cycle of the project. The project scope management also manages such changes in the project scope. Changes in project scope are also called changes. The project scope is managed through five management processes.
1.1 Five management processes
- Plan scope management (prepare scope management plan). Describe the process for defining, validating, and controlling project scope.
- Define the scope. Describe the product scope and project scope in detail and prepare a project scope statement as a basis for future project decisions. Its inputs include: Project charter. Project scope management plan. Organizational process assets. Approved change application.
- Create a work breakdown structure. The overall project work is broken down into smaller, manageable components, forming a top-down breakdown structure.
- Confirm the scope. Formal acceptance of the completed deliverables.
- Range control. Monitor project and product scope status and manage scope baseline changes.
1.2 Product scope and Project scope
Product scope refers to the functions that a product or service should contain. Product scope completion is determined by whether the product meets the product description. The product scope is the basis of the project scope. The definition of the product scope is a description of the product requirements.
Project scope refers to the work that must be done on the project in order to deliver the product. The definition of the project scope is the basis for generating the project management plan. The completion of the project scope is measured against the scope benchmark. The scope baseline for the project is the approved project scope statement, THE WBS, and the WBS Dictionary.
The product scope description is an important part of the project scope statement, so when the product scope changes, the project scope is the first to be affected.
The WBS breaks down the overall project or major deliverables into manageable sub-projects or work packages, which need to continue to be broken down into manageable work packages, and the process continues until the entire project department is broken down into manageable work packages, the sum of which is the scope of the project. The most common WBS are shown in the following table:
2 🌷 Progress management
Schedule management is to adopt scientific methods to determine schedule goals, prepare schedule plans and resource supply plans, control schedule, and achieve schedule goals on the basis of coordination with quality and cost goals.
2.1 Progress management process:
-
Activity definition: Identify the specific activities required to complete the project deliverables.
-
Activity sequencing: Identify and record sequential and logical relationships between activities.
-
Activity resource estimation: Estimates the types and benefits of resources needed to complete activities.
-
Activity duration estimation: Estimate the specific time required to complete each activity.
-
Schedule planning: analyze activity sequence, activity duration, resource requirements and schedule constraints, and develop project schedule.
-
Schedule control: carry out project activities according to schedule plan. If deviation is found, analyze the cause or make adjustment.
2.2 The methods for estimating activity resources mainly include expert judgment, determination of alternative schemes, open estimation data, estimation software and bottom-up estimation.
-
Expert judgment. The expert judgment method is usually based on the experience of similar projects in the past and the judgment of the project by the project management experts, after careful thinking, reasonable prediction, so as to estimate the project resources.
-
Determination of the replacement plan. Resource estimates are intended to provide room for project budget clarity, data for early resource preparation, and a clear statement if an alternative to an activity exists, or if alternative support is possible for the resources provided.
-
Publicly available estimates. Some companies regularly publish data on productivity or labor rates, including labor transactions, materials and equipment information for many countries and regions.
-
Estimation software. With the power of software, you can define resource availability, rates, and different resource calendars.
-
Bottom-up estimates. Decompose complex activities into smaller tasks to facilitate resource estimation. Estimate the amount of resources required for each task, and then summarize the amount of resources required for the entire activity.
2.3 the COCOMO model
Common software sizing methods. The commonly used line of code analysis method, as one of the units of measurement estimation, estimates the amount of work per programmer in line of code and adds up the software cost. According to its level of detail, the model can be divided into three levels:
-
The basic COCOMO model is a static univariate model that calculates software development effort using an empirical function that takes the estimated number of lines of code (LOC) as an independent variable.
-
On the basis of the basic COCOMO model, the intermediate COCOMO model adjusts the workload estimation by using the influencing factors involving products, hardware, personnel and projects.
-
The detailed COCOMO model includes all the characteristics of the intermediate COCOMO model, divides the software system model into three levels: system, subsystem and module, and further considers the influence of each step in software engineering (such as analysis and design).
2.4 COCOMO Ⅱ model
COCOMO’s upgrade also uses software size as the primary cost factor, considering multiple cost drivers. The method includes three stage models, namely, the application assembly model, the early design stage model and the architecture stage model. Contains three different sizing options: object points, function points, and lines of code. The application assembly model uses object points; The early design phase model uses function points, which can be converted into lines of code. Gantt chart (Gantt chart) and Program Evaluation&Review Technique (PERT) chart are commonly used to describe the schedule.
2.5 Critical Path method
Critical path: The shortest duration of a project, but the longest path from start to finish. There may be multiple critical paths in the schedule network diagram, and the critical paths are constantly changing as activities change. Critical activities: Activities on the critical path, earliest start time = latest start time. In general, each node’s activity will have several times:
- Earliest start time (ES), the earliest time that an activity can begin.
- Earliest end time (EF), the earliest time that an activity can be completed. EF = ES + time limit for a project
- Latest end time (LF). The latest time at which an activity must be completed in order for the project to be completed on time.
- Latest start time (LS). The latest time at which an activity must begin in order for the project to be completed on time. LS=LF- Duration These times are usually part of each node.
Forward push: first start ES= the maximum value of all pre activities completing EF first; Earliest completed EF= earliest Started ES+ Duration. Reverse: the latest completion LF= the minimum value of all subsequent activities to start LS at the latest; Latest start LS= Latest Finish LF-Sustained event.
Total floating time = Start LS at latest – Start ES at earliest or complete LF at latest – EF at earliest or critical path – Non-critical path Duration.
Free floating time: it refers to the amount of time that an activity can be delayed or delayed from the earliest start time without delaying the earliest start time of any subsequent activity and without violating the schedule constraints.
Free float time = Minimum of the earliest start time of the following activity – the earliest finish time of this activity.
🍑 Cost management
Project cost management is to manage and control the various processes required in the implementation process of the whole project in order to ensure that the project can be completed as soon as possible with quality under the approved budget conditions.
3.1 Three Processes
-
Cost estimation: the estimation and planning of the cost required to complete the project, which is an important, critical and sensitive part of the project plan; Cost estimation is mainly carried out by means of decomposition and analogy. The basic estimation methods are divided into three categories: top-down estimation, bottom-up estimation and differential estimation.
-
Cost budgeting: allocate the estimated total cost to each work package of the project and establish a cost benchmarking plan to measure project performance; Emergency reserve and management reserve.
-
Cost control: ensure that all work is carried out within the respective budget.
3.2 Type of cost
-
Variable costs: Costs that vary with production, effort, or time. Variable costs are also called variable costs.
-
Fixed costs: Non-repetitive costs that do not vary with production, workload, or time are fixed costs.
-
Direct costs: Costs that can be directly attributed to project work are direct costs. Such as project team travel expenses, wages, materials and equipment used in the project, etc.
-
Overhead costs: The overhead costs of a project, such as taxes, additional benefits, and security costs, are derived from the general overhead account or from the apportion of the project costs shared by several projects.
-
Opportunity cost: when a commodity is produced with a certain amount of time or resources, the lost opportunity to use these resources to produce other best alternatives is the opportunity cost, which generally refers to one of the biggest losses after making a choice.
-
Sunk costs: The costs incurred by past decisions that cannot be changed by any present or future decisions. Sunk cost is a kind of historical cost, which is uncontrollable cost for existing decisions. It will greatly affect people’s behavior and decision making. The interference of sunk cost should be eliminated in investment decision making.
Learning curve: When the product is repeatedly generated, the unit cost of the product will decrease regularly as the production expands. This should also be taken into account when estimating costs.
4 🍊 Software configuration management
Configuration management is the discipline that identifies systems configured at different points in time in order to systematically control configuration changes and maintain configuration integrity and traceability throughout the life cycle of the system. In GB/T11457-2006, “configuration management” is formally defined as “the technical and managerial guidance and monitoring methods of applying to identify and describe the functional and physical characteristics of configuration items, controlling changes to these characteristics, recording and reporting the status of change processing and implementation, and verifying compliance with specified requirements.”
4.1 Six main activities:
- Develop a configuration management plan
- The configuration identifier
- Configuration control
- Configuration status report
- Configuration audit
- Release management and delivery.
4.2 configuration items
GB/T11457-2006 defines a configuration item as “hardware, software, or a collection of both designed for configuration management and treated as a single entity during configuration management”.
The following items can be managed as configuration items: externally delivered software products and data, specified internal software work products and data, specified support tools for creating or supporting software products, vendor/vendor-provided software, and customer-provided equipment/software. Typical configuration items include project plans, requirements documents, design documents, source code, executable code, test cases, and various data required to run software. After being reviewed and checked, they enter configuration management.
The main attributes of each configuration item are name, identifier, file status, version, author, and date.
Configuration items can be classified into baseline configuration items and non-baseline configuration items. For example, the baseline configuration items may include all design documents and source programs. Non-baseline configuration items may include various plans and reports for the project.
Operation rights of all configuration items should be strictly managed by the CMO (configuration administrator). The basic principles are as follows: Developers are allowed to read the baseline configuration items. Non-baseline configuration items are open to the PM, CCB, and related personnel.
4.3 Status of configuration Items
It can be divided into “draft”, “formal” and “revised”. When a configuration item is created, its status is draft. After the configuration item passes the review, its status changes to Official. If you change the configuration item later, its status changes to Modify. After the modification is complete and the configuration item passes the review again, its status changes to Official. As is shown in
4.4 Version number of the Configuration item
-
The version number of the configuration item in draft state is in the format of 0.YZ. The YZ number ranges from 01 to 99. As the draft is revised, the value of YZ should increase. YZ initial value and increase by the user’s own grasp.
-
The version number of the configuration item in the official state is in the format of X.Y, where X is the main version. The value ranges from 1 to 9. Y indicates the version number. The value ranges from 0 to 9.
When a configuration item becomes an official file for the first time, the version number is 1.0.
If the upgrade scope of the configuration item is relatively small, you can make the changed part as the attachment of the configuration item. The attachment version is 1.0, 1.L… . When the changes in accessories accumulate to a certain extent, you can increase the Y value of the configuration item. When the Y value increases to a certain extent, the X value increases. The X value can be directly increased only when the upgrade range of the configuration item is large.
- The version number of the configuration item in the Modified state is in x. YZ format. When a configuration item is being modified, only the Z value is increased and the X.Y value remains unchanged. After the configuration item is modified and the status becomes official, set Z to 0 and add X.Y. See rule 2 above.
4.5 Version management of Configuration Items
In the process of project development, most of the configuration items have to be modified several times before they are finally determined. Any changes to the configuration items will result in a new version. Since there is no guarantee that the new version will be “better” than the old one, the old one cannot be discarded. The purpose of version management is to save all versions of configuration items according to certain rules, avoid version loss or confusion, and quickly and accurately find any version of configuration items.
4.6 Configuring the Baseline
(baseline for short) consists of a set of configuration items that constitute a relatively stable logical entity. Configuration items in the baseline are “frozen” and cannot be modified by anyone. Changes to the baseline must follow formal change control procedures.
Baselines usually correspond to milestones in the development process, and a product can have multiple baselines or just one. Baselines delivered to external customers are commonly called Release baselines, and baselines used by internal development are commonly called Build baselines.
A set of uniquely identified requirements, designs, source code files, and corresponding executable code, construction files, and user documents constitute a baseline. An example of a baseline is a test version of a product (which may include requirements analysis specifications, summary design specifications, detailed design specifications, compiled executable code, test Outlines, test cases, user manuals, etc.).
For each baseline, define the events that establish the baseline, the controlled configuration items, the procedures for establishing and changing the baseline, and the authority required to approve changes to the baseline. During project implementation, each baseline is subject to configuration control, and these baselines can only be updated using formal change control procedures.
4.6.1 Baseline Benefits
- Baselines provide a fixed point and snapshot of the development effort.
- New projects can be established at the points provided by the baseline. The new project is isolated from subsequent changes to the original project (on the main branch) as a separate branch.
- Baselines provide a way for teams to undo changes when updates are considered unstable or untrustworthy.
- Baselines can be used to re-establish a configuration based on a particular release to reproduce reported errors.
4.6.2 Functions of the Configuration Library
It stores configuration items and records all information related to configuration items. It is a powerful tool for configuration management.
- Record all information related to the configuration, where it is important to store controlled software configuration items.
- Using the information section in the repository to evaluate the consequences of changes is of great significance for change control.
- X Extracts management information for various configuration management processes from the library.
The use of the configuration library can help the configuration administrator to information system development process of a variety of work products, including semi-finished products or phase products and final products management in good order, so that it will not be confused, mixed, lost.
4.6.3 Configuring the Library Type.
-
Development libraries, also known as dynamic libraries, programmer libraries, or working libraries, hold configuration entities that developers are currently developing, such as new modules, documents, data elements, or existing elements that have been modified. Configuration items in the dynamic are placed under version management. A dynamic library is a developer’s personal workspace, controlled by the developer. The information in the library may be changed more frequently, and no configuration control is required as long as the consumer of the development library considers it necessary, since it usually does not affect the rest of the project. You can change it at will.
-
A controlled repository, also known as a master repository, contains the current baseline plus changes to the baseline. Configuration items in the controlled repository are placed under full configuration management. At the end of a phase of information system development, the current work products are stored in a controlled repository. Can modify, need to go through the change process.
-
Product libraries, also known as static libraries, release libraries, and software repositories, contain archives of baselines that have been released for use and are placed under full configuration management. Upon completion of system testing, the developed INFORMATION system products are stored in the product base as final products awaiting delivery to users or field installation. Generally no longer modify, really want to modify the words need to go through the change process.
🍅 quality management
Quality is a combination of software product features and represents the ability of a software product to meet either explicit (basic) or implied (expected) requirements. Quality management refers to the determination of quality policy, objectives and responsibilities, and through quality planning, quality control, quality assurance and quality improvement in the quality system to achieve all the management functions of all activities;
5.1 Three major processes:
-
Quality planning: the process of identifying quality requirements and standards for the project and its products and describing in writing how the project will meet these requirements and standards.
-
Quality assurance: It is generally performed at regular intervals (e.g., at the end of each phase) to ensure project quality through systematic quality audits (software reviews) and process analysis.
-
Quality control: monitor the specific results of projects in real time to determine whether they meet relevant quality standards and develop effective plans to eliminate the causes of quality problems.
5.2 Quality Characteristics
GB/T 16260-2002 Information technology software product evaluation quality characteristics
5.3 McCal quality model
5.4 Software Review
Quality: The specification of the design meets the user’s standard, which is called design quality. The correct execution of the program according to the conditions specified in the design specification is referred to as program quality.
5.4.1 Software fault-tolerant techniques
Fault tolerance is the processing ability of software when it encounters errors. The main means to realize fault tolerance is redundancy, including the following four redundancy technologies:
-
Structure redundancy: There are static, dynamic, and mixed redundancy. When an error occurs, the system backs up the error.
-
Information redundancy: The addition of an additional piece of information to the data for error detection and correction, such as the principle of check codes.
-
Time redundancy: Repeat execution when an error is encountered, such as rollback, repeat execution and error, then roll into error handling logic.
-
Redundant additional technology: refers to the resources and technologies required to implement the redundant technology of structure, information and time, including programs, instructions, data, space and channels for storing and mobilizing them. In fault-tolerant techniques that mask hardware errors,
🚀 Risk management
Risk management is to carry out serious analysis and scientific management of project risks, so as to avoid adverse conditions, less losses, achieve expected results and achieve project objectives, to avoid the occurrence of risks or minimize the impact of risks. However, it is impossible to completely avoid or eliminate risk, or to enjoy the equity without bearing the risk.
6.1 Risk management plan preparation
How to arrange and implement project risk management, develop the following steps plan.
-
Risk identification: Identify the known and predictable risks in the project, identify the sources of risks, the conditions under which risks arise, describe the characteristics of risks and which projects can generate risks, and form a risk list.
-
Qualitative analysis of risks: to rank the identified risks, determine the possibility and impact of risks, determine the priority of risks, and determine the types of risks.
-
Quantitative analysis of risks: to further understand the specific possibility of risk occurrence by how much, the specific consequences by how serious. Including sensitivity analysis, expected monetary value analysis, decision tree analysis, Monte Carlo simulation.
-
Risk response plan: For each identified risk to develop a separate response, the measures of the document called the risk response plan. Including negative risk (avoidance strategy, transfer strategy, mitigation strategy); Positive risk (pioneering, sharing, strong).
-
Risk monitoring: Monitor the execution of risk plans, detect residual risks, identify new risks, ensure the execution of risk plans, and evaluate the effectiveness of these plans in reducing risks.
-
Project risk: an uncertain event or condition affecting a project that may create either a threat or an opportunity.
Through active and rational planning, more than 90% of risks can be dealt with and managed in advance.
Risks should be identified as early as possible, and high level risks should be documented in the charter. The party who has the most control over the risk shall bear the corresponding risk.
The degree of risk-taking should match the reward. There should be an upper limit of risk-taking.
6.2 Risk Attributes
-
Randomness: the occurrence of risk events and their consequences are all contingent (double contingent) and follow certain statistical laws.
-
Relativity: Risk is relative to the subject of project activity. Bearing capacity is different, the effect is different. Factors affecting risk tolerance: the size of return (the greater the return, the more willing to take risks); Input size (the larger the input, the smaller the bearing capacity); The e position and resources of the subject (people of higher rank can take greater risks).
-
Variability of risk: changes in conditions will cause changes in risk. These include changes in nature, consequences, and the emergence of new risks.
6.3 Risk classification:
Risk can be divided into pure risk (no return) and speculative risk (possible return) depending on its consequences.
According to risk sources, natural risks (natural disasters) and man-made risks (human activities, can be divided into behavioral risks, economic risks, technical risks, political and organizational risks, etc.).
According to whether can manage, can manage (such as internal most risks) and can not manage (such as external policies), also depends on the management level of the subject.
Local risk (non-critical path activity delay) and overall risk (critical path activity delay) are divided by scope of impact. According to the consequence undertakers: owners, government, contractors, investors, design units, supervision units, insurance companies, etc. By predictability: known risks (known schedule risks), predictable risks (possible server failures), and unpredictable risks (earthquakes, floods, policy changes, etc.).
In the information system project, from the macro point of view, risks can be divided into project risks, technical risks and business risks.
6.3.1 Project Risks
- Refers to potential budget, schedule, individual (including personnel and organization), resource, user, and demand issues, and their impact on the project.
- Uncertainties in project complexity, size, and structure also constitute (estimated) project risk factors.
- Project risk threatens the project plan. Once the project risk becomes reality, it may delay the project schedule and increase the project cost.
6.3.2 Technical Risks
- Refers to potential design, implementation, interface, test, and maintenance issues.
- In addition, specification ambiguity, technical uncertainty, technology obsolescence, the latest technology (immature) is also a risk factor.
- Technical risks threaten the quality and scheduled delivery of the system under development.
- If technical risks become real, development can become difficult or impossible.
6.3.3 Business Risks
Business risks threaten the viability of the system to be developed. There are five different types of business risks:
- Market risk. The system developed was excellent but not what the market really wanted.
- Strategic risk. The systems developed no longer fit the enterprise’s information systems strategy.
- Sales risk. Developed a system that the sales department didn’t know how to sell.
- Manage risk. Loss of support from higher management due to a shift in emphasis or personnel change.
- Budget risk. The development process is not guaranteed by budget or staff.
7 🏀 Organizational structure
7.1 Organizational Structure Mode:
- Project type (project manager absolute leadership),
- Functional (mainly department leader),
- Matrix (a combination of the two, with both project managers and department heads, but with different division of authority).
7.2 The organization of the programming team
-
Lead programmer team (lead programmer is in full charge, backup engineer can replace lead programmer if necessary, suitable for large-scale projects)
-
A democratic team (i.e., a team of coders without a master, where all members are equal and all decisions are decided by a vote) is ideal for small projects with fewer developers, new technologies, and less certainty.
-
Hierarchical teams (two levels, one leader leading several senior programmers, each senior programmer leading several programmers).