Next GDPA Header
 
 

Standard Meta Processes

The following text is a work is in preparation. For any comments and suggestions please send an e-mail to Carla Freericks (Blanck Purper)
 

Motivation:

Software process standards such as GD 250, also known as the V-Model, IEEE1220, ISO 12204 [ISO 12204] describe generic process models that should be tailored to the needs of a specific project.

Usually, these models are informally described and delivered by means of static, paper-based documents, which are unwieldy and strenuous to learn. Few of them are optionally available as postscript (or PDF, RTF, Word documents), help-based documents or web-based documents.

In a typical use, the person responsible in constructing a project process compliant to a standard "reads" the contents of the standard and mentally maps the regulations into the intended process model. During and/or after constructing the process model, he (or another person) performs manual checks against the standard mandatory practices. These practices may concern the constraints to hold for the process itself or for the artifacts (documents, software or hardware components, systems etc.) which are produced by the enactment of the process.

The fact that the standard model is not on the same platform and architecture as the project model leads to a significant consumption of resources to harmonize them. This problem is strongly increased when the process of the real-world project evolves and this is not reflected in the process model.

Meta-process concepts [Warb99] have been employed to deal with these problems.

Definition:

A real-world production process (P), which assigns human resources, methods, tools etc. to the activities needed to produce a software product, is modeled in a process model (PM). Frequently, when P evolves to cope with the dynamics of system development, its evolution is not reflected in the original PM. As a consequence, PM and P may no longer be in accordance. Nevertheless it is possible to define a process in order to assure that P and PM remain consistent. This process is called the meta-process.

In this context, a real-world standard for software process (SP) which defines activities, artifacts and practices that are needed to produce software, is modeled in a standard process model (SPM). Based on the SPM, the process participant defines the PM for a particular project. The project PM must obey the constraints of the practices defined in SPM. Whenever the project PM evolves, the affected constraints of SPM must be reviewed. This process is called the standard meta-process. Next figure illustrates the flow among the process models and meta-processes for both project and standard.

Figure LTSA
Figure Intro 3: Overview of the standard meta process

For the standard meta-process employed in GDPA, six standards were analyzed: GD250, ISO 12207, ISO 9000-3, IEEE 1220, IEEE 1074, ESA PSS-05 and AQAP-150. In order to specify a common repository for all the different process models defined by the above mentioned standards, we had to take into consideration:

  • the diversities among the process models of the standards,
  • the formalization of the rules extracted from the standards
  • an experience library based on the experience factory /Basili, 1993/.

  •  

    Standard meta-process in GDPA:

      The core of the repository in the process web-centre is the process meta-model which organises the following information:

    What to be done? the binding set of activities and artefacts which are required and produced during the system development. This question should be entirely covered by the assets of the process modelling phase.

    With what? all the possible methods, techniques and tools which might be used to perform/execute an activity. The answers to this question establish the connections between process technologies and software engineering.

    Is it done? appraisals based on rules, regulations, checklists and assessments lists which can be used either to determine compliance with a standard or to set-out the actual state of a process. It is the kernel of the process assessment.

    How is it to be done? all the practices, recommendations and improvements that can be undertaken based on the results of the previous question. This is the essence of the process improvement.

    Why is it done? the explanations and justifications for any of the former questions. They are also known as "rationales".

       
     

    Based on these 5 groups of information to be extracted from a process standards, we defined the following structure:

    The structure of the meta-model:

    Figure LTSA
    Figure Intro 3: Meta-Model layers in GDPA

    The next sections depict some of the elements presented in the structure of the meta-process and outline the forms for collecting information from the standards.

    Standard. For the purpose of this paper only four from the six analyzed standards are considered: GD 250 [GD250] also known as the V-Model, ESA PSS-05, ISO 12207 and IEEE 1074.

    Delivery forms. Typically, software process standards are delivered by means of static documents, usually paper-based. Few of them are optionally available as:

    1. Postscript, PDF, RTF, Word documents
    2. Help-based documents. Usually, these are generated from word-processor formats.
    3. Web-based documents. Frequently, these are automatically converted from word-processor formats into HTML documents for direct display via Web-browsers. The hyper-links are usually limited to references within the same document.
    4. Data files to be directly imported by other databases.

    GD 250 V-Model

    ESA-PSS 05

    ISO 12207

    IEEE 1074

    (a),(b),(c),(d)

    (a), (b)

    Paper, (a)

    Paper, (a)

    Table 2: Delivery forms

    Edition. Most of the analyzed standards call their released versions as "editions". In order to serve as an effective instrument for continuous improvement, process standards should be dynamic. Probably in the near future, the period for delivering new versions of process standards will diminish and it will be necessary to implement substantial version control. The following table identifies the version actually used for the research described in this paper.

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    09/1997 (2nd edition)

    First edition 1992

    02/1991 (2nd edition)

    First edition 1987

    1995 (E) 1st edition

    04/1995 - 2nd edition

    First edition 1991

    Table 3: Standards Editions

    Tailoring forms. Tailoring forms contain the templates for tailoring the process model according to pre-classified characteristics of the project, development environment, etc. The tailoring forms are the only element that could not be modeled. Each standard offers its own method for describing and performing the tailoring. Tailoring forms are stored in the repository as text.

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    Ad-hoc

    Ad-hoc

    Ad-hoc

    Ad-hoc

    Table 4: Tailoring Forms

    Activities. Although the standards organize and classify the activities in a different manner, almost all of them can be modeled in three levels. The table below identifies the given titles and the quantity, and illustrates one example for each level. For instance the GD 250 has 5 sub-models ordered into 42 activities which, in turn, are composed of 128 sub-activities. The letter "D" used in the following tables means that the information can be directly collected from the standard, and "I", indirectly, resp.

    Level

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    Level A

    Title

    D: "Sub-models"

    D: "Standards"

    D: "Lifecycles"

    D: "Processes"

    #

    5

    2

    3

    6

    E.g.

    SD - System Development

    Product Standard

    Primary Lifecycle

    Software Lifecycles Process

    Level B

    Title

    D: "Activities"

    D: "Phases"

    D: "Processes"

    D: "Processes"

    #

    42

    10

    17

    17

    E.g.

    SD1 - System Requirement Anal.

    UR - User Requirements

    Acquisition Process

    Software Lifecycle Model Process

    Level C

    Title

    D: "Sub-Activities"

    D: "Activities"

    D: "Activities"

    D: "Activities"

    #

    128

    47

    74

    65

    E.g.

    SD1.1 Recording of Actual Status and Analysis

    3.2.1 Capture of user Requirements

    5.1.1 Initiation

    2.3 Identify Candidate Software Lifecycle models

    Table 5: Standards classifications for activities

    Regulations. Despite the fact that regulations are the core of controlling compliance with the standard, most standards have their regulations mixed up with explanations and recommendations. The task of splitting them in order to fit into the E-R model is quite laborious. Table 6 identifies for each standard from where the regulations should be taken, the minimal quantity of regulations, and one example of the original regulation before extracting the practice. The regulations are formulated in [Emme99] as "practices" and the explanations and recommendations as "rationale".

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    I: "Handling" +

    I: "Explanation"

    I: "Mandatory Practices"

    I: "Tasks"

    I: "Description"

    170

    199

    232

    65

    An overall horizon must be specified for the system functionality within the scope of this activity. This is realized by means of a preliminary system description which is the background for all further refinements and additions of the User Requirements

    UR01 The definition of the user requirements shall be the responsibility of the user

    5.1.1.1 The acquirer begins the acquisition process by describing a concept or a need to acquire, develop, or enhance a system, software product or software service.

    2.3.1 In this activity, the set of Available SLCMs and applicable Constraints shall be considered and Candidate SLCMs identified. A new model may be constructed by combining elements of others SLCMs.

    Table 6: Standards regulations

    Rules. The rules are the formalization of the informal and unstructured regulations written in the standards. Here are four categories of rules:

    Document rules

    These are the most frequent ones. Typically they entail phrases like "the document ... shall describe the ...."

    Process rules

    These might be constraints on the order of the activities, on roles that must perform the activity, on hardware or software resources, on schedules or on the budget, e.g. "the software unit test must be performed by a person outside the development team and completed before the system test".

    Software/Hardware rules

    These make explicit reference to attributes or qualities that the software or hardware shall have, e.g. "the user-interface must ...."

    General rules

    These are rules that are defined in a broad spectrum and cannot be allocated to any of the above categories, e.g. "the supplier shall ensure that this policy is understood.."

    Furthermore, the following information must be retrieved for each rule:

    • The activity that contains the rule
    • The artifact being checked for compliance
    • The properties of the rule:
    1. Obligation:
      The sort of rule obligations are taken from the PS-005 classification:
      1. Mandatory: Usually defined by "shall", "must", "have to be", "is to be", "is". These rules must be followed without exception.
      2. Recommended: Usually defined by "should". Generate a warning when not followed.
      3. Guidelines: Usually defined by "may" or "could".
    2. Automation:
      This classification is only used as an additional help. So far, there is no automation provided.
      1. Automatic: The name of the software tool to be activated and the parameters to be checked must be defined.
      2. Semi-automatic.
      3. Manual checklist.
    3. System Type:
      This classification is not much used in the system yet. It is designed with the intention to hold in other standards.
    The extraction of the rules from the informal definition described in the standards is a burdensome task. The "rules" are essential for defining a rank for the standard compliance.

    Explanations (Rationale)
    . The explanations have to be separated from the regulations in the original text but the link between an explanation and its rationale must be preserved.

    Artifact Flow.
    The artifact-flow is essential to construct the process model. It can be straightforwardly extracted from GD 250, ESA-PSS05 and IEEE 1074. The process model can be illustrated in a matrix form as in Table 8 or in a graphical form with the graph visualization tool daVinci [FW94].

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    D: "Product Flow"

    D: "Inputs to the Phase"

    D: "Outputs from the Phase"

    I: "Activities"

    I: "Tasks"

    D: "Input Information"

    D: "Output Information"

    160

    47

    74

    65

    Table 7: Artifact Flow

    The ISO 12207 is a particular standard because it sets the practices to construct a software life cycle. Although it claims not to be a lifecycle it is possible the define the "meta-process" of this standard which is a process itself. For example it is possible to reconstruct the following artifact flow from the text of the activity 5.3.7.2 "The developer shall test each software unit and database ensuring that it satisfies the requirements. The test results shall be documented":

    From

    Artifact

    To

    Activity

    State

    Activity

    State

    5.3.7.1* Not tested SW unit 5.3.7.5* Tested
    5.3.7.1* Not tested Database 5.3.7.5* Tested
    5.3.4.2* Approved Requirements Document - -
    - - Test Results

    Document
    5.3.7.5* Submitted

    * Information was extracted indirectly from the description of other activities.

    Table 8: Artifact flow for the ISO 12207 - 5.3.7.2

    Artifacts. Three sorts of artifacts can be produced by enacting the activities defined in the standards: documents, software/hardware products and process lifecycles (IEEE 1074). Although the last two artifacts are mentioned in the standards, they are not easily extracted from the content or the regulations. For example, to select the practices that shall be conducted for a software/hardware unit the user has to review all of them. Table 9 identifies the form for collecting the information about the artifacts and the number of them.

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    D: Manual "Documents"

    D: Appendix B:

    "Software project documents"

     

    I: "Input Information" I: "Output Information"

    32

    18

    Open

    Open

    Table 9: Documents

    The ISO 12207 is not intended to prescribe the name, format, or explicit content of the documentation to be produced. It may require development of documents of similar class or type. However, it does not imply that such documents be developed or packaged separately or combined in some fashion

    The IEEE 1074 is not projected to be a software lifecycle model (SLCM). Rather, it describes the practices in order to select and adapt an SLCM. In this context, the Input Information matrices and Output Information matrices provides information on what should be documented but do not specify how.

     

    Glossary and acronyms are indirect explanations and rationale for the regulations.

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    D: "Appendix A: Definitions"

    D: "Appendix A:

    Glossary-List of Terms"

    D: "Section 3 "Definitions"

    D: "1.3.1 Definitions"

    109

    37 + reference to other standards

    37

    31 + reference to other standards

    Table 10: Glossary

    GD 250 V-Model

    ESA-PSS05

    ISO 12207

    IEEE 1074

    D: "Appendix B1: List of Abbreviations"

    D: "Appendix A:

    Glossary-List of Acronyms"

    none

    D: "1.3.2 Acronyms"

    64

    43

    0

    11

    Table 11: Acronyms

    Experience Library.
    The experience library is not contained in the standards. Rather, it is a collection of "experiences" well-organized in order to provide various kinds of assistance for the process participants. In GDPA the experience library includes:

    • The e-mails sent to the GD 250 mailing list (ca. 400)
    • The publications which are a substantial reference to the standard (ca. 800)
    • Projects and products which apply or automate the standard (ca. 200)
    • General directories and catalogues (ca. 2000)
    • Other ad-hoc information

    Methods and Methods Rules
    . Methods, methodologies or techniques that help to enact the activities defined in the model. In GDPA, the standard GD251 "Methods Allocations" [GD251] was the basis for the data collection. Circa 140 methods were identified. The repository of methods is independent of the standard being applied.

    Tools and Tool Rules
    . Tools implement one or a set of methods, methodologies or techniques that may be used to enact activities. In GDPA only the functional requirements for software tools are considered and not the tools themselves. These requirements are taken from the standard GD 252: "Functional Tool Requirements" [GD252]. The repository of tools is independent of the standard being applied.

    The Web-Based Environment

    Once the information is adequately stored in the repository it is possible to construct templates to generate html files.

       
      Example: Mapping the five questions for SD1.1activity page of GD250 (V-Model):

    "What to be done?" is mainly provided in [GD250] in the sections with the title "product-flow (see the index "contents")

    "With what?" is supplied by the items "Methods" and "Tool Requirements".

    "How is it to be done?" at "Handling" and "Recommendation" sessions.

    "Why is it done?" explanations and justifications are explained on the sessiones "Explanation", "External norms" and "Links to the V-Model Mailinglist"

    As the V-Model [GD250] does not provides any pre-defined checklists/tests to assess it, the question "Is it done?" is not attended.

    Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster