SOFTWARE ENGINEERING (BCS755C)

FACULTY NAME: Prof. DEEPU K / Prof. MANOJ L N

SECTION:VII C & A

SEM:VII
 MODULE-1
Software and Software Engineering: The nature of
Software, The unique nature of WebApps, Software
Engineering, The software Process, Software Engineering
Practice, Software Myths. Process Models: A generic
process model, c,
Prescriptive process models: Waterfall model, Incremental
process models, Evolutionary process models, Concurrent
models, Specialized process models. Unified Process ,
Personal and Team process models
 PROCESS MODELS
1. A generic process model.
2. Process assessment and improvement.
3. Prescriptive process models.
4. Waterfall model.
5. Incremental process models.
6. Evolutionary process models.
7. Concurrent models
8. Specialized process models.
9. Unified Process
10. Personal and Team process models
1.A generic process model.
 1.1 Defining a Framework Activity

1. A linear process flow

2. An iterative process flow

3. An evolutionary process flow.

4.A parallel process flow

 1.A linear process flow
A linear process flow executes each of the five framework activities
in sequence, beginning with communication and culminating with
deployment
 2. An iterative process flow
An iterative process flow repeats one or more of the activities before
proceeding to the next
 3. An evolutionary process flow
An evolutionary process flow executes the activities in a “circular” manner.
Each circuit through the five activities leads to a more complete version of the
software.
 4. A parallel process flow
A parallel process flow executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might be
executed in parallel with construction of another aspect of the software).
1.2 Identifying a Task Set
 1.3 Process Patterns
A process pattern describes a process-related problem that is encountered during
software engineering work, identifies the environment in which the problem has been
encountered, and suggests one or more proven solutions to the problem.

➢Patterns can be defined at any level of abstraction. In some cases, a pattern might be
used to describe a problem (and solution) associated with a complete process model
(e.g., prototyping).

➢In other situations, patterns can be used to describe a problem (and solution)
associated with a framework activity (e.g., planning) or an action within a framework
activity (e.g., project estimating).
A pattern template provides a consistent means for
describing a pattern.
Pattern Name.
Forces.
Type
Initial context.
Problem.
Solution.
Resulting Context
Related Patterns.
Known Uses and Examples.
Pattern Name. The pattern is given a meaningful name describing it within the
context of the software process (e.g., Technical Reviews).
Forces. The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution

Type. The pattern type is specified. Ambler [Amb98] suggests three types:
1. Stage pattern
➢ defines a problem associated with a framework activity for the process.
➢ Since a framework activity encompasses multiple actions and work tasks, a stage
pattern incorporates multiple task patterns (see the following) that are relevant to the
stage (framework activity).
➢ An example of a stage pattern might be Establishing Communication. This pattern
would incorporate the task pattern Requirements Gathering and others.
2. Task pattern

Defines a problem associated with a software engineering action or work task and relevant
to successful software engineering practice (e.g., Requirements Gathering is a task pattern).

3. Phase pattern
➢ Define the sequence of framework activities that occurs within the process, even when the
overall flow of activities is iterative in nature.
➢ An example of a phase pattern might be Spiral Model or Prototyping.
Initial context. Describes the conditions under which the pattern applies. Prior to the
initiation of the pattern:
1) What organizational or team-related activities have already occurred?
2) What is the entry state for the process?
3) What software engineering information or project information already exists?
Problem: The specific problem to be solved by the pattern.
Solution
➢ Describes how to implement the pattern successfully.
➢This section describes how the initial state of the process (that exists
before the pattern is implemented) is modified as a consequence of the
initiation of the pattern.
➢It also describes how software engineering information or project
information that is available before the initiation of the pattern is
transformed as a consequence of the successful execution of the pattern.
Resulting Context. Describes the conditions that will result once the pattern
has be
1. What organizational or team-related activities must have occurred?
2. What is the exit state for the process?
3. What software engineering information or project information has
been developed?
Related Patterns
Provide a list of all process patterns that are directly related to this one. This
may be represented as a hierarchy or in some other diagrammatic form. For
example, the stage pattern Communication encompasses the task patterns:
ProjectTeam,CollaborativeGuidelines, Scope Isolation,equirementsGathering,
Constraint Description, and Scenario Creation.

Known Uses and Examples. Indicate the specific instances in which the
pattern is applicable. For example, Communication is mandatory at the
beginning of every software project, is recommended throughout the software
project, and is mandatory once the deployment activity is under way
 2. Process assessment and improvement
➢Assessment attempts to understand the current state of the
software process with the intent of improving it.
➢A number of different approaches to software process
assessment and improvement have been proposed over the
past few decades:
1. Standard CMMI Assessment Method for Process
Improvement
2. CMM-Based Appraisal for Internal Process
Improvement (CBA IPI)
3. SPICE (ISO/IEC15504)
4. ISO 9001:2000 for Software
[Link] CMMI Assessment Method for Process Improvement
(SCAMPI)—provides a five-step process assessment model that incorporates
five phases: initiating, diagnosing, establishing, acting, and learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment [SEI00].
[Link]-BasedAppraisal for Internal Process Improvement (CBA IPI)
provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment
[Link] (ISO/IEC15504):a standard that defines a set of requirements for
software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of any
defined software process
[Link] 9001:2000 for Software:a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies
 [Link] Process Models

• The Waterfall Model

• Incremental Process Models

• Evolutionary Process Models

• Concurrent Models

• A Final Word on Evolutionary Processes

 3.1 The Waterfall Model
The waterfall model, sometimes called the classic life cycle, suggests a
systematic sequential approach6 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
The V-model
❖ A variation in the representation of the waterfall model is called the V-model
❖ the V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities.
❖ As a software team moves down the left side of the V, basic problem requirements are refined into
progressively more detailed and technical representations of the problem and its solution.
❖ Once code has been generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models created as the team moved
down the left side.
❖ In reality, there is no fundamental difference between the classic life cycle and the V-model. The V-
model provides a way of visualizing how verification and validation actions are applied to earlier
engineering work.
3.2 Incremental Process Models
❖The incremental model delivers a series of releases, called increments, that
provide progressively more functionality for the customer as each increment
is delivered

❖The incremental model combines elements of linear and parallel process

flows.

❖The incremental model 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
❖That is, basic requirements are addressed but many supplementary features (some known,
others unknown) remain undelivered. The core product is used by the customer (or undergoes
detailed evaluation). As a result of use and/or 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
❖Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the
project.

❖Early increments can be implemented with fewer people. If the core product is well
received, then additional staff (if required) can be added to implement the next
increment

❖In addition, increments can be planned to manage technical risks. For example, a major
system might require the availability of new hardware that is under development and
whose delivery date is uncertain.

❖It might be possible to plan early increments in a way that avoids the use of this
hardware, thereby enabling partial functionality to be delivered to end users without
inordinate delay.
 3.3 Evolutionary Process Models
❖ Evolutionary process models produce an increasingly more complete version of the software with

each iteration

❖ Software, like all complex systems, evolves over a period of time.

❖Business and product requirements often change as development proceeds, making a straight line
path to an end product unrealistic tight market deadlines make completion of a comprehensive
software product impossible, but a limited version must be introduced to meet competitive or
business pressure.

❖Evolutionary models are iterative. They are characterized in a manner that enables you to develop

increasingly more complete versions of the software. In the paragraphs that follow, I present two
common evolutionary process models
[Link]
➢ 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.

➢The prototyping paradigm (Figure) begins with communication. You meet with other
stakeholders to define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory.

➢A prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs.

➢A quick design focuses on a representation of those aspects of the software that will be
visible to end users (e.g., human interface layout or output display formats).
➢The prototype is deployed and evaluated by stakeholders, who provide
feedback that is used to further refine requirements.

➢Iteration occurs as the prototype is tuned to satisfy the needs of various

stakeholders, while at the same time enabling you to better understand what
needs to be done

➢Ideally, the prototype serves as a mechanism for identifying software

requirements.

➢If a working prototype is to be built, you can make use of existing program
fragments or apply tools (e.g., report generators and window managers)
that enable working programs to be generated quickly
➢Both stakeholders and software engineers like the prototyping paradigm.
Users get a feel for the actual system, and developers get to build something
immediately.

➢Prototyping can be problematic for the following reasons

1. Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together haphazardly, unaware that in the
rush to get it working you haven’t considered overall software quality or
long-term maintainability
2. As a software engineer, you often make implementation compromises in
order to get a prototype working quickly
[Link] Spiral Model
❖The spiral model is an evolutionary software process model that couples the iterative nature of
.
prototyping with the controlled and systematic as pects

❖It provides the potential for rapid development of increasingly more complete versions of the

software. describes the model in the following manner of the waterfall 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.

1. One is a cyclic approach for incrementally growing a system’s degree of definition

and implementation while decreasing its degree of risk.

2. The other is a set of anchor point milestones for ensuring stakeholder commitment to
feasible and mutually satisfactory system solutions.
❖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
illustrated in Figure 2
❖The first circuit around the spiral might result in the development of a
product specification; subsequent passes around the spiral might be used to
develop a prototype and then progressively more sophisticated versions of
the software.
❖Each pass through the planning region results in adjustments to the project
plan.
❖Cost and schedule are adjusted based on feedback derived from the
customer after delivery.
❖In addition, the project manager adjusts the planned number of iterations
required to complete the software.
❖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 first circuit around the spiral might represent a “concept development
project” that starts at the core of the spiral and continues for multiple
iterations
❖The spiral model is a realistic approach to the development of large-scale
systems and software.
[Link] Models
❖The concurrent development model, sometimes called concurrent
engineering, allows a software team to represent iterative and
concurrent elements of any of the process models
❖For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following software
engineering actions: prototyping, analysis, and design.
❖Figure provides a schematic representation of one software
engineering activity within the modeling activity using a concurrent
modeling approach.
❖The activity—modeling—may be in any one of the states noted at any
given time. Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an analogous
manner.
• All software engineering activities exist concurrently but reside in different states.

❖ For example, early in a project the communication activity (not shown in the figure) has completed its first
iteration and exists in the awaiting changes state.

❖ The molding activity which existed in the inactive state while initial communication was completed, now
makes a transition into the under development state.

❖ If, however, the customer indicates that changes in requirements must be made, the modeling activity moves
from the under development state into the awaiting changes state.

❖ Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the
software engineering activities, actions, or tasks.

❖ Concurrent modeling is applicable to all types of software development and provides an accurate picture of
the current state of a project. Rather than confining software engineering activities, actions, and tasks to a
sequence of events, it defines a process network
 3.4 A Final Word on Evolutionary Processes
Evolutionary process models were conceived to address these issues

1. The first concern is that prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product. Most project management
and estimation techniques are based on linear layouts of activities, so they do not fit
completely

2. Second, evolutionary software processes do not establish the maximum speed of the
evolution.

3. Third, software processes should be focused on flexibility and extensibility rather than
on high quality.
 4. Specialized process models
Specialized process models take on many of the characteristics of one or more of
the traditional models presented in the preceding sections. , these models tend to

be applied when a specialized or narrowly defined software engineering

approach is chosen.

1. Component-Based Development
2. The Formal Methods Model
3. Aspect-Oriented Software Development
 [Link]-Based Development
❖ The component-based development model incorporates many of the characteristics of the

spiral model.

❖ It is evolutionary in nature demanding an iterative approach to the creation of software.

❖However, the component-based development model constructs applications from

prepackaged software components

❖ Modeling and construction activities begin with the identification of candidate components

❖These components can be designed as either conventional software modules or object-

oriented classes or packages of classes.

The component-based development model incorporates the following steps
(implemented using an evolutionary approach):

1. Available component-based products are researched and evaluated for the

application domain in question.

2. Component integration issues are considered.

3. A software architecture is designed to accommodate the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is conducted to ensure proper functionality.

The component-based development model leads to software reuse and reusability
provides software engineers with a number of measurable benefits
 2. The Formal Methods Model
❖The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
❖Formal methods enable you to specify, develop, and verify a computer-based
system by applying a rigorous, mathematical notation.
❖A variation on this approach, called cleanroom software engineering is
currently applied by some software development organizations.
❖When formal methods are used during development, they provide a mechanism
for eliminating many of the problems that are difficult to overcome using other
software engineering paradigms
❖When formal methods are used during design, they serve as a basis for program
verification and therefore enable you to discover and correct errors that might
otherwise go undetected.
The formal methods model offers the promise of defect-free software. Yet, concern
about its applicability in a business environment has been voiced:

▪ The development of formal models is currently quite time consuming and expensive.

▪ Because few software developers have the necessary background to apply formal
methods, extensive training is required.

▪ It is difficult to use the models as a communication mechanism for technically

unsophisticated customers.

The formal methods approach has gained adherents among software developers who
must build safety-critical software and among developers that would suffer severe
economic hardship should software errors occur.
 [Link]-Oriented Software Development
• AOSD defines “aspects” that express customer concerns that cut across
multiple system functions, features, and information.
• Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects—
“mechanisms beyond subroutines and inheritance for localizing the
expression of a crosscutting concern
• AOCE uses a concept of horizontal slices through vertically-decomposed
software components, called “aspects,” to characterize cross-cutting
functional and non-functional properties of components.
• Common, systemic aspects include user interfaces, collaborative work,
distribution, persistency, memory management, transaction processing, security,
integrity and so on.

• Components may provide or require one or more “aspect details” relating to a

particular aspect, such as a viewing mechanism, extensible affordance and
interface kind (user interface aspects); event generation, transport and receiving
(distribution aspects); data store/retrieve and indexing (persistency aspects);
authentication, encoding and access rights (security aspects); transaction
atomicity, concurrency control and logging strategy (transaction aspects); and so
on.

• Each aspect detail has a number of properties, relating to functional and/or non-
functional characteristics of the aspect details.
 5. Unified Process
➢In some ways the Unified Process is an attempt to draw on the best
features and characteristics of traditional software process models, but
characterize them in a way that implements many of the best principles
of agile software development
➢The Unified Process recognizes the importance of customer
communication and streamlined methods for describing the customer’s
view of a system.
➢It emphasizes the important role of software architecture and “helps the
architect focus on the right goals, such as understandability, reliance to
future changes, and reuse”
➢It suggests a process flow that is iterative and incremental, providing
the evolutionary feel that is essential in modern software
 A Brief History

➢ During the early 1990s James Rumbaugh [Rum91], Grady Booch [Boo94], and Ivar Jacobson [Jac92]
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
(e.g., [Wir90]) 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.
➢ Over the next few years, Jacobson, Rumbaugh, and Booch developed the Unified Process, a
framework for object-oriented software engineering using UML. Today, the Unified Process (UP) and
UML are widely used on object-oriented projects of all kinds.
➢ The iterative, incremental model proposed by the UP can and should be adapted to meet specific
project needs.
Phases of the Unified Process1
➢ 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 (Figure 2.9).
➢ The construction phase of the UP is identical to the construction activity defined for
the generic software process.
➢ The transition phase of the UP encompasses the latter stages of the generic con
struction activity and the first part of the generic deployment (delivery and
feedback) activity
➢ 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
 [Link] AND TEAM PROCESS MODELS
1. Personal Software Process (PSP)
❑ Every developer uses some process to build computer software. The process may be haphazard or ad hoc;
may change on a daily basis; may not be efficient, effective, or even successful; but a “process” does exist.
❑ The Personal Soft ware Process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product
❑ The PSP model defines five framework activities:
1. Planning. This activity isolates requirements and develops both size and resource estimates. In addition,
a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and a project schedule is created.
2. High-level design. External specifications for each component to be con structed are developed and a
component design is created. Prototypes are built when uncertainty exists. All issues are recorded and
tracked.
3. High-level design review. Formal verification methods (Chapter 21) are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
4. Development. The component-level design is refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all important tasks and work results.
5. Postmortem. Using the measures and metrics collected (this is a substan tial amount of data that should
be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.
 Team Software Process (TSP)
Because many industry-grade software projects are addressed by a team of
practitioners, Watts Humphrey extended the lessons learned from the introduction of
PSP and proposed a Team Software Process (TSP).
The goal of TSP is to build a “self directed” project team that organizes itself to produce
high-quality software. Humphrey [Hum98] defines the following objectives for TSP:
➢ Build self-directed teams that plan and track their work, establish goals, and own
their processes and plans. These can be pure software teams or integrated product
teams (IPTs) of 3 to about 20 engineers.
➢ Show managers how to coach and motivate their teams and how to help them
sustain peak performance.
➢ Accelerate software process improvement by making CMM23 Level 5 behavior
normal and expected.
➢ Provide improvement guidance to high-maturity organizations.
➢ Facilitate university teaching of industrial-grade team skills.
Thank You