UNIT-1

Software & Software Engineering

What is Software?

Software is:

(1) instructions (computer programs) that when executed provide desired features, function,
and performance;

(2) data structures that enable the programs to adequately manipulate information and

(3) documentation that describes the operation and use of the programs.

Software Characteristics
1)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.

2)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 doesn’t 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.

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

Software Applications
• 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, databasemanagement.

 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, Expertsystems, gameplaying etc.

Software—New Categories
 Open world computing—pervasive, distributed computing

 Ubiquitous computing—wireless networks

 Netsourcing—the Web as a computing engine

 Open source—”free” source code open to the computing .

Legacy Software
Why must it change?
  software must be adapted to meet the needs of new computing environments
or technology.

 software must be enhanced to implement new business requirements.

 software must be extended to make it interoperable with other more modern

systems or databases.

 software must be re-architected to make it viable within a network

environment.

What is Software Engineering ?

 Some realities:
 a concerted effort should be made to understand the problem before a software
solution is developed

 design becomes a pivotal activity

 software should exhibit high quality

 software should be maintainable

 The seminal definition:

[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real
machines.

 The IEEE definition:

Software engineeringis :

(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).
 A LAYERED TECHNOLOGY:

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-to’s for building Software. Methods encompass a broad array
of tasks that include

- Communication

- Requirements analysis

- design modeling

- Program construction

- testing

- Support

Tools:-Provide semi-automatic and automatic support to methods. When tools are integrated so
that information created byone tool can be used by another, a system for the support of software
development,called computer-aided software engineering, is established.

THE SOFTWARE PROCESS

A process is a collection of activities, actions, and tasks that are performed whensome 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.

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

framework activities
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.

These five generic framework activities can be used during the development of small,simple
programs, the creation of large Web applications, and for the engineering oflarge, complex
computer-based systems.

Software engineering process framework activities are complemented by a numberof umbrella

activities. In general, umbrella activities are applied throughout a softwareproject and help a
software team manage and control progress, quality,change, and risk.

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

Therefore, a process adopted for one project might be significantlydifferent than a process
adopted for another project. Among the differences are :

 the overall flow of activities, actions, and tasks and the interdependencies among
them

 the degree to which actions and tasks are defined within each framework activity

 the degree to which work products are identified and required

 the manner which quality assurance activities are applied

 the manner in which project tracking and control activities are applied

 the overall degree of detail and rigor with which the process is described

 the degree to which the customer and other stakeholders are involved with the
project

 the level of autonomy given to the software team

 the degree to which team organization and roles are prescribed

Software General Principles

David Hooker has Proposed seven principles that focus on software Engineering practice.

The First Principle: The Reason It All Exists

A software system exists for one reason: to provide value to its users.

The Second Principle: Keep It Simple

Software design is not a haphazard process. There are many factors to consider in anydesign
effort. All design should be as simple as possible, but no simpler.

The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project. Without one, a project
almostunfailingly ends up being “of two [or more] minds” about itself.

The Fourth Principle: What You Produce, Others Will Consume

Always specify, design, and implement knowing someone else will have to understand what you

are doing.

The Fifth Principle: Be Open to the Future

A system with a long lifetime has more value. Never design yourself into a corner.
Beforebeginning a software project, be sure the software has a business purpose and that
usersperceive value in it.

The Sixth Principle: Plan Ahead for Reuse

Reuse saves time and effort. Planning ahead for reuse reduces the cost and increases the valueof
both the reusable components and the systems into which they are incorporated.

The Seventh principle: Think!

Placing clear, complete thought before action almost always produces better results. When
youthink about something, you are more likely to do it right.

SOFTWARE MYTHS
• Propagate misinformation and confusion

• Three types of myths

- Management myth

- Customer myth

- Practitioner’s myth

MANAGEMENT MYTHS
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 doesn’t 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.