What is a Computer?

A computer is an electronic and mechanical device or machine that

accepts data as input, processes that data using programs, and outputs the
processed data as information. Many computers can store and retrieve
information using hard disk drives. Computers can be connected together
to form networks, allowing connected computers to communicate with
each other.

A computer has two main important components:

1. Hardware
2. Software
 INTRODUCTION TO SOFTWARE
Definition:
A software is

Instructions(or computer programs) that when executed provide

desired function.

Data structures that enable the programs to manupulate information

such as creation, insertion, deletion, searching, sorting, and merging
in data structures like stacks, queues, ,Arrays, linked lists, trees, and
graphs. and

 Documents that explains how to use and operation of the programs.

 Nature of the Software
The following are the characteristics of a Software:

1. A software is much more intangible(not visible) than other branches of

engineering products.
A software has no physical shape like other branches of engineering products. So you
cannot feel a shape of single piece of software.

2. A software duplication (The mass production of duplication of a software) is easy and

with least cost than other branches of engineering products duplication.
A software can be duplicated by creating a CD or it can be downloaded over network
called Internet, no cost paid for downloaded software from Internet, just the cost
paying only for Internet connection.

3. A software development increases the labour intensity than other branches of

engineering products manufacturing.
Other branches of engineering products has been able to automate many aspects of
manufacturing and construction using tools. Therefore other branches of engineering
have been production of no.of mass products with less labour. But this is not true for
software development because software would need high intelligent machines with
automated software development tools like CASE and success rate is low. Software
development and maintenance mostly dependent on skilled people. So software
development increases the labour intensity.
 Nature of the software to be continued...
4. A software is easy to create or develop by novice(or an inexperience)
programmer or developer also. But it has introduced many errors in created
software or developed software .Therefore, software does not functioning or
working properly to meet the user requirements satisfaction.

5. A software is easy to modify, without fully understanding the software Design.

But it has introduced many errors in modified software. Therefore, software does
not functioning or working properly to meet the user requirements satisfaction.

6. A software does not wear out like other branches of engineering products.
A software has no spare parts than other branches of engineering products. Other
branches of engineering products are replaced by its spare parts. Therefore a
software is not replaced by spare parts but errors in software can be modified or
corrected according to user requirements changes.

7. A software is developed but not manufactured than other branches of

engineering products manufacturing.
A software is not manufactured than other branches of engineering products
manufacturing. A software can be developed or created. Although, software is
also designed and produced like other branches of engineering products.
8. A software is highly malleable than other branches of engineering products.
suppose you bought a TV that does not fit into your cupboard, then take a
hammer to knock the cupboard or TV structure until TV fit into the cupboard,
but this is not happened in software because software does not changes its
structure to fit into, is called malleable.

9. A software is created or developed but not assembled of existing components.

suppose a computer is assembled with the existing components
CPU,RAM,ROM,HDD,MOTHEBOARD,KEYBOARD,MONITOR(screen),
SMPS(Switched mode power supply), PROCESSOR etc. But this is not
happened in software, because software is not assembled of existing
components and software has no spare parts or components, but software is
divided into sub-modules, each separate sub module developed by different
people.
Here the intelligent task is to combine or integrate modules together to ensure
the software quality (software has minimum no .of errors, so, it can be
functioning or working properly to meet the user or customer requirements
satisfaction)
 SOFTWARE TYPES
The following are the software applications types:

1.Custom software

2. Generic software

3. Embedded software

4. Web based software

5. Scientific software

6. Real time software

7. Artificial Intelligence software

1.Custom software:
The custom software is developed to meet the specific needs of particular
customers.
It is used by only few people.
It is developed in house or within the same organization and uses it.
Examples are
1.Web sites design for the organizations
2 .Managing finance of the organizations.
2.Generic software:
The generic software is developed to be sold on open market in packages wrapped
in plastic called shrink-wrapped software.
It is also called as commercial-off-the-shelf(COTS) software.
It is used by many people.
It is developed by large organizations such as Microsoft, Redhat, Google, alpha-
jet, Apple,wipro,TCS,Cognizent,mahindra satyam, capgemini ,hp,hcl, etc..

Examples are
1.Word processor(MS-WORD), Word presentation(MS-POWERPOINT),
Spreadsheets(MS-EXCEL), Database(MS-ACCESS),Compilers, Editors
(MS-NOTEPAD),Operating system(MS-WINDOWS, LINUX ,UBUNTU,
etc.),Computergames(pubzee,ludo,chess,caroms, visecity, etc..),Accounting
packages(Tally)for small organization,
antivirus(Bitdefenderplus,nortonplus,Mcafee,Avast,Avira anti-virus, anti-virus
pro, F-Secure anti-virus safe,kaspersky anti-virus,webroot SecureAnywhere
AntiVirus, ,ESET NOD32 Antivirus,G-data Antivirus,Comodo Windows Antivirus
), etc.
3.Embedded software:
Embedded software runs on specific hardware devices are sold on pen market, such
devices are fully automated washing machines, Air conditioners(A/Cs), microwave
voven, pridge, fans and automobiles (power steering, power windows automated door
locking)etc..

4.Web based software:

Web based software runs on a web server (computer system with large amounts of
storages and processing power) unlike local computer system(pcs).The web
applications software accessed by a user or customer through a web browser like
Google Chrome, Internet Explorer, Mozilla fire fox with active Internet. All mobile apps
are web apps like gmail, yahoo, twitter, zoom, youtube, facebook, netflix,
DisneyHotstar, video players, music players,Amazon(E-commerce), flip cart
(E-commerce) ,all online shopping(E-commerce), online reservation system, Internet
banking etc..
5.Scientific Software Engineering and manufacturing:
Computer Aided Design(CAD), Computer Aided Manufacturing(CAM) Software
are Scientific Soft wares. They automated design of scientific applications ranging
from astronomy to volcanology, from molecular biology to automated
manufacturing.. Etc..

6.Real time Software:

The software that monitor/analyse/control real world events called Real time
software.Elements of Realtime software include a data gathering component that
collects and formats information from an external environment, an analysis
component that transforms information as required by the application.
Examples are: Closed Circuit Television (CCT)cameras,

7.Artificial Intelligence software

It uses non numerical algorithms to solve complex problems. Examples are Expert
system like knowledge based systems,pattern recognization systems voice and
image. Artificial Neural Networks like Theorem proving,Game playing etc.
 SOFTWARE CRISIS

A Software Crisis is defined as a turning point in the course of disease. A

disease is the natural problems like evolutionary changes in software that
troubled software development.

A Software Crisis is also defined as chronic(continuing indefinitely)

affliction (any thing causing pain or distress). A chronic affliction have
problems associated with how we develop a software, how we support a
growing volume of existing software, how can we expect to keep pace
with a growing demand for more software .
 Software Myths(Imaginations)

The following are the software myths(imagination) types:

1. Management myths(Imaginations)

2. Customer myths(Imaginations)

3. Practitioner's myths(Imaginations)
1. Management myths(Imaginations)
We already have a book of full standards and procedures for building
software, won’t that provide my people with everything they need to know.
My people have software development tools(CASE) after all, we buy them
a newest computer.
if we get behind schedule, we can add more programmers and catch up.

2.Customer myths(Imaginations)
A general statement of objectives is sufficient to begin writing
programs , we can fill in the details later.
Project requirements continually change, but change can be easily
accommodated , because software is flexible.
3. Practitioner's myths(Imaginations)
Once we write the program and get it to work, our job is done.
Until I get the program running. I have no way of accessing its quality.
The only deliverable work product for a successful project is the working
program.
Software will make to create voluminous and unnecessary
documentation and will invariably slow us down.
Management Myths(Imaginations):

 We already have a book of full standards and procedures for building

software, won’t that provide my people with everything they need to know.
Reality: The book of standards very well exists. But ,Is a practitioner’s will aware
of this book?, does it really works for modern software development?, is it
complete?, does it strearmlined to deliver the software project on time? The listed
questions have answer NO.

 My people have software development tools(CASE) after all, we buy them

a newest computer.
Reality:YES,We need to buy a modern mainframe computer, desk top computer,
personal computer that support for generation of quality software(has minimum
no.of errors so, software can be functioning or working properly to meet the user
requirements satisfaction)

 if we get behind schedule, we can add more programmers and catch up.
Reality: Adding new programmers to late software project makes it later.
However, the new programmers are added, people who were working in late
project must spend time to educate the new added programmers(new comers).
Thus reducing time spent on product development effort. Programmers can be
added to late project only in planned and well coordinated manner.
Customer myths(Imagination’s):

A general statement of objectives is sufficient to begin writing

programs , we can fill in the details later.
Reality: The detailed description of information domain ,function, behaviour,
interface, data base constraints can be determined only after communication
between developer and customer.

Project requirements continually change, but change can be easily

accommodated , because software is flexible.
Reality: The software can accommodated the requirements changes requested
by the customer but it would be cost effective i.e.
The requirements changes requested at the earliest software development ,the
cost to change would be low.
The requirements changes requested during design and
implementation(coding)stage the cost to change would be high.
The requirements changes requested after software in production the cost to
change would be very high
Practitioner's myths(Imaginations):

Once we write the program and get it to work, our job is done.
Reality: No, the practitionaer’s should also provide maintenance of the software

Until I get the program running. I have no way of accessing its quality.
Reality:There are certain software quality measures called software quality metrics
such as formal technical(software usage) review to evaluate the quality of the software.
how much of quality that software has. That means how many no.of users use that
software. If more numbered users use the software then that software has high
quality(software has minimum no.of errors so software can be functioning or working
properly to meet the user requirements satisfaction).

The only deliverable work product for a successful project is the working
program.
Reality:The practioner’s not only produce work product(working program) and also
provide a documentation support for software usage and their operation.

Software will make to create voluminous and unnecessary documentation and

will invariably slow us down.
Reality: Documentation is only the part of software development. Software
development is about the quality, the quality reduces the work, the reduced work
results in faster deliverables.
 How do we define a Software Engineering?

We define
Software Engineering is the application of engineering to software. it is
the application of a systematic, discipline and quantifiable approach to
the development, operation and maintenance/support of software .
 Software Engineering Phases

The work associated with software engineering can be categorized into 3

generic phases.

1.Software Definition phase

2. Software Development phase

3. Software Evaluation phase

 1.Software Definition phase

1.The definition phase focuses on what :

that is during definition, the software engineer attempts to identify

What type of data to be processed by programs?

What functions are implemented by programs?

What algorithms are used by programs?

What performance is expected from programs?

What behaviour is expected from programs?

What type of interfaces are to be established by programs?

What type of validation(testing) criteria used by programs?

 2. Software Development phase

2.The development phase focus on how:

that is during development, a software engineer attempts to define

How data are to be structured ?

How functions are to be implemented?

How algorithms are to be implemented?

.
How interfaces are to be characterized?

How the design will be translated into a programming languages?

How testing will be performed?

 3.Software Evaluation phase

3.The maintenance/support phase focuses on the software evaluation:

The software undoubtedly undergo changes after it is delivered to the

customer(a possible exception is embedded software).change will occur because
errors have been encountered, because software must be adapted to
accommodate changes in external environment(e.g., a change required because
of a new OS or peripheral device)or because the customer requires functional or
performance enhancements.
Software Engineering Practice
The essence of problem solving is the essence of software engineering practice

1. Understand the problem(communication)

2. Prepare Plan a Solution(planning)

3. Carryout the plan(Modelling &construction)

4. Examining the output Results for efficiency(deployment)

1. Understand the problem(Customer Communication)

Answering the following questions:

a software engineer attempts to define

1. Who are the stake holders(customers, users) in the solution to the problem?

2. What data, function(or task) and features are required to properly solve the
problem?

3. Can problems be compartmentalized?

4. Is it possible to represent smaller problems that may be easier to understand?

5. Can the problems be represented graphically?

6. Can an analysis model be created?

 2.Prepare Plan a Solution(planning)
Now you understand the problem as you think, you can’t wait to begin coding.
Before you do ,slow down little a bit and do design.

Answer the following questions:

a software engineer attempts to identify

1. Have you seen similar problems before? Is there existing software that implements
the data, function and features that are required?

2. Has a similar problems been solved? If so, are the elements of the solution
reusable?

3. Can sub problems be defined? if so, are solutions readily for the sub problems?

4. Can you represent a solution in a manner that leads to an effective implementation?

5. Can a design model be created?

 3.Carryout the plan((Modelling &construction)

The design you have created as a road map for the software system you
want to build.

Answer the following questions:

a software engineer attempts to define

1. Does the solution to confirm the design a plan?

2. Is source code traceable to the design model?

3. Is each component part of the solution provably correct?

 4.Examining the output Results for efficiency(deployment)

You can’t sure that your solution is perfect but you can designed a sufficient
number of tests to uncover as many errors as possible.

Answer the following questions:

a software engineer attempts to define

1. Is it possible to teach each component part of the solution?

2. Has a reasonable testing strategy(black box, white box) been implemented?

3. Does the solution produce the results that conform the data, function and
features that are required?

4. Has the developed or designed or created software been validated(tested)

against all stakeholders(customers, users) requirements?
SOFTWARE ENGINEERING /SOFTWARE DEVELOPMENT
TERMINOLOGY

Problem or problem domain for Software Engineering/software development :

Is Industrial Strength Software that solves some problem of some set of users or
clients or customers and is expected to be a high quality and high productivity.
The cost, schedule, and quality are the basic driving forces for this problem or
problem domain.

A project or a software project is one instance( means one example) of

industrial strength software. That is a project or software project is an
industrial strength software.

A software product is the outcome of the project or software project .

A work product is the outcome of the software process(set of processes).

 process
A process is a sequence of steps or phases or stages or activities executed to develop a
high quality, low cost, low cycle time software project. The software project is to satisfy
the needs of users or clients or customers or stake holders.

satisfies

User/client/ step1 ....... Step n

customer/ Software outcome Software
stake holder .... project product
needs sequence of steps
input called process output
 Sub process

Sub process: A process is a sequence of stages. The sequence of steps for each stage is the
process for that stage and is referred to as a sub process of the process used to develop a
high quality, low cost, low cycle time software project. The software project is to satisfy
the needs of users or clients or customers or stake holders.
satisfies

User/client/ stage 1 .......... Stage n. outcome

customer/ Software Software
stake holder project product
needs
input sequence of steps ........ Sequence of steps output

called sub process

 s/w Project s/w Process s/w project
management improvement development
process process process

Software
configuration outcome Work
non Software
management Software
process product
Development
process
process

Used by

satisfies

Needs of Software software

Taken into Outcome or
Product
Client or Project Release s/w
user or Development project
customer or Out put
stake holder Data
base hardware
Used by
Input people
Software
Resources
network Technology or
programming
Process, project and product relationship in Software project development language
 Software Process
A Software Process is a set of processes including a software project development
process(which is a set of activities, work products, actions, work tasks ) and a non
software development process Called umbrella process(s/w management process) used to
develop a software project.
Software process

Non- Software project development process or

Software project project management process
development process (called umbrella activities)

s/w Process Project s/w configuration

improvement management management process
process(s/w quality) process (s/w maintenance)

Project Project Project Project

schedule Project
Budget Quality Risks
(constraint) (constraint) (constraint) Resources
Software process Activities or stages or Work products Actions Work tasks
phases (SDLC) (outcome or output)
Software 1.Communication User Requirements report 1.Coordination 1. Make contact with
project 2.Communication stakeholder via
development 2.Planning Project Plan Report 3. Feedback telephone.
process 4.Reusability
3.Medelling : 2. Discuss
3.1.Analysis Feasibility report requirements and
(Requirements Software Data analysis models take notes.
Engineering) Called conceptual or logical
models such as 3. Organize notes into
DFD,ERD,STD,DD. a brief written
SRS Document statement of
requirements.
3.2.Design Software Architecture design
Software Interface design 4. Prioritize the
Software component(or class) requirements.
design
4.construction: Data base design 5. E-mail to stakeholder
for review and
4.1.Coding Program codes document approval.

4.2.Testing Test reports document

5.Deployment Installation guide

(installation) Defect or bug report(feedback)
Requirements to change
(maintenance)
6..Production(release):
6.1 operation& Error report(feedback)
maintenance Requirements to change
(maintenance)
Software Activities Work Actions Work tasks
process products
(outcome or
output)
Project 1.Initiating 1.Project budget Project manager do 1. Make contact with
management 2.Planning 2.Project schedule 1.Design project team stakeholder via
Process 3.Coordinating 3.Project quality 2.Allocate the tasks telephone.
4.Controlling 4.Project team risk 3.Monitor the progress 2. Discuss
5.Executing 5. Project contracts of project team members requirements and
6.Terminating take notes.
3. Organize notes into
a brief written
statement of
requirements.
4. Prioritize the
requirements.
5. E-mail to stakeholder
for review and
approval.
Software Activities for Work Actions Work tasks
process performing products
changes in the (outcome or
software output)
Project 1.Identification of 1.Reduce 1.Identifying changes 1. Make contact with
Configuration configuration items development cost stakeholder via
(change) 2.Evaluating changes telephone.
management 2.Device mechanisms 2.Enhance product
Process called quality 3 Implementing changes 2. Discuss
maintenance of for performing in the main function requirements and
software in changes 3.Enchance take notes.
SDLC. Product Integrity
3.Tracking the status 3. Organize notes into
of those changes a brief written
statement of
requirements.

4. Prioritize the
requirements.

5. E-mail to stakeholder
for review and
approval.
 SOFTWARE QUALITY ASSURANCE(SQA):
Software Process Assessment and Improvement process for software quality.
A number of different approaches to process assessment and improvement process
for software quality have been proposed over past few decades.

1. SCAMPI-Standard CMMI Assessment Method for Process Improvement:

It provides a five-step process assessment model that includes five phases:
initiating, diagnosing, establishing, acting, and learning.

2. CBA-IPI-CMM Based Appraisal for Internal Process Improvement:

provides a diagnostic technique for assessing the relative maturity of a software
organization uses the SEI CMM as the basis for the assessment.

3. SPICE(ISO/IEC 15504)
A standard that defines a set of requirements for software process assessment.

4. ISO 9001:2000 for Software: A generic standard that applies to any organization
that wants to improve the overall quality of the products, systems, or services
that it provides. Therefore, the standard is directly applicable to software
organizations and companies.
 The Five Software Project Development Activities Called SDLC-software
development life cycle. Also called a phased development life cycle

1.Communication. By collaborating with stakeholders, business requirements are

gathered &identified for software project development.
2.Planning. In Planning, A project plan must be prepared. It includes the following

Estimate the software project size in terms of KLOC(Kilo Lines of Code).

Estimate the software project cost by using LOC(Lines of Codes), FPA(function

point analysis),COCOMO(Constructive Cost Model)

 Assessment of the Software Project Risks by using RMMM(Risk Mitigation

Monitor and Management)

Evaluate the software project quality by SQA(Software Quality Assurance) with

standards like ISO 9001:2000.

Define the software project schedules of milestones(work products) for Software

project tracking(monitoring) and controlling activities for completion of software
project within a budget.

Identify Resources(like people, hardware, software, network, database software

technology (programming languages),user interfaces, etc..)for software project
development.
3.Modeling: It includes Analysis(Requirements Engineering) and Design.

What should we do in requirements analysis ?

In analysis,
we should do Requirements Engineering. It is the process of
 understanding the business requirements identified in communication with stake holder.
 Defining what services are expected from software project.
 and, Identifying the constraints(budget, schedule, and quality) on software project
development.

There are 4 activities in Requirements Engineering

1.Feasibility Study: It consider,
 An estimate is made of whether identified user needs may be satisfied with current
software technology and hardware technology.
 Whether proposed software project will be cost effective from business point of
view
 And if software project can be developed within existing budgetary constraint.
2.Requirements elicitation and analysis:
This is the process of deriving the software project requirements through
• Observation of existing software system.
• Development of one or more data analysis models(DFD,ERD,State-Transistion,DD)
3.Requirements Specification: It is the activity of translating the information gathered during requirements
engineering of analysis activity into a document(SRS) that defines set of requirements. Two types of
requirements may be included in this document.
User requirements are the abstract statements of software project requirements for end user or customer.
Software project requirements are the detailed description
of the functionality to be provided

Requirement document-SRS
4 Requirements validation: This activity checks the requirements for realism,
consistency, and completeness.

The Requirements Engineering Process or Requirements analysis:

 DESIGN PROCESS(Activity of Modelling)

A software design is a description of the structure of the software project to

be implemented(executed software project).
An abstract model of this design process showing the inputs to the design
process, design process activities, and the documents produced as outputs from
this design process.
 Design Input: The Software Platform
The software project interfaces with other software systems.
These include the operating system, database, Middleware is software which lies
between an operating system and the applications running on it. ...
Common middleware examples include database middleware, application
server middleware, message-oriented middleware, web middleware and
transaction-processing monitors.) and other application systems. These make up
the ‘software platform’, the environment in which the software project will
execute. Information about this platform is an essential input to the design
process, as designers must decide how best to integrate it with the software’s
environment.

Design Input: The requirements specification

The requirements specification is a description of the functionality the software
project must provide and its performance and dependability requirements.

Design Input: The data description

If the software project system is to process existing database data , then the
description of that data may be included in the platform specification; otherwise,
the data description must be an input to the design process so that the software
project data organization in the database (b-trees or b+-trees)to be defined.
Four activities that may be part of the design process for
software project development:
Four activities that may be part of the design process for software project
development:

1. Architectural design, where you identify the overall structure of the system, the principal
components (sometimes called sub-systems or modules), their relationships, and how they are
distributed.

2. Interface design, where you define the interfaces between system components.
This interface specification must be unambiguous. With a precise interface, a component can be
used without other components having to know how it is implemented. Once interface
specifications are agreed, the components can be designed and developed concurrently.
3. Component design, where you take each system component and design how it will operate.
This may be a simple statement of the expected functionality to be implemented, with the specific
design left to the programmer. Alternatively, it may be a list of changes to be made to a reusable
component or a detailed design model. The design model may be used to automatically generate
an implementation.

4. Database design, where you design the system data structures and how these are to be
represented in a database. Again, the work here depends on whether an existing database is to be
reused or a new database is to be created.
4.Construction(coding and Testing).

This activity combines code generation (either manual or automated) and the testing
that is required to uncover errors in the code.

Programming is a personal activity and there is no general process that is usually

followed. Some programmers start coding with components that they
understand, develop these, and then move on to less-understood components.
 The testing is a process that is required to uncover errors in the code.

The fig. Shows a 3-stages(levels) testing process .

The system components are tested(called component testing) then the integrated
system is tested (called system testing)and, finally, the system is tested with the
customer’s data(called acceptance testing). The testing process is an iterative one
with information being fed back from later stages to earlier parts of the process.

Acceptance testing is sometimes called ‘alpha testing’. Custom software project is

developed for a single client/customer/user/stakeholder. The alpha testing process
continues until the system developer and the client agree that the delivered system is an
acceptable implementation of the requirements.
 Deployment(installation):
The alpha-tested Software project is given to end users for beta testing and user
feedback reports both defects (errors)and necessary changes. In addition, the
software team creates the necessary support information (e.g., user manuals,
troubleshooting guides, installation procedures) that is required for the released
software project as software product.

Production phase(operation(use)&maintenance):
The production phase coincides with the deployment activity of the Software project
development process. During this phase, the ongoing use(operation) of the software
product is monitored, support for the operating environment (infrastructure) is
provided, and defect reports and requests for changes are submitted and evaluated.
The Five Software Project Development Activities Called SDLC-software
development life cycle. Also called a phased development life cycle
 The Five Software Project Development Activities Called SDLC-software
development life cycle. Also called a phased development life cycle
1.communication 2.planning

Collect user or Estimate Project size in KLOC

customer or Estimate Project cost by COCOMO
Stakeholder Handle Project risks by RMMM
requirements Identify Project Resource
Establish Project Schedules

3.Modelling 4.Construction
Analysis-Conceptual (or logical ) Design-physical
design Modelling by data analysis design modelling by Code Test
models called structured models UML Diagrams for
such as
Architectural Writing
DFD Interface Program
ERD Database
codes
STD Component
or Class design
DD by algorithm

Delivery software product to

customers sites for β-acceptance
5.Deployment testing by installation
Take Customer Feedback
 Process Models

A process is a sequence of steps or phases or stages or activities executed to develop a

high quality ,low cost, low cycle time software project(industrial strength software).

Process model provides(gives) a process structure that is well suited for a class of
projects or software project(industrial strength software).

Software project development process models are

1.Generic process models
2.Prescriptive process models
3.Specilized process models
4.Unified process (RUP-Rational unified process ) model
5.Personal and Team process model
6. Automated process model(process technology tool-CAD)
Generic (Software Project Development )Process Models

1.A Linear process flow(work flow) model

2. An Iterative process flow(work flow) model

3. An Evolutionary process flow(work flow) model

4. A Parallel process flow(work flow) model

 1. A Linear process flow(work flow) model:

A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment

A linear process flow

2. An Iterative process flow(work flow) model

An iterative process flow repeats one or more of the activities before proceeding to
the next.

An iterative process flow

 3. An Evolutionary process flow(work flow) model

An evolutionary process flow executes the activities in a “circular”

manner. Each circuit through the five activities leads to a more complete
version of the software

An evolutionary process flow

 4. A Parallel process flow(work flow) model

A parallel process flow executes one or more activities in parallel with other
activities (e.g., modelling for one aspect of the software might be executed in
parallel with construction of another aspect of the software).

A parallel process flow

 Prescriptive Process Models

Non Evolutionary An Evolutionary

Process Models
Process Model

An Incremental An Iterative
Water fall Prototype A Spiral Process
Process Model l
Process Model Process
Model
Model

1. A non evolutionary Process Model:

1.1 A Water fall Process Model or A Classical Waterfall Process Model
2. An Evolutionary Process Models
2.1 An Incremental Process Model
2.2 An Iterative Prototype Process Model
2.3 A Spiral Process Model
Water Fall Process Model or Classical Life Cycle Process Model
or linear process model

Water Fall Process Model

Water Fall Process Model:
It is also known as linear sequential software development process model
It is also known as classical life cycle software development process model.

Advantages of classical water fall model:

1.It is a simple and straightforward approach(or method) and divides the large
complex task of building software into a series of divided phases or stages or
activities that are organized in a linear sequential order(one after another).

2.It is easy to administrates as each phase or each stage or each activity of software
development is completed and its work product (the outcome of each phase or stage
or activity of software development)is produced, some amount of money is given
by customer to development organization.
Applications of classical water fall model:
1.It has been the most widely used software development model.
2.It is well suited for routine types of projects where the requirements
are well understood.

Limitations of classical waterfall software development process model:

1.It assumes that the requirements of a system can be frozen before the design begins.
2.It follows “big bang” approach – the entire software is delivered in one shot at the
end.
This is heavy risk, as the users don not know until the very end what they are getting.
if the project runs out of money in the middle, then there will be no software. that is it
has the’ all or nothing value’ proposition.
3.It is document driven process that requires formal documents at the end of each phase.
The incremental model combines elements of linear and parallel process flows.
The incremental model applies linear sequences in a staggered fashion as calendar
time progresses. Each linear sequence produces deliverable “increments” of the
software in a manner that is similar to the increments produced by an evolutionary
process flow.
For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
production functions in the first increment;

more sophisticated editing and document production capabilities in the

second increment;

spelling and grammar checking in the third increment;

and advanced page layout capability in the fourth increment.

It should be noted that the process flow for any increment can incorporate the
prototyping paradigm.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed but many supplementary features (some known, others
unknown) remain undelivered. The core product is used by the customer(or undergoes detailed
evaluation). As a result of use and/or evaluation a plan is developed for the next increment. The
plan addresses the modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality. This process is repeated following the
delivery of each increment, until the complete product is produced.

The incremental process model focuses on the delivery of an operational product with each
increment. Early increments are stripped-down versions of the final product, but they do
provide capability that serves the user and also provide a platform for evaluation by the user.

Incremental development is particularly useful when staffing is unavailable for a complete

implementation of the project. Early increments can be implemented with fewer people. If the
core product is well received, then additional staff (if required) can be added to implement the
next increment.
An iterative prototyping paradigm(process model)
The prototyping paradigm (process model) begins with communication. You meet with
other stakeholders to identify whatever requirements are known. A prototyping
iteration is planned quickly, and modelling (in the form of a “quick design”) occurs. A
quick design focuses on a representation of those aspects of the software that will be
visible to end users (e.g., human interface layout or output display formats). The quick
design leads to the construction of a prototype. The prototype is deployed and
evaluated by stakeholders, who provide feedback that is used to further refine
requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various
stakeholders, while at the same time enabling you to better understand what needs to
be done.
When a customer does not identify detailed requirements for functions and
features.
In other cases, when the developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system.
In these, and many other situations, a prototyping paradigm may offer the best
approach.

the prototyping paradigm(process model) assists you and other stakeholders

to better understand what is to be built(develop) when requirements are
fuzzy(not clear).

prototyping can be used as a stand-alone process model,

 Boehm’s spiral model

The Spiral Model. Originally proposed by Barry Boehm [Boe88/1988],

The spiral model is an evolutionary software process model that combines
the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model. It provides the rapid development of
increasingly more complete versions of the software.

Using the spiral model, software is developed in a series of evolutionary

releases.

During early iterations, the release might be a model or prototype.

During later iterations, increasingly more complete versions of the
engineered system are produced.
Spiral process model has a feature called Anchor point milestones—a
combination of work products and conditions that are attained along the path of
the spiral—are noted for each evolutionary pass.

The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more advanced versions of the software. Each
pass through the planning region results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback derived from the customer after
delivery. In addition, the project manager adjusts the planned number of
iterations required to complete the software.
Unlike other process models that end when software is delivered,
the spiral model can be adapted to apply throughout the life of the
computer software.
Rational Unified Process model(RUP)
The inception phase of the UP encompasses both customer communication and
planning activities. By collaborating with stakeholders, business requirements for
the software are identified; a rough architecture for the system is proposed; and a
plan for the iterative, incremental nature of the ensuring project is developed.

Planning identifies resources, assesses major risks, defines a schedule, and

establishes a basis for the phases that are to be applied as
the software increment is developed.
The elaboration phase have the planning and modelling activities of the
generic process model . Elaboration refines and expands the preliminary use
cases that were developed as part of the inception phase and expands the
architectural representation to include five different views of the software—
the use case model, the requirements model, the design model, the
implementation model, and the deployment model.
The construction phase of the UP is identical to the construction activity
defined for the generic software process.
All necessary and required features and functions for the software
increment (i.e., the release) are then implemented in source code. As
components are being implemented, unit tests are designed and
executed for each. In addition, integration activities (component assembly
and integration testing) are conducted. Use cases are used to derive a suite
of acceptance tests that are executed prior to the initiation of the next UP
phase.
The transition phase of the UP encompasses the latter stages of the generic
construction activity and the first part of the generic deployment (delivery and
feedback) activity. Software is given to end users for alpha acceptance testing
and user feedback reports both defects and necessary changes. In addition, the
software team creates the necessary support information (e.g., user manuals,
troubleshooting guides, installation procedures) that is required for the
release. At the conclusion of the transition phase, the software increment
becomes a usable software release.
The production phase of the UP coincides with the deployment activity of the
generic process. During this phase, the ongoing use of the software is
monitored for beta acceptance testing , support for the operating environment
(infrastructure) is provided, and defect reports and requests for changes are
submitted and evaluated.
 PERSONAL AND TEAM PROCESS MODELS

The Personal Software Process (PSP) gives special importance on personal measurement of both the
work product that is produced and the resultant quality of the work product. In addition PSP makes
the practitioner responsible for project planning (e.g., estimating and scheduling) and empowers the
practitioner to control the quality of all software work products that are developed.
The PSP model defines five framework activities:
Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics are
recorded on worksheets or templates. Finally, development tasks are identified and a project
schedule is created.
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 tasks and work results.
Postmortem. Using the measures and metrics collected (this is a substantial amount of data that
should be analyzed statistically), the effectiveness of the process is determined. Measures and
metrics should provide guidance for modifying the process to improve its effectiveness.
Team Software Process (TSP)
The goal of TSP is to build a “self directed” project team that organizes itself to produce high-
quality software.

the following objectives for TSP:

• Build self-directed teams that plan and track their work, establish goals, and
own their processes and plans. These can be pure software teams or integrated
product teams (IPTs) of 3 to about 20 engineers.

• Show managers how to coach and motivate their teams and how to help them sustain peak
performance.

• Accelerate software process improvement by making CMM23 Level 5 behavior normal and
expected.

• Provide improvement guidance to high-maturity organizations.

• Facilitate university teaching of industrial-grade team skills.

A self-directed team has a consistent understanding of its overall goals and
objectives;

A self-directed team defines roles and responsibilities for each team member; tracks
quantitative project data (about productivity and quality).

A self-directed team identifies a team process that is appropriate for the project and a
strategy for implementing the process.

A self-directed team defines local standards that are applicable to the team’s
software engineering work.

A self-directed team continually assesses risk and reacts to it.

A self-directed team reports project status.

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
(i.e., project launch, design, implementation, integration and system testing,
postmortem) and other more detailed work functions (e.g., development
planning, requirements development, software configuration management, unit
test) that are part of the team process.

TSP recognizes that the best software teams are self-directed.Team members
set project objectives, adapt the process to meet their needs, control the project
schedule, and through measurement and analysis of the metrics collected, work
continually
to improve the team’s approach to software engineering.
 SPECIALIZED PROCESS MODELS:

The Formal Methods Model(FMM)

The formal methods model have a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify ,develop, and
verify a computer-based system by applying a rigorous, mathematical notation. A variation on
this approach, called clean room software engineering is currently applied by some software
development organizations.

Aspect-Oriented Software Development (AOSD)

When concerns cut across multiple system functions, features, and information, they are
often referred to as crosscutting concerns. Aspectual requirements define those crosscutting
concerns that have an impact across the software architecture.
Aspect-oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP), is a relatively new software engineering paradigm that provides a
process and methodological approach for defining, specifying, designing, and constructing
aspects.
 PROCESS TECHNOLOGY(automated software project development process model)

Process technology tools allow a software organization to build an

automated software project development model of the process framework
activities(communication, planning, modelling, construction, and
deployment),work products, task sets, and umbrella activities. The model
normally represented as a network, and can reduced development time or
cost.