لخّصلي

cess Models of SDLCs cOMPArIsON AND EVOLUtION OF PrOcEss MODELs OF sDLcs Well-Defined Software Process Oktaba and Ibarguengoita (1998) have developed a general meta-model of software process (Figure 1), which provides a 'parsimonious' and 'engineer- ing-based' mode to conceptualize a well-defined software process.In this model, a process is com- posed of the following elements: phases, activities, artifacts, roles, and agents; where a software process is the main concept that is being modeled; a phase is the highest-activity level of a process that is be- ing modeled; and an activity is the execution of an useful work to deliver a main artifact or artifacts (e.g., pieces of the full software artifact, documents, components, data files, or codes). The concepts of role and agent complete this semi-formal definition. A role is a functional responsibility in the process that is assigned to an agent, which can be a human- being, a tool, or a combination of both. The class software process is made up of the several instances of the phase class. Figure 1 shows the meta-model using a class diagram notation. An instance of a process class is composed of several instances of phase class. Phase class is re- lated with several instances of activity class. Under an operation of specialization, the authors report that the phase class can be specialized in analysis, design, code and test, and installation phases. Similarly, the activity class can be specialized in production, control, technology, and communica- tion activities, and each one of these, in other spe- cializations. The activity class is also related to at least an input artifact and an output one, represented by the instances of the artifact class. Specialization of artifacts is also feasible in the model. Finally, a many-to-many association between the role and activity classes and a one-to-many from agent and role classes are defined in the model. We use this meta-model as base for a conceptual framework to compare different process models. Under the consideration of each life cycle is an instance of the model; the comparative framework provides a theoretical base to develop instances for the generic classes of phase, artifact, and role. Activity and agent classes are not considered in this chapter. Well-defined software process model Software Process Phase Artifact Activity Rol Agentare difficult to develop and test. Very often, software exhibits unexpected and undesired behaviors that may even cause severe problems and damages.For these reasons, researchers and practitioners have been paying increasing attention to understanding and improving the quality of the software being developed. The underlying assumption is that there is a direct correlation between the quality of the process and the quality of the developed software. The research area that deals with these issues is referred to using the term software process. The large diversity of PM-SDLCs suggests, then, that apparently none of the PM-SDLCs is sufficient for covering all needs to guarantee a successful development of software-intensive systems. This study, then develops a comparison of the main PM-SDLCs based on their historical evolution, and in terms of their component structure (e.g., based in the Oktaba & Ibarguengoitia meta-model, 1998) to help organize the available knowledge on these models.The 13 PM-SDLCs analyzed are: waterfall (Royce, 1970), SADT (Dickover, McGowa, & Ross, 1977), prototyping (Naumann & Jenkins, 1982), structured cycle (Yourdon, 1993), spiral (Boehm, 1988), win-win spiral (Boehm & Rose, 1994; Egyed & Boehm, 1998), unified process (Rational Software Corporation, 1998), MBASE (Center for Software Engineering, 1997), component-based cycles (Aoyama, 1998; Brown & Wallnau, 1996), XP (Beck, 1999), PSP (Humphrey, 2000), TSP (McAndrews, 2000), and RAD (Cross, 2006).The most relevant findings from Table 1 can be summarized as follows: a. The set of common phases includes the analysis, design, codification, testing, and implementation phases (Note: the emergent agile-based systems approaches such as XP also support an engineering view of these phases); b. The initial business and high-level systems phases (as part of the macro-phase definition of the system) are only part of some PM- SDLCs; c. The iterative approach was disseminated by prototyping SDLC, but this was originally suggested in the Royce's4 (1970) variant of the waterfall model.Later, was reinforced and extended by the spiral model; and d. The postmortem phase, which appeared previ- ous to year 2000, was indirectly suggested by MBASE and XP, and it is attributed mainly to PSP and TSP models.For this, the following specialization of phases was identified in the same study: user conditions, business context pre-systematization, component identification, requirements, analysis, design, coding, test, implementation, postmortem analysis, and iteration decisions.Table 1 contributes to organize comprehensively the phases reported of practically all public PM-SDLCs, and suggests from its analysis a set of generic phases.Table 2 shows the comparative framework for the "artifact" component versus the several PM-SDLCs studied.We propose a comparative specialization of artifacts.Phases and Artifacts in the PM-sDLcs It has been also reported (Fuggetta, 2000) that: software applications are complex products that Figure 1.For the cases of "2," "3," "4," and "5," they indicate that more of one artifact of the PM-SDLC (indicated in the column) corresponds to a unique artifact of the comparative specialization.These activities constitute the generic life-cycle (proposed in this chapter) that includes all activities of the PM-SDLC under study.A scheme of three macro-phases (definition, development, and deployment) well-known in systems engineering is used to group the phases (Sage & Armstrong, 2000).used in Table 1 indicates that the phase reported in the related row is part of the PM-SDLC reported in the corresponding column.Phases are grouped by the general macro-phases: definition of the system, development of the system, and deployment of the system, a well-know systems engineering model.It must be noted that the unique features are considered in the period of their formulation, then, some elements that were considered unique at once, later were incorporated to other models.The phases are proposed by consider- ing all activities that are part of each phase of each PM-SDLC under study.Table 1 shows the comparative framework, for the phase class of the 13 PM-SDLCs analyzed.In this table, each number means the number of artifacts that are generated as equivalent to the artifact specialization proposed.No similar comparison was found in the literature.The symbol ?

cess Models of SDLCs
cOMPArIsON AND EVOLUtION OF
PrOcEss MODELs OF sDLcs
Well-Defined Software Process
Oktaba and Ibargüengoita (1998) have developed
a general meta-model of software process (Figure
1), which provides a ‘parsimonious’ and ‘engineer-
ing-based’ mode to conceptualize a well-defined
software process. In this model, a process is com-
posed of the following elements: phases, activities,
artifacts, roles, and agents; where a software process
is the main concept that is being modeled; a phase
is the highest-activity level of a process that is be-
ing modeled; and an activity is the execution of an
useful work to deliver a main artifact or artifacts
(e.g., pieces of the full software artifact, documents,
components, data files, or codes). The concepts of
role and agent complete this semi-formal definition.
A role is a functional responsibility in the process
that is assigned to an agent, which can be a human-
being, a tool, or a combination of both. The class
software process is made up of the several instances
of the phase class. Figure 1 shows the meta-model
using a class diagram notation.
An instance of a process class is composed of
several instances of phase class. Phase class is re-
lated with several instances of activity class. Under
an operation of specialization, the authors report
that the phase class can be specialized in analysis,
design, code and test, and installation phases.
Similarly, the activity class can be specialized in
production, control, technology, and communica-
tion activities, and each one of these, in other spe-
cializations. The activity class is also related to at
least an input artifact and an output one, represented
by the instances of the artifact class. Specialization
of artifacts is also feasible in the model. Finally,
a many-to-many association between the role and
activity classes and a one-to-many from agent and
role classes are defined in the model. We use this
meta-model as base for a conceptual framework
to compare different process models. Under the
consideration of each life cycle is an instance of
the model; the comparative framework provides a
theoretical base to develop instances for the generic
classes of phase, artifact, and role. Activity and agent
classes are not considered in this chapter.
Phases and Artifacts in the
PM-sDLcs
It has been also reported (Fuggetta, 2000) that:
software applications are complex products that
Figure 1. Well-defined software process model
Software
Process
Phase
Artifact Activity Rol
Agentare difficult to develop and test. Very often, software
exhibits unexpected and undesired behaviors that
may even cause severe problems and damages.For
these reasons, researchers and practitioners have
been paying increasing attention to understanding
and improving the quality of the software being
developed. The underlying assumption is that there
is a direct correlation between the quality of the
process and the quality of the developed software.
The research area that deals with these issues is
referred to using the term software process.
The large diversity of PM-SDLCs suggests, then,
that apparently none of the PM-SDLCs is sufficient
for covering all needs to guarantee a successful
development of software-intensive systems. This
study, then develops a comparison of the main
PM-SDLCs based on their historical evolution,
and in terms of their component structure (e.g.,
based in the Oktaba & Ibargüengoitia meta-model,
1998) to help organize the available knowledge on
these models. For this, the following specialization
of phases was identified in the same study: user
conditions, business context pre-systematization,
component identification, requirements, analysis,
design, coding, test, implementation, postmortem
analysis, and iteration decisions. These activities
constitute the generic life-cycle (proposed in this
chapter) that includes all activities of the PM-SDLC
under study. The phases are proposed by consider-
ing all activities that are part of each phase of each
PM-SDLC under study.
The 13 PM-SDLCs analyzed are: waterfall
(Royce, 1970), SADT (Dickover, McGowa, & Ross,
1977), prototyping (Naumann & Jenkins, 1982),
structured cycle (Yourdon, 1993), spiral (Boehm,
1988), win-win spiral (Boehm & Rose, 1994;
Egyed & Boehm, 1998), unified process (Rational
Software Corporation, 1998), MBASE (Center for
Software Engineering, 1997), component-based
cycles (Aoyama, 1998; Brown & Wallnau, 1996),
XP (Beck, 1999), PSP (Humphrey, 2000), TSP
(McAndrews, 2000), and RAD (Cross, 2006). Table
1 shows the comparative framework, for the phase
class of the 13 PM-SDLCs analyzed. A scheme of
three macro-phases (definition, development, and
deployment) well-known in systems engineering
is used to group the phases (Sage & Armstrong,
2000).
The symbol ♦ used in Table 1 indicates that
the phase reported in the related row is part of the
PM-SDLC reported in the corresponding column.
No similar comparison was found in the literature.
Phases are grouped by the general macro-phases:
definition of the system, development of the system,
and deployment of the system, a well-know systems
engineering model. Table 1 contributes to organize
comprehensively the phases reported of practically
all public PM-SDLCs, and suggests from its analysis
a set of generic phases.
The most relevant findings from Table 1 can be
summarized as follows:
a. The set of common phases includes the
analysis, design, codification, testing, and
implementation phases (Note: the emergent
agile-based systems approaches such as XP
also support an engineering view of these
phases);
b. The initial business and high-level systems
phases (as part of the macro-phase definition
of the system) are only part of some PM-
SDLCs;
c. The iterative approach was disseminated by
prototyping SDLC, but this was originally
suggested in the Royce’s4
(1970) variant of
the waterfall model. Later, was reinforced
and extended by the spiral model; and
d. The postmortem phase, which appeared previ-
ous to year 2000, was indirectly suggested by
MBASE and XP, and it is attributed mainly
to PSP and TSP models.
It must be noted that the unique features are
considered in the period of their formulation,
then, some elements that were considered unique
at once, later were incorporated to other models.
Table 2 shows the comparative framework for the
“artifact” component versus the several PM-SDLCs
studied.We propose a comparative specialization of
artifacts. In this table, each number means the
number of artifacts that are generated as equivalent
to the artifact specialization proposed. Then, “1”
implies that an artifact of the PM-SDLC (indicated
in the column) is equivalent with one artifact of the
artifact specialization proposed. For the cases of
“2,” “3,” “4,” and “5,” they indicate that more of one
artifact of the PM-SDLC (indicated in the column)
corresponds to a unique artifact of the comparative
specialization. A greater number of artifacts implies
that the model aggregates more control or detail in
the definition of such artifacts.
Due to space limitations, the specialization of
roles is not reported here. However, we can report
that in general, the roles of agents-persons have
not suffered much variation, but the number of
activities each one executes as well as the number
of required agents has been increased. Additionally,
the PM-SDLC descriptions usually do not report
explicit information about roles.
From the previous tables and the conceptual
analysis of each PM-SDLC, we identified a set of
common, distinct, and unique features. Table 3 sum-
marizes the common and distinct features, whereas
the Table 4 summarizes the set of unique ones.
These distinct features remark the historic evo-
lution and allow to establish a time-line evolution
(based from Avison and Fitzgerald, 2004) of critical
events of the PM-SDLCs that is shown in Table 5.
The time line (Table 5) shows how the several
PM-SDLCs have been proposed since 1970s. TheTable 3. Common and distinct features for PM-SDLCs
Common Features Distinct Features

1. Group of activities that are performed to identify
   stakeholders and the set of user requirements and
   conditions. First, these activities were focused to
   collect and specify requirements and then they were
   extended to business modeling, system conceptual
   definition, based-scenarios analysis and design, stories
   construction, and in some cases the building of proto-
   types.


2. Group of activities that are performed to define the
   scope of system (negotiation of stakeholders’ condi-
   tions; objectives, alternatives and restrictions deter-
   mination; risk analysis). First, these activities were
   limited to objectives, alternatives and restrictions de-
   termination, and risk analysis was then integrated.


3. Group of activities that are performed to define the
   system architecture (system-requirements definition,
   architecture design and analysis). First, these were lim-
   ited to system-requirements definition and analysis but
   system architecture was integrated later as a common
   feature.


4. Group of activities that are performed to design,
   build, test, and implement the software artifact (de-
   sign, coding, test, implementation).


5. Five models consider the development of a pro-
   totype (waterfall5
   , SADT, spiral, prototyping, and
   RAD).


6. Four models include explicitly the elaboration of
   the user manual (waterfall, a modern structured cycle,
   unified process, and MBASE).


7. Non-iterative, iterative, and incremental approach-
   es. Some methodologies carry out several iterations by
   repetitions of the phases of the same manner in each
   iteration (iterative approach like unified process),
   while others PM-SDLC carry out several iterations
   executing the phases with distinct tasks in each itera-
   tion (incremental approach like spiral). Other ones do
   not utilize iteration (like structured cycle).


8. Iteration/increment next-entry-condition. Some
   models execute the next iterations/increment strictly
   depending on some condition that indicates the prod-
   uct has reached these objectives. Others execute it in
   a certain number of iterations/ increments, indepen-
   dently of the total fulfillment of the condition.


9. Level of detail of the formulation of the PM-SDLC.
   There are significant differences between the models
   regarding to the level of detail used to formulate/de-
   scribe the tasks and the concept of a well-defined pro-
   cess that the software engineering claims.


10. Sophistication of techniques and tools. The most re-
    cent models suggest the utilization of techniques and
    tools for analysis, design, codification, testing, and
    implementation of more sophisticated models.historic evolution is since the 1950s with code &
    fix, to the 2000s with MBASE, unified process,
    component-based, XP, PSP, and TSP. Hence, a rel-
    evant research purpose that emerges is to explore
    the next evolution stage.