Software Engineering Body of Knowledge (v3) (2014) (811503), страница 36
Текст из файла (страница 36)
Resourceallocation is based on, and constrained by, theavailability of resources and their optimal use, aswell as by issues relating to personnel (for example, productivity of individuals and teams, teamdynamics, and team structures).2.5. Risk Management[3*, c9] [5*, c5]Risk and uncertainty are related but distinct concepts. Uncertainty results from lack of information.
Risk is characterized by the probability of anevent that will result in a negative impact plus acharacterization of the negative impact on a project. Risk is often the result of uncertainty. Theconverse of risk is opportunity, which is characterized by the probability that an event having apositive outcome might occur.Risk management entails identification of riskfactors and analysis of the probability and potential impact of each risk factor, prioritization ofrisk factors, and development of risk mitigationstrategies to reduce the probability and minimizethe negative impact if a risk factor becomes aproblem.
Risk assessment methods (for example,expert judgment, historical data, decision trees,and process simulations) can sometimes be usedin order to identify and evaluate risk factors.Project abandonment conditions can also bedetermined at this point in discussion with allrelevant stakeholders. Software-unique aspectsof risk, such as software engineers’ tendency toadd unneeded features, or the risks related to software’s intangible nature, can influence risk management of a software project. Particular attention should be paid to the management of risksrelated to software quality requirements such assafety or security (see the Software Quality KA).Risk management should be done not only at thebeginning of a project, but also at periodic intervals throughout the project life cycle.2.6. Quality Management[3*, c4] [4*, c24]Software quality requirements should be identified, perhaps in both quantitative and qualitativeterms, for a software project and the associatedwork products.
Thresholds for acceptable quality measurements should be set for each softwarequality requirement based on stakeholder needsSoftware Engineering Management 7-7and expectations. Procedures concerned withongoing Software Quality Assurance (SQA) andquality improvement throughout the developmentprocess, and for verification and validation ofthe deliverable software product, should also bespecified during quality planning (for example,technical reviews and inspections or demonstrations of completed functionality; see the SoftwareQuality KA).2.7. Plan Management[3*, c4]For software projects, where change is an expectation, plans should be managed.
Managing theproject plan should thus be planned. Plans andprocesses selected for software developmentshould be systematically monitored, reviewed,reported, and, when appropriate, revised. Plansassociated with supporting processes (for example, documentation, software configuration management, and problem resolution) also should bemanaged. Reporting, monitoring, and controllinga project should fit within the selected SDLC andthe realities of the project; plans should accountfor the various artifacts that will be used to manage the project.3. Software Project EnactmentDuring software project enactment (also knownas project execution) plans are implemented andthe processes embodied in the plans are enacted.Throughout, there should be a focus on adherence to the selected SDLC processes, with anoverriding expectation that adherence will lead tothe successful satisfaction of stakeholder requirements and achievement of the project’s objectives.
Fundamental to enactment are the ongoingmanagement activities of monitoring, controlling, and reporting.3.1. Implementation of Plans[4*, c2]Project activities should be undertaken in accordance with the project plan and supporting plans.Resources (for example, personnel, technology,and funding) are utilized and work products (forexample, software design, software code, andsoftware test cases) are generated.3.2. Software Acquisition and Supplier ContractManagement[3*, c3, c4]Software acquisition and supplier contract management is concerned with issues involved incontracting with customers of the software development organization who acquire the deliverablework products and with suppliers who supplyproducts or services to the software engineeringorganization.This may involve selection of appropriate kindsof contracts, such as fixed price, time and materials, cost plus fixed fee, or cost plus incentive fee.Agreements with customers and suppliers typically specify the scope of work and the deliverables and include clauses such as penalties for latedelivery or nondelivery and intellectual propertyagreements that specify what the supplier or suppliers are providing and what the acquirer is paying for, plus what will be delivered to and ownedby the acquirer.
For software being developed bysuppliers (both internal to or external to the software development organization), agreements commonly indicate software quality requirements foracceptance of the delivered software.After the agreement has been put in place, execution of the project in compliance with the termsof the agreement should be managed (see chapter12 of SWX, Software Procurement Management,for more information on this topic [2]).3.3. Implementation of Measurement Process[3*, c7]The measurement process should be enacted during the software project to ensure that relevantand useful data are collected (see sections 6.2,Plan the Measurement Process, and 6.3, Performthe Measurement Process).3.4. Monitor Process[3*, c8]Adherence to the project plan and relatedplans should be assessed continually and at7-8 SWEBOK® Guide V3.0predetermined intervals.
Also, outputs and completion criteria for each task should be assessed.Deliverables should be evaluated in terms of theirrequired characteristics (for example, via inspections or by demonstrating working functionality).Effort expenditure, schedule adherence, and coststo date should be analyzed, and resource usageexamined. The project risk profile (see section2.5, Risk Management) should be revisited, andadherence to software quality requirements evaluated (see Software Quality Requirements in theSoftware Quality KA).Measurement data should be analyzed (see Statistical Analysis in the Engineering FoundationsKA).
Variance analysis based on the deviation ofactual from expected outcomes and values shouldbe determined. This may include cost overruns,schedule slippage, or other similar measures.Outlier identification and analysis of quality andother measurement data should be performed (forexample, defect analysis; see Software QualityMeasurement in the Software Quality KA). Riskexposures should be recalculated (see section 2.5,Risk Management).
These activities can enableproblem detection and exception identificationbased on thresholds that have been exceeded.Outcomes should be reported when thresholdshave been exceeded, or as necessary.3.5. Control Process[3*, c7, c8]The outcomes of project monitoring activitiesprovide the basis on which decisions can be made.Where appropriate, and when the probability andimpact of risk factors are understood, changes canbe made to the project. This may take the form ofcorrective action (for example, retesting certainsoftware components); it may involve incorporating additional actions (for example, decidingto use prototyping to assist in software requirements validation; see Prototyping in the SoftwareRequirements KA); and/or it may entail revisionof the project plan and other project documents(for example, the software requirements specification) to accommodate unanticipated events andtheir implications.In some instances, the control process maylead to abandonment of the project. In all cases,software configuration control and software configuration management procedures should beadhered to (see the Software Configuration Management KA), decisions should be documentedand communicated to all relevant parties, plansshould be revisited and revised when necessary,and relevant data recorded (see section 6.3, Perform the Measurement Process).3.6. Reporting[3*, c11]At specified and agreed-upon times, progress todate should be reported—both within the organization (for example, to a project steering committee) and to external stakeholders (for example, clients or users).
Reports should focus onthe information needs of the target audience asopposed to the detailed status reporting within theproject team.4. Review and EvaluationAt prespecified times and as needed, overall progress towards achievement of the stated objectivesand satisfaction of stakeholder (user and customer)requirements should be evaluated. Similarly,assessments of the effectiveness of the softwareprocess, the personnel involved, and the tools andmethods employed should also be undertaken regularly and as determined by circumstances.4.1. Determining Satisfaction of Requirements[4*, c8]Because achieving stakeholder satisfaction isa principal goal of the software engineeringmanager, progress towards this goal shouldbe assessed periodically.
Progress should beassessed on achievement of major project milestones (for example, completion of softwaredesign architecture or completion of a software technical review), or upon completion ofan iterative development cycle that results ina product increment. Variances from softwarerequirements should be identified and appropriate actions should be taken.As in the control process activity above (see section 3.5, Control Process), software configurationSoftware Engineering Management 7-9control and software configuration managementprocedures should be followed (see the SoftwareConfiguration Management KA), decisions documented and communicated to all relevant parties,plans revisited and revised where necessary, andrelevant data recorded (see section 6.3, Performthe Measurement Process).4.2. Reviewing and Evaluating Performance[3*, c8, c10]Periodic performance reviews for project personnel can provide insights as to the likelihoodof adherence to plans and processes as well aspossible areas of difficulty (for example, teammember conflicts).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
