Lakhasly

Online English Summarizer tool, free and accurate!

Summarize result (100%)

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 ?


Original text

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.


Summarize English and Arabic text online

Summarize text automatically

Summarize English and Arabic text using the statistical algorithm and sorting sentences based on its importance

Download Summary

You can download the summary result with one of any available formats such as PDF,DOCX and TXT

Permanent URL

ٌYou can share the summary link easily, we keep the summary on the website for future reference,except for private summaries.

Other Features

We are working on adding new features to make summarization more easy and accurate


Latest summaries

Understanding t...

Understanding this phenomenon sheds light on language acquisition, identity, and social dynamics, wh...

ثانيا: مفهوم ال...

ثانيا: مفهوم التعلم اإللكتروني: لم يتم اتفاق كامل حول تحديد مفهوم شامل يغطي جميع جوانبمصطلح "التعليم...

في عالمنا اليوم...

في عالمنا اليوم، يولى اهتمام متزايد لفهم ودعم الأطفال الذين يعانون من اضطراب طيف التوحد (ASD)، وهو ح...

The process of ...

The process of collecting, compiling, summarizing and presenting data into graphical forms such as c...

Older people an...

Older people and people who have been exposed to injuries and blows suffer from joint and muscle pai...

It provides a u...

It provides a user-friendly interface and a wide range of features to streamline the process of crea...

المادة المعرفية...

المادة المعرفية: كثيرا ما يفترض الوضع التدريسي والتموقع الإيجابي الفصلي أن تعير اهتماما والتفاتا إلى...

ثالثا. نظريات ا...

ثالثا. نظريات التف�سري بدأ التف�سري االجتماعي للحركات االجتماعية مع درا�سات ال�سلوك اجلمعي، حينما طو...

المبحث الأول ...

المبحث الأول أهمية البحث التاريخي ،التاريخ بصورة عامة هو بحث واستقصاء الماضي، أوسجل الخبرا...

صحيح، الولايات ...

صحيح، الولايات المتحدة الأمريكية هي قوة اقتصادية عظمى. إليك بعض الأسباب التي تجعلها قوة اقتصادية بار...

نذكر بانه على ه...

نذكر بانه على هذا المدى تكون المعلومات كاملة و بالتالي التوقعات صحيحة و باتباع سياسة ميزانية توسعية ...

إن دراستنا المت...

إن دراستنا المتفحصة والمتعمقة لموضوع التجارة الخارجية انتهت بنا إلى الإحاطة بالدور الرئيسي الذي لعبت...