UNIT- I

Software is
Instructions (computer programs) that provide desired features, function, and performance, when
executed
Data structures that enable the programs to adequately manipulate information,
Documents that describe the operation and use of the programs.

Characteristics of Software:
Software is developed or engineered; it is not manufactured in the classical sense.
Software does not ―wear out‖
Although the industry is moving toward component-based construction, most software continues
to be custom built.

Software Engineering:
The systematic, disciplined quantifiable approach to the development, operation and maintenance
of software; that is, the application of engineering to software.
The study of approaches as in (1)

EVOLVING ROLE OF SOFTWARE:

Software takes dual role. It is both a product and a vehicle for delivering a product.
As a product: It delivers the computing potential embodied by computer Hardware or bya
network of computers.
As a vehicle: It is information transformer-producing, managing, acquiring, modifying,
displaying, or transmitting information that can be as simple as single bit or as complex as a multimedia
presentation. Software delivers the most important product of our time-information.
It transforms personal data
It manages business information to enhance competitiveness
It provides a gateway to worldwide information networks
It provides the means for acquiring information

The role of computer software has undergone significant change over a span of little more than 50 years
Dramatic Improvements in hardware performance
Vast increases in memory and storage capacity
A wide variety of exotic input and output options

Today a huge software industry has become a dominant factor in the economies of the industrialized world.

THE CHANGING NATURE OF SOFTWARE:

The 7 broad categories of computer software present continuing challenges for software engineers:
System software
Application software
Engineering/scientific software
Embedded software
Product-line software
Web-applications
Artificial intelligence software.
System software: System software is a collection of programs written to service other
programs. The systems software is characterized by
Heavy interaction with computer
hardwareheavy usage by multiple users
Concurrent operation that requires scheduling, resource sharing, and sophisticated
process management
complex data structures
multiple external interfaces
E.g. compilers, editors and file management utilities.
  Application software:
Application software consists of standalone programs that solve a specific business need.
It facilitates business operations or management/technical decision making.
It is used to control business functions in real-time
E.g. point-of-sale transaction processing, real-time manufacturing process control.

 Engineering/Scientific software: Engineering and scientific applications range

- from astronomy to volcano logy

- from automotive stress analysis to space shuttle orbital dynamics
- from molecular biology to automated manufacturing
E.g. computer aided design, system simulation and other interactive applications.

 Embedded software:
Embedded software resides within a product or system and is used to implement
and control features and functions for the end-user and for the system itself.
It can perform limited and esoteric functions or provide significant function and
control capability.
E.g. Digital functions in automobile, dashboard displays, braking systems etc., washing machines etc.,

 Product-line software: Designed to provide a specific capability for use by many different
customers, product-line software can focus on a limited and esoteric market place or address
mass consumer markets
E.g. Word processing, spreadsheets, computer graphics, multimedia, entertainment,
database management, personal and business financial applications
 Web-applications: WebApps are evolving into sophisticated computing environments that
not only provide standalone features, computing functions, and content to the end user, but
also are integrated with corporate databases and business applications.
 Artificial intelligence software: AI software makes use of nonnumerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis.
Application within this area includes robotics, expert systems, pattern recognition, artificial
neural networks, theorem proving, and game playing.

The following are the new challenges on the horizon:

 Ubiquitous
 computing
 Net sourcing
 Open source

The ―new economy‖

Ubiquitous computing: The challenge for software engineers will be to develop systems and application
software that will allow small devices, personal computers and enterprise system to communicate across
vast networks.
Net sourcing: The challenge for software engineers is to architect simple and sophisticated applications
that provide benefit to targeted end-user market worldwide.
Open Source: The challenge for software engineers is to build source that is self descriptive but more
importantly to develop techniques that will enable both customers and developers to know what changes
have been made and how those changes manifest themselves within the software.
The ―new economy‖: The challenge for software engineers is to build applications that will facilitate mass
communication and mass product distribution.
SOFTWARE MYTHS

Beliefs about software and the process used to build it- can be traced to the earliest days of computing
myths have a number of attributes that have made them insidious.
Management myths: Manages with software responsibility, like managers in most disciplines, 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 - 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? Does it reflect modern software engineering practice?
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Software development is not a mechanistic process like manufacturing. As new people are added,
people who were working must spend time educating the new comers, thereby reducing the amount of time
spend on productive development effort. People can be added but only in a planned and well coordinated
manner.
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm built 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: The customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false expectations and ultimately,
dissatisfaction with the developer.

Myth: A general statement of objectives is sufficient to begin with 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 recipe for disaster.

Myth: Project requirements continually change, but change can be easily accommodated because software
is flexible.

Reality: It is true that software requirements change, but the impact of change varies with the time at which
it is introduced and change can cause upheaval that requires additional resources and major design
modification.

Practitioner’s myths: Myths that are still believed by software practitioners: during the early days of
software, programming was viewed as an art from old ways and attitudes die hard.

Myth: Once we write the program and get it to work, our jobs are 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.

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.
Documentation provides guidance for software support.

Myth: software engineering will make us create voluminous and unnecessary documentation and will
invariably slows 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.
A GENERIC VIEW OF PROCESS

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY:

Tools

Methods

Process

A quality focus

Software Engineering Layers

Software engineering is a layered technology. Any engineering approach 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 engineering process is the glue that
holds the technology layers. Process defines a framework that must be established for effective
delivery of software engineering technology.

The software 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 rely on a set of basic principles that govern area of the technology and
include modeling activities.

Methods encompass a broad array of tasks that include

communication,
requirements analysis,
design modeling,
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, is established.

A PROCESS FRAMEWORK:

Software process must be established for effective delivery of software engineering technology.
A process framework establishes the foundation for a complete software process by identifying a
Small l number of framework activities that are applicable to all software projects, regardless of
their size or complexity.

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

In brief
"A process defines who is doing what, when, and how to reach a certain goal."

A Process Framework
Establishes the foundation for a complete software process identifies a small
number of framework activities applies to all s/w projects, regardless of
Size / Complexity. Also, set of umbrella activities applicable across entire
s/w process.
Each framework activity has set of s/w engineering actions.
Each s/w engineering action (e.g., design) has
 - collection of related tasks (called task sets):

work tasks

Work products

(deliverables)quality

assurance points project

milestones.
Software process

Process framework
Umbrella activities
Framework activity #1

Software engineering action Work tasks

Work products
Task sets Quality assurance points
Project milestones

Work tasks
Task sets
Software engineering action Work products
Quality assurance points
Project milestones

Framework activity #n
Software engineering action
Work tasks
Work products
Task sets Quality assurance points
Project milestones

Work tasks
Work products
Software engineering action Quality assurance points
Project milestones

Page 6
SOFTWARE ENGINEERING

Generic Process Framework: It is applicable to the vast majority of software projects

Communication activity
Planning activity
modeling activity
Analysis action
Requirements gathering work
task elaboration work task
Negotiation work task
specification work task
validation work task
Design action
Data design work task
architectural design work task
interface design work task
component-level design work task
Construction activity
Deployment activity

Communication: This framework activity involves heavy communication and collaboration with
the customer and encompasses requirements gathering and other related activities.
Planning: This activity establishes a plan for the software engineering work that follows. 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 allow the developer and
customer to better understand software requirements and the design that will achieve those
requirements. The modeling activity is composed of 2 software engineering actions- analysis and
design.
Analysis encompasses a set of work tasks.
Design encompasses work tasks that create a design model.
Construction: This activity combines core generation and the testing that is required for
uncovering the errors in the code.
Deployment: The software is delivered to the customer who evaluates the delivered product and
provides feedback based on the evolution.
These 5 generic framework activities can be used during the development of small programs, the
creation of large web applications, and for the engineering of large, complex computer-based systems.

The following are the set of Umbrella Activities.

Software project tracking and control – allows the software team to assess progress against
the project plan and take necessary action to maintain schedule.
Risk Management - assesses risks that may affect the outcome of the project or the quality of
the product.
Software Quality Assurance - defines and conducts the activities required to ensure
software quality.
Formal Technical Reviews - assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next action or activity.

Page 7
SOFTWARE ENGINEERING

Measurement - define and collects process, project and product measures that assist the team in
delivering software that needs customer‘s needs, can be used in conjunction with all other
framework and umbrella activities.

Software configuration management - manages the effects of change throughout the software
process.

Reusability management - defines criteria for work product reuse and establishes mechanisms
to achieve reusable components.

Work Product preparation and production - encompasses the activities required to create
work products such as models, document, logs, forms and lists.

Intelligent application of any software process model must recognize that adaption is essential for success
but process models do differ fundamentally in:
The overall flow of activities and tasks and the inter dependencies among activities and tasks.
The degree through which work tasks are defined within each frame work activity.

The degree through 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 the detailed and rigor with which the process is described.

The degree through which the customer and other stakeholders are involved with the project.

The level of autonomy given to the software project team.

The degree to which team organization and roles are prescribed.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):

The CMMI represents a process meta-model in two different ways:

As a continuous model
As a staged model.
Each process area is formally assessed against specific goals and practices and is rated according to the
following capability levels.

Level 0: Incomplete. The process area is either not performed or does not achieve all goals and objectives
defined by 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;
Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is ―tailored from the
organizations set of standard processes according to the organizations tailoring guidelines, and contributes
and 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 in managing the process‖

Page 8
Level 5: Optimized. All 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‖

Page 9
SOFTWARE ENGINEERING

The CMMI defines each process area in terms of ―specific goals‖ and the ―specific practices‖ required to
achieve these goals. Specific practices refine a goal into a set of process-related activities.

The specific goals (SG) and the associated specific practices(SP) defined for project planning are

SG 1 Establish estimates
SP 1.1 Estimate the scope of the project
SP 1.2 Establish estimates of work product and task attributes
SP 1.3 Define project life cycle
SP 1.4 Determine estimates of effort and cost
SG 2 Develop a Project Plan
SP 2.1 Establish the budget and schedule
SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for needed knowledge and skills
SP 2.5 Plan stakeholder involvement
SP 2.6 Establish the project plan
SG 3 Obtain commitment to the plan
SP 3.1 Review plans that affect the project
SP 3.2 Reconcile work and resource levels
SP 3.3 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 (GG) 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 and 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

Page 10
SOFTWARE ENGINEERING

GP 4.2 Stabilize sub process performance

GG 5 Institutionalize and optimizing process
GP 5.1 Ensure continuous process improvement
GP 5.2 Correct root causes of problems

PROCESS PATTERNS
The software process can be defined as a collection patterns that define a set of activities, actions,
work tasks, work products and/or related behaviors required to develop computer software.
A process pattern provides us with a template- a consistent method for describing an important
characteristic of the software process. A pattern might be used to describe a complete process and a task
within a framework activity.

Pattern Name: The pattern is given a meaningful name that describes its function within the
software process.

Intent: The objective of the pattern is described briefly.

Type: The pattern type is specified. There are three types

Task patterns define a software engineering action or work task that is part of the process and
relevant to successful software engineering practice. Example: Requirement Gathering
Stage Patterns define a framework activity for the process. This pattern incorporates
multiple task patterns that are relevant to the stage.
Example: Communication
Phase patterns define the sequence of framework activities that occur with the process,
even when the overall flow of activities is iterative in nature.
Example: Spiral model or prototyping.

Initial Context: The conditions under which the pattern applies are described prior to the initiation of
the pattern, we ask
What organizational or team related activities have already occurred.
What is the entry state for the process
What software engineering information or project information already exists

Problem: The problem to be solved by the pattern is described.

Solution: The implementation of the pattern is described.
This section describes how the initial state of the process is modified as a consequence the initiation of
the pattern.
It also describes how software engineering information or project information that is available before
the initiation of the pattern is transformed as a consequence of the successful execution of the pattern

Resulting Context: The conditions that will result once the pattern has been successfully implemented
are described. Upon completion of the pattern we ask
What organizational or team-related activities must have occurred
What is the exit state for the process
What software engineering information or project information has been developed?

Known Uses: The specific instances in which the pattern is applicable are indicated
Process patterns provide and effective mechanism for describing any software process.
The patterns enable a software engineering organization to develop a hierarchical process description
that begins at a high-level of abstraction.
Once process pattern have been developed, they can be reused for the definition of process variants-that is,
a customized process model can be defined by a software team using the pattern as building blocks for the
process models.

Page 11
SOFTWARE ENGINEERING

PROCESS ASSESSMENT
The existence of a software process is no guarantee that software will be delivered on time, that it
will meet the customer‘s needs, or that it will exhibit the technical characteristics that will lead to long-term
quality characteristics. In addition, the process itself should be assessed to be essential to ensure that it
meets a set of basic process criteria that have been shown to be essential for a successful software
engineering.

Software

Identifies Identifies capabilities and risk

Software

Lead

Software Capability
Motivat

A Number of different approaches to software process assessment have been proposed over the past few
decades.

Standards CMMI Assessment Method for Process Improvement (SCAMPI) provides a five step
process assessment model that incorporates initiating, diagnosing, establishing, acting & learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment.
CMM Based Appraisal for Internal Process Improvement (CBA IPI) provides a diagnostic technique
for assessing the relative maturity of a software organization, using the SEI CMM as the basis for the
assessment.
SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessments. The
intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any
defined software process.
ISO 9001:2000 for Software is a generic standard that applies to any organization that wants to improve
the overall quality of the products, system, or services that it provides. Therefore, the standard is directly
applicable to software organizations &companies.

PERSONAL AND TEAM PROCESS MODELS:

The best software process is one that is close to the people who will be doing the work.Each software
engineer would create a process that best fits his or her needs, and at the same time meets the broader needs
of the team and the organization. Alternatively, the team itself would create its own process, and at the
same time meet the narrower needs of individuals and the broader needs of the organization.

Personal software process (PSP)

The personal software process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product.

Page 12
SOFTWARE ENGINEERING

The PSP process model defines five framework activities: planning, high-level design, high level design
review, development, and postmortem.

Planning: This activity isolates requirements and, base on these develops both size and resource estimates.
In addition, a defect estimate 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 task and work results.
Postmortem: Using the measures and metrics collected the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
PSP stresses the need for each software engineer to identify errors early and, as important, to
understand the types of errors that he is likely to make.

PSP represents a disciplined, metrics-based approach to software engineering.

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 are the 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(IPT) 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 CMM level 5 behavior normal and expected.
Provide improvement guidance to high-maturity organizations.
Facilitate university teaching of industrial-grade team skills.
self-directed team defines
roles and responsibilities for each team member
tracks quantitative project data
identifies a team process that is appropriate for the project
a strategy for implementing the process
defines local standards that are applicable to the teams software engineeringwork;
continually assesses risk and reacts to it
Tracks, manages, and reports project status.
-
TSP defines the following framework activities: launch, high-level design, implementation, integration and
test, and postmortem.
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 and other more detailed work functions that are part of the team
process.
Each project is ―launched‖ using a sequence of tasks.

The following launch script is recommended

Review project objectives with management and agree on and document team goals
Establish team roles
Define the teams development process
Make a quality plan and set quality targets
Plan for the needed support facilities

Page 13
 A PROCESS FRAMEWORK
Used as a basis for the description of process models Generic process activities
• Communication
• Planning
• Modeling
• Construction
• Deployment

A PROCESS FRAMEWORK
Generic view of engineering complimented by a number of umbrella activities
 Software project tracking and control
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurement
 Risk management

CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• Developed by SEI(Software Engineering institute)
• Assess the process model followed by an organization and rate the organization with different levels
• A set of software engineering capabilities should be present as organizations reach different levels of
process capability and maturity.

Software Engineering Page 8

 CMMI process meta model can be represented in different ways
1.A continuous model
2.A staged model

Continuous model:
-Lets organization select specific improvement that best meet its business objectives and minimize risk-
Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated according to the
following capability levels.

CMMI
• Six levels of CMMI
– Level 0:Incomplete
– Level 1:Performed
– Level 2:Managed
– Level 3:Defined
– Level 4:Quantitatively managed
– Level 5:Optimized

CMMI
• Incomplete -Process is adhoc . Objective and goal of process areas are not known
• Performed -Goal, objective, work tasks, work products and other activities of software process are
carried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
• Quantitatively Managed -Metrics and indicators are available to measure the process and quality
• Optimized - Continuous process improvement based on quantitative feed back from the user
-Use of innovative ideas and techniques, statistical quality control and other methods for process
improvement.

Software Engineering Page 9

 CMMI - Staged model
- This model is used if you have no clue of how to improve the process for quality software.
- It gives a suggestion of what things other organizations have found helpful to work first
- Levels are called maturity levels

PROCESS PATTERNS
Software Process is defined as collection of Patterns.Process pattern provides a template. It comprises of
• Process Template
-Pattern Name
-Intent
-Types
-Task pattern
- Stage pattern
-Phase Pattern
• Initial Context
• Problem
• Solution
• Resulting Context
• Related Patterns

PROCESS ASSESSMENT
Does not specify the quality of the software or whether the software will be
delivered on time or will it stand up to the user requirements. It attempts to keep a check on the current
state of the software process with the intention of improving it.
PROCESS ASSESSMENT
Software Process
Software Process Assessment Software Process improvement Motivates Capability determination
APPROACHES TO SOFTWARE ASSESSMENT
• Standard CMMI assessment (SCAMPI)
• CMM based appraisal for internal process improvement
• SPICE(ISO/IEC 15504)
• ISO 9001:2000 for software
Personal and Team Software Process
Personal software process
 PLANNING
 HIGH LEVEL DESIGN
 HIGH LEVEL DESIGN REVIEW
 DEVELOPMENT
 POSTMORTEM

Personal and Team Software Process

Team software process Goal of TSP
- Build self-directed teams
- Motivate the teams
- Acceptance of CMM level 5 behavior as normal to accelerate software process improvement
- Provide improvement guidance to high maturity organization

Software Engineering Page 10