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.

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 by a 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
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
hardware heavy 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: Web applications 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 non-numerical

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

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
will 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:

Fig: 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 modelling activities. Methods encompass a broad
array of tasks that include
 communication,
 requirements analysis,
 design modelling,
 program construction,
 Testing
 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.
Generic Process Framework: It is applicable to the vast majority of software
projects
Communication activity
Planning activity
modelling activity
Analysis action
 Requirements gathering
 task elaboration
 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.

Modelling: 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 modelling 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.
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.

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):

The CMMI represents a process meta-model in two different ways: As a
continuous model and 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.

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.

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 Generic 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
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 Models:

THE WATERFALL MODEL:

• Used when requirements are well understood in the beginning

• Also called classic life cycle
• A systematic, sequential approach to Software development
• Begins with customer specification of Requirements and progresses through
planning,
modelling, construction and deployment.
This Model suggests a systematic, sequential approach to SW development that begins
at the system level and progresses through analysis, design, code and testing
Disadvantages of waterfall model:
• Real projects rarely follow the sequential flow since they are always iterative

• The model requires requirements to be explicitly spelled out in the beginning, which
is often difficult

• A working model is not available until late in the project time plan.

 Waterfall isn't ideal for complex, high-risk ongoing projects.

Advantages of the waterfall model:

Today, Agile methodology is often used in place of the waterfall model. However,
there are advantages to the waterfall approach, such as the following:

 Enables large or changing teams to move toward a common goal that has been
defined in the requirements stage;
 Forces structured, disciplined organization;
  Simplifies understanding, following and arranging tasks;
 Facilitates departmentalization and managerial control based on the schedule or
deadlines;
 Reinforces good coding habits to define before implementing design and then
code;
 enables early system design and specification changes to be easily done; and
 clearly defines milestones and deadlines.

Disadvantages of Waterfall Model:

 Difficulty in making changes. The methodology, in its traditional form, almost

never leaves room for unexpected changes or revisions. A sudden change in
project parameters could render much of the work you have done up to that
point useless, resulting in a delayed deadline.
 Customer or End User Exclusion. Being an internal process, the Waterfall
methodology has little focus on the end-user or customer involved in a project.
Customers often want to be involved during a project, adding opinions and
clarifying their needs and expectations.
 Testing phase at the end of the project. Leaving the testing phase for last is
risky. The project has probably taken a long time to complete, so large
revisions could cause significant delays.

THE INCREMENTAL MODEL:

• Software releases in increments

• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment. Plan addresses the modification
of core product to better meet the needs of customer
• Process is repeated until the complete product is produced
Advantages of Incremental Model:

1. Distribution of modules makes the SDLC easier.

2. This model is Cost Efficient.

3. Resources are properly utilized as per skill set.

4. Comparatively leads to faster product delivery.

5. Risk can be managed easily.

6. Functionalities are achieved, analysed, and checked thoroughly throughout

7. Exposure to new technologies.

8. Errors can be easily recognized throughout.

9. Easier to debug.

10. Functionality wise release.

11. Better Support throughout the SDLC.

AGILE MODEL:

The of Agile is swift or versatile. “Agile process model" refers to a software

development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project
scope and requirements are laid down at the beginning of the development process.
Plans regarding the number of iterations, the duration and the scope of each iteration
are clearly defined in advance.

Phases of Agile Model:

a. When frequent changes are required.

b. When a highly qualified and experienced team is available.
c. When a customer is ready to have a meeting with a software team all the time.
d. When project size is small.

Following are the phases in the Agile model are as follows:

a. Requirements gathering
b. Design the requirements
c. Construction/ iteration
d. Testing/ Quality assurance
e. Deployment
f. Feedback
 1. Requirements gathering:
In this phase, you must define the requirements. You should explain
business opportunities and plan the time and effort needed to build the
project. Based on this information, you can evaluate technical and
economic feasibility.
2. Design the requirements:
When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML
diagram to show the work of new features and show how it will apply to
your existing system.
3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which
aims to deploy a working product. The product will undergo various
stages of improvement, so it includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the
product's performance and looks for the bug.
5. Deployment: In this phase, the team issues the product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this,
the team receives feedback about the product and works through the
feedback.

Advantages of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages of Agile Method:

 Due to the shortage of formal documents, it creates confusion and crucial

decisions taken throughout various phases can be misinterpreted at any time by
different team members.
 Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can
become a difficulty.
Spiral Model:
 An evolutionary model which combines the best feature of the classical life
cycle and the iterative nature of prototype model. Include new element: Risk
element. Starts in middle and continually visits the basic tasks of
communication, planning, modelling, construction and deployment.

 In 1986, it was initially proposed by Barry Boehm and established as a well-

suited model for large, complex projects where risks need to be managed
effectively. The Spiral Model is characterized by its emphasis on risk analysis
and management throughout the software development lifecycle.

 Graphically, the spiral model consists of multiple phases that are executed in a
cyclic or spiral fashion, with each iteration referred to as a "spiral."

a) Planning (Requirement Gathering):

The primary purpose of the planning phase in the spiral model SDLC is to
collect, understand and identify the core objectives and set some alternative
solutions.
b) Risk Analysis (Risk Management):

In this phase of the spiral model for software development, the developer term
will identify all the potential risks that will arise during the software
development process. After the risk identification process, the developer team
will release a prototype, which will be a risk-free demographic version of the
software. Not only will the developer release a risk-free prototype, but they
also will plan alternative solutions to handle the risk.

c) Engineering (Design and Coding):

After the software engineering is done designing the software, they will start
coding, testing and the deployment process. Moreover, developers will deploy
the software on the client’s site to gather feedback. This phase in the spiral
model is totally technical and needs experience and expertise to tackle any
challenge or change.

d) Evaluation (Review and Deployment):

 After the launch of a software project on the client’s site, the client is
open to sharing feedback and insightful observations about the
software.

 Hence, the testing team from the client side will note down all the
feedback, observations, additions and changes needed in the software or
its functionality. All the correction lists will be sent to the development
team.

 Again, a new baseline will begin to fix all the bugs, and after fixation of
all requirements, the final product will be ready for final launch.

Advantages of Spiral Model:

a. Best Model to Handle Risky Projects

b. Good Choice for Large Project
c. Flexible with Requirements
d. Better Customer Satisfaction
e. Iterative and incremental approach
f. Open to receiving any feedback
g. Better quality

Disadvantages of Spiral Method:

a. Complexity
b. Expensive
c. Follows multiple iterations
d. Time-consuming