Software Engineering Body of Knowledge (v3) (2014) (811503), страница 35
Текст из файла (страница 35)
There is no intent in this breakdown to recommend a specific life cycle model.The breakdown implies only what happens anddoes not imply when, how, or how many timeseach activity occurs. The seven topics are:• Initiation and Scope Definition, which dealwith the decision to embark on a softwareengineering project;• Software Project Planning, which addressesthe activities undertaken to prepare for a successful software engineering project fromthe management perspective;• Software Project Enactment, which dealswith generally accepted software engineeringmanagement activities that occur during theexecution of a software engineering project;• Review and Evaluation, which deal withensuring that technical, schedule, cost, andquality engineering activities are satisfactory;• Closure, which addresses the activitiesaccomplished to complete a project;• Software Engineering Measurement, whichdeals with the effective development andimplementation of measurement programs insoftware engineering organizations;• Software Engineering Management Tools,which describes the selection and use of toolsfor managing a software engineering project.1. Initiation and Scope DefinitionThe focus of these activities is on effective determination of software requirements using various elicitation methods and the assessment ofproject feasibility from a variety of standpoints.Once project feasibility has been established, theremaining tasks within this section are the specification of requirements and selection of the processes for revision and review of requirements.1.1. Determination and Negotiation ofRequirements[3*, c3]Determining and negotiating requirements setthe visible boundaries for the set of tasks beingundertaken (see the Software Requirements KA).Activities include requirements elicitation, analysis, specification, and validation.
Methods andtechniques should be selected and applied, takinginto account the various stakeholder perspectives.This leads to the determination of project scope inorder to meet objectives and satisfy constraints.1.2. Feasibility Analysis[4*, c4]The purpose of feasibility analysis is to develop aclear description of project objectives and evaluate alternative approaches in order to determinewhether the proposed project is the best alternative given the constraints of technology, resources,finances, and social/political considerations. Aninitial project and product scope statement, projectdeliverables, project duration constraints, and anestimate of resources needed should be prepared.Resources include a sufficient number ofpeople who have the needed skills, facilities,infrastructure, and support (either internally orexternally).
Feasibility analysis often requiresapproximate estimations of effort and cost basedon appropriate methods (see section 2.3, Effort,Schedule, and Cost Estimation).Software Engineering Management 7-51.3. Process for the Review and Revision ofRequirements[3*, c3]Given the inevitability of change, stakeholdersshould agree on the means by which requirementsand scope are to be reviewed and revised (forexample, change management procedures, iterative cycle retrospectives). This clearly impliesthat scope and requirements will not be “set instone” but can and should be revisited at predetermined points as the project unfolds (for example,at the time when backlog priorities are created orat milestone reviews).
If changes are accepted,then some form of traceability analysis and riskanalysis should be used to ascertain the impactof those changes (see section 2.5, Risk Management, and Software Configuration Control in theSoftware Configuration Management KA).A managed-change approach can also form thebasis for evaluation of success during closure ofan incremental cycle or an entire project, basedon changes that have occurred along the way (seetopic 5, Closure).2. Software Project PlanningThe first step in software project planning shouldbe selection of an appropriate software development life cycle model and perhaps tailoring itbased on project scope, software requirements,and a risk assessment.
Other factors to be considered include the nature of the application domain,functional and technical complexity, and software quality requirements (see Software QualityRequirements in the Software Quality KA).In all SDLCs, risk assessment should be anelement of initial project planning, and the “riskprofile” of the project should be discussed andaccepted by all relevant stakeholders. Softwarequality management processes (see SoftwareQuality Management Processes in the SoftwareQuality KA) should be determined as part of theplanning process and result in procedures andresponsibilities for software quality assurance,verification and validation, reviews, and audits(see the Software Quality KA). Processes andresponsibilities for ongoing review and revisionof the project plan and related plans should alsobe clearly stated and agreed upon.2.1. Process Planning[3*, c3, c4, c5] [5*, c1]Software development life cycle (SDLC) models span a continuum from predictive to adaptive(see Software Life Cycle Models in the SoftwareEngineering Process KA).
Predictive SDLCs arecharacterized by development of detailed software requirements, detailed project planning, andminimal planning for iteration among development phases. Adaptive SDLCs are designed toaccommodate emergent software requirementsand iterative adjustment of plans. A highly predictive SDLC executes the first five processeslisted in Figure 7.1 in a linear sequence with revisions to earlier phases only as necessary.
Adaptive SDLCs are characterized by iterative development cycles. SDLCs in the mid-range of theSDLC continuum produce increments of functionality on either a preplanned schedule (on thepredictive side of the continuum) or as the products of frequently updated development cycles(on the adaptive side of the continuum).Well-known SDLCs include the waterfall,incremental, and spiral models plus various formsof agile software development [2] [3*, c2].Relevant methods (see the Software Engineering Models and Methods KA) and tools should beselected as part of planning. Automated tools thatwill be used throughout the project should alsobe planned for and acquired. Tools may includetools for project scheduling, software requirements, software design, software construction,software maintenance, software configurationmanagement, software engineering process, software quality, and others.
While many of thesetools should be selected based primarily on thetechnical considerations discussed in other KAs,some of them are closely related to the management considerations discussed in this chapter.2.2. Determine Deliverables[3*, c4, c5, c6]The work product(s) of each project activity (forexample, software architecture design documents, inspection reports, tested software) shouldbe identified and characterized. Opportunities toreuse software components from previous projects or to utilize off-the-shelf software products7-6 SWEBOK® Guide V3.0should be evaluated. Procurement of softwareand use of third parties to develop deliverablesshould be planned and suppliers selected (seesection 3.2, Software Acquisition and SupplierContract Management).2.3. Effort, Schedule, and Cost Estimation[3*, c6]The estimated range of effort required for a project, or parts of a project, can be determined usinga calibrated estimation model based on historicalsize and effort data (when available) and otherrelevant methods such as expert judgment andanalogy.
Task dependencies can be establishedand potential opportunities for completing tasksconcurrently and sequentially can be identifiedand documented using a Gantt chart, for example. For predictive SDLC projects, the expectedschedule of tasks with projected start times, durations, and end times is typically produced duringplanning. For adaptive SDLC projects, an overall estimate of effort and schedule is typicallydeveloped from the initial understanding of therequirements, or, alternatively, constraints onoverall effort and schedule may be specified andused to determine an initial estimate of the number of iterative cycles and estimates of effort andother resources allocated to each cycle.Resource requirements (for example, peopleand tools) can be translated into cost estimates.Initial estimation of effort, schedule, and cost isan iterative activity that should be negotiated andrevised among affected stakeholders until consensus is reached on resources and time availablefor project completion.2.4. Resource Allocation[3*, c5, c10, c11]Equipment, facilities, and people should be allocated to the identified tasks, including the allocation of responsibilities for completion of various elements of a project and the overall project.A matrix that shows who is responsible for,accountable for, consulted about, and informedabout each of the tasks can be used.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
