�ݺ�ߣ

Process Models
A process model provides a specific roadmap for
software engineering work. It defines the flow of all
activities, actions and tasks, the degree of iteration,
the work products, and the organization of the work
that must be done.

Generic Process Model
Process - a collection of work activities, actions, and
tasks that are performed when some work product is
to be created.
Each of these activities, actions, and tasks reside
within a framework or model that defines their
relationship with the process and with one another.
A generic process framework for software engineering
defines five framework activities — communication,
planning, modeling, construction, and
deployment.
Each framework activity is populated by a set of
software engineering actions.
Each software engineering action is defined by a task
set that identifies the work tasks that are to be
completed, the work products that will be produced,
the quality assurance points that will be required, and
the milestones that will be used to indicate progress.
One important aspect of the software process called
process flow—describes how the framework activities
and the actions and tasks that occur within each
framework activity are organized with respect to
sequence and time.

Sample- For a small software project requested by one person (at a remote location) with simple, straightforward requirements.
Communication Activity
a phone call or email with the appropriate stakeholder.
tasks (the task set ) that this action encompasses are:
Task set
1. Make contact with stakeholder via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. Email to stakeholder for review and approval.

Software Engineering -UNIT1 - Part2.pptx

Prescriptive Process Models
Prescriptive process models were originally proposed to bring order to the chaos of software
development. Software engineering work and the product that it produces remain on “the
edge of chaos.”
All software process models can accommodate the generic framework activities, but each
applies a different emphasis to these activities and defines a process flow that invokes
each framework activity in a different manner.

Waterfall Model
Classic lifecycle….Although the original waterfall model proposed by
Winston Royce [Roy70] made provision for “feedback loops,” the
vast majority of organizations that apply this process model treat it
as if it were strictly linear.
01

When to choose?
when the requirements for a problem are well
understood—when work flows from
communication through deployment in a
reasonably linear fashion.
suggests a systematic, sequential approach to
software development that begins with
customer specification of requirements and
progresses through planning, modeling,
construction, and deployment, culminating in
ongoing support of the completed software.
1. Real projects rarely follow the sequential flow that the model
proposes. Although the linear model can accommodate
iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements
explicitly. The waterfall model requires this and has
difficulty accommodating the natural uncertainty that
exists at the beginning of many projects.
3. The customer must have patience. A working version of the
program(s) will not be available until late in the project
time span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
4. The linear nature of the classic life cycle leads to “blocking
states” in which some project team members must wait for
other members of the team to complete dependent tasks.
In fact, the time spent waiting can exceed the time spent
on productive work.
Often inappropriate today, as software work is fast-paced and subject to a never-ending stream of changes.

Incremental Model
The incremental model delivers a series of releases, called
increments, that provide progressively more functionality
for the customer as each increment is delivered.
02

When to choose?
The incremental model combines elements of linear and parallel process flows. Applies linear sequences in a staggered
fashion as calendar time progresses. Each linear sequence produces deliverable “increments” of the software in a
manner that is similar to the increments produced by an evolutionary process flow.
When an incremental model is used, the first increment is often a core product. That is, basic requirements are
addressed but many supplementary features remain undelivered.
The core product is used by the customer (or undergoes detailed evaluation). As a result, a plan is developed for the
next increment. The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality.
This process is repeated following the delivery of each increment, until the complete product is produced.
The incremental process model focuses on the delivery of an operational product with each increment.
Early increments are stripped-down versions of the final product, but they do provide capability that serves the user
and also provide a platform for evaluation by the user.
For example, word-processing software developed using the incremental paradigm might deliver basic file
management, editing, and document production functions in the first increment; more sophisticated editing
and document production capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment.
Incremental development is particularly useful when staffing is unavailable for a complete implementation by the
business deadline that has been established for the project.

Evolutionary Process Model
Evolutionary process models produce an increasingly more
complete version of the software with each iteration.
but a limited version must be introduced to meet competitive or
business pressure; a set of core product or system
requirements is well understood, but the details of product
or system extensions have yet to be defined.
Evolutionary models are iterative. They are characterized in a
manner that enables you to develop increasingly more
complete versions of the software. There are two common
evolutionary process models.
03

Prototyping
When your customer has a legitimate need, but is clueless
about the details, develop a prototype as a fi rst step..
3.1

Highlights….
A customer defines a set of general objectives for
software, but does not identify detailed
requirements for functions and features.
In other cases, the developer may be unsure of the
efficiency of an algorithm, the adaptability of
an operating system, or the form that human-
machine interaction should take.
In these, and many other situations, a prototyping
paradigm may offer the best approach.
Although prototyping can be used as a stand-
alone process model, it is more commonly used
as a technique that can be implemented within
the context of any one of the process models.

Spiral Model
The spiral development model is a risk -driven process
model generator that is used to guide multi-
stakeholder concurrent engineering of software
intensive systems.
It has two main distinguishing features.
One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while
decreasing its degree of risk.
The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually
satisfactory system solutions.
3.2

Highlights….
Originally proposed by Barry Boehm, the spiral model is an evolutionary software process model that
couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
It provides the potential for rapid development of increasingly more complete versions of the
software.
Using the spiral model, software is developed in a series of evolutionary releases.
During early iterations, the release might be a model or prototype.
During later iterations, increasingly more complete versions of the engineered system are
produced.
A spiral model is divided into a set of framework activities defined by the software engineering
team. Each of the framework activities represent one segment of the spiral path.
As this evolutionary process begins, the software team performs activities that are implied by a
circuit around the spiral in a clockwise direction, beginning at the center.
Risk is considered as each revolution is made.
Anchor point milestones—a combination of work products and conditions that are attained along
the path of the spiral—are noted for each evolutionary pass.

When to choose….
Unlike other process models that end when software is delivered, the spiral model can be adapted to
apply throughout the life of the computer software.
The spiral model is a realistic approach to the development of large-scale systems and software. Because
software evolves as the process progresses, the developer and customer better understand and
react to risks at each evolutionary level.
The spiral model uses prototyping as a risk reduction mechanism but, more importantly, enables you to
apply the prototyping approach at any stage in the evolution of the product.
It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into
an iterative framework that more realistically reflects the real world.
It may be difficult to convince customers (particularly in contract situations) that the
evolutionary approach is controllable. It demands considerable risk assessment expertise
and relies on this expertise for success. If a major risk is not uncovered and managed,
problems will undoubtedly occur.

The concurrent development model
 The concurrent development model is called as concurrent model.
 The communication activity has completed in the first iteration and exits in the
awaiting changes state.
 The modeling activity completed its initial communication and then go to the
underdevelopment state.
 If the customer specifies the change in the requirement, then the modeling
activity moves from the under development state into the awaiting change state.
 The concurrent process model activities moving from one state to another state
Concurrent Process Models

Disadvantages of the concurrent development model
 It needs better communication between the team members. This may not be
achieved all the time.
 It requires to remember the status of the different activities.
Concurrent Process Models

Unified Process Model
During the early 1990s James Rumbaugh, Grady Booch, and Ivar Jacobson
began working on a “unified method” that would combine the best
features of each of their individual object-oriented analysis and
design methods and adopt additional features proposed by other
experts in object-oriented modeling.
The result was UML—a unified modeling language that contains a robust
notation for the modeling and development of object-oriented
systems.
By 1997, UML became a de facto industry standard for object-oriented
software development.
UML provided the necessary technology to support object-oriented
software engineering practice, but it did not provide the process
framework to guide project teams in their application of the
technology. Later they developed the Unified Process, a framework
for object-oriented software engineering using UML.
4

Phases….
The Inception phase:
The inception phase of the UP encompasses both customer communication and planning activities. By
collaborating with stakeholders, business requirements for the software are identified; a rough
architecture for the system is proposed; and a plan for the iterative, incremental nature of the ensuing
project is developed.
The elaboration phase:
Encompasses the communication and modeling activities of the generic process model. Elaboration
refines and expands the preliminary use cases that were developed as part of the inception phase and
expands the architectural representation to include five different views of the software—the use case
model, the requirements model, the design model, the implementation model, and the deployment
model. In some cases, elaboration creates an “executable architecture baseline” that represents a
“first cut” executable system.
The construction phase:
identical to the construction activity defined for the generic software process. Using the architectural
model as input, the construction phase develops or acquires the software components that will make
each use case operational for end users.
•All necessary and required features and functions for the software increment are then implemented
in source code. As components are being implemented, unit tests are designed and executed for each.
•In addition, integration activities (component assembly and integration testing) are conducted.

Phases cont….
The transition phase:
•The transition phase of the UP encompasses the latter stages of the generic construction activity and
the first part of the generic deployment (delivery and feedback) activity.
•Software is given to end users for beta testing and user feedback reports both defects and necessary
changes. At the conclusion of the transition phase, the software increment becomes a usable software
release.
•The production phase:
•The production phase of the UP coincides with the deployment activity of the generic process.
•During this phase, the ongoing use of the software is monitored, support for the operating
environment (infrastructure) is provided, and defect reports and requests for changes are submitted
and evaluated.
•The five UP phases do not occur in a sequence, but rather with staggered concurrency.
•A software engineering workflow is distributed across all UP phases.

Agile Development
Agile software engineering combines a
philosophy and a set of development
guidelines.
The philosophy encourages customer
satisfaction and early incremental delivery of
software;
small, highly motivated project teams; informal
methods;
minimal software engineering work products;
and overall development simplicity.
The development guidelines stress delivery
over analysis and design (although these
activities are not discouraged), and active and
continuous communication between
developers and customers.
JANE DOE

Agile Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
4
Human Factors
Competence
Common Focus
Collaboration
Decision Making Ability
Fuzzy Problem Solving Ability
Mutual Trust and Respect
Self organization

What is an Agile process
Any agile software process is characterized in a manner that addresses a number of key assumptions
about the majority of software projects:
It is difficult to predict in advance which software requirements will persist and which will change.
It is equally difficult to predict how customer priorities will change as the project proceeds.
For many types of software, design and construction are interleaved. That is, both activities should be
performed in tandem so that design models are proven as they are created. It is difficult to predict
how much design is necessary before construction is used to prove the design.
Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we
might like.
Unpredictability--adaptability
Incremental adaptation- Customer feedback

An agile process
reduces the cost
of change because
software is released in
increments and change
can be better controlled
within an increment.
Agility and Cost of Change

Agility Principles-12
1. Our highest priority -satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for customer’s
competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get
the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self– organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.

Extreme Programming(XP)
Extreme Programming (XP), the most widely used approach to agile software development.
Beck defines a set of five values that establish a foundation for all work performed as part of XP—
communication, simplicity, feedback, courage, and respect.
Each of these values is used as a driver for specific XP activities, actions, and tasks.
In order to achieve effective communication between software engineers and other stakeholders,,
XP emphasizes close, yet informal (verbal) collaboration between customers and developers, the establishment
of effective metaphors for communicating important concepts, continuous feedback, and the avoidance of
voluminous documentation as a communication medium.
Feedback is derived from three sources: the implemented software itself, the customer, and other software
team members. By designing and implementing an effective testing strategy, the software provides the
agile team with feedback. XP makes use of the unit test as its primary testing tactic
Beck argues that strict adherence to certain XP practices demands courage. A better word might be discipline.
By following each of these values, the agile team inculcates respect among its members, between other
stakeholders and team members, and indirectly, for the software itself. As they achieve successful delivery
of software increments, the team develops growing respect for the XP process.

XP Process
Extreme Programming uses an object-oriented approach as its preferred development paradigm and
encompasses a set of rules and practices that occur within the context of four framework activities:
planning, design, coding, and testing.
The following figure illustrates the XP process and notes some of the key ideas and tasks that are
associated with each framework activity.

The planning activity (also called the planning game) begins with listening—a requirements gathering
activity.
Listening leads to the creation of a set of “stories” (also called user stories) that describe required
output, features, and functionality for software to be built.
Each story is written by the customer and is placed on an index card.
The customer assigns a value (i.e., a priority) to the story based on the overall business value of the
feature or function.
Members of the XP team then assess each story and assign a cost—measured in development
weeks—to it.
If the story is estimated to require more than three development weeks, the customer is asked to
split the story into smaller stories and the assignment of value and cost occurs again.
It is important to note that new stories can be written at any time.
After the first project release (also called a software increment) has been delivered, the XP team
computes project velocity.
Project velocity is the number of customer stories implemented during the first release.
Planning

Design
XP design rigorously follows the KIS (keep it simple) principle.
A simple design is always preferred over a more complex representation.
XP encourages the use of CRC cards as an effective mechanism for thinking about the software in an
object-oriented context.
CRC (class-responsibility-collaborator) cards identify and organize the object-oriented classes that are
relevant to the current software increment.
If a difficult design problem is encountered as part of the design of a story, XP recommends the
immediate creation of an operational prototype of that portion of the design, called a spike
solution.
A central notion in XP is that design occurs both before and after coding commences.
Refactoring means that design occurs continuously as the system is constructed.

Coding
After stories are developed and preliminary design work is done, the team does not move to code, but
rather develops a series of unit tests
Once the unit test has been created, the developer is better able to focus on what must be
implemented to pass the test.
Once the code is complete, it can be unit-tested immediately, thereby providing instantaneous
feedback to the developers.
A key concept during the coding activity is pair programming.
XP recommends that two people work together at one computer workstation to create code for a
story.
This provides a mechanism for real time problem solving (two heads are often better than one) and
real-time quality assurance (the code is reviewed as it is created).
It also keeps the developers focused on the problem at hand.

Testing
We have already noted that the creation of unit tests before coding commences is a key element
of the XP approach.
The unit tests that are created should be implemented using a framework that enables them to be
automated.
As the individual unit tests are organized into a “universal testing suite”, integration and validation
testing of the system can occur on a daily basis.
XP acceptance tests, also called customer tests, are specified by the customer and focus on
overall system features and functionality that are visible and reviewable by the customer.

�ݺ�ߣ

Software Engineering -UNIT1 - Part2.pptx

More Related Content

Similar to Software Engineering -UNIT1 - Part2.pptx (20)

Recently uploaded (20)

Software Engineering -UNIT1 - Part2.pptx