Unit-I: Introduction to software Engineering

The Evolving role of software

Definition of software: Software is a set of items or objects that form a configuration that
includes
Programs
Documents
Data
Softwares Dual Role
Software is a product
Delivers computing potential
Produces, manages, acquires, modifies, displays, or transmits information
Software is a vehicle for delivering a product
Supports or directly provides system functionality
Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)

Software Characteristics
Software is developed or engineered; it is not manufactured in the classical sense.
Although some similarities exist between software development & hardware manufacturing
both the activities are different. In both activities high quality is achieved through good design, but
manufacturing phase will introduce quality problems that are non-existent in software. Both
activities depend on people but relationship between people applied and work accomplished is
different.

Software does not wear out. However it deteriorates due to change

Fig:Failure curve for h/w

It indicates that hardware exhibits high failure rates early in its life. Defects are corrected, and
failure rate drops to a steady-state level for some period of time. As time passes, the failure rate rises
again as hardware components suffer from cumulative effects of dust, temperature and other
environmental maladies. Simply hardware begins to wear out.

Fig: failure curve or s/w

Software doesnt wear out so it should take form of idealized curve. Undiscovered defects
will cause high failure rates early in its life of a program. However these are corrected and curve
flattens the actual curve shows that during its life software will undergo change. As changes are
made, it is likely that errors will be introduced, causing failure rate curve to spike again. Before
curve can return to original state, another change is requested, causing curve to spike again. Slowly
failure rate level begins to rise the software is deteriorating due to change.
-Although the industry is moving towards component based construction, most software
continues to be custom built
Custom-built: building according to needs of customer
The main of component-based construction is reuse. In the hardware world, component reuse is a
natural part of engineering process. In software world it has only begun to achieve on a broad scale.
Evolution of software:
1950s-60s (mid): Batch orientation, limited distribution
1960s (mid)-1970s (mid): multiuser, real time, database, product s/w
1970s mid-1980s (late): distributed systems, low cost h/w, and consumer impact s/w
1980s (late)-2000: object-oriented techniques, artificial neural networks.

Changing Nature of Software

Seven Broad Categories of software are challenges for software engineers

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

programs

Software is determinate is the order and timing of its inputs, processing, and outputs
is predictable (Ex compiler, file management utilities)
Indeterminate if the order and timing of its input, processing, and outputs is not predictable
in advance. (Ex: networking software, operating system components)
Application software: This is designed to help users in order to perform a specific task.
Applications in this area process business or technical data. Ex: C,JAVA
Engineering and scientific software: Engineering and scientific software have been
characterized by "number crunching" algorithms (which performs complex, lengthy and
complex numeric calculations). However modern applications are moving away from
numeric algorithms to computer-aided design, system simulation.
Embedded software: It resides within a product or system and is used to implement and
control features and functions of end-user and system itself.
Ex: Keypad control of microwave oven, fuel control etc
Product-line software: Designed to provide a specific capability for se by many different
customers.
Ex: Computer Graphics, entertainment, database management.
Web-applications: These are applications which are accessed over a network.
Artificial intelligence software: Artificial intelligence (AI) software makes use of
nonnumeric algorithms to solve complex problems that are not amenable to computation or
straightforward analysis Ex: Robotics, Expert systems, game playing etc.
Factors Contributing to the Software Crisis:
Larger problems,
Lack of adequate training in software engineering,
Increasing skill shortage,
Low productivity improvements
Some Software failures: Ariane 5, Y2K problem, The Patriot Missile, The Space Shuttle,
Windows XP, No Silver Bullet
SOFTWARE MYTHS: Propagate misinformation and confusion

Three types of myths

o Management myth
o Customer myth
o Practitioners myth

Myth (1) :: -Already we have a book of standards and procedures for building software wont
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? Is it complete? Is it adaptable?
Myth (2) ::

-If we get behind schedule we can add more programmers and can catch up.

Reality: As new people are added, people who were working must spend time educating the
newcomers, thereby reducing amount of time spent on productive development effort.

Myth (3) :: -Outsourcing the software project to third party, we can relax and let that party
build it.
Reality: If an organization doesnt understand how to manage and control software projects
internally, will face struggle when it outsources projects.
CUSTOMER MYTHS
Myth (1) :: General statement of objective is enough to begin writing programs, the details can
be filled in later.
Reality: Unambiguous requirements can be developed only through efficient and continuous
communication between developer and customer.
Myth (2) ::
-Software requirements continually change but change can be easily
accommodated because software is flexible.
Reality: When requirement changes are requested early cost impact is relatively small. However as
time passes cost impact grows rapidly.
Practitioner myths:
Myth (1) :: -Once the program is written, the job has been 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 customer for first time.
Myth (2) :: Until the program is running, there is no way of assessing the quality.
Reality: Formal technical reviews have been found more effective than actual testing
Myth (3) :: -The only deliverable work product is the working program
Reality: A working program is only part of software configuration. Documentation provides a
foundation for successful engineering.
Myth (4) ::
-Software Engineering creates voluminous and unnecessary documentation and
invariably slows down software development.
Reality: S.E is not about creating documents. It is about creating quality. Better quality leads to
reduced rework.

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY:

Definitions: Software engineering encompasses a process, a collection of methods (practice) and an
array of tools that allow professionals to build high quality computer software.
Software engineering: (1) The application of 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 in (1).

Quality focus: Bedrock that supports software Engineering.

Process - Foundation for software Engineering. It defines a framework that must be established for
effective delivery of software engineering technology. This provides a basis for management control
of software projects.
Methods: Provide technical how-tos for building Software. Methods encompass a broad array of
tasks that include
o
o
o
o
o
o

Communication
Requirements analysis
design modeling
Program construction
testing
Support

Tools: - Provide semi-automatic and automatic support to methods. When well-integrated, it is a

CASE system. (Computer-Aided Software Engineering)
Software Process: The software process is the way in which we produce software. Software process
Improvement is difficult because of not enough time, Wrong motivations, insufficient
commitment and Lack of knowledge.

Figure: The process

improvement learning curve
Ivar Jacobson, Grady Booch and James Rumbaugh defined A process As who is doing, what
when and how to reach a certain goal.
A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created. An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of rigor with which software engineering is to be applied. An action (e.g.,
architectural design) encompasses a set of tasks that produce a major work product (e.g., an
architectural design model). A task focuses on a small, but well-defined objective (e.g., conducting a
unit test) that produces a tangible outcome.
In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the work (the
software team) to pick and choose the appropriate set of work actions and tasks. The intent is always
to deliver software in a timely manner and with sufficient quality to satisfy those who have
sponsored its creation and those who will use it.

Process framework
A Process Framework establishes the foundation for a complete software process by identifying a
small number of framework activities that are applicable to all s/w projects, regardless of
size/complexity and set of umbrella activities which are applicable across entire s/w process
Each framework activity is populated by a set of software engineering action-collection of related
tasks that produce a major engineering work product
These are the 5 framework activities
Communication: This activity involves heavy communication and collaboration with customer and
encompasses requirements gathering.

Planning: It establishes a software project plan for software engineering work that follows. It
describes technical tasks to be conducted, risks that are likely, resources that will be required, work
product to be produced and a work schedule.
Modeling: This activity encompasses creating models that allows customer to better understand
software requirements and design.
Construction: This activity combines code generation and testing.
Deployment : The software is delivered to customer who evaluates the delivered product and
provides feedback.
Each Software engineering action is represented by a number of task sets. The task set that best
accommodates the needs o project and characteristics of team is chosen.
A task set defines the actual work to be done to accomplish the objectives of software
Engineering Action. For example: requirement gathering is an important software engineering
action that occurs during the communication activity. The goal of requirement gathering is to
understand what various stakeholders want from the software that is to be built.
For a small, relatively simple project, the task set for requirements gathering might look like this:
1. Make a list of stakeholders for the project.
2. Invite all stakeholder to an informal meeting
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.

Umbrella activities
Software project tracking and control: asses progress against project plan and take necessary
action to maintain schedule.
Formal technical reviews: Assesses software engineering work products in an effort to uncover or
remove errors before they are propagated to next action.
Software quality assurance: defines and conducts activities required to ensure quality
Software configuration management; manages change throughout the process.
Work product preparation and production: encompasses activities required to create work
products such as documents, forms,logs reports etc.
Reusability management: Defines criteria for work product reuse and establishes mechanisms to
achieve reusable components.
Measurement: Defines and collects process, project and product measures that assist team in
delivering software that meets customer needs
Risk management: assesses risks that may affect outcome of project and quality
CAPABILITY MATURITY MODEL INTEGRATION: Developed by SEI(Software Engineering
institute), Assess the process model followed by an organization and rate the organization with
different levels
A set of software engineering capabilities should be present as organizations reach different levels of
process capability and maturity.
CMMI process Meta model can be represented in different ways
1. A continuous model
2. A staged model
Continuous model: - -Levels are called capability levels. -Describes a process in 2 dimensions

-Each process area is assessed against specific goals and practices and is rated according to the
following capability levels.

Six levels of CMMI

Level 0:Incomplete

Level 1:Performed

Level 2:Managed

Level 3:Defined

Level 4:Quantitatively managed

Level 5:Optimized

INCOMPLETE

-Process is adhoc. Objective and goal of process areas are not known

Performed
All the specific goals and practices process area have been satisfied but performance
may not be stable they do not meet some specific objectives such as quality, cost and schedule
Managed
-Activities are monitored, reviewed, evaluated and controlled to achieve a given
purpose and cost, schedule, quality are maintained. These companies have some planned processes
within teams and teams are made to represent them for projects handled by them. However processes
are not standardized across organization.
Defined -All level2 criteria have been satisfied and in addition process are well defined and are
followed throughout the organization
Quantitatively Managed

-Metrics and indicators are available to measure the process and quality

Optimized (perfect & complete)

- Continuous process improvement based on quantitative feedback from the user
-Use of innovative ideas and techniques, statistical quality control and other methods for process
improvement.
In addition to specific goals and practices for each process area 5 generic goals correspond to
capability levels. In order to achieve a particular capability level the generic goal for that level and
generic practices correspond to the goal must be achieved.
Staged model
- This model is used if you have no clue of how to improve the process for quality software.
- It gives a suggestion of what things other organizations have found helpful to work first
-

Levels are called maturity levels

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

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

important characteristic of s/w process.

Patterns can be defined at any level of abstraction. In some cases it is used to define complete
process (e.g. prototyping).In other situations patterns can be used to describe an important
framework activity (e.g. planning) or a task within a framework activity(e.g. projectestimating).

Pattern Template
-Pattern Name: The pattern given a meaningful name that describes its function within the software
process. (E.g. requirements unclear)
-Intent: The objective of pattern is described briefly. For ex the objective of pattern is to build a
model that can be assessed iteratively by stakeholders.
-Type: pattern type is specified. Suggests 3 types
-Task pattern: defines a software engineering action or work task that is part o process (e.g.
requirements gathering)
- Stage pattern: defines a framework activity for the process (e.g. communication)
-Phase Pattern: defines sequence of framework activities that occur with the process (ex spiral
model or prototyping)
Initial Context: The condition under which pattern applies are described. Prior to initiation of
pattern the following conditions must be met

For ex:1) stakeholders have been identified 2) mode of communication between software team and
stakeholder has been established. 3) Problem to be solved has been identified by stakeholders.4) an
initial understanding of requirements has been developed
Problem: The problem to be solved by pattern is described.
Ex: Requirements are hazy or non-existent i.e., stakeholders are unsure of what they want. that is
they cannot describe software requirements in detail.
Solution: The implementation of pattern is described ex: A description of prototyping process is
described here.
Resulting Context: The conditions that ill result once the pattern has been successfully implemented
are described.
Ex: 1) A software prototype that identifies basic requirements are approved by stakeholders
And a prototype may evolve through a series of increments to become production software.
Related Patterns: A list of process patterns that are related to this one are provided.
Ex: customer-communication, iterative design & development, customer assessment, requirements
extraction.
Known uses and examples: The specific instances in which pattern are applicable are indicated.

PROCESS ASSESSMENT

It attempts to keep a check on the current state of the software process with the intention of
improving it.

Standard CMMI assessment for process improvement (SCAMPI): provides a 5 step

process assessment model that incorporates initiating, diagnosing, establishing, acting and
learning. The SCAMPI uses SEI CMMI as basis for assessment.

CMM based appraisal for internal process improvement: provides a diagnostic technique
for assessing relative maturity of a software organization

SPICE(ISO/IEC 15504):standard defines a set of requirements or sotware process

assessment

ISO 9001:2000 for software: is a generic standard that applies to any organization that wants
to improve overall quality of products, systems or services that it provides.

PROCESS MODELS

Process Models help in the software development

They Guide the software team through a set of framework activities

Process Models may be linear, incremental or evolutionary

LIFE CYCLE MODEL: A software life cycle model (also called process model) is a descriptive
and diagrammatic representation of the software life cycle. A life cycle model represents all the
activities required to make a software product transit through its life cycle phases. It also captures
the order in which these activities are to be undertaken. In other words, a life cycle model maps
the different activities performed on a software product from its inception to retirement. Different
life cycle models may map the basic development activities to phases in different ways. Thus, no
matter which life cycle model is followed, the basic activities are included in all life cycle models
though the activities may be carried out in different orders in different life cycle models. During
any life cycle phase, more than one activity may also be carried out.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software product is being
developed by a team there must be a clear understanding among team members about when and
what to do. Otherwise it would lead to chaos and project failure. This problem can be illustrated
by using an example. Suppose a software development problem is divided into several parts and
the parts are assigned to the team members. From then on, suppose the team members are allowed
the freedom to develop the parts assigned to them in whatever way they like. It is possible that one
member might start writing the code for his part, another might decide to prepare the test
documents first, and some other engineer might begin with the design phase of the parts assigned
to him. This would be one of the perfect recipes for project failure. A software life cycle model
defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria
have been satisfied. So without software life cycle model the entry and exit criteria for a phase
cannot be recognized. Without software life cycle models it becomes difficult for software project
managers to monitor the progress of the project.
Many life cycle models have been proposed so far. Each of them has some advantages as well as
some disadvantages. A few important and commonly used life cycle models are as follows:
o Classical Waterfall Model
o Iterative Waterfall Model
o Prototyping Model
o Evolutionary Model
o Spiral Model
THE WATERFALL MODEL

Used when requirements are well understood in the beginning

Also called classic life cycle model.

A systematic, sequential approach to Software development

Begins with customer specification of Requirements and progresses through planning,

modeling, construction and deployment

Feasibility study - The main aim of feasibility study is to determine whether it would be
financially and technically feasible to develop the product.
At first project managers or team leaders try to have a rough understanding of what is required to
be done by visiting the client side. They study different input data to the system and output data
to be produced by the system. They study what kind of processing is needed to be done on these
data and they look at the various constraints on the behavior of the system.

After they have an overall understanding of the problem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what kind of
resources required, what would be the cost of development and what would be the
development time for each solution.

Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically. They check whether the customer budget would meet the
cost of the product and whether they have sufficient technical expertise in the area of
development.
Requirements analysis and specification: - The aim of the requirements analysis and specification
phase is to understand the exact requirements of the customer and to document them properly. This
phase consists of two distinct activities, namely
Requirements gathering and analysis
Requirements specification
The goal of the requirements gathering activity is to collect all relevant information from
the customer regarding the product to be developed. This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies are removed.
The requirements analysis activity is begun by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer through interviews and
discussions. For example, to perform the requirements analysis of a business accounting software
required by an organization, the analyst might interview all the accountants of the organization to
ascertain their requirements. The data collected from such a group of users usually contain several
contradictions and ambiguities, since each user typically has only a partial and incomplete view of
the system. Therefore it is necessary to identify all ambiguities and contradictions in the
requirements and resolve them through further discussions with the customer. After all ambiguities,
inconsistencies, and incompleteness have been resolved and all the requirements properly
understood, the requirements specification activity can start. During this activity, the user
requirements are systematically organized into a Software Requirements Specification (SRS)

document. The customer requirements identified during the requirements gathering and analysis
activity are organized into a SRS document. The important components of this document are
functional requirements, the nonfunctional requirements, and the goals of implementation.
Design: - The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some programming language. In
technical terms, during the design phase the software architecture is derived from the SRS document.
Two distinctly different approaches are available: the traditional design approach and the objectoriented design approach.
Traditional design approach -Traditional design consists of two different activities; first a
structured analysis of the requirements specification is carried out where the detailed
structure of the problem is examined. This is followed by a structured design activity. During
structured design, the results of structured analysis are transformed into the software design.
Object-oriented design approach -In this technique, various objects that occur in the problem
domain and the solution domain are first identified, and the different relationships that exist
among these objects are identified. The object structure is further refined to obtain the
detailed design.
Coding and unit testing:-The purpose of the coding phase (sometimes called the implementation
phase) of software development is to translate the software design into source code. Each component
of the design is implemented as a program module. The end-product of this phase is a set of program
modules that have been individually tested. During this phase, each module is unit tested to
determine the correct working of all the individual modules. It involves testing each module in
isolation as this is the most efficient way to debug the errors identified at this stage.
Integration and system testing: -Integration of different modules is undertaken once they have been
coded and unit tested. During the integration and system testing phase, the modules are integrated in
a planned manner. The different modules making up a software product are almost never integrated
in one shot. Integration is normally carried out incrementally over a number of steps. During each
integration step, the partially integrated system is tested and a set of previously planned modules are
added to it. Finally, when all the modules have been successfully integrated and tested, system
testing is carried out. The goal of system testing is to ensure that the developed system conforms to
its requirements laid out in the SRS document. System testing usually consists of three different
kinds of testing activities:
testing: It is the system testing performed by the development team.
testing: It is the system testing performed by a friendly set of customers.
Acceptance testing: It is the system testing performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product.
System testing is normally carried out in a planned manner according to the system test plan
document. The system test plan identifies all testing-related activities that must be performed,
Specifies the schedule of testing, and allocates resources. It also lists all the test cases and the
expected outputs for each test case.
Maintenance: -Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself. Many studies carried out in the past confirm this and indicate
that the relative effort of development of a typical software product to its maintenance effort is
roughly in the 40:60 ratios. Maintenance involves performing any one or more of the following three
kinds of activities:
Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.
Improving the implementation of the system, and enhancing the functionalities of the system
according to the customers requirements. This is called perfective maintenance.

Porting the software to work in a new environment. For example, porting may be required to
get the software to work on a new computer platform or with a new operating system. This is
called adaptive maintenance.
Shortcomings of the classical waterfall model
The classical waterfall model is an idealistic one since it assumes that no development
error is ever committed by the engineers during any of the life cycle phases. However, in
practical development environments, the engineers do commit a large number of errors in almost
every phase of the life cycle. The source of the defects can be many: oversight, wrong
assumptions, use of inappropriate technology, communication gap among the project engineers,
etc. These defects usually get detected much later in the life cycle. For example, a design defect
might go unnoticed till we reach the coding or testing phase. Once a defect is detected, the
engineers need to go back to the phase where the defect had occurred and redo some of the work
done during that phase and the subsequent phases to correct the defect and its effect on the later
phases. Therefore, in any practical software development work, it is not possible to strictly follow
the classical waterfall model.
Disadvantages:

Real projects rarely follow the sequential flow since they are always iterative

The model requires requirements to be explicitly spelled out in the beginning, which is often
difficult

A working model is not available until late in the project time span

THE INCREMENTAL PROCESS MODEL

Linear sequential model is not suited for projects which are iterative in nature

Incremental model suits such projects

Used when initial requirements are reasonably well-defined and compelling need to provide
limited functionality to users quickly and then refine and expand on that functionality in later
releases.
It combines elements of waterfall model in an iterative fashion.

The incremental model applies linear sequences in a staggered ashion as calendar time
progresses.Each linear sequence provides deliverable increments of software.For ex word
processing sotware developed sing incremental paradigm might deliver basic file
management,editing,and document production functions in 1st increment ;more sophisticated
editing and document production capabilities in 2nd increment;spelling and grammar checking in
3rd increment; etc

1st increment constitutes Core product

Basic requirements are addressed

Core product undergoes detailed evaluation by the customer

As a result, plan is developed for the next increment Plan addresses the modification of core
product to better meet the needs of customer

Process is repeated until the complete product is produced

The incremental process model unlike prototyping and other evolutionary approaches,is iterative
in nature.But unlike prototyping,the incremental model focuses on delivery of an operational
product with each increment.
This model is particularly useul when staffing is unavailable for a complete implementation by
business deadline that has been established for the project.
THE RAD MODEL (Rapid Application Development)

An incremental software process model

Having a short development cycle

High-speed adoption of the waterfall model using a component based construction approach

Creates a fully functional system within a very short span time of 60 to 90 days

Multiple software teams work in parallel on different functions

Modeling encompasses three major phases: Business modeling, Data modeling and process
modeling

Construction uses reusable components, automatic code generation and testing

Problems in RAD

Requires a number of RAD teams

Requires commitment from both developer and customer for rapid-fire completion of
activities otherwise it fails

If system cannot be modularized properly project will fail.

Not suited when technical risks are high

EVOLUTIONARY PROCESS MODEL: Software evolves over a period of time

Business and product requirements often change as development proceeds making a straightline path to an end product unrealistic

Evolutionary models are iterative and as such are applicable to modern day applications

Types of evolutionary models

Prototyping
Spiral model
Concurrent development model

PROTOTYPING: Mock up or model( throw away version) of a software product

Used when customer defines a set of objective but does not identify input,output,or
processing requirements

Developer is not sure of:

efficiency of an algorithm
adaptability of an operating system
human/machine interaction

Begins with requirement gathering

Identify whatever requirements are known

Outline areas where further definition is mandatory

A quick design occur

Quick design leads to the construction of prototype

Prototype is evaluated by the customer

Requirements are refined

Prototype is turned to satisfy the needs of customer,while at the same time enabling developer
to better understand hat needs to be done.

Ideally prototype serves as a mechanism for identifying software requirements.

Disadvantages:

In a rush to get it working, overall software quality or long term maintainability are generally
overlooked

The developer often makes implementation compromises in order to get a prototype working
quickly.An inappropriate OS or PL may be used simply because it is available and known;an
inefficient algorithm may be implemented simply to demonstrate capability.After a
time,developer may become comfortable with these choices and forget all the reasons why
they were inappropriate.
Spiral model: This is a model proposed by boehm it is an evolutionary model which
combines the best feature of the classical life cycle and the iterative nature of prototype
model

Include new element : Risk element

Starts in middle and continually visits

planning,modeling,construction and deployment

Using spiral model,software is developed in a series of evoltionary releases.During early

iterations,the release might be a model or prototype.During later iterations increasinly more
complete versions of engineered system are produced

Realistic approach to the development of large scale system and software

Unlike other process models that end when software is delivered,the spiral model can be
adapted to apply through out the life of computer software.Therefore the first circuit around
the spiral represent a concept development project which starts at the core of the spiral and
contines for multiple iterations until concept development is complete.If the concept is to be
developed into an actual product,process proceeds outward on the spiral and a new product
development project commences.The new product will evolve through a number of
iterations around the spiral.Later,a circuit around spiral might be used to represent a product
enhancement project.The spiral remains operative until the software is retired.

It is difficult to convince customers that the evolutionary approach is controllable.

the

basic

tasks

of

communication,

CONCURRENT DEVELOPMENT MODEL

This is sometimes called concurrent engineering.This is represented schematically as

a series of framework activities,software engineering actions and tasks,and their
associated states.
Fig provides schematic representation of one software engineering task within
modelling activity.The activity modelling may in any one of these states at any given
time.Similarly other activities can be represented in a similar manner.
All activities exist concurrently but reside in different states.
For ex.early in a project communication activity has completed its first iteration and
exists in awaiting changes state.The modelling activity wchich existed in none state
while initial communication was completed now makes a transition to
underdevelopment state.If however customer indicates changes in requirements must
be made,the modelling activity moves from under development to awaiting changes
state
The concurrent process model dfines a series of events that will trigger transition from
state to state for each software engineering activities,actions and tasks.
This model is applicable to all types of software development and provides correct
pictre of accurate state of a project.

UNIFIED PROCESS MODEL

This model is proposed by ivan jacobson,grady booch,rumbaugh

This is a use-case driven,architecture-centric,iterative and incremental software process.
This is a framework for object-oriented software engineering sing UML.
The inception phase of Unified Process(UP) encompasses oth customer communication and
planning activities.By colloborating with customer,business requirements for the software
are identified.Fundamental business requirements are expressed through a set of preliminary
use-cases that describes what features and functions are desired by major class of sers.
Architecture at this point is nothing but outline of features and functions.Planning identifies
resources,assesses major risks,defines a schedule.
The elaboration phase encompasses communication,planning and modelling.Elaboration
reines and expands preliminary use-cases

that were developed as part of inception phase.Expands architectural representation to include ive
different views of software.the use-case model,the analysis model,the design model,the
implementation model and the deployment model.Modification to the plan may be made at tis
time

Construction of UP is identical to constuction activity of generic process models.All

necessary features and functions are implemented in souce code.As components are being
developed unit test is bein conducted.
The transition phase of UP encompasses later stages of construction activity and first
part of deployment activity.Softwareis given to end-users for beta-testing.In addition
software team creates installation procedres,user manuals etc.

The prodction phase cooincides with deployment activity .During tis phase on-going use
of software is monitored,and defect reports and request for changes are submitted and
evaluated.

PERSONAL AND TEAM SOFTWARE PROCESS MODELS

The best software process is one that is close to people who will be doing the work.
Watts Humphrey argues that it is possible to create personal and/or team software
process.Both require ardwaork,training&co-ordination butoth are acievable.
Personal s/w process
Every developer uses some process to build computer software.The process may be
inefficient,effective or successful but a process does exist.
In order to change an ineffiecient process an individal mustmove through 4 phases,each
require training and careful instrumentation.
Planning:Basedon requirements develop size and resource estimates.Metrics are recorded on
worksheets.Finally development tasks are identified & a schedule is created.
High-Level Design: External specifications for each component to be constructed &
developed & a component design is constructed.Prototypes are built when uncertainity exists.
High-Level Design Review:Formalverification methods are applied to uncover errors in
design.Metrics are maintained for all important tasks and work result.
Development: Design is refined&reviewed.Code is generated, reviewed, compiled & tested.
Metrics are maintained for all imp tasks.
Postmortem: Using measure & metrics collected,eectiveness of process is determined.
Team s/w process: Many projects are addressed by a team of practitioners
The goal of TSP is to ils a team that organises itself to produce high quality s/w.
TSP objectives
1
2
3
4

Build self directed teams that plan & track their goals
Show manager how to coach and motivate their teams.
Accelerate software process improvement by making CMM level 5 normal and expected.
Facilitate university teaching to pgrade team skills

TSP
defines
following
framework
activities
design,implementation,integration,test & postmortem

project

launch,high

level

TSP uses wide variety of scripts & standards that serve to guide team members in their
work.Scripts define specific activities.
This is an exmple for project launch script.