SYLLABUS

Unit-I: Introduction to Software Engineering: The evolving role of software, changing nature of software, software myths. A
Generic view of process: Software engineering- a layered technology, a process framework, the capability maturity model
integration (CMMI). Process models: The waterfall model, Spiral model and Agile methodology

Unit-II: Software Requirements: Functional and non-functional requirements, user requirements, system requirements,
interface specification, the software requirements document. Requirements engineering process: Feasibility studies,
requirements elicitation and analysis, requirements validation, requirements management.

Unit-III: Design Engineering: Design process and design quality, design concepts, the design model. Creating an architectural
design: software architecture, data design, architectural styles and patterns, architectural design, conceptual model of UML,
basic structural modeling, class diagrams, sequence diagrams, collaboration diagrams, use case diagrams, component
diagrams.Un
t-IV:
Unit-IV: Testing Strategies: A strategic approach to software testing, test strategies for conventional software, black-box and
white-box testing, validation testing, system testing, the art of debugging. Metrics for Process and Products: Software
measurement, metrics for software quality.

Unit-V: Risk management: Reactive Vs proactive risk strategies, software risks, risk identification, risk projection, risk
refinement, RMMM. Quality Management: Quality concepts, software quality assurance, software reviews, formal technical
reviews, statistical software quality assurance, software reliability, the ISO 9000 quality standards.
What is Software?
 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.

What are the 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.
What is 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:

There are Seven broad categories of computer software present continuing challenges for software engineers:
1. System software
2. Application software
3. Engineering/scientific software
4. Embedded software
5. Product-line software
6. Web-applications
7. Artificial intelligence software.

1. 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 file management utilities and operating Systems.

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

3. Engineering/Scientific software:
Engineering and scientific applications range
a. - from astronomy to volcano logy
b. - from automotive stress analysis to space shuttle orbital dynamics
c. - from molecular biology to automated manufacturing

E.g. computer aided design, system simulation and other interactive applications.

4. 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.,
5. 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

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

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

1. 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?
2.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.
A generic view of process
Software engineering - A layered technology:

Fig: Software Engineering Layers

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
a. communication,
b. requirements analysis,
c. design modelling,
d. program construction,
e. Testing
f. 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:
It 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):
1. work tasks
2. Work products
3. (deliverables) quality assurance points
4. project milestones.
Generic Process Framework: It is applicable to the vast majority of software projects:
 Communication activity
 Planning activity
 modelling activity

Analysis action
a. Requirements gathering
b. task elaboration
c. Negotiation work task
d. specification work task
e. validation work task

Design action
f. Data design work task
g. architectural design work task
h. interface design work task
i. component-level design work task
j. Construction activity
k. 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.
The following are the set of Umbrella Activities:

• Software project tracking and control

• Risk Management
• Software Quality Assurance
• Formal Technical Reviews

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.
Level 1: Performed.
Level 2: Managed.
Level 3: Defined
Level 4: Quantitatively managed.
Level 5: Optimized.
 Process Models:

THE WATERFALL MODEL:

 This Waterfall model is used when requirements are well understood in the
beginning
 It is also called as classic life cycle. A systematic, sequential approach to
Software development.
 It 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 .
 This Waterfall model is used when requirements are well understood in the
beginning
 It is also called as classic life cycle. A systematic, sequential approach to
Software development.
 It 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 .
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.
 clearly defines milestones and deadlines.
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

 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 Spiral Model is one of the most important Software Development Life Cycle models. The Spiral
Model is a combination of the waterfall model and the iterative model. It provides support for Risk
Handling. The Spiral Model was first proposed by Barry Boehm. This article focuses on discussing
the Spiral Model in detail.

The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic
and iterative approach to software development. In its diagrammatic representation, looks like a
spiral with many loops. The exact number of loops of the spiral is unknown and can vary from
project to project. Each loop of the spiral is called a phase of the software development process.
 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. This Model is useful when:

a) frequent changes are required.

b) A highly qualified and experienced team is available. Phases of Agile Model:
c) A customer is ready to have a meeting with a software team a. Requirements gathering
all the time. b. Design the requirements
d) project size is small.
c. Construction/ iteration
d. Testing/ Quality assurance
e. Deployment
f. Feedback