Introduction to Software

Engineering

Presented By: Sushma Vankhede

What is Software?

 Software is a set of instructions to acquire inputs and to

manipulate them to produce the desired output in terms of
functions and performance as determined by the user of
the software
 Also include a set of documents, such as the software
manual , meant for users to understand the software
system
Description of the Software

 A software is described by its capabilities. The capabilities relate to

the functions it executes, the features it provides and the facilities it
offers.
EXAMPLE
Software written for Sales-order processing would have
different functions to process different types of sales order from
different market segments .
 The features for example , would be to handle multi-currency
computing, updating product , sales and Tax status.
 The facilities could be printing of sales orders, email to customers
and reports to the store department to dispatch the goods.
Classes of Software

Software is classified into two classes:

 Generic Software:
is designed for broad customer market whose
requirements are very common, fairly stable and well understood by
the software engineer.
 Customized Software:
is developed for a customer where domain ,
environment and requirements are being unique to that customer and
cannot be satisfied by generic products.
What is Good Software?

 Software has number of attributes which decide whether it is a

good or bad .
 The definition of a good software changes with the person who
evaluates it.
 The software is required by the customer , used by the end users of an
organization and developed by software engineer .
 Each one will evaluate the different attributes differently in order to
decide whether the software is good.
 What are the attributes of good
software?

The software should deliver the required functionality and performance to

the user and should be maintainable, dependable and usable.
• Maintainability
– Software must evolve to meet changing needs
 Dependability
– Software must be trustworthy
 Efficiency
– Software should not make wasteful use of system resources
 Usability
– Software must be usable by the users for which it was designed
Changing nature of
software(Types)
 System Software- A collection of programs written to service other
programs at system level.
For example, compiler, operating systems.

 Real-time Software- Programs that monitor/analyze/control real

world events as they occur.

 Business Software- Programs that access, analyze and process

business information.

 Engineering and Scientific Software - Software using “number

crunching” algorithms for different science and applications. System
simulation, computer-aided design.
Changing nature of
software(Types)
 Embedded Software-:
Embedded software resides in read-only memory and is used to
control products and systems for the consumer and industrial markets.
It has very limited and esoteric functions and control capability.

 Artificial Intelligence (AI) Software:

Programs make use of AI techniques and methods to solve complex
problems. Active areas are expert systems, pattern recognition, games

 Internet Software :
Programs that support internet accesses and applications. For example,
search engine, browser, e-commerce software, authoring tools.
Software - Characteristics

 Software has a dual role. It is a product, but also a vehicle for delivering a
product.

 Software is a logical rather than a physical system element.

 Software has characteristics that differ considerably from those of hardware.

 Software is developed or engineered, it is not manufactured in the

classical sense

 Software doesn’t “wear out”

 Most software is custom-built, rather than being assembled from

existing components.
Software doesn’t “Wear Out”
Software Engineering

 “A systematic approach to the analysis, design, implementation and

maintenance of software.”
(The Free On-Line Dictionary of Computing)
 “ The systematic application of tools and techniques in the
development of computer-based applications.”
(Sue Conger in The New Software Engineering)
 “ Software Engineering is about designing and developing high-
quality software.”
(Shari Lawrence Pfleeger in Software Engineering -- The Production
of Quality Software)
What is Software Engineering?

 Engineering: The Application of Science to the Solution of Practical

Problems
 Software Engineering: The Application of CS to Building Practical Software
Systems
 Programming
– Individual Writes Complete Program
– One Person, One Computer
– Well-Defined Problem
– Programming-in-the-Small
 Software Engineering
– Individuals Write Program Components
– Team Assembles Complete Program
– Programming-in-the-Large
 What is the difference between software engineering and
computer science?

Computer Science Software Engineering

is concerned with
 theory  the practicalities of developing
 fundamentals  delivering useful software

Computer science theories are currently insufficient to act as a complete

underpinning for software engineering, BUT it is a foundation for practica
aspects of software engineering
What is Software Engineering?

Although hundreds of authors have developed personal definitions of software

engineering, a definition proposed by Fritz Bauer[NAU69] provides a basis:

 “[Software engineering is] the establishment and use of sound

engineering principles in order to obtain economically software that is
reliable and works efficiently on real machines.”

The IEEE [IEE93] has developed a more comprehensive definition when it

states:

 “Software Engineering: (1) The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study
of approaches as in (1).”
Software engineering is a layered
technology - Pressman’s view:

Software Engineering Layers

tools

methods

process model

a “quality” focus
What is Software Engineering?

 Software methods:
 Software engineering methods provide the technical “how to’s” for
building software.

 Methods --> how to encompass a broad array of tasks:

- requirements analysis, design, coding, testing, and maintenance

 Software engineering methods rely on a set of basic principles.

What is Software Engineering?

 Software process:
Software engineering process is the glue that holds:
- technology together
- enables rational and timely development of computer
software.
Software engineering process is a framework of a set of key process
areas.
It forms a basis for:
- project management, budget and schedule control
- applications of technical methods
- product quality control
What is Software Engineering?

 Software tools:
- programs provide automated or semi-automated support for the
process and methods.
- programs support engineers to perform their tasks in a systematic
and/or automatic manner.
Why Software Engineering?

 Objectives:
- Identify new problems and solutions in software production.
- Study new systematic methods, principles, approaches for system
analysis,design, implementation, testing and maintenance.
- Provide new ways to control, manage, and monitor software process.
- Build new software tools and environment to support software
engineering.
Why Software Engineering?

Major Goals:
- To increase software productivity and quality.
- To effectively control software schedule and planning.
- To reduce the cost of software development.
- To meet the customers’ needs and requirements.
- To enhance the conduction of software engineering process.
- To improve the current software engineering practice.
- To support the engineers’ activities in a systematic and efficient
manner.
A Process Framework
Process Framework Activities

 Communication
 Planning
 Modeling
– Analysis of Requirements
– Designing
 Construction
– Coding
– Testing
 Deployment
Umbrella Activities

 Software project tracking & control

 Risk Management
 Formal Technical reviews
 Software configuration management
 Reusability management
 Adapting a Process Model

– the overall flow of activities, actions, and tasks and the

interdependencies among them
– the degree to which actions and tasks are defined within
each framework activity
– the degree to which work products are identified and
required
– the manner which quality assurance activities are applied
– the manner in which project tracking and control activities
are applied
– the degree to which the customer and other stakeholders
are involved with the project
– the level of autonomy given to the software team
– the degree to which team organization and roles are
prescribed
24
 The Essence of Practice

Polya suggests:
[Link] the problem (communication and analysis).
[Link] a solution (modeling and software design).
[Link] out the plan (code generation).
[Link] the result for accuracy (testing and quality
assurance).

25
 Understand the Problem

 Who has a stake in the solution to the problem? That

is, who are the stakeholders?
 What are the unknowns? What data, functions, and
features are required to properly solve the problem?
 Can the problem be compartmentalized? Is it possible
to represent smaller problems that may be easier to
understand?
 Can the problem be represented graphically? Can an
analysis model be created?

26
 Plan the Solution

 Have you seen similar problems before? Are there patterns that
are recognizable in a potential solution? Is there existing
software that implements the data, functions, and features that
are required?
 Has a similar problem been solved? If so, are elements of the
solution reusable?
 Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
 Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

27
 Carry Out the Plan

 Does the solution conform to the plan? Is

source code traceable to the design model?
 Is each component part of the solution
provably correct? Has the design and code
been reviewed, or better, have correctness
proofs been applied to algorithm?

28
 Examine the Result

 Is it possible to test each component part of the

solution? Has a reasonable testing strategy been
implemented?
 Does the solution produce results that conform to the
data, functions, and features that are required? Has the
software been validated against all stakeholder
requirements?

29
 Hooker’s General Principles
• 1: The Reason It All Exists
– To provide value to its user
• 2: KISS (Keep It Simple, Stupid!)
– All design should be as simple as possible.
• 3: Maintain the Vision
– A clear vision is essential.
• 4: What You Produce, Others Will Consume
– Always specify, design and implement knowingly someone else have to
understand what you are doing.
• 5: Be Open to the Future
– Never design yourself to corner.
• 6: Plan Ahead for Reuse
– Reduces cost/time and increase value of reusable component and system
which needs to be built.
• 7: Think!
– Place complete thought before action always produces better result.

30
 How It all Starts

– Every software project is provoked by some

business need—
 the need to correct a defect in an existing application;
 the need to adapt a ‘legacy system’ to a changing
business environment;
 the need to extend the functions and features of an
existing application, or
 the need to create a new product, service, or system.

31
A Generic Process Model

32
Process Flow

33
Identifying a Task Set

 A task set defines the actual work to be done

to accomplish the objectives of a software
engineering action.
– A list of the task to be accomplished
– A list of the work products to be produced
– A list of the quality assurance filters to be applied

34
Process Patterns

 A process pattern
– describes a process-related problem that is
encountered during software engineering work,
– identifies the environment in which the problem
has been encountered, and
– suggests one or more proven solutions to the
problem.
 So, a process pattern provides you a
consistent method for describing problem
solutions within the context of the software
process. 35
Process Pattern Types

 Stage patterns—defines a problem

associated with a framework activity for the
process.
 Task patterns—defines a problem associated
with a software engineering action or work
task and relevant to successful software
engineering practice
 Phase patterns—define the sequence of
framework activities that occur with the
36
process, even when the overall flow of
 Software Process Assessment

 Process is suffered by the following

problems.-
1. The s/w has to be delivered on time.
2. The s/w Should satisfy customer needs
and requirements
3. The s/w Should posses the long term
quality characteristics.
 Process assessment is an activity in which it
37 is ensured whether the software meets the
 Software Process Assessment

38
Process Assessment and Improvement

 Standard CMMI Assessment Method for Process Improvement

(SCAMPI) — provides a five step process assessment model that incorporates
five phases: initiating, diagnosing, establishing, acting and learning.
 CMM-Based Appraisal for Internal Process Improvement (CBA
IPI)—provides a diagnostic technique for assessing the relative
maturity of a software organization; uses the SEI CMM as the basis for
the assessment [Dun01]
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the
standard is to assist organizations in developing an objective evaluation
of the efficacy of any defined software process. [ISO08]

 ISO 9001:2000 for Software—a generic standard that applies to any

organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies.
39
PROCESS
MODELS
SDLC Process Model

SDLC – Software Development Life Cycle

Process model is a framework that describes

the activities,actions,tasks,milestones,and
work products performed at each stage of a
software development project that leads to a
high quality software
Life cycle models

 Waterfall model
 Incremental process models
– Incremental model
– RAD model
 Evolutionary Process Models
– Prototyping model
– Spiral model
 Object oriented process model
 WATERFALL MODEL
[Link] Linear life cycle model or
COMMUNICATION
Project initiation
classic life cycle model
Req. gathering

PLANNING
Estimating
Scheduling
tracking

MODELLING
Analysis
design

CONSTRUCTION
Code
Test

DEPLOYMENT
Delivery
Support
feedback
WATERFALL MODEL

 Project initiation & requirement gathering

– What is the Problem to Solve?
– What Does Customer Need/Want?
– Interactions Between SE and Customer
– Identify and Document System Requirements
– Generate User Manuals and Test Plans
• Planning
– Prioritize the requirements
– Plan the process
WATERFALL MODEL

 Analysis and design

– How is the Problem to be Solved?
– High-Level Design
– Determine Components/Modules
– Transition to Detailed Design
– Detail Functionality of Components/Modules
 Coding and Testing
– Writing Code to Meet Component/Module Design Specifications
– Individual Test Modules in Isolation
– Integration of Components/Modules into Subsystems
– Integration of Subsystems into Final Program
WATERFALL MODEL

 Deployment
– System Delivered to Customer/Market
– Bug Fixes and Version Releases Over Time
Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost or schedule
Waterfall Drawbacks

 All projects cannot follow linear process

 All requirements must be known upfront
 Few business systems have stable
requirements.
 The customer must have patience. A working
version of the program will not be available until
late in the project time-span
 Leads to ‘blocking states’
 Inappropriate to changes
When to use the Waterfall
Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
Incremental SDLC Model
 Combines the elements of waterfall model in an iterative
fashion
 Construct a partial implementation of a total system
 Then slowly add increased functionality
 User requirements are prioritised and the highest priority
requirements are included in early increments.
 Each subsequent release of the system adds function to the
previous release, until all designed functionality has been
implemented.
Incremental Model Weaknesses

 Requires good planning and design

 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower
 When to use the Incremental
Model

 When staffing is not available by deadline

 Most of the requirements are known up-front but are
expected to evolve over time
 When the software can be broken into increments and
each increment represent a solution
 A need to get basic functionality to the market early
 On projects which have lengthy development schedules
 On a project with new technology
 RAD MODEL
Rapid Application Development
Model

 An incremental process model that emphasizes short

development cycle
 “High-speed” adaptation of the waterfall model.
 RAD approach also maps into the generic framework
activities
Drawbacks of RAD

 For large projects, RAD requires sufficient human

resources to create the right number of RAD teams.
 If developers & customers are not committed to rapid-fire
activities, RAD projects will fail.
 If the system cannot be properly modularized, building the
components will be problematic
 If high-performance is an issue, RAD may not work.
 RAD may be inappropriate when technical risks are high
When to use RAD

 Reasonably well-known requirements

 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized
EVOLUTIONARY PROCESS
MODEL

 These models produce an increasingly more

complete version of the software with each
iteration
 When to use
– Tight market deadlines
– Well defined system requirements
– No details about system definition
 PROTOTYPING MODEL

 A prototype is a partially developed product that enables

customers and developers to examine some aspects of the
proposed system and decide if it is suitable or appropriate
for the finished product
– Start with what is known about requirements.
– Do a quick design.
– Build the prototype by focusing on what will be seen
by the user.
– Use the prototype to show the user and help refining
requirements
PROTOTYPING MODEL
Drawbacks of Prototyping Model

 Customer sees what appears to be a working

version of the software and presumes that it
is the final thing.
 The developer often makes implementation
compromises in order to get a prototype
working quickly
Only one advantage is actual software is engineered
with an eye toward quality
SPIRAL MODEL

 It couples the iterative nature of prototyping with the

controlled and systematic aspects of the waterfall model
Process
 Adapted to complete life cycle
 Process is represented as a spiral rather than as a sequence
of activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design - loops in
the spiral are chosen depending on what is required.
SPIRAL MODEL
Spiral Model Strengths

• Focuses attention on reuse options.

• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software
Development.
Drawbacks of the Spiral Model

 It may be difficult to convince customers that

the evolutionary approach is controllable.
 It demands risk assessment expertise and
relies on this expertise for success.
 If a major risk is uncovered and managed,
problems will occur.
When to use Spiral Model

 When creation of a prototype is appropriate

 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because
of potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected
 Agile methodology

 In this after every development iteration, the

customer is able to see the result and
understand if he is satisfied with it or he is not.
 One of its disadvantages is that with the
absence of defined requirements it is difficult to
estimate the resources and development cost.
 Extreme programming is one of the practical use
of the agile model. The basis of such model
consists of short weekly meetings – Sprints
which are the part of the Scrum approach.

66
 Agile Methodology

67
 Agile Testing Methods:

• Scrum
• Crystal
• Dynamic Software Development
Method(DSDM)
• Feature Driven Development(FDD)
• Lean Software Development
• eXtreme Programming(XP)

68
 Scrum

 SCRUM is an agile development process focused primarily on

ways to manage tasks in team-based development conditions.
 There are three roles in it, and their responsibilities are:
 Scrum Master: The scrum can set up the master team, arrange the
meeting and remove obstacles for the process
 Product owner: The product owner makes the product backlog,
prioritizes the delay and is responsible for the distribution of
functionality on each repetition.
 Scrum Team: The team manages its work and organizes the work
to complete the sprint or cycle.

69
 Crystal:

 There are three concepts of this method-

 Chartering: Multi activities are involved in this phase such as
making a development team, performing feasibility analysis,
developing plans, etc.
 Cyclic delivery: under this, two more cycles consist, these are:
 Team updates the release plan.
 Integrated product delivers to the users.
 Wrap up: According to the user environment, this phase
performs deployment, post-deployment.

70
 Dynamic Software Development
Method(DSDM):

 DSDM is a rapid application development strategy

for software development and gives an agile project
distribution structure. The essential features of
DSDM are that users must be actively connected,
and teams have been given the right to make
decisions. The techniques used in DSDM are:
 Time Boxing
 MoSCoW Rules
 Prototyping

71
 Dynamic Software Development
Method(DSDM):

 The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

72
 Feature Driven Development(FDD):

 This method focuses on "Designing and Building"

features. In contrast to other smart methods, FDD
describes the small steps of the work that should be
obtained separately per function.

73
 Lean Software Development:
 Lean software development methodology follows the principle
"just in time production." The lean method indicates the
increasing speed of software development and reducing costs.
Lean development can be summarized in seven phases.
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

74
 extreme Programming(XP)

 This type of methodology is used when

customers are constantly changing demands
or requirements, or when they are not sure
about the system's performance.

75
 advantages of agile methodology

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

76
 disadvantages of agile
methodology
 Difficulties with measuring the final cost because of permanent
changes
 The team should be highly professional and client-oriented
 New requirements may conflict with the existing architecture
 With all the corrections and changes there is possibility that the
project will exceed expected time
 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.

77
 When to Use the Agile model

 When frequent changes are required.

 When a highly qualified and experienced
team is available.
 When a customer is ready to have a meeting
with a software team all the time.
 When project size is small.
 Unlike the Waterfall model, it requires only
initial planning to start the project
78
 Choosing the Life Cycle Model
 Waterfall model
– Sequential
– Good when problem and solution well understood
 Iterative enhancement model
– Incremental versions developed
– Good when problem or solution not well understood, schedule for full function a
risk, requirements changing
 Prototyping model
– Experimental version
– Good when user unsure of needs, some aspect of the system unclear,
experimental analysis needed
 Spiral model
– Risk oriented iterative enhancement
– Good when high risk, customer unclear of evolving requirements

79
END