Software Engineering Body of Knowledge (v3) (2014) (811503), страница 91
Текст из файла (страница 91)
1074-2006 Standard for Developing aSoftware Project Life Cycle ProcessThis standard provides a process for creating asoftware project life cycle process (SPLCP). It isprimarily directed at the process architect for agiven software project.B-16 SWEBOK® Guide V3.0All of the standards described so far in this section provide a basis for defining processes. Someusers are interested in assessing and improvingtheir processes after implementation. The 15504series provides for process assessment; it is currently being revised and renumbered 330xx.ISO/IEC 15504 [ten parts] Information Technology—Process AssessmentISO/IEC 15504-2:2003 defines the requirementsfor performing process assessment as a basisfor use in process improvement and capabilitydetermination.Process assessment is based on a two-dimensional model containing a process dimension anda capability dimension. The process dimension isprovided by an external process reference model(such as 12207 or 15288), which defines a set ofprocesses characterized by statements of processpurpose and process outcomes.
The capabilitydimension consists of a measurement frameworkcomprising six process capability levels and theirassociated process attributes.The assessment output consists of a set of process attribute ratings for each process assessed,termed the process profile, and may also includethe capability level achieved by that process.ISO/IEC 15504-2:2003 identifies the measurement framework for process capability and therequirements for• performing an assessment;• process reference models;• process assessment models;• verifying conformity of process assessment.The requirements for process assessmentdefined in ISO/IEC 15504-2:2003 form a structure that• facilitates self-assessment;• provides a basis for use in process improvement and capability determination;• takes into account the context in which theassessed process is implemented;• produces a process rating;• addresses the ability of the process to achieveits purpose;• is applicable across all application domainsand sizes of organization; and• may provide an objective benchmarkbetween organizations.The minimum set of requirements defined inISO/IEC 15504-2:2003 ensures that assessmentresults are objective, impartial, consistent, repeatable, and representative of the assessed processes.Results of conformant process assessments maybe compared when the scopes of the assessmentsare considered to be similar; for guidance on thismatter, refer to ISO/IEC 15504-4.Several other standards are mentioned herebecause they are written as elaborations of theprocesses of 12207 or 15288.
They are allocatedto other KAs because each one deals with topicsdescribed in those other KAs.IEEE Std. 828-2012 Standard for ConfigurationManagement in Systems and Software EngineeringSee Software Configuration Management KAIEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006)Standard for Software Engineering—Software LifeCycle Processes—MaintenanceSee Software Maintenance KAISO/IEC 15026-4:2012 Systems and Software Engineering—Systems and Software Assurance—Part 4:Assurance in the Life CycleSee Software Quality KAIEEE Std. 15939-2008 Standard Adoption of ISO/IEC 15939:2007 Systems and Software Engineering—Measurement ProcessSee Software Engineering Management KAISO/IEC 15940:2006 Information Technology—Software Engineering Environment ServicesSee Software Engineering Models andMethods KAIEEE Std.
16085-2006 (a.k.a. ISO/IEC 16085:2006)Standard for Systems and Software Engineering—Software Life Cycle Processes—Risk ManagementSee Software Engineering Management KAAppendix B B-17ISO/IEC/IEEE 16326:2009 Systems and Software Engineering—Life Cycle Processes—ProjectManagementSee Software Engineering Management KAISO/IEC/IEEE 29148:2011 Systems and SoftwareEngineering—Life Cycle Processes—RequirementsEngineeringSee Software Requirements KASome users desire process standards usablefor IT operations or IT service management.The ISO/IEC 20000 series describe IT servicemanagement. The processes are less rigorouslydefined than those of the aforementioned engineering standards, but may be preferable for situations where the risks of failure involve moneyor customer satisfaction rather than public health,safety, and welfare.
The ISO/IEC 20000 seriesnow extend to many parts. The foundation ofthe series, ISO/IEC 20000-1, is briefly describedbelow.ISO/IEC 20000-1:2011 Information Technology—Service Management—Part 1: Service ManagementSystem RequirementsISO/IEC 20000-1:2011 is a service managementsystem (SMS) standard. It specifies requirementsfor the service provider to plan, establish, implement, operate, monitor, review, maintain, andimprove an SMS. The requirements include thedesign, transition, delivery and improvement ofservices to fulfill agreed service requirements.IEEE has adopted the first two parts of the ISO/IEC 20000 series.SOFTWARE ENGINEERING MODELSAND METHODSSome approaches to software engineering usemethods that cut across large parts of the lifecycle, rather than focusing on specific processes.“Chief Programmer” was one traditional example.
“Agile development” (actually an exampleof traditional incremental delivery) is a currentexample. Neither S2ESC nor SC 7 has a standardfor agile development, but there is a standardfor developing user documentation in an agileproject.ISO/IEC/IEEE 26515:2012 Systems and SoftwareEngineering—Developing User Documentation in anAgile EnvironmentISO/IEC/IEEE 26515:2012 specifies the way inwhich user documentation can be developed inagile development projects.
It is intended for usein all organizations that are using agile development or are considering implementing their projects using these techniques. It applies to peopleor organizations producing suites of documentation, to those undertaking a single documentation project, and to documentation producedinternally, as well as to documentation contractedto outside service organizations. ISO/IEC/IEEE26515:2012 addresses the relationship betweenthe user documentation process and the life cycledocumentation process in agile development. Itdescribes how the information developer or project manager may plan and manage the user documentation development in an agile environment.It is intended neither to encourage nor to discourage the use of any particular agile developmenttools or methods.Many methodologies are based on semiformaldescriptions of the software to be constructed.These range from simple descriptive notationsto models that can be manipulated and testedand, in some cases, can generate code.
Two relatively old techniques start the list; the first hasbeen widely applied for modeling processes andworkflows.IEEE Std. 1320.1-1998 Standard for Functional Modeling Language—Syntax and Semantics for IDEF0IDEF0 function modeling is designed to represent the decisions, actions, and activities of anexisting or prospective organization or system.IDEF0 graphics and accompanying texts are presented in an organized and systematic way to gainB-18 SWEBOK® Guide V3.0understanding, support analysis, provide logic forpotential changes, specify requirements, and support system-level design and integration activities. IDEF0 may be used to model a wide varietyof systems, composed of people, machines, materials, computers, and information of all varieties,and structured by the relationships among them,both automated and nonautomated.
For new systems, IDEF0 may be used first to define requirements and to specify the functions to be carriedout by the future system. As the basis of thisarchitecture, IDEF0 may then be used to designan implementation that meets these requirementsand performs these functions. For existing systems, IDEF0 can be used to analyze the functionsthat the system performs and to record the meansby which these are done.IEEE Std. 1320.2-1998 Standard for ConceptualModeling Language—Syntax and Semantics forIDEF1X97 (IDEFobject)IDEF1X 97 consists of two conceptual modelinglanguages.
The key-style language supports data/information modeling and is downward compatible with the US government’s 1993 standard,FIPS PUB 184. The identity-style language isbased on the object model with declarative rulesand constraints. IDEF1X 97 identity style includesconstructs for the distinct but related componentsof object abstraction: interface, requests, andrealization; utilizes graphics to state the interface;and defines a declarative, directly executable ruleand constraint language for requests and realizations. IDEF1X 97 conceptual modeling supportsimplementation by relational databases, extendedrelational databases, object databases, and objectprogramming languages.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
