IEEE 24774-2012 pdf free

IEEE 24774-2012 pdf free.lEEE Guide-Adoption of ISO/IEC TR 24774:2010 Systems and Software Engineering-Life Cycle Management- Guidelines for Process Description.
Not all elements need to be treated in all standards. Some standards will treat only process Title, Purpose, and Outcomes, for example, leaving the activities for further elaboration by other standards.
The goals and objectives of performing a process can be described by using the elements of Title, Purpose, and Outcomes. These elements are used to describe intended results without the necessity of performing structural decomposition of the process. Processes defined using Title, Purpose, and Outcomes provide a common starting point for process implementation and process assessment.
NOTE The distinction between a process and a procedure is a simple one. A procedure is a set of steps to be followed that, when completed, might or might not achieve the intended obectlve. This is similar to following a recipe when cooking. On the other hand, a process is executed wtth knowledge of the intended purpose and outcomes to achieve the desired result.
3.2 The title element
The title of a process description is a short noun phrase that presents a descriptive heading for the process. The title identifies the principle concern of the process and distinguishes the process from other processes in the model. Because of the latter criterion, it may sometimes be necessary to change the title of a process. For example, one might have a “software design process” which is later renamed as a “software detailed design process” to distinguish it from a newly-invented “software architectural design process”.
NOTE I Process descriptions may be used both to describe generic objects of a particular type (for example “pfoiect management process”), and to describe a partictiar instance of a generic type (for example “protect management process for proiect A”). For a process model or a standard the type description is sufficient, but in other cases (for example project planning) generic process types are instantiated with respect to resources and time. When both generic types and particular instances are described, in order to differentiate between the two a typographical convention may be adopted (for example the title of the specific instance may be set in italic font).
NOTE 2 The intent is to give a title not a summary. Noun-verb or verb-noun phrases lead to an attempt to summarise the purpose or process so that the title can stand for the purpose. This is often misleading. A descriptive noun phrase – the name of the process – is less open to misinterpretation and the temptation to let it stand in for the purpose.
3.3 The purpose element
The purpose of the process is stated as a high level, overall goal for performing the process. In cases where processes might be thought to overlap, the purpose should be used to characterize the scope or bounds of the process.
Whenever possible, the purpose should be succinctly captured in a single sentence. Summarizing the activities or outcomes of the process in the purpose statement should be avoided. Use of the conjunction “and” to connect multiple clauses should be avoided as it would indicate that the description is being written as an aggregation of marginally-related outcomes rather than as a statement of a single purpose. The purpose element shall begin with the words, “The purpose of the xxx process is…”. The phrase. “in order to” may be useful In recording the objective of the process.
If any further explanation of the purpose of a process is desirable, it should be placed in informahve Notes.
3.4 The outcomes element
An outcome is an observable result of the successful achievement of the process purpose. Outcomes are measurable, tangible, technical or business results that are achieved by a process. for example the results that are used by other processes. Outcomes are observable and assessable.
Outcomes should be differentiated from benefits, which are positive achievements from the execution of a process, often spread broadly across the business and not necessarily related to the technical or business intent of executing a process, Benefits are not usually assessable, or at least not assessable using process assessment approaches. A benefit might provide the motivation to execute a process. but it might not be the primary reason to do so. Benefits may be described in an informative note to the purpose statement.
a) The list of outcomes associated with a process shall be prefaced by the text, As a result of successful implementation of this process…”.
b) An outcome shall be phrased as a declarative sentence using a verb in the present tense. For example, if the preceding sentence was phrased as an outcome, it might read, “Outcomes are phrased as dedarative sentences using verbs in the present tense.” Typically, the verb is “is” or “are” although others may be used when appropriate.
c) Outcomes should be expressed in terms of a positive, observable objective, e.g. the production of an artefact, the provision of a service, a significant change of state, the successful maintenance of a desired state (e.g. safety), or the meeting of specified constraints (such as requirements, goals, etc).
d) Outcome statements should be no longer than two lines of text, about twenty words.
e) The number of outcomes for a process should fall within the range 3 to 7.
f) Although an outcome should express an observable result, it is not necessary to express the outcome as the production of a document, record of other item of information.
g) An outcome should express a single result, Hence, the use of the word and” or and/or” to conjoin clauses should be avoided; such constructions are better expressed as multiple outcomes.IEEE 24774 pdf free download.