UNIT 1

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.
(3) Documents that describes the operation and use of the programs.

Software has characteristics that are considerably different than those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware manufacturing,
the two activities are fundamentally different.

In both activities, high quality is achieved through good design, but the manufacturing phase for
hardware can introduce quality problems that are nonexistent (or easily corrected) for software.
Both activities are dependent on people, but the relationship between people applied and work
accomplished is entirely different, both activities require the construction of a “product,” but
the approaches are different.

2. Software doesn’t “wear out.”

Figure 1.1. depicts failure rate as a function of time for hardware. The relationship, often called
the “bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life
defects are corrected and the failure rate drops to a steady-state level for some period of time. As
time passes, however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature extremes, and many other
environmental maladies. i.e. the hardware begins to wear out.
Software is not susceptible to the environmental maladies. therefore, the failure rate curve
for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered
defects will cause high failure rates early in the life of a program. However, these are corrected
and the curve flattens as shown. As changes are made, it is likely that errors will be introduced,
causing the failure rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the
curve can return to the original steady-state failure rate, another change is requested, causing the
curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is
deteriorating(to become worse as time passes) due to change.

When a hardware component wears out, it is replaced by a spare part. There are no software
spare parts. Every software failure indicates an error in design or in the process through which
design was translated into machine executable code. Therefore, the software maintenance is
considerably more complex than hardware maintenance.
 Figure 1.1.Failure curve for hardware Figure 1.2.Failure curve for software

3. Although the industry is moving toward component-based construction, most software

continues to be custom built.

In the hardware world, component reuse is a natural part of the engineering process. In the
software world, it is something that has only begun to be achieved on a broad scale.

THE CHANGING NATURE OF SOFTWARE:

The 7 broad categories of computer software present continuing challenges for software engineers:

• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• Web-applications
• Artificial intelligence software.

System software: System software is a collection of programs written to service other programs.
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 UNIQUE NATURE OF WEB APPS

Introduction:
In the early days of the World Wide Web (1990 to 1995), websites consisted of little more than a
set of linked hypertext files that presented information using text and limited graphics.
Today, WebApps have evolved into sophisticated computing tools that not only provide stand-
alone function to the end user, but also have been integrated with corporate databases and
business applications due to the development of HTML, JAVA, xml etc.
Attributes of WebApps:
 Network Intensiveness
 Concurrency
 Unpredictable load
 Performance
 Availability
 Data driven
 Content Sensitive
 Continuous evolution
 Immediacy
 Security
 Aesthetic
Network intensiveness:
A WebApp resides on a network and must serve the needs of a diverse community of clients.
The network may enable worldwide access and communication (i.e., the Internet) or more
limited access and communication (e.g., a corporate Intranet Network Intensiveness)

Concurrency: [Operation at the same time]

A large number of users may access the WebApp at one time. In many cases, the patterns of
usage among end users will vary greatly.

Unpredictable load:
The number of users of the WebApp may vary by orders of magnitude from day to day. One
hundred users may show up on Monday; 10,000 may use the system on Thursday.
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.
In addition, WebApps are commonly used to access information that exists on databases that are
not an integral part of the Web-based environment (e.g., e-commerce or financial applications).
Content sensitive:
The quality and artistic 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. It is not unusual for some WebApps
(specifically, their content) to be updated on a minute-by-minute schedule or for content to be
independently computed for each request.
Immediacy:Although immediacy—the compelling (forceful) needs 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. In order to protect sensitive content and
provide secure mode of data transmission, strong security measures must be implemented.
Aesthetics: [Artistic / Visual]
An undeniable part of the appeal of a WebApp is its look and feel. When an application has been
designed to market or sell products or ideas, aesthetic may have as much to do with success as
technical design.
SOFTWARE ENGINEERING
Software engineering is defined as 'the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance and retirement of software.
Software engineering can be defined as a systematic approach to develop software within
specified time and budget. One of the main objectives of software engineering is to help
developers to obtain high quality software.

F S
iayS
gtso
u itf Customer needs
rset
efm w Customer needs

ia
SOFTWARE PROCESS
1etr
A process is a collection of activities, actions, and tasks that are performed when some work
.sie
product is to be created.
3c  An activity
 An has set of s/w engineering actions. (e.g., communication with stakeholders)
action (e.g., architectural design) encompasses a set of tasks that produce a major
:q work product (e.g., an architectural design model).
a  Aproduces
u task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
a tangible outcome.
S apby identifying a smallestablishes
A process framework the foundation for a complete software engineering process
number of framework activities that are applicable to all software
olpprojects, regardless of their size or complexity.
fir A generic process framework for software engineering encompasses five activities:
to Communication: involves heavy communication with the customer (and other
w ya stakeholders) and encompasses requirements gathering.
ac Planning: Describes the technical tasks to be conducted, the risks that are likely,
resources that will be required, the work products to be produced and a work schedule.
rch Modeling: encompasses the creation of models that allow the developer and customer to
er better understand S/W req. and the design that will achieve those req.
i Construction: combines code generation and the testing required uncovering errors in
the code.
et
n e Deployment: deliver the product to the customer who evaluates the delivered product
and provides feedback.
gr
i
n a
A Process Framework defines set of umbrella activities applicable across entire s/w process.

Typical umbrella activities are:

•
Software project tracking and control – allows the software team to assess
progress against the project plan and take necessary action to maintain schedule.
• Risk Management - assesses risks that may affect the outcome of the project or the
quality of the product.
• Software Quality Assurance - defines and conducts the activities required to ensure
software quality.
• Formal Technical Reviews - assesses software engineering work products in an
effort to uncover and remove errors before they are propagated to the next action or
activity.
• Measurement - define and collects process, project and product measures that assist
the team in delivering software that needs customer’s needs, can be used in
conjunction with all other framework and umbrella activities.
• Software configuration management - manages the effects of change throughout
the software process.
• Reusability management - defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.
• Work Product preparation and production - encompasses the activities required
to create work products such as models, document, logs, forms and lists.
PROCESS PATTERNS

The software process can be defined as a collection patterns that define a set of activities,
actions, work tasks, work products and/or related behaviors 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

 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
 Stage Patterns define a framework activity for the process. This pattern incorporates
multiple task patterns that are relevant to the stage.
 Example: Communication
 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

 What organizational or team related activities have already occurred.

 What is the entry state for the process
 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

 What organizational or team-related activities must have occurred?

 What is the exit state for the process?
 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.

SOFTWARE ENGINEERING PRACTICE

Software engineering practice consists of a collection of concepts, principles, methods, and tools
that a software engineer calls upon on a daily basis.
The essence of practice
1. Understand the problem (communication and analysis).
2. Plan a solution (modelling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

1. Understand the problem (communication and analysis)

• Who has a stake in the solution to the problem?
• What are the unknowns? and what (data, function, behavior) are required to
properly solve the Problem?
• Can the problem be compartmentalized? Is it possible to represent smaller
problems that may be easier to understand.
• Can the problem be represented graphically? Can analysis model be created?
2. Plan a solution (planning, modeling and software design)
• Have you seen similar problems like this before?
• Has a similar problem been solved? If so, are the elements of the solution
reusable?
• Can sub problems be defined and are solutions available for the sub problems?
• Can you represent a solution in a manner that leads to effective implementation?
Can a design model be created?

3) Carry out the plan (construction; code generation)

• Does the solution conform to the plan? Is the source code traceable back to the
design model?
• Is each component of the solution correct? Has the design and code been
reviewed, or better?

4) Examine the results for accuracy (testing and quality assurance)

• Is it possible to test each component of the solution? Has a reasonable testing
strategy been implemented?
• Does the solution produce results that conform to the data, function, and behavior
that are required?Has the Software been validated against all stakeholders
requirement?

General principles
Seven principles that focus on software engineering practice as a whole.

1) Remember the reason that the software exists

• The software should provide value to its users and satisfy the requirements.
2) Keep it simple
• All design and implementation should be as simple as possible.
3) Maintain the vision of the project
• A clear vision is essential to the project’s success.
4) Others will consume what you produce.
• Always specify, design, and implement knowing that someone else will later
have to understand and modify what you did
5) Be open to the future
• Never design yourself into a corner; build software that can be easily changed
and adapted.
6) Plan ahead for software reuse
• Reuse of software reduces the long-term cost and increases the value of the
program and the reusable components.
7) Think, then act
• Placing clear, complete thought before action will almost always produce better
results.
SOFTWARE MYTHS

Software myths—Myth is a false belief(not reality)

--erroneous beliefs about software and the process that is used to build it.
--misleading attitudes that have caused serious problems for managers and
practitioners.

There are 3 types of myths

 Management myths
 Customer myths
 Practitioner’s myths

Management myths:

Myth: We already have a book that’s full of standards and procedures for building software.
Won’t that provide my people with everything they need to know?
Reality: The book of standards may very well exist,
but is it used?
Are software practitioners aware of its existence?
Does it reflect modern software engineering practice?
Is it complete?
Is it adaptable?
Is it streamlined to improve time-to-delivery while still maintaining a focus on
quality?
In many cases, the answer to all of these questions is “no.”
Myth: If we get behind schedule, we can add more programmers and catch up
Reality: As new people are added, people who were working must spend time educating the
newcomers, thereby reducing the amount of time spent on productive development
effort. People can be added but only in a planned and well coordinated manner.

Myth: If I decide to outsource the software project to a third party, I can just relax and let that
firm build it.
Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.

Customer myths:
Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in
the details later.
Reality: Although a comprehensive and stable statement of requirements is not always possible,
an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous
requirements (usually derived iteratively) are developed only through effective and
continuous communication between customer and developer.
Myth: Software requirements continually change, but change can be easily accommodated
because software is flexible.
Reality: Impact of change depends on where and when it occurs in the software life cycle
(requirements analysis, design, code, test) When requirements changes are requested
early (before design or code has been started), the cost impact is relatively small.
However, as time passes, the cost impact grows rapidly—resources have been
committed, a design framework has been established, and change can cause confusion
that requires additional resources and major design modification.
Practitioner’s myths:
Myth: Once we write the program and get it to work, our job is done.
Reality: Industry data indicate that between 60 and 80 percent of all effort expended on software
will be expended after it is delivered to the customer for the first time.

Myth: Until I get the program “running” I have no way of assessing its quality.
Reality: Software reviews are a “quality filter” that have been found to be more effective than
testing for finding certain classes of software defects.

Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many
elements. A variety of work products (e.g., models, documents, plans) provide a
foundation for successful engineering and, more important, guidance for software
support.

Myth: Software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster
delivery times.

PROCESS ASSESSMENT AND IMPROVEMENT

The existence of a software process is no guarantee that software will be delivered on time, that it will
meet the customer’s needs.
Numbers of different approaches to process assessment and improvement 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.
PRESCRIPTIVE PROCESS MODELS
• These models define a distinct set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software.
• The activities may be linear, incremental, or evolutionary.
There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process models
3. Evolutionary process models

1. The Waterfall Model

• The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle
model' ,suggests a systematic sequential approach to software development that begins
with customer specification of requirements and progresses through planning, modeling,
construction, and deployment
• In this model, each phase is fully completed before the beginning of the next phase.
• In Communica
this model, feedback is taken after each phase to ensure that the project is on the right
path.
tionstarts only
• Testing part Planni
after the development is complete.
Project ng
initiation Estima
Requiremen ting Model
ts gatheringSchedu ing
Analys Constr Deploy
ling uction ment
Tracki is
Code Deliver
ng Design
Test y
Support
Fig. waterfall model Feedba
Advantages of waterfall model ck
• The waterfall model is simple and easy to understand, implement, and use.
• All the requirements are known at the beginning of the project; hence it is easy to manage.
• Where the requirements are well understood and the developers are confident, the waterfall
model works well.
• It avoids overlapping of phases because each phase is completed at once.

Disadvantages of the waterfall model

• No working software is produced until late during the life cycle.
• Not a good model for complex and object-oriented projects.
 • Poor model for long and ongoing projects.
• The amount of risk is high.

Application:

 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 The project is short

A variation in the representation of the waterfall model is called the V-model. It is also known as
Verification and Validation model.

V-MODEL

The V-Model is an extension of the waterfall model and is based on the association of a testing
phase for each corresponding development stage. This means that for every single phase in the
development cycle, there is a directly associated testing phase. This is a highly-disciplined model
and the next phase starts only after completion of the previous phase.

Under the V-Model, the corresponding testing phase of the development phase is planned in
parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the
other side. The Coding Phase joins the two sides of the V-Model.

Fig .different phases in a V-Model of the SDLC

Different phases in a V-Model of the SDLC
Business Requirement Analysis This is the first phase in the development cycle where the
product requirements are understood from the customer’s perspective. The acceptance test
design planning is done at this stage as business requirements can be used as an input for
acceptance testing.
System design The system design will have the understanding and detailing the complete
hardware and communication setup for the product under development. The system test plan is
developed based on the system design can be given as input for System testing.
Architectural Design The system design is broken down further into modules taking up
different functionality. This is also referred to as High Level Design (HLD). Integration testing
is associated with the architectural design phase.

Module Design In this phase, the detailed internal design for all the system modules are
specified, referred to as Low Level Design (LLD). Unit testing is associated with this phase.
Coding Phase The actual coding of the system modules designed in the design phase is taken up
in the Coding phase. The best suitable programming language is decided based on the system
and architectural requirements.

Advantages:

 This is a highly-disciplined model and Phases are completed one at a time.

 Works well for smaller projects where requirements are very well understood.
 Simple and easy to understand and use.

Disadvantages:

 High risk and uncertainty.

 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 No working software is produced until late during the life cycle.

Application:

 Requirements are well defined, clearly documented and fixed.

 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 The project is short.

2. INCREMENTAL PROCESS MODELS:

i) The incremental model
ii) The RAD model
i) The incremental model
• The incremental model combines elements of the waterfall model applied in an
iterative fashion.
• The incremental model delivers a series of releases called increments that provide
progressively more functionality for the customer as each increment is delivered.
• When an incremental model is used, the first increment is often a core product. That
is, basic requirements are addressed. The core product is used by the customer. 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.
For example, the word-processing software is developed using the incremental
model.

Fig. The incremental model

Advantages
• The main advantage of the incremental model is the early production of working software
during the software life cycle.
• Because each module is tested thoroughly, there is little possibility to change scope and
requirements in the final software.
• Due to incremental development, testing and debugging of each module become easier.
 Better suited for large and mission-critical projects.
 Results are obtained early and periodically.

 Parallel development can be planned.

 With every increment, operational product is delivered.

  During the life cycle, software is produced early which facilitates customer evaluation
and feedback.

Disadvantages

 Needs good planning and design

 Defining increments may require definition of the complete system.
 Not suitable for smaller projects.
 Highly skilled resources are required for risk analysis.

Application

 A new technology is used

 There is a need get a product to the market early.
 There are some high risk features and goals.

ii) 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.

Fig. The RAD model

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.
 Construction encompasses three major activities such as component reuse, automatic
code generation using RAD tools and testing.
 Deployment establishes a basis for subsequent iterations.
Advantages

 Changing requirements can be accommodated.

 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.

Disadvantages

 Dependency on technically strong team members for identifying business requirements.

 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 Inapplicable to cheaper projects as cost of modelling and automated code generation is
very high.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

Application

 RAD should be used only when a system can be modularized to be delivered in an

incremental manner.
 It should be used if there is a high availability of designers for modelling.
 It should be used only if the budget permits use of automated code generating tools.

3. Evolutionary process models

Evolutionary models are iterative. They are characterized in a manner that enables
software engineers to develop increasingly more complete versions of the software.
The two common evolutionary process models are
 Prototyping
 Spiral model
 PROTOTYPING:

• Prototype is a working model of software with some limited functionality.

• Prototyping is the process of developing partial working software (i.e. a prototype instead
of developing the final product.
• The prototyping paradigm begins with communication. The software engineer and
customer meet and define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory.
• Prototyping iteration is planned quickly and modeling occurs. The quick design leads to
the construction of a prototype. The prototype is deployed and then evaluated by the
customer/user.
• Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the
same time enabling the developer to better understand what needs to be done.

Fig. The Prototyping model

Advantages

• The prototype model is well suited for projects where requirements are difficult to
understand and the customer is not confident in illustrating and clarifying the
requirements.
• It fits best where the customer risks are related to the changing requirements (software
and hardware requirements) of the projects.

Disadvantages
• This model requires exclusive involvement of the customer, which is not always possible.
• Sometimes bad design decisions during prototype development may propagate to the real
product.

Application
  Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems.

Spiral Model:
• The spiral model is an iterative software development approach, which was proposed by
Boehm in 1988.
• In this model, activities are organized as a spiral with many loops.
• Each loop in the spiral represents a phase of software development.
• The exact number of loops in the spiral is not fixed.
• The main focus of this model is identification and resolution of potential risks (product
risks, project risks, and process risks).
 • Each loop in the spiral is split into four quadrants. Each of these four quadrants is used
for the development of each phase.
– Determine objectives, alternatives, and constraints(Planning)
– Evaluate alternatives; identify and resolve risks(Risk Analysis)
– Develop, verify the next level product(Development and Testing)
– Plan for the next phase(Evaluation)
• The redial dimension represents the cumulative cost incurred so far for the development
of phases in a project.
• The angular dimension indicates the progress made so far in completing each cycle.
• It is considered a Meta model because it incorporates the features of all other models,
which are the waterfall, prototyping, incremental, simulation, and performance models.

Advantages

 Changing requirements can be accommodated.

 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be developed
earlier which helps in better risk management.

Disadvantages

 Management is more complex.

 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive documentation.

Application

 When there is a budget constraint and risk evaluation is important.

 For medium to high-risk projects.
 Customer is not sure of their requirements which are usually the case.
 Requirements are complex and need evaluation to get clarity.
 Significant changes are expected in the product during the development cycle.

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.

Fig. One element of the concurrent process model

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

1. under development

2. awaiting changes

3. under revision

4. 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 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.

Application: 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.

SPECIALIZED PROCESS MODELS

1. Component-based Development Model

• 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.
• The component-based development model constructs applications from pre-packaged
software components.
• Modelling and construction activities begin with the identification of candidate
components.

•
This model consists of the following process steps
– Available component-based products are researched and evaluated for the
application domain in question
– Component integration issues are considered
– A software architecture is designed to accommodate the components
– Components are integrated into the architecture
– Comprehensive testing is conducted to ensure proper functionality
Advantage
• The component-based development model leads to software reuse, and reusability makes
reduction in development cycle time as well as a reduction in project cost.

2. Formal Methods Model

• Encompasses a set of activities that leads to formal mathematical specification of
computer software.
• It enables a software engineer to specify, develop, and verify a computer-based system by
applying a rigorous, mathematical notation.
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily through mathematical analysis
• Offers the promise of defect-free software.
• Used often when building safety-critical systems.

Formal Methods Model Challenges:

 • Development of formal methods 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 UNIFIED PROCESS:

Greedy Booch, Ivar Jacobson, and James Rumbaugh developed the unified process, which is a
framework for object-oriented software engineering using UML

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 development.

It consists of five phases:

• Inception
• Elaboration
• Construction
• Transition
• production

Fig. The Unified Process

1. Inception Phase
• 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.
2. Elaboration phase
 • It 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.

3. Construction Phase
• Encompasses the construction activity of the generic process.
• Uses the architectural model from the elaboration phase as input.
• Develops or acquires the software components that make each use-case operational.
• Analysis and design models from the previous phase are completed to reflect the final version
of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to the next phase.
4. Transition Phase
• Encompasses the last part of the construction activity and the first part of the
deployment activity of the generic process.
• Software is given to end users for beta testing and user feedback reports on defects
and necessary changes.
• The software teams create necessary support documentation (user manuals, trouble-
shooting guides, installation procedures).
• At the conclusion of this phase, the software increment becomes a usable software
release.
5. Production Phase
• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated

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.
 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.

1. 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: 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 represents a disciplined, metrics-based approach to software engineering.

2. 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 behaviors 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 appropriate for project implementation
 A strategy for implementing the process
 Continually assesses risk and reacts to it
 Tracks, manage, and reports project status.
TSP defines the various framework activities: launch, high-level design, implementation,
integration and test, and postmortem. These activities enable the team to plan, design and
construct software in a disciplined manner.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work.