Software Engineering

CS3201
Dr. Ashish Kumar
Dept. of CSE

1
Syllabus
Introduction: The Evolving Role of Software, The changing
nature of software, Legacy software, Software Myths.
Software Engineering: A Layered Technology, a Process
Framework, the Capability Maturity Model Integration (CMMI),
Specialized Process Models, and the Unified Process. Agile
development: Agile Process Models Software Engineering
Practice, Communication Practice, Planning Practices,
Modeling Practices, Construction Practice, Deployment
Computer–Based Systems, The System Engineering Hierarchy,
Business Process Engineering: An Overview. Product
Engineering: An Overview, Data Modeling Concepts, Object
Oriented Analysis, Flow-Oriented Modeling, Taxonomy of
Quality Attributes, Perspectives of Quality, Quality System,
Software Quality Assurance, Capability Maturity Model
Observation on Estimation, The Project Planning Process,
Software Scope and Feasibility, Human Resources, Empirical2
Books
Text Book
Roger S. Pressman, “Software Engineering: A
Practitioners Approach”, 7th Edition, TMH, 2016.
Ian Summerville, “Software Engineering”, 9th
Edition, Addition Wesley, 2002.
Reference Books
M. Walls, “Building a Dev Ops Culture”, O’Reilly
Publications, 2013.
J. Joyner, “Dev Ops for Beginners, Dev Ops
Software Development Method guide for software
developers and IT professionals”, Mihails
Konoplovs, 2015.
3
Course Evaluation
Component Duration Date Weightage

MTE I 1:30 hour As per Academic 30%

Calendar

CSW -- To be given by 30%

faculty

ETE 3 hours As per Academic 40%

Calendar

4
Course Faculty Details

Dr. Ashish Kumar

Assocaite Professor,
Dept. of CSE,
Manipal University Jaipur

Contact No. - +91-8233244583

Email – kumar.
[email protected]

5
6
What is Software Engineering?
Engineering approach to develop software.
 Building Construction Analogy.
Systematic collection of past experience:
 techniques,
 methodologies,
 Software engineering is the application of a
systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of
software. (Definition by IEEE) That is the application of
engineering to software.
The term software engineering first appeared in the
1968 NATO Software Engineering Conference, and was
meant to provoke thought regarding the perceived
"software crisis" at the time.
7
Software Engineering
Software engineering is:
An engineering discipline that provides
knowledge, tools, and methods for:
 Defining software requirements
 Performing software design
 Software construction
 Software testing
 Software maintenance tasks
 Software project management

8
Sub-disciplines of Software Engineering
 Software engineering can be divided into 11 sub
disciplines. They are:
 Software requirements: The elicitation, analysis,
specification, and validation of requirements for software.
 Software architecture: The elicitation, analysis,
specification, definition and design, and validation and
control of software architecture requirements.
 Software design: The design of software is usually done
with Computer-Aided Software Engineering (CASE) tools
and use standards for the format, such as the Unified
Modeling Language (UML).
 Software development: The construction of software
through the use of programming languages.
 Software testing
 Software maintenance: Software systems often have
problems and need enhancements for a long time after they9
Sub-disciplines of Software Engineering
 Software configuration management: Since software
systems are very complex, their configuration (such as
versioning and source control) have to be managed in a
standardized and structured method.
 Software engineering management: The management of
software systems borrows heavily from project
management, but there are nuances encountered in
software not seen in other management disciplines.
 Software development process: The process of building
software is hotly debated among practitioners; some of the
better-known processes are the Waterfall Model, the Spiral
Model, Iterative and Incremental Development, and Agile
Development.
 Software engineering tools
 Software quality
10
Software products
Generic products
Stand-alone systems that are marketed and
sold to any customer who wishes to buy them.
Examples – PC software such as editing,
graphics programs, project management tools;
CAD software; software for specific markets
such as appointments systems for dentists.
Customized products
Software that is commissioned by a specific
customer to meet their own needs.
Examples – embedded control systems, air
traffic control software, traffic monitoring
systems. 11
Software Applications
1. System software: such as compilers, editors, file
management utilities
2. Application software: stand-alone programs for specific
needs.
3.Engineering/scientific software: Characterized by
“number crunching”algorithms. such as automotive stress
analysis, molecular biology, orbital dynamics etc
4. Embedded software resides within a product or system.
(key pad control of a microwave oven, digital function of
dashboard display in a car)
5. Product-line software focus on a limited marketplace to
address mass consumer market. (word processing,
graphics, database management)
6. WebApps (Web applications) network centric software.
As web 2.0 emerges, more sophisticated computing
environments is supported integrated with remote database
and business applications.
7. AI software uses non-numerical algorithm to solve 12
Need for Software Engineering
The Five Drivers of Software Engineering
Manage complexity of large programs
Reduce time and cost of development
Reduce maintenance cost
Address “Software crisis” (Unacceptable low
quality of software, exceeds deadline and
budget.)
Produce quality software

13
Software Characteristics
Its characteristics that make it different from other
things human being build.
Features of such logical system:
Software is developed or engineered, it is not
manufactured in the classical sense which has quality
problem.
Software doesn't "wear out.” but it deteriorates (due
to change). Hardware has bathtub curve of failure
rate ( high failure rate in the beginning, then drop to
steady state, then cumulative effects of dust,
vibration, abuse occurs).
Although the industry is moving toward component-
based construction (e.g. standard screws and off-the-
shelf integrated circuits), most software continues to
be custom-built. Modern reusable components
encapsulate data and processing into software parts
14
to be reused by different programs. E.g. graphical
 FAQ about software engineering
Question Answer

What is software? Computer programs, data structures and associated

documentation. Software products may be developed for a
particular customer or may be developed for a general
market.

What are the attributes of good software? Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.

What is software engineering? Software engineering is an engineering discipline that is

concerned with all aspects of software production.

What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities of
developing and delivering useful software.

What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including hardware,
software and process engineering. Software engineering is
part of this more general process.

15
Essential attributes of good software
Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a
changing business environment.

Dependability and Software dependability includes a range of characteristics

security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.

Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.
16
Software Qualities
Pressman's definition of “Software Quality”
 Conformance to
1.explicitly stated functional and performance
requirements,
2.explicitly documented development standards,
and
3.implicit characteristics that are expected of all
professionally developed software.
IEEE Definition of “Software Quality”
4. The degree to which a system, component, or
process meets specified requirements.
5. The degree to which a system, component, or
process meets customer or user needs or17
Software Qualities
Software quality:
Conformance to explicitly stated
requirements and standards
Quality assurance:
is the activity that leads to “fitness of
purpose”.
Quality product:
is the one that does what the
customer expects it to do.
User satisfaction = compliant product + good
quality + delivery within budget and18
Software Qualities
Quality criteria include but are not limited to:
• Correctness • Evolvability
• Reliability • Reusability
• Robustness • Portability
• Performance • Understandabilit
• User friendliness y
• Verifiability • Productivity
• Maintainability • Size
• Reparability • Timeliness
• Safety
• Visibility
Select the critical attributes and plan how to achieve them
19
Software Quality Factors
Low defects level when deployed
Zero defect most preferably
High reliability
Capability of running without crashes
Majority of the user satisfy with software
when conducted the survey
Effective customer support
Rapid defect repair

20
Benefits Of Software Quality
Reduced maintenance cost
Stable and useful product
Satisfy customer needs
Better chances for continuing releases
Build corporate culture and identity
Better chances for software and design reuse

21
McCall’s Quality Factors
 McCall’s quality factors were proposed in the early 1970s. They are
as valid today as they were in that time. It’s likely that software built
to conform to these factors will exhibit high quality well into the 21st
century, even if there are dramatic changes in technology.
M a in ta in a b ility P o r ta b ility

F le x ib ility R e u s a b ility
T e s ta b ility
In te r o p e ra b ility

P R O D U C T R E V IS IO N P R O D U C T T R A N S IT I O N

P R O D U C T O P E R A T IO N

C o rre c tn e s s U s a b ility E ff ic ie n c y

R e lia b ility In te g r ity

22
McCall’s Software Quality Factors
Product Operations
Operational characteristics
Product Revision
Ability to undergo changes
Product Transition
Adaptability to new environments

23
McCall’s Quality Factors Model Tree

24
McCall’s Software Quality Factors
Factor Criteria Description
Product Maintainabilit Can I fix it?
Revision y
Flexibility Can I change it?
Testability Can I test it?
Product Portability Will I be able to use it on another
Transition machine?
Reusability Will I be able to reuse some of the other
software in other application?
Interoperabili Will I be able to interface it with another
ty system?
Product Correctness Does it do what I want?
Operation Reliability Does it do it accurately all the time?
Efficiency Will it run as well as it can?
Integrity Is it secure?
25
Usability Is it easy to use?
Software Myths
Management Myths
 Myth: We already have a book that’s full of standards and
procedures for building software. Won’t that provide my
people with everything they need to know?
 Reality: The book of standards may very well exist, but is it
used? Is it complete? In many cases, the answer is no.
 Myth: If we get behind schedule, we can add more
programmers and catch up.
 Reality: Software development is not a mechanistic
process like manufacturing.
 Myth: If we decide to outsource the software project to a
third party, I can just relax and let that firm build it.
 Reality: If an organization does not understand how to
manage and control software projects internally, it will
invariably struggle when it out sources software projects.
26
Software Myths
Customer Myths
• Myth: Project requirements continually change, but change
can be easily accommodated because software is flexible.
• Reality: It is true that software requirements do change,
but the impact of change varies with the time at which it is
introduced.
• Myth: A general statement of objectives is sufficient to
begin writing programs we can fill in the details later.
• Reality: Although a comprehensive and stable statement of
requirements is not always possible, an ambiguous statement
of objectives is a recipe for disaster.

27
Software Myths
Practitioner’s Myths
• Myth: Once we write the program and get it to work our
job is done.
• Reality: “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: Until I get the program running, I have no way of
assessing its quality.
• Reality: One of the most effective software quality
assurance mechanisms can be applied from the inception of a
project-the formal technical review.
• Myth: The only deliverable work product for a successful
project is the
working program. 28
Thank You

29