IT-DEPT

SOFTWARE ENGINEERING

UNIT- I

Unit-1

PART-A

Introduction to Software Engineering: The evolving role of software, Changing Nature of

Software, , Software myths.

INTRODUCTION TO SOFTWARE ENGINEERING :

Computer Software is the product that software Professionals build and then
support over the long term. We have to build computer software by applying an agile,
adaptable process that leads to a high quality result that meets the needs of the people who
will use the product. A framework provides for building computer software, called
Software Engineering.
THE EVOLVING ROLE OF SOFTWARE :

Today, software takes on a dual role. It is a product and, at the same time, the
vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer hardware.
Whether it resides within a cellular phone or operates inside a mainframe computer,
software is an information transformer—producing, managing, acquiring, modifying,
displaying, or transmitting information.
As the vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information (networks), and
the creation and control of other programs (software tools and environments).
The lone programmer of an earlier era has been replaced by a team of software
specialists, each focusing on one part of the technology required to deliver a complex
application. And yet, the same questions asked of the lone programmer are being asked
when modern computer-based systems are built:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all the errors before we give the software to our customers?
• Why do we spend so much time and effort for maintaining existing programs?
 • Why do we continue to have difficulty in measuring progress as software is
being developed and maintained?

These, and many other questions, are a manifestation of the concern about software and
the manner in which it is developed—a concern that has lead to the adoption of software
engineering practice.

Definitions of Software -

• Software is instructions (computer programs) that when executed provide

desired features, function and performance.
• Software is data structures that enable the programs to adequately manipulate
information.
• Software is documents that describe the operation and use of the programs.

Software Characteristics :

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

• Software doesn't "wear out"

• Although the industry is moving toward component based construction, most software
continues to be custom built.

CHANGING NATURE OF SOFTWARE :

Today, various broad categories of computer software present continuing

challenges for software engineers :
• System software - compilers, operating systems, drivers.(Interaction with hardware)

• Real-time software - monitors/analyzes/controls information from an external environment

• Business software - payroll, inventory, management information system (MIS)

• Engineering and scientific software - astronomy to volcanology, from automotive stress

analysis to space shuttle orbital dynamics, and from molecular biology to automated
manufacturing.
• Embedded software - keypad control for a microwave oven, digital functions in an
automobile such as fuel control, dashboard displays and braking systems.
• Personal computer software - Word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management, personal and business financial
applications, external network, and database access.
• Web-based software - CGI, HTML, Java

• Artificial intelligence software - Expert systems, pattern recognition (image and voice),
artificial neural networks and game playing.
• Ubiquitous computing software - Wireless networks

• Net sourcing software - Personal financial planning software

• Open Source software - Operating systems, Databases and Development environments

SOFTWARE MYTHS :

Software myths — beliefs about software and the process that is used to build it.
Myths have a number of attributes. For instance, they appear to be reasonable statements
of fact (sometimes containing elements of truth), they have an intuitive feel.
Management myths. Managers with software responsibility, are often under pressure
to maintain budgets, keep schedules from slipping, and improve quality.
Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know?
Reality: The book of standards may very well exist, but is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering
practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-
delivery while still maintaining a focus on quality? In many cases, the answer to all
of these questions is “no.”

Myth: If we get behind schedule, we can add more programmers.

Reality: Software development is not a mechanistic process like manufacturing. As

new people are added, people who were working must spend time educating the
newcomers, thereby reducing the amount of time spent on productive development
effort. People can be added but only in a planned and wellcoordinated manner.
 Myth: If I decide to outsource the software project to a third party, I can just relax
and let that firm build it.
Reality: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsources software
projects.

Customer myths. A customer who requests computer software believes myths about
software because software managers and practitioners do little to correct misinformation.
Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the
developer.

Myth: A general statement of objectives is sufficient to begin writing programs—

we can fill in the details later.
Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for disaster.
Unambiguous requirements (usually derived iteratively) are developed only
through effective and continuous communication between customer and developer.

Myth: Software requirements continually change, but change can be easily

accommodated because software is flexible.
Reality: When requirements changes are requested early (before design or code
has been started), the cost impact is relatively small. However, as time passes, the
cost impact grows rapidly—resources have been committed, a design framework
has been established, and change can require additional resources and major design
modification.

Practitioner’s myths. Myths that are still believed by software practitioners have been
fostered by over 50 years of programming culture. During the early days, programming
was viewed as an art form.

Myth: Once we write the program and get it to work, our job is done.

Reality: Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the customer for the
first time.

Myth: Until I get the program “running” I have no way of assessing its quality.

Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the technical review. Software reviews
are a “quality filter” that have been found to be more effective than testing for
finding certain classes of software defects.

Myth: The only deliverable work product for a successful project is the working
program.

Reality: A working program is only one part of a software configuration that

includes many elements. A variety of work products (e.g., models, documents,
plans) provide a foundation for successful engineering and, more important,
guidance for software support.

Myth: Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.

Reality: Software engineering is not about creating documents. It is about creating

a quality product. Better quality leads to reduced rework. And reduced rework
results in faster delivery times.

Recognition of software realities is the first step toward formulation of practical

solutions for software engineering. The intent of software engineering is to provide a
framework for building higher quality software.
Unit-1

PART-B

A Generic view of process: Software engineering- A layered technology, a process

framework, The Capability Maturity Model Integration (CMMI),

A GENERIC VIEW OF PROCESS:

SOFTWARE ENGINEERING- A LAYERED TECHNOLOGY :

Software engineering is a layered technology. Any engineering approach (including

software engineering) must rest on an organizational commitment to quality. The bedrock
that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software Process
defines a framework that must be established for effective delivery of software engineering
technology. Software process is a framework for the activities, actions, and tasks that are
required to build high-quality software.
When building a product or system, it’s important to go through a series of
predictable steps—a road map that helps to create a timely, high-quality result. The road
map that you follow is called a “software process.”
The software process forms the basis for management control of software projects
and establishes the context in which technical methods are applied, work products are
produced, milestones are established, quality is ensured, and change is properly managed.
Software engineering methods provide the technical ways for building software.
Methods encompass a broad array of tasks that include requirements analysis, design,
program construction, testing, and support.
Software engineering tools provide automated or semi-automated support for the
process and the methods. 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), is established.
A 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 software
projects, regardless of their size or complexity. In addition, the process framework
encompasses a set of umbrella activities that are applicable across the entire software
process.
Each framework activity is populated by a set of software engineering actions - a
collection of related tasks that produces a major software engineering work product (eg.,
design is a software engineering action). Each action is populated with individual work
tasks that accomplish some part of the work implied by the action.

A generic process framework for software engineering encompasses five activities :

• Communication
• Planning
• Modeling
• Construction
• Deployment

Communication. This framework

activity involves heavy communication
and collaboration with the customer and
other stakeholders that encompasses
requirements gathering and other related
activities.
Planning. This activity establishes a plan
for the software engineering work. It
describes the technical tasks to be
conducted, the risks that are likely, the
resources that will be required, the work
products to be produced, and a work
schedule.
Modeling. This activity encompasses the
creation of models that follow the
developer and the customer to better
 understand software requirements and the
design that will achieve those
requirements.

The modeling activity is composed of two software engineering actions -

• Analysis model and
• Design model.
Analysis encompasses a set of work tasks (eg. requirements gathering, elaboration,
negotiation, specification and validation). Design encompasses work tasks ( data design,
architectural design, interface design, and component-level design) that create a design
model.
Construction. This activity combines code generation (either manual or automated) and
the testing that is required to uncover errors in the code.
Deployment. The software is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.
Each software engineering action is represented by a number of different task sets -
each a collection of software engineering work tasks, related work products, quality
assurance points, and project milestones. The task set that best accommodates the needs of
the project.

These five generic framework activities can be used during the development of
small, simple programs, the creation of large Web applications, and complex computer-
based systems. The details of the software process will be quite different in each case, but
the framework activities remain the same.
In general, umbrella activities are applied throughout a software project and help a
software team to manage and control progress, quality, change, and risk.
Typical umbrella activities include:

Software project Allows the software team to assess progress against the project
tracking and control plan and take any necessary action to maintain the schedule.
Risk management Assesses risks that may affect the outcome of the project or the
quality of the product.
Software quality Defines and conducts the activities required to ensure software
assurance quality.
Technical reviews Assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next
activity.
Measurement Defines and collects process, project, and product measures that
assist the team in delivering software that meets stakeholders’
needs.
Software Manages the effects of change throughout the software process.
configuration
management
Reusability Defines criteria for work product reuse (including software
management components) and establishes mechanisms to achieve reusable
components.
Work product Encompasses the activities required to create work products such
preparation and as models, documents, logs, forms, and lists.
production

A process adopted for one project might be significantly different than a process
adopted for another project. Among the differences are
• Overall flow of activities, actions, and tasks and the
interdependencies among them
• Degree to which actions and tasks are defined within each framework activity
• Degree to which work products are identified and required.
• Manner in which quality assurance activities are applied
• Manner in which project tracking and control activities are applied
• Overall degree of detail and rigor with which the process is described
• Degree to which the customer and other stakeholders are involved with the project
• Level of autonomy given to the software team
• Degree to which team organization and roles are prescribed

When these process models are applied, the intent is to improve system quality, to
make projects more manageable, to make delivery dates and cost more predictable, and to
guide teams of software engineers as they perform the work required to build a system.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI) :

The CMMI represents a process meta-model in two different ways :
• Continuous model - Describes a process in two dimensions

Each process area ( eg. project planning or requirements management) is

formally assessed against specific goals and practices and is rated according to the
following capability levels:
 Level 0 : Incomplete - The process area (eg. requirements management) is either
not performed or does not achieve all goals and objectives defined by the CMMI for level
1 capability.
Level 1 : Performed - All of the specific goals of the process area have been
satisfied. Work tasks required to produce defined work products are being conducted.
Level 2 : Managed - All level 1 criteria have been satisfied. In addition, all work
associated with the process area conforms to an organizationally defined policy; all people
doing the work have access to adequate resources to get the job done; stakeholders are
actively involved in the process area as required; all work tasks and work products are
"monitored, controlled, and reviewed; and are evaluated for adherence to the process
description".
Level 3 : Defined - All level 2 criteria have been achieved. In addition, the process
is "tailored from the organization's set of standard processes according to the organization's
tailoring guidelines, and contributes work products, measures, and other process
improvement information to the organizational process assets".
Level 4 : Quantitatively managed - All level 3 criteria have been achieved. In
addition, the process area is controlled and improved using measurement and quantitative
assessment. " Quantitative objectives for quality and process performance are established
and used as criteria and used as criteria in managing the process".

Level 5 : Optimized - All capability level 4 criteria have been achieved. In

addition, the process area is adapted and optimized using quantitative means to meet
changing customer needs and to continually improve the efficacy of the process area under
consideration".
The CMMI defines each process area interms of "specific goals" and the "specific
practices" required to achieve these goals.
Specific goals establish the characteristics and specific practices refine a goal into a
set of process - related activities. For example, project planning is one of eight process
areas defines by the CMMI for the "project management" category.
The specific goals(SG) and the associated specific practices (SP) defined for
project planning are :
SG - I Establish estimates
SP 1.1 - 1 Estimate the scope of the project
SP 1.2 - 1 Establish estimates of work product and task
attributes SP 1.3 - 1 Define project life cycle
SP 1.4 - 1 Determine estimates of effort and cost
SG - 2 Develop a Project Plan
 SP 2.1 - 1 Establish the budget and
schedule SP 2.2 - 1 Identify project risks
SP 2.3 - 1 Plan for data
management SP 2.4 - 1 Plan for
project resources
SP 2.5 - 1 Plan for needed knowledge and
skills SP 2.6 - 1 Plan stakeholder
involvement
SP 2.7 - 1 Establish the project plan
SG 3 Obtain commitment to the plan
SP 3.1 - 1 Review plans that affect the
project SP 3.2 - 1 Reconcile work and
resource levels SP 3.3 - 1 Obtain plan
commitment
In addition to specific goals and practices, the CMMI also defines a set of five
generic goals and related practices for each process area. Each of the five generic goals
corresponds to one of the five capability levels. Hence, to achieve a particular capability
level, the generic goal for that level and the generic practices that correspond to that goal
must be achieved. To illustrate, the generic goals (CG) and practices (GP) for the project
planning process area are :
GG 1 Achieve specific goals
GP 1.1 Perform base practices
GG 2 Institutionalize a managed process
GP 2.1 Establish an organizational
policy GP 2.2 Plan the process
GP 2.3 Provide resources
GP 2.4 Assign
responsibility GP 2.5
Train people
GP 2.6 Manage configurations
GP 2.7 Identify and involve relevant
stakeholders GP 2.8 Monitor and control the
process
GP 2.9 Objectively evaluate adherence
GP 2.10 Review status with higher level management

GG 3 Institutionalize a defined process

GP 3.1 Establish a defined process
GP 3.2 Collect improvement information
GG 4 Institutionalize a quantitatively managed process
GP 4.1 Establish quantitative objectives for the
process GP 4.2 Stabilize sub process performance
GG 5 Institutionalize an optimizing process
GP 5.1 Ensure continuous process
improvement GP 5.2 Correct root causes of
problems

• Staged CMMI model

 The staged model defines five maturity levels, rather than five capability levels. To
achieve a maturity level, the specific goals and practices associated with a set of process
areas must be achieved. The relationship between maturity levels and process areas is
shown in fig.

Unit-1

PART-C

PROCESS MODELS :
Each framework activity have a set of software engineering actions, and each
action define a task set that identifies the work and work products to be accomplished to
meet the development goals. The work products are the programs, documents, and data
that are produced as a consequence of the activities and tasks defined by the process.
Each process model prescribes a process flow (also called a work flow)—that is,
the manner in which the process elements are interrelated to one another.

THE WATERFALL MODEL :

The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modeling, construction, and deployment.
The waterfall model is the oldest paradigm for software engineering. However,
over the past three decades, criticism of this process model has caused even ardent
supporters to question its efficacy. Among the problems that are sometimes encountered
when the waterfall model is applied are:
• Real time projects rarely follow the sequential flow that the model proposes. Although
the linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
• It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty in accommodating the natural uncertainty that exists
at the beginning of many projects.
• The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.
Some project team members must wait for other members of the team to complete
dependent tasks. In fact, the time spent waiting can exceed the time spent on productive
work. Today, software work is fast-paced and subject to a never-ending stream of changes
(to features, functions, and information content). The waterfall model is often
inappropriate for such work. However, it can serve as a useful process model in situations
where requirements are fixed and work is to proceed to completion in a linear manner.

• SPIRAM MODEL :

The spiral model is an evolutionary software process model that couples the
iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model. It provides the potential for rapid development of increasingly more complete
versions of the software.
The spiral development model is a risk-driven process model generator that is used
to guide multi-stakeholder concurrent engineering of software intensive systems. It has
two main distinguishing features. One is a cyclic approach for incrementally growing a
system’s degree of definition and implementation while decreasing its degree of risk. The
other is a set of anchor point milestones for ensuring stakeholder commitment to feasible
and mutually satisfactory system solutions.
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.
A spiral model is divided into a set of framework activities defined by the software
engineering team. 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 sophisticated 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.
 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. Therefore, the first
circuit around the spiral might represent a “concept development project” that starts at the
core of the spiral and continues for multiple iterations until concept development is
complete. If the concept is to be developed into an actual product, the 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
the spiral might be used to represent a “product enhancement project.” In essence, the
spiral, when characterized in this way, remains operative until the software is retired. There
are times when the process is dormant, but whenever a change is initiated, the process
starts at the appropriate entry point (e.g., product enhancement).
The spiral model is a realistic approach to the development of large-scale systems
and software. The spiral model demands a direct consideration of technical risks at all
stages of the project and, if properly applied, should reduce risks before they become
problematic.
Evolutionary software processes do not establish the maximum speed of the
evolution. If the evolutions occur too fast, without a period of relaxation, it is certain that
the process will fall into chaos. On the other hand if the speed is too slow then productivity
could be affected .