Software Engineering

UNIT I Lecture Notes

What is Software?
Software is: (1) instructions (computer programs) that when executed provide
desired features, function, and performance; (2) data structures that enable the
programs to adequately manipulate information and (3) documentation that
describes the operation and use of the programs.
 Software is developed or engineered; it is not manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward component-based construction, most
software continues to be custom-built.
What is a Legacy Software?
The definition of legacy software (Monolithic Architecture) is an old and outdated
program that is still used to perform a task for a user, even though newer and more
efficient options are available.
An example of legacy software is a factory's computer system running on an old version
of Windows because there is not a need to invest in the most updated software.
Different type of Software Applications
The 7 broad categories of computer software present:
1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web-applications
7) Artificial intelligence software.

System software: System software is a collection of programs written to service other

programs. The systems software is characterized by
- heavy interaction with computer hardware
- heavy usage by multiple users
- concurrent operation that requires scheduling, resource sharing, and sophisticated
process management
- complex data structures
- multiple external interfaces

E.g. compilers, editors and file management utilities.

Application software:
- Application software consists of standalone programs that solve a specific business
need.
- It facilitates business operations or management/technical decision making.
- It is used to control business functions in real-time

E.g. point-of-sale transaction processing, real-time manufacturing process control.

Engineering/Scientific software: Engineering and scientific applications range
- from astronomy to volcanology
- from automotive stress analysis to space shuttle orbital dynamics
- from molecular biology to automated manufacturing
E.g. computer aided design, system simulation and other interactive applications.

Embedded software:
- Embedded software resides within a product or system and is used to implement and
control features and functions for the end-user and for the system itself.
- It can perform limited and esoteric functions or provide significant function and control
capability.
E.g. Digital functions in automobile, dashboard displays, braking systems etc.
Product-line software: Designed to provide a specific capability for use by many
different customers, product-line software can focus on a limited and esoteric market
place or address mass consumer markets

E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment,

database management, personal and business financial applications
Web-applications: WebApps are evolving into sophisticated computing environments
that not only provide standalone features, computing functions, and content to the end
user, but also are integrated with corporate databases and business applications.
Artificial intelligence software: AI software makes use of nonnumerical algorithms to
solve complex problems that are not amenable to computation or straightforward
analysis. Application within this area includes robotics, expert systems, pattern
recognition, artificial neural networks, theorem proving, and game playing.

The following are the new challenges on the horizon:

Ubiquitous computing
Netsourcing
Open source
The “new economy”

Ubiquitous computing: The challenge for software engineers will be to develop

systems and application software that will allow small devices, personal computers and
enterprise system to communicate across vast networks.

Net sourcing: The challenge for software engineers is to architect simple and
sophisticated applications that provide benefit to targeted end-user market worldwide.

Open Source: The challenge for software engineers is to build source that is self
descriptive but more importantly to develop techniques that will enable both customers
and developers to know what changes have been made and how those changes manifest
themselves within the software.

The “new economy”: The challenge for software engineers is to build applications that
will facilitate mass communication and mass product distribution
What are all the expectations of the new Generation of Software?
The expectations of the new generation of software are as follows
 Software must be adapted to meet the needs of new computing environments or
technology.
 Software must be enhanced to implement new business requirements.
 Software must be extended to make it interoperable with other more modern systems
or databases.
 Software must be re-architected to make it viable within a network environment.
What are all the Characteristics of WebApps?
 Network intensiveness. A WebApp resides on a network and must serve the
needs of a diverse community of clients.
 Concurrency. A large number of users may access the WebApp at one time.
 Unpredictable load. The number of users of the WebApp may vary by orders of
magnitude from day to day.
 Performance. If a WebApp user must wait too long (for access, for server-side
processing, for client-side formatting and display), he or she may decide to go
elsewhere.
 Availability. Although expectation of 100 percent availability is unreasonable,
users of popular WebApps often demand access on a “24/7/365” basis.
 Data driven. The primary function of many WebApps is to use hypermedia to
present text, graphics, audio, and video content to the end-user.
 Content sensitive. The quality and aesthetic nature of content remains an
important determinant of the quality of a WebApp.
 Continuous evolution. Unlike conventional application software that evolves
over a series of planned, chronologically-spaced releases, Web applications evolve
continuously.
 Immediacy. Although immediacy—the compelling need to get software to market
quickly—is a characteristic of many application domains, WebApps often exhibit
a time to market that can be a matter of a few days or weeks.
 Security. Because WebApps are available via network access, it is difficult, if not
impossible, to limit the population of end-users who may access the application.
 Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel.
What is software Engineering?
Definition 1:
Software engineering is the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real
machines.
Definition 2:
The IEEE definition:
 Software Engineering: (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of approaches as in (1).
Explain a Generic View of Software Engineering
Engineering is the analysis, design, construction, verification, and management of
technical (or social) entities. Regardless of the entity to be engineered, the following
questions must be asked and answered:

• What is the problem to be solved?

• What characteristics of the entity are used to solve the problem?
• How will the entity (and the solution) be realized?
• How will the entity be constructed?
• What approach will be used to uncover errors that were made in the design
and construction of the entity?
• How will the entity be supported over the long term, when corrections, adaptations,
and enhancements are requested by users of the entity.

The work associated with software engineering can be categorized into three generic
phases, regardless of application area, project size, or complexity. Each phase addresses
one or more of the questions noted previously.

The definition phase focuses on what. That is, during definition, the software engineer
attempts to identify what information is to be processed, what function and performance
are desired, what system behavior can be expected, what interfaces are to be established,
what design constraints exist, and what validation criteria are required to define a
successful system. The key requirements of the system and the software are identified.
Although the methods applied during the definition phase will vary depending on the
software engineering paradigm (or combination of paradigms) that is applied, three
major tasks will occur in some form: system or information engineering, software project
planning, and requirements analysis .

The development phase focuses on how. That is, during development a software engineer
attempts to define how data are to be structured, how function is to be implemented
within a software architecture, how procedural details are to be implemented, how
interfaces are to be characterized, how the design will be translated into a programming
language (or nonprocedural language), and how testing will be performed. The methods
applied during the development phase will vary, but three specific technical tasks should
always occur: software design, code generation,and software testing.

The support phase focuses on change associated with error correction, adaptations
required as the software's environment evolves, and changes due to enhancements
brought about by changing customer requirements. The support phase reapplies the
steps of the definition and development phases but does so in the context of existing
software. Four types of change are encountered during the support phase:

Correction. Even with the best quality assurance activities, it is likely that the customer
will uncover defects in the software. Corrective maintenance changes the software to
correct defects.

Adaptation. Over time, the original environment (e.g., CPU, operating system, business
rules, external product characteristics) for which the software was developed is likely to
change. Adaptive maintenance results in modification to the software to accommodate
changes to its external environment.

Enhancement. As software is used, the customer/user will recognize additional

functions that will provide benefit. Perfective maintenance extends the software beyond
its original functional requirements.

Prevention. Computer software deteriorates due to change, and because of this,

preventive maintenance, often called software reengineering, must be conducted to
enable the software to serve the needs of its end users. In essence, preventive
maintenance makes changes to computer programs so that they can be more easily
corrected, adapted, and enhanced.

In addition to these support activities, the users of software require continuing support.
In-house technical assistants, telephone-help desks, and application-specific Web sites
are often implemented as part of the support phase.

The phases and related steps described in our generic view of software engineering are
complemented by a number of umbrella activities. Typical activities in this category
include:

• Software project tracking and control

• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management
Explain the Software Engineering as a Layered Technology.

Divided into 4 layers: -

1. A quality Process: -
• Any engineering approach must rest on an quality.
• The "Bed Rock" that supports software Engineering is Quality Focus.

2. Process: -
• Foundation for SE is the Process Layer
• SE process is the GLUE that holds all the technology layers together and enables
the timely development of computer software.
• It forms the base for management control of software project.

3. Methods :-
• SE methods provide the "Technical Questions" for building Software.
• Methods contain a broad array of tasks that include communication requirement
analysis, design modeling, program construction testing and support.

4. Tools: -
• SE tools provide automated or semi-automated support for the "Process" and
the "Methods".
• Tools are integrated so that information created by one tool can be used by another.

Explain the Software Process Framework in detail.

Framework is a Standard way to build and deploy applications. Software Process
Framework is a foundation of complete software engineering process. Software process
framework includes all set of umbrella activities. It also includes number of framework
activities that are applicable to all software projects.
A generic process framework encompasses five activities which are given below one
by one:
Communication:
In this activity, heavy communication with customers and other stakeholders,
requirement gathering is done.
Planning:
In this activity, we discuss the technical related tasks, work schedule, risks, required
resources etc.
Modeling:
Modelling is about building representations of things in the ‘real world’.In modelling
activity, a product’s model is created in order to better understanding and requirements.
Construction:
In software engineering, construction is the application of set of procedures that are
needed to assemble the product. In this activity, we generate the code and test the
product in order to make better product.
Deployment:
In this activity, a complete or non-complete products or software are represented to the
customers to evaluate and give feedback. on the basis of their feedback we modify the
products for supply better product.
Typical umbrella activities are:

1. Software project tracking and control

 In this activity, the developing team accesses project plan and compares it with the
predefined schedule.
 If these project plans do not match with the predefined schedule, then the required
actions are taken to maintain the schedule.
2. Risk management
 Risk is an event that may or may not occur.
 If the event occurs, then it causes some unwanted outcome. Hence, proper risk
management is required.
 3. Software Quality Assurance (SQA)
 SQA is the planned and systematic pattern of activities which are required to give a
guarantee of software quality.
For example, during the software development meetings are conducted at every
stage of development to find out the defects and suggest improvements to produce
good quality software.
4. Formal Technical Reviews (FTR)
 FTR is a meeting conducted by the technical staff.
 The motive of the meeting is to detect quality problems and suggest improvements.
 The technical person focuses on the quality of the software from the customer point
of view.
5. Measurement
 Measurement consists of the effort required to measure the software.
 The software cannot be measured directly. It is measured by direct and indirect
measures.
 Direct measures like cost, lines of code, size of software etc.
 Indirect measures such as quality of software which is measured by some other
factor. Hence, it is an indirect measure of software.
6. Software Configuration Management (SCM)
 It manages the effect of change throughout the software process.
7. Reusability management
 It defines the criteria for reuse the product.
 The quality of software is good when the components of the software are developed
for certain application and are useful for developing other applications.
8. Work product preparation and production
 It consists of the activities that are needed to create the documents, forms, lists, logs
and user manuals for developing a software.
Explain the Process Patterns

The software process can be defined as a collection of patterns that define a set of
activities, actions, work tasks, work products and/or related behaviours required to
develop computer software.

A process pattern provides us with a template- a consistent method for describing an

important characteristic of the software process. A pattern might be used to describe a
complete process and a task within a framework activity.

Pattern Name: The pattern is given a meaningful name that describes its function within
the software process.

Intent: The objective of the pattern is described briefly.

Type: The pattern type is specified. There are three types

1. Task patterns define a software engineering action or work task that is part of
the process and relevant to successful software engineering practice. Example:
Requirement Gathering

2. Stage Patterns define a framework activity for the process. This pattern
incorporates multiple task patterns that are relevant to the stage.

Example: Communication
3. Phase patterns define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature.

Example: Spiral model or prototyping.

Initial Context: The conditions under which the pattern applies are described prior to
the initiation of the pattern, we ask
(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 problem to be solved by the pattern is described.

Solution: The implementation of the pattern is described.
This section describes how the initial state of the process is modified as a consequence
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: The conditions that will result once the pattern has been successfully
implemented are described. Upon completion of the pattern we ask
(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?
Known Uses: The specific instances in which the pattern is applicable are indicated
Process patterns provide and effective mechanism for describing any software process.
The patterns enable a software engineering organization to develop a hierarchical
process description that begins at a high-level of abstraction.

Once process pattern have been developed, they can be reused for the definition of
process variants-that is, a customized process model can be defined by a software team
using the pattern as building blocks for the process models.

Explain the Process Assessment

The existence of a software process is no guarantee that software will be delivered on

time, that it will meet the customer’s needs, or that it will exhibit the technical
characteristics that will lead to long-term quality characteristics. In addition, the process
itself should be assessed to be essential to ensure that it meets a set of basic process
criteria that have been shown to be essential for a successful software engineering.

A Number of different approaches to software process assessment have been proposed

over the past few decades.

Standards CMMI Assessment Method for Process Improvement (SCAMPI) provides

a five step process assessment model that incorporates initiating, diagnosing,
establishing, acting & learning. The SCAMPI method uses the SEI CMMI as the basis for
assessment.

CMM Based Appraisal for Internal Process Improvement (CBA IPI) provides a
diagnostic technique for assessing the relative maturity of a software organization, using
the SEI CMM as the basis for the assessment.
SPICE (ISO/IEC15504) standard defines a set of requirements for software process
assessments. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process.

ISO 9001:2000 for Software is a generic standard that applies to any organization that
wants to improve the overall quality of the products, system, or services that it provides.
Therefore, the standard is directly applicable to software organizations &companies.

Explain the PERSONAL AND TEAM PROCESS MODELS.

The best software process is one that is close to the people who will be doing the
work.Each software engineer would create a process that best fits his or her needs, and
at the same time meets the broader needs of the team and the organization. Alternatively,
the team itself would create its own process, and at the same time meet the narrower
needs of individuals and the broader needs of the organization.

Personal software process (PSP)

The personal software process (PSP) emphasizes personal measurement of both the
work product that is produced and the resultant quality of the work product.
The PSP process model defines five framework activities: planning, high-level design,
high level design review, development, and postmortem.

Planning: This activity isolates requirements and, base on these develops both size and
resource estimates. In addition, a defect estimate is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and a project schedule
is created.

High level design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.

High level design review: Formal verification methods are applied to uncover errors in
the design. Metrics are maintained for all important tasks and work results.

Development: The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important task and work
results.

Postmortem: Using the measures and metrics collected the effectiveness of the process
is determined. Measures and metrics should provide guidance for modifying the process
to improve its effectiveness.
PSP stresses the need for each software engineer to identify errors early and, as
important, to understand the types of errors that he is likely to make.
PSP represents a disciplined, metrics-based approach to software engineering.

Team software process (TSP): The goal of TSP is to build a “self-directed project team
that organizes itself to produce high-quality software. The following are the 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(IPT) 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 CMM level 5 behavior normal
and expected.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade team skills. A self-directed team
defines

- roles and responsibilities for each team member

- tracks quantitative project data
- identifies a team process that is appropriate for the project
- a strategy for implementing the process
- defines local standards that are applicable to the teams software engineering work;
- continually assesses risk and reacts to it
- Tracks, manages, and reports project status.
- TSP defines the following framework activities: launch, high-level design,
implementation, integration and test, and postmortem.
-TSP makes use of a wide variety of scripts, forms, and standards that serve to guide
team members in their work.
-Scripts define specific process activities and other more detailed work functions that
are part of the team

Software Engineering Practice

Practice is a broad array of concepts, principles, methods, and tools that you must
consider as software is planned and developed.

It represents the details—the technical considerations and how to’s—that are below the
surface of the software process—the things that you’ll need to actually build high-quality
computer software.

The Essence of Practice

This section lists the generic framework (communication, planning, modeling,
construction, and deployment) and umbrella (tracking, risk management, reviews,
measurement, configuration management, reusability management, work product
creation, and product) activities found in all software process models.

George Polya, in a book written in 1945 (!), describes the essence of software
engineering practice …
1. Understand the problem (communication and analysis).
 Who are the stakeholders?
 What are the unknowns? “Data, functions, features to solve the problem?”
 Can the problem be compartmentalized? “Smaller that may be easier to
understand?
  Can the problem be represented graphically? Can an analysis model be
created?
2. Plan a solution (modeling and software design).
 Have you seen a similar problem before?
 Has a similar problem been solved? If so, is the solution reusable?
 Can sub-problems be defined?
 Can you represent a solution in a manner that leads to effective
implementation?

3. Carry out the plan (code generation).

 Does the solution conform to the plan?
 Is each component part of the solution probably correct?
4. Examine the result for accuracy (testing and quality assurance).
 Is it possible to test each component part of the solution?
 Does the solution produce results that conform to the data, functions,
features, and behavior that are required?

Software Process

A software process (also known as software methodology) is a set of related activities that
leads to the production of the software. These activities may involve the development of
the software from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main

functionalities of the software and the constrains around them.

2. Software design and implementation: The software is to be designed and

programmed.

3. Software verification and validation: The software must conforms to it’s

specification and meets the customer needs.

4. Software evolution (software maintenance): The software is being modified to meet

customer and market requirements changes.

In practice, they include sub-activities such as requirements validation, architectural

design, unit testing, …etc.

There are also supporting activities such as configuration and change management,
quality assurance, project management, user experience.
Along with other activities aim to improve the above activities by introducing new
techniques, tools, following the best practice, process standardization (so the diversity of
software processes is reduced), etc.

When we talk about a process, we usually talk about the activities in it. However, a process
also includes the process description, which includes:

1. Products: The outcomes of an activity. For example, the outcome of architectural

design maybe a model for the software architecture.

2. Roles: The responsibilities of the people involved in the process. For example, the
project manager, programmer, etc.

3. Pre and post conditions: The conditions that must be true before and after an
activity. For example, the pre-condition of the architectural design is the
requirements have been approved by the customer, while the post condition is the
diagrams describing the architectural have been reviewed.

Software process is complex, it relies on making decisions. There’s no ideal process and
most organizations have developed their own software process.

For example, an organization works on critical systems has a very structured process,
while with business systems, with rapidly changing requirements, a less formal, flexible
process is likely to be more effective.

Software Process Models / Prescriptive Models

Prescriptive process models advocate an orderly approach to software engineering

A software process model is a simplified representation of a software process. Each model

represents a process from a specific perspective.

We’re going to take a quick glance about very general process models. These generic
models are abstractions of the process that can be used to explain different approaches to
the software development. They can be adapted and extended to create more specific
processes.

Some methodologies are sometimes known as software development life cycle (SDLC)
methodologies, though this term could also be used more generally to refer to any
methodology.
Waterfall Model

The waterfall model is a sequential approach, where each fundamental activity of a

process represented as a separate phase, arranged in linear order.

In the waterfall model, you must plan and schedule all of the activities before starting
working on them (plan-driven process).

Plan-driven process is a process where all the activities are planned first, and the progress is
measured against the plan. While the agile process, planning is incremental and it’s easier to
change the process to reflect requirement changes.

The phases of the waterfall model are: Requirements, Design, Implementation,

Testing, and Maintenance.

The Waterfall Model

The Nature of Waterfall Phases

In principle, the result of each phase is one or more documents that should be approved
and the next phase shouldn’t be started until the previous phase has completely been
finished.

In practice, however, these phases overlap and feed information to each other. For
example, during design, problems with requirements can be identified, and during coding,
some of the design problems can be found, etc.

The software process therefore is not a simple linear but involves feedback from one
phase to another. So, documents produced in each phase may then have to be modified to
reflect the changes made.
When to Use?

In principle, the waterfall model should only be applied when requirements are well
understood and unlikely to change radically during development as this model has a
relatively rigid structure which makes it relatively hard to accommodate change when the
process in underway.

Incremental Development

Incremental development is based on the idea of developing an initial implementation,

exposing this to user feedback, and evolving it through several versions until an acceptable
system has been developed.

The activities of a process are not separated but interleaved with feedback involved across
those activities.

The Incremental Development Model

Each system increment reflects a piece of the functionality that is needed by the customer.
Generally, the early increments of the system should include the most important or most
urgently required functionality.

This means that the customer can evaluate the system at early stage in the development
to see if it delivers what’s required. If not, then only the current increment has to be
changed and, possibly, new functionality defined for later increments.

Incremental Vs Waterfall Model

Incremental software development is better than a waterfall approach for most business,
e-commerce, and personal systems.
By developing the software incrementally, it is cheaper and easier to make changes in the
software as it is being developed.

Compared to the waterfall model, incremental development has three important benefits:

1. The cost of accommodating changing customer requirements is reduced. The

amount of analysis and documentation that has to be redone is much less than that’s
required with waterfall model.

2. It’s easier to get customer feedback on the work done during development than
when the system is fully developed, tested, and delivered.

3. More rapid delivery of useful software is possible even if all the functionality hasn’t
been included. Customers are able to use and gain value from the software earlier
than it’s possible with the waterfall model.

THE RAD MODEL:

Rapid Application Development (RAD) is an incremental software process model that

emphasizes a short development cycle. The RAD model is a “high-speed” adaption of the
waterfall model, in which rapid development is achieved by using a component base
construction approach.

Context: If requirements are well understood and project scope is constrained, the RAD
process enables a development team to create a “fully functional system” within a very
short time period.
The RAD approach maps into the generic framework activities.

Communication works to understand the business problem and the information

characteristics that the software must accommodate.

Planning is essential because multiple software teams works in parallel on different

system functions.

Modeling encompasses three major phases- business modeling, data modeling and
process modeling- and establishes design representation that serve existing software
components and the application of automatic code generation.

Deployment establishes a basis for subsequent iterations. The RAD approach has

drawbacks:
 For large, but scalable projects, RAD requires sufficient human resources to create
the right number of RAD teams.
 If developers and customers are not committed to the rapid-fire activities
necessary to complete the system in a much abbreviated time frame, RAD projects
will fail
 If a system cannot be properly modularized, building the components necessary
for RAD will be problematic
 If high performance is an issue, and performance is to be achieved through tuning
the interfaces to system components, the RAD approach may not work; and

RAD may not be appropriate when technical risks are high.

EVOLUTIONARY PROCESS MODELS:

Evolutionary process models produce with each iteration produce an increasingly more
complete version of the software with every iteration.

Evolutionary models are iterative. They are characterized in a manner that enables
software engineers to develop increasingly more complete versions of the software.

Prototyping

A prototype is a version of a system or part of the system that’s developed quickly to check
the customer’s requirements or feasibility of some design decisions.

So, a prototype is useful when a customer or developer is not sure of the requirements, or
of algorithms, efficiency, business rules, response time, etc.

In prototyping, the client is involved throughout the development process, which

increases the likelihood of client acceptance of the final implementation.

While some prototypes are developed with the expectation that they will be discarded, it
is possible in some cases to evolve from prototype to working system.
A software prototype can be used:
[1] In the requirements engineering, a prototype can help with the elicitation and
validation of system requirements.
It allows the users to experiment with the system, and so, refine the requirements. They
may get new ideas for requirements, and find areas of strength and weakness in the
software.
Furthermore, as the prototype is developed, it may reveal errors and in the requirements.
The specification maybe then modified to reflect the changes.
[2] In the system design, a prototype can help to carry out deign experiments to check
the feasibility of a proposed design.
For example, a database design may be prototype-d and tested to check it supports
efficient data access for the most common user queries.

The process of prototype development

The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made explicit from
the start of the process. Is it to validate system requirements, or demonstrate
feasibility, etc.

2. Define prototype functionality: Decide what are the inputs and the expected output
from a prototype. To reduce the prototyping costs and accelerate the delivery
schedule, you may ignore some functionality, such as response time and memory
utilization unless they are relevant to the objective of the prototype.

3. Develop the prototype: The initial prototype is developed that includes only user
interfaces.

4. Evaluate the prototype: Once the users are trained to use the prototype, they then
discover requirements errors. Using the feedback both the specifications and the
prototype can be improved. If changes are introduced, then a repeat of steps 3 and 4
may be needed.

Prototyping is not a standalone, complete development methodology, but rather an

approach to be used in the context of a full methodology (such as incremental, spiral, etc).

Spiral Model

The spiral model is a risk-driven where the process is represented as spiral rather than a
sequence of activities.

It was designed to include the best features from the waterfall and prototyping models,
and introduces a new component; risk-assessment.

Each loop (from review till service — see figure below) in the spiral represents a phase.
Thus the first loop might be concerned with system feasibility, the next loop might be
concerned with the requirements definition, the next loop with system design, and so on.
The spiral model

Each loop in the spiral is split into four sectors:

1. Objective setting: The objectives and risks for that phase of the project are defined.

2. Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is conducted, and steps are taken to reduce the risk. For example, if there’s a
risk that the requirements are inappropriate, a prototype may be developed.

3. Development and validation: After risk evaluation, a process model for the system
is chosen. So if the risk is expected in the user interface then we must prototype the
user interface. If the risk is in the development process itself then use the waterfall
model.

4. Planning: The project is reviewed and a decision is made whether to continue with a
further loop or not.

Spiral model has been very influential in helping people think about iteration in software
processes and introducing the risk-driven approach to development. In practice, however,
the model is rarely used.

THE CONCURRENT DEVELOPMENT MODEL:

The concurrent development model, sometimes called concurrent engineering, can be

represented schematically as a series of framework activities, software engineering
actions and tasks, and their associated states.
The activity modeling may be in anyone of the states noted at any given time. Similarly,
other activities or tasks can be represented in an analogous manner. All activities exist
concurrently but reside in different states.
Any of the activities of a project may be in a particular state at any one time:
- under development
- awaiting changes
- under revision
- under review

In a project the communication activity has completed its first iteration and exists in the
awaiting changes state. The modeling activity which existed in the none 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.
The concurrent process model defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, actions, or tasks.

The event analysis model correction which will trigger the analysis action from the done
state into the awaiting changes state.

Context: The concurrent model is often more appropriate for system engineering
projects where different engineering teams are involved.

Advantages:

The concurrent process model is applicable to all types of software development and
provides an accurate picture of the current state of a project.
It defines a network of activities rather than each activity, action, or task on the network
exists simultaneously with other activities, action and tasks.

THE UNIFIED PROCESS:

The unified process (UP) is an attempt to draw on the best features and characteristics of
conventional 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“. If suggests a process
flow that is iterative and incremental, providing the evolutionary feel that is essential in
modern software development.

A BRIEF HISTORY:

During the 1980s and into early 1990s, object-oriented (OO) methods and programming
languages gained a widespread audience throughout the software engineering
community. A wide variety of object- oriented analysis (OOA) and design (OOD) methods
were proposed during the same time period.

During the early 1990s James Rumbaugh, Grady Booch, and Ival Jacobsom began working
on a “Unified method” that would combine the best features of each of OOD & OOA. The
result was UML- a unified modeling language that contains a robust notation fot the
modeling and development of OO systems.

By 1997, UML became an industry standard for object-oriented software development.

At the same time, the Rational Corporation and other vendors developed automated tools
to support UML methods.

Over the next few years, Jacobson, Rumbugh, and Booch developed the Unified process, a
framework for object-oriented software engineering using UML. Today, the Unified
process and UML are widely used on OO 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 PROCESS:

The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with the customer and end-users, 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 customer 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 analysis model, the design model, the implementation model, and the
deployment model.
The construction phase of the UP is 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. To accomplish this, analysis and design models that were started during
the elaboration phase are completed to reflect the final version of the software increment.
The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment activity. Software given to end-users
for beta testing, and user feedback reports both defects and necessary changes.
The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the on-going use of the software is monitored, support for the
operating environment is provided, and defect reports and requests for changes are
submitted and evaluated.
A software engineering workflow is distributed across all UP phases. In the context of UP,
a workflow is analogous to a task set. That is, a workflow identifies the tasks required to
accomplish an important software engineering action and the work products that are
produced as a consequence of successfully completing the tasks.

UNIFIED PROCESS WORK PRODUCTS:

During the inception phase, the intent is to establish an overall “vision” for the project,
- identify a set of business requirements,
- make a business case for the software, and
- define project and business risks that may represent a threat to success.

The most important work product produced during the inception is the use-case modell-
a collection of use-cases that describe how outside actors interact with the system and
gain value from it. The use-case model is a collection of software features and functions
by describing a set of preconditions, a flow of events and a set of post-conditions for the
interaction that is depicted.

The use-case model is refined and elaborated as each UP phase is conducted and serves
as an important input for the creation of subsequent work products. During the inception
phase only 10 to 20 percent of the use-case model is completed. After elaboration,
between 80 to 90 percent of the model has been created.

The elaboration phase produces a set of work products that elaborate requirements and
produce and architectural description and a preliminary design. The UP analysis model
is the work product that is developed as a consequence of this activity. The classes and
analysis packages defined as part of the analysis model are refined further into a design
model which identifies design classes, subsystems, and the interfaces between
subsystems. Both the analysis and design models expand and refine an evolving
representation of software architecture. In addition the elaboration phase revisits risks
and the project plan to ensure that each remains valid.
The construction phase produces an implementation model that translates design
classes into software components into the physical computing environment. Finally, a
test model describes tests that are used to ensure that use cases are properly reflected in
the software that has been constructed.

The transition phase delivers the software increment and assesses work products that
are produced as end-users work with the software. Feedback from beta testing and
qualitative requests for change is produced at this time.

Agile Process View

Agility is flexibility, it is a state of dynamic, adapted to the specific circumstances.

The agile methods refers to a group of software development models based on the
incremental and iterative approach, in which the increments are small and typically, new
releases of the system are created and made available to customers every few weeks.

The principles of agile methods

They involve customers in the development process to propose requirements changes.
They minimize documentation by using informal communications rather than formal
meetings with written documents. They are best suited for application where the
requirements change rapidly during the development process.

1. Is driven by customer descriptions of what is required (scenarios)(Story

Writing)
2. Recognizes that plans are short-lived
3. Develops software iteratively with a heavy emphasis on construction activities
4. Delivers multiple ‘software increments’
5. Adapts as changes occur.

Human Factors

Traits that need to exist in members of agile development teams:

 Competence
 Common focus
 Collaboration
 Decision-making ability
 Fuzzy-problem solving ability
 Mutual trust and respect
 Self-organization

There are a number of different agile methods available such as: Extreme Programming
(XP), Adaptive Software Development (ASD), Dynamic Systems Development Method
(DSDM), Scrum, Crystal, Feature Driven Development (FDD), Agile Modeling (AM).
Extreme Programming (XP)
Having described the Waterfall Model, the idea of the Extreme Programming (XP)
approach now follows. XP has been chosen here as an example because it describes the
most extreme case of agile procedure methodology.
The roots of XP lie in Project C3 (Chrysler Consolidated Compensation) at
DaimlerChrysler between the years 1997 and 1998 – an internal accounting system for
employees. After the project threatened to fail, the company commissioned Kent Beck,
Ron Jeffries, Martin Fowler and others to set it up from scratch – with success. Kent Beck
summarized the ideas that formed into a method and published them in the book
“Extreme Programming Explained – EMBRACE CHANGE”.
XP is a framework consisting of three main elements:
1. Values
2. Principles
3. Practices
 spike solut ions
simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

ref act oring

pair
programming

Release
sof t ware increment
unit t est
project v elocit y comput ed cont inuous int egrat ion

accept ance t est ing

Values of XP

XP is based on four values:

 Simplicity: Simple solutions are cheaper and quicker to implement than complex
solutions. Therefore, XP always tries to find the simplest solutions.
 Communication: All team members should communicate intensively with each other .
Through personal dialogue, misunderstandings can be eliminated very quickly; questions
can likewise be answered very promptly. As a result, documentation can sometimes be
waived.
 Feedback: In order to achieve high quality, namely to achieve what the customer needs,
very short feedback loops are used to show the development to the customer
continuously. Thus, an incorrect development can be stopped very quickly. Feedback
does not only come from the customer but also from the tests.
 Courage: To use these values and at the same time communicate openly requires a great
deal of courage, especially for those project members who are not used to acting in
accordance with these values. It takes courage to scale the requirements of the customer
down to the most important points with continuous feedback and openness as well as
direct communication with the customer and other project members.

Principles of XP

XP is based on fifteen principles that can be derived from the four values. The individual
points shown here are admittedly very brief, but a basic understanding of XP can still be
formed.
 Rapid Feedback: Feedback on all activities should be sought as quickly as possible,
resulting in good learning effects.
 Assume Simplicity: Simple solutions are easier to understand and feedback can be
obtained faster.
 Incremental Change: Continuous small changes press ahead – major changes usually have
many dependencies.
 Embracing Change: Being open to change.
 Quality Work: Allowing the team to deliver quality work increases job satisfaction. The
users make the decisions regarding the quality.
 Teach Learning: Project members should learn to decide for themselves what they need
to achieve their goals. For example, the developers are left to decide how many tests to
write.
 Small Initial Investment: By focusing on the most important functions, initial usable
systems are delivered quicker.
 Play to Win: The will to win is an attitude in XP. To play to win is far more motivating
than simply wanting to avoid mistakes.
 Concrete Experiments: To minimize risks, decisions are underpinned by specific
experiments.
 Open, Honest Communication: Attention is paid to open, honest communication. All
project members are encouraged to enforce this.
 Work with people’s instincts, not against them: Trust in the team – even if an unusual
approach is adopted to achieve a goal.
 Accepted Responsibility: Responsibility is not assigned, but should be taken. This
creates very strong identification with the tasks.
 Local Adaptions: XP should be adapted to local needs and conditions because not all
points from the textbook can be used in every project.
 Travel light: Do not provide too many tools and methods; fewer, more effective tools
should support the project.
 Honest Measurement: Some measurements are required to steer projects. These
measurements must be taken honestly by the project members.

Practices of XP

12 practices supplement the 4 values and 15 principles. These practices are designed to
help developers behave according to the principles.

Management-Practices

 On-Site Customer: A central customer contact must always be accessible in order to

clarify requirements and questions directly.
 Planning Game: Projects, in accordance with XP, run iteratively (repeatedly) and
incrementally (gradually build on each other). The contents of the next step are planned
before each iteration. All project members (incl. the customer) participate.
 Short Releases: New deliveries should be made at short intervals. Consequently,
customers receive the required functions quicker and can therefore give feedback on the
development quicker.

Team-Practices

 Metaphor: Only a few clear metaphors should describe the system being developed so
that the nitty-gritty of the system is clear to all of the project members.
 Collective Ownership: The whole team is responsible for the system, not individuals. Each
developer must have access to all lines of code so that each developer is able to take over
the task of another developer.
 Continuous Integration: All changes to the system are integrated promptly so that not too
many dependencies between changes occur.
 Coding Standards: Regarding the common responsibility for the code, there should be a
given common standard for writing the code.
 Sustainable Pace: XP builds on the creativity of the individual project members. This
creativity cannot be achieved if the project team constantly works overtime. Overtime is
to be avoided.

Programming-Practices

 Testing: All developments must be tested.

 Simple Design: The system should be designed as simply as possible so that it is easier to
understand, modify and test.
 Refactoring: As soon as it becomes necessary to alter the structure of the system, it should
be implemented.
 Pair Programming: There are always two developers sitting in front of a computer in
order to increase the quality and transfer the knowledge better.

Adaptive Software Development

 Self-organization arises when independent agents cooperate to create a solution to a

problem that is beyond the capability of any individual agent
 Emphasizes self-organizing teams, interpersonal collaboration, and both individual and
team learning
 Adaptive cycle characteristics
 Phases
 Mission-driven
 Component-based
 Iterative
 Time-boxed
 Risk driven and change-tolerant
  Speculation (project initiated and adaptive cycle planning takes place)
 Collaboration (requires teamwork from a jelled team, joint application
development is preferred requirements gathering approach, minispecs created)
 Learning (components implemented and testes, focus groups provide feedback,
formal technical reviews, postmortems)

Dynamic Systems Development Method

 Provides a framework for building and maintaining systems which meet tight time
constraints using incremental prototyping in a controlled environment
 Uses Pareto principle (80% of project can be delivered in 20% required to deliver the
entire project)
 Each increment only delivers enough functionality to move to the next increment
 Uses time boxes to fix time and resources to determine how much functionality will be
delivered in each increment
 Guiding principles
 Active user involvement
 Teams empowered to make decisions
 Fitness foe business purpose is criterion for deliverable acceptance
 Iterative and incremental develop needed to converge on accurate business
solution
 All changes made during development are reversible
 Requirements are baselined at a high level
 Testing integrates throughout life-cycle
 Collaborative and cooperative approach between stakeholders
 Life cycle activities
 Feasibility study (establishes requirements and constraints)
 Business study (establishes functional and information requirements needed to
provide business value)
 Functional model iteration (produces set of incremental prototypes to
demonstrate functionality to customer)
 Design and build iteration (revisits prototypes to ensure they provide business
value for end users, may occur concurrently with functional model iteration)
 Implementation (latest iteration placed in operational environment)
 Scrum

 Scrum principles
 Small working teamed used to maximize communication, minimize overhead,
and maximize sharing of informal knowledge
 Process must be adaptable to both technical and business challenges to ensure
bets product produced
 Process yields frequent increments that can be inspected, adjusted, tested,
documented and built on
 Development work and people performing it are partitioned into clean, low
coupling partitions
 Testing and documentation is performed as the product is built
 Provides the ability to declare the product done whenever required
 Process patterns defining development activities
 Backlog (prioritized list of requirements or features the provide business value
to customer, items can be added at any time)
 Sprints (work units required to achieve one of the backlog items, must fir into a
predefined time-box, affected backlog items frozen)
 Scrum meetings (15 minute daily meetings) addressing these questions: What
was done since last meeting? What obstacles were encountered? What will be
done by the next meeting?
 Demos (deliver software increment to customer for evaluation)

Crystal

 Development approach that puts a premium on maneuverability during a resource-

limited game of invention and communication with the primary goal of delivering useful
software and a secondary goal of setting up for the next game
 Crystal principles
 Its always cheaper and faster to communicate face-to-face
 As methodologies become more formal teams become weighed down and have
trouble adapting to project work vagaries
 As projects grow in size, teams become larger and methodologies become
heavier
  As projects grow in criticality some degree of formality will need to be
introduced in parts of the methodology
 As feedback and communication become more efficient the need for
intermediate work products is reduced
 Discipline, skills, and understanding counter process, formality, and
documentation
 Team members not on the critical project path can spend their excess time
improving the product or helping people who are on the critical path
 Incremental development strategy used with 1 to 3 month time lines
 Reflection workshops conducted before project begins, during increment development
activity, and after increment is delivered
 Crystal methodologies
 Clear (small, low criticality projects)
 Orange (larger, moderately critical projects)
 Orange Web (typical e-business applications)

Feature Driven Development

 Practical process model for object-oriented software engineering

 Feature is a client-valued function, can be implemented in two weeks or less
 FDD Philosophy
 Emphasizes collaboration among team members
 Manages problem and project complexity using feature-based decomposition
followed integration of software increments
 Technical communication using verbal, graphical, and textual means
 Software quality encouraged by using incremental development, design and code
inspections, SQA audits, metric collection, and use of patterns (analysis, design,
construction)

 Framework activities
 Develop overall model (contains set of classes depicting business model of
application to be built)
 Build features list (features extracted from domain model, features are
categorized and prioritized, work is broken up into two week chunks)
 Plan by feature (features assessed based on priority, effort, technical issues,
schedule dependencies)
 Design by feature (classes relevant to feature are chosen, class and method
prologs are written, preliminary design detail developed, owner assigned to each
class, owner responsible for maintaining design document for his or her own work
packages)
  Build by feature (class owner translates design into source code and performs unit
testing, integration performed by chief programmer)
Agile Modelling

 Practice-based methodology for effective modelling and documentation of software

systems in a light-weight manner
 Modeling principles
 Model with a purpose
 Use multiple models
 Travel light (only keep models with long-term value)
 Content is more important than representation
 Know the models and tools you use to create them
 Adapt locally
 Requirements gathering and analysis modelling
 Work collaboratively to find out what customer wants to do
 Once requirements model is built collaborative analysis modelling continues
with the customer
 Architectural modelling
 Derives preliminary architecture from analysis model
 Architectural model must be realistic for the environment and must be
understandable by developers.

**********