Chapter 1: Software

Development Process
1
Chapter : Topic Covered
What is Software?
Software characteristic
Software Myths
Layered Technology
Software Process Framework
Generic Process Framework Activities
Umbrella Activities

2
What is Software ?
Software is a collection of computer
programs and related documents that
are intended to provide features,
functionalities and better performance.
3
Hardware vs. Software
Hardware Software
Manufactured
wear out
Built using components
Relatively simple
Developed/ engineered
deteriorate
Custom built
Complex
4
Software characteristics
Software is developed or engineered; it is not
manufactured.
Software does not wear out but it does
deteriorate.
Software continues to be custom built, as
industry is moving toward component based
construction.
5
Software Characteristics
1. Software is engineered, not
manufactured
Once a hardware product has been manufactured, it is
difficult or impossible to modify. In contrast, software
products are routinely modified and upgraded.
In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
Unlike hardware, software costs are concentrated in
design rather than production.

6

2. Software does not ware out.

Failure curve for Hardware
7
Failure curve for Software
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, software maintenance involves
considerably more complexity

8
3.Most s/w is custom built rather than
being assembled from components
Hardware products typically employ many
standardized design components.
Most software continues to be custom built.
The software industry does seem to be
moving (slowly) toward component-based
construction.
9
Software Myths
Definition: Beliefs about software and the process used to build it.
Myths have number of attributes that have made them insidious (i.e.
dangerous).
Misleading Attitudes - caused serious problem for managers and
technical people.
Management myths
Managers in most disciplines, are often under pressure to maintain
budgets, keep schedules on time, and improve quality.
Myth1: 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 :
Are software practitioners aware of existence standards?
Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to delivery while still
maintaining a focus on quality?
10
Myth2: If we get behind schedule, we can add more programmers and
catch up
Reality: Software development is not a mechanistic process like
manufacturing. Adding people to a late software project makes it later.
People can be added but only in a planned and well-coordinated
manner
Myth3: 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
outsource software projects

11
Customer Myths
Customer may be a person from inside or outside the company that has
requested software under contract.

Myth: A general statement of objectives is sufficient to begin writing
programs we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software
efforts. A formal and detailed description of the information domain,
function, behavior, performance, interfaces, design constraints, and
validation criteria is essential. These characteristics can be determined
only after thorough communication between customer and developer.
Myth: Project requirements continually change, but change can be
easily accommodated because software is flexible.
Reality: Customer can review requirements and recommend
modifications with relatively little impact on cost. When changes are
requested during software design, the cost impact grows rapidly. Below
mentioned figure for reference.
12
13
Practitioner's myths

Myth1: Once we write the program and get it to work, our job is
done.
Reality: Someone once said that "the sooner you begin 'writing
code', the longer it'll take you to get done." 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.
Myth2: Until I get the program "running" I have no way of
assessing its quality.
Reality: One of the most effective software quality assurance
mechanisms can be applied from the inception of a projectthe
formal technical review.
14
Myth3: 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.
Documentation provides a foundation for successful
engineering and, more important, guidance for
software support.
Myth4 : 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
quality. Better quality leads to reduced rework. And
reduced rework results in faster delivery times.

15
What is software engineering?
Definition :
(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 as
in (1) above
Its a discipline that is concerned with all aspects of software production.

Software engineers should adopt
Systematic and organized approach to their work
Use appropriate tools and techniques depending on the problem to be
solved
The development constraints and the resources available
Apply Engineering Concepts to developing Software
Challenge for Software Engineers is to produce high quality software with
finite amount of resources & within a predicted schedule
16
Software Engineering Layered
Technology
Layered Technology
A quality focus: the bedrock
Process model: the framework
Methods: technical how tos
Tools: CASE preferred
17
Layered Technology
A quality Focus
Every organization is rest on its commitment to quality.
Total quality management, Six Sigma, or similar continuous improvement culture and
it is this culture ultimately leads to development of increasingly more effective
approaches to software engineering.
The bedrock that supports software engineering is a quality focus.

Process:
Its a foundation layer for software engineering.
Its define framework for a set of key process areas (KRA) for effectively manage
and deliver quality software in a cost effective manner
The processes define the tasks to be performed and the order in which they are to be
performed
18
Methods:
It provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis,
design, program construction, testing, and support.
There could be more than one technique to perform a task and different techniques
could be used in different situations.
Tools:
Provide automated or semi-automated support for the process, methods and quality
control.
When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided
software engineering (CASE)

Layered Technology
19
Generic Process Framework Activities
Communication:
Heavy communication with customers, stakeholders, team
Encompasses requirements gathering and related activities
Planning:
Workflow that is to follow
Describe technical task, likely risk, resources will require, work products to
be produced and a work schedule.
Modeling:
Help developer and customer to understand requirements (Analysis of
requirements) & Design of software
Construction
Code generation: either manual or automated or both
Testing to uncover error in the code.
Deployment:
Delivery to the customer for evaluation
Customer provide feedback
20
Software project tracking and control
Assessing progress against the project plan.
Take adequate action to maintain schedule.
Formal technical reviews
Assessing software work products in an effort to uncover and remove errors before goes
into next action or activity.
Software quality assurance
Define and conducts the activities required to ensure software quality.
Software configuration management
Manages the effects of change.
Document preparation and production
Help to create work products such as models, documents, logs, form and list.
Reusability management
Define criteria for work product reuse
Mechanisms to achieve reusable components.
Measurement
Define and collects process, project, and product measures
Assist the team in delivering software that meets customers needs.
Risk management
Assesses risks that may effect that outcome of project or quality of product (i.e. software)

Umbrella Activities
21