Software Engineering Body of Knowledge (v3) (2014) (811503), страница 40
Текст из файла (страница 40)
The temporal relationships among software processes are provided bya software life cycle model: either an SDLC orSPLC. Life cycle models typically emphasizethe key software processes within the modeland their temporal and logical interdependencies and relationships. Detailed definitions ofthe software processes in a life cycle model maybe provided directly or by reference to otherdocuments.In addition to conveying the temporal andlogical relationships among software processes,the software development life cycle model (ormodels used within an organization) includes thecontrol mechanisms for applying entry and exitcriteria (e.g., project reviews, customer approvals, software testing, quality thresholds, demonstrations, team consensus).
The output of onesoftware process often provides the input for others (e.g., software requirements provide input fora software architectural design process and thesoftware construction and software testing processes). Concurrent execution of several softwareprocess activities may produce a shared output(e.g., the interface specifications for interfacesamong multiple software components developedby different teams).
Some software processesmay be regarded as less effective unless othersoftware processes are being performed at thesame time (e.g., software test planning duringsoftware requirements analysis can improve thesoftware requirements).Software Engineering Process 8-52.1. Categories of Software Processes[1*, Preface] [2* , p294–295] [3*, c22–c24]2.2. Software Life Cycle Models[1*, c2] [2*, s3.2] [3*, s2.1] [5]Many distinct software processes have beendefined for use in the various parts of the software development and software maintenance lifecycles. These processes can be categorized asfollows:The intangible and malleable nature of softwarepermits a wide variety of software developmentlife cycle models, ranging from linear models inwhich the phases of software development areaccomplished sequentially with feedback anditeration as needed followed by integration, testing, and delivery of a single product; to iterativemodels in which software is developed in increments of increasing functionality on iterativecycles; to agile models that typically involvefrequent demonstrations of working software toa customer or user representative who directsdevelopment of the software in short iterativecycles that produce small increments of working,deliverable software.
Incremental, iterative, andagile models can deliver early subsets of workingsoftware into the user environment, if desired.Linear SDLC models are sometimes referredto as predictive software development life cyclemodels, while iterative and agile SDLCs arereferred to as adaptive software developmentlife cycle models. It should be noted that various maintenance activities during an SPLC canbe conducted using different SDLC models, asappropriate to the maintenance activities.A distinguishing feature of the various software development life cycle models is the way inwhich software requirements are managed. Linear development models typically develop a complete set of software requirements, to the extentpossible, during project initiation and planning.The software requirements are then rigorouslycontrolled.
Changes to the software requirementsare based on change requests that are processedby a change control board (see Requesting,Evaluating and Approving Software Changes inthe Change Control Board in the Software Configuration Management KA). An incrementalmodel produces successive increments of working, deliverable software based on partitioningof the software requirements to be implementedin each of the increments. The software requirements may be rigorously controlled, as in a linearmodel, or there may be some flexibility in revisingthe software requirements as the software productevolves.
Agile models may define product scopeand high-level features initially; however, agile1.Primary processes include software processes for development, operation, andmaintenance of software.2.Supporting processes are applied intermittently or continuously throughout a softwareproduct life cycle to support primary processes; they include software processes suchas configuration management, quality assurance, and verification and validation.3.Organizational processes provide support for software engineering; they includetraining, process measurement analysis,infrastructure management, portfolio andreuse management, organizational processimprovement, and management of softwarelife cycle models.4.Cross-project processes, such as reuse, software product line, and domain engineering;they involve more than a single softwareproject in an organization.Software processes in addition to those listedabove include the following.Project management processes include processes for planning and estimating, resourcemanagement, measuring and controlling, leading,managing risk, managing stakeholders, and coordinating the primary, supporting, organizational,and cross-project processes of software development and maintenance projects.Software processes are also developed forparticular needs, such as process activities thataddress software quality characteristics (seethe Software Quality KA).
For example, security concerns during software development maynecessitate one or more software processes toprotect the security of the development environment and reduce the risk of malicious acts. Software processes may also be developed to provideadequate grounds for establishing confidence inthe integrity of the software.8-6 SWEBOK® Guide V3.0models are designed to facilitate evolution of thesoftware requirements during the project.It must be emphasized that the continuum ofSDLCs from linear to agile is not a thin, straightline.
Elements of different approaches may beincorporated into a specific model; for example, an incremental software development lifecycle model may incorporate sequential software requirements and design phases but permitconsiderable flexibility in revising the softwarerequirements and architecture during softwareconstruction.2.3. Software Process Adaptation[1*, s2.7] [2*, p51]Predefined SDLCs, SPLCs, and individual software processes often need to be adapted (or“tailored”) to better serve local needs.
Organizational context, innovations in technology, projectsize, product criticality, regulatory requirements,industry practices, and corporate culture maydetermine needed adaptations. Adaptation ofindividual software processes and software lifecycle models (development and product) mayconsist of adding more details to software processes, activities, tasks, and procedures to addresscritical concerns. It may consist of using an alternate set of activities that achieves the purpose andoutcomes of the software process.
Adaptationmay also include omitting software processesor activities from a development or product lifecycle model that are clearly inapplicable to thescope of work to be accomplished.2.4. Practical Considerations[2*, p188–190]In practice, software processes and activities areoften interleaved, overlapped, and applied concurrently. Software life cycle models that specify discrete software processes, with rigorously specifiedentry and exit criteria and prescribed boundariesand interfaces, should be recognized as idealizations that must be adapted to reflect the realities ofsoftware development and maintenance within theorganizational context and business environment.Another practical consideration: softwareprocesses (such as configuration management,construction, and testing) can be adapted to facilitate operation, support, maintenance, migration,and retirement of the software.Additional factors to be considered whendefining and tailoring a software life cycle modelinclude required conformance to standards, directives, and policies; customer demands; criticalityof the software product; and organizational maturity and competencies.
Other factors include thenature of the work (e.g., modification of existing software versus new development) and theapplication domain (e.g., aerospace versus hotelmanagement).3. Software Process Assessment andImprovement[2*, p188, p194] [3*, c26] [4*, p397, c15]This topic addresses software process assessment models, software process assessment methods, software process improvement models, andcontinuous and staged process ratings.
Softwareprocess assessments are used to evaluate the formand content of a software process, which maybe specified by a standardized set of criteria. Insome instances, the terms “process appraisal”and “capability evaluation” are used instead ofprocess assessment. Capability evaluations aretypically performed by an acquirer (or potentialacquirer) or by an external agent on behalf ofan acquirer (or potential acquirer).
The resultsare used as an indicator of whether the softwareprocesses used by a supplier (or potential supplier) are acceptable to the acquirer. Performanceappraisals are typically performed within an organization to identify software processes in need ofimprovement or to determine whether a process(or processes) satisfies the criteria at a given levelof process capability or maturity.Process assessments are performed at the levels of entire organizations, organizational unitswithin organizations, and individual projects.Assessment may involve issues such as assessing whether software process entry and exit criteria are being met, to review risk factors andrisk management, or to identify lessons learned.Process assessment is carried out using both anassessment model and an assessment method.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
