Introduction to Software
Engineering
Dr. Preeti Kaur
CSE Dept, NSUT
What is Software ?
Software can define as:
❑ Instruction – executed provide desire features, function & performance.
❑ Data structure – to adequately manipulate operation.
❑ Documents – operation and use of the program.
Software products may be developed for a particular customer or may be developed for a general
market.
❑ Software products may be
❑ Generic - developed to be sold to a range of different customers e.g. PC software
such as Excel or Word.
❑ Custom - developed for a single customer according to their specification.
TITLE OF THE COURSE
COURSE NO PRE-REQUISITE
COURSE STRUCTURE
Software 3L - 0T - 2P None
CO CSC 4 02
Engineering
COURSE OUTCOMES (COs)
After completion of this course, the students are expected to demonstrate
the following knowledge and skills:
1. To understand the process of designing and developing software to solve
complex problems.
2. To understand the importance of requirements engineering in SDLC and
learn various steps involved in Requirements Engineering.
3. To learn software architecture Models
4. To learn and apply various software testing techniques
5. To learn and apply different techniques for software project
management. To learn about different Software Quality frameworks,
Software Metrics, Software Reliability, Risk Management, Software
Maintenance.
Unit I
• Introduction: Introduction to software engineering. The Software evolution,
Software characteristics, Software components, Software applications, Software
Crisis-Problem and causes. Software Development Life cycle (SDLC)-Requirements
analysis, software design, coding, testing, maintenance. Approach to software
design and development – Structured and Object-Oriented Analysis and Design
(OOAD), Difference between Structured and OOAD.
• Software Process Models: Waterfall model, Evolutionary Modell, Iterative and
incremental models, prototyping, V Model, Spiral model, RAD Model, RUP
• What is Agile Development, Introduction to Agile models like Scrum, Extreme
Programming, Feature Driven Development, Crystal etc. Devops, Comparison
between Traditional and Agile models.
Unit II
• Requirement Engineering: Importance of Requirements engineering in SDLC.
Requirements engineering steps, Different Types of Requirements: Functional,
Non-Functional and Domain Requirements in detail, Requirement elicitation
Techniques like interviews, questionnaire, brainstorming, JAD, Scenario, Mind
mapping, developing use cases and use case scenarios, use case diagram
requirements management, Writing SRS as per IEEE standard, Quality
characteristics of SRS, human oriented software engineering.
• Requirements Specification: Difference between structured and Object-Oriented
Analysis, Role of modelling in Requirements understanding, Different views of
modeling-Static, Functional, Dynamic, ER diagram, Data flow Diagrams, State
Transition Diagrams, Data Dictionary, Techniques for describing process
specifications, Object oriented requirements analysis- Introduction to Unified
Modeling Language (UML).
Unit III
• System Design: Types of Coupling and Cohesion, Deriving structure chart from DFD in
case of structured analysis.
• Software Architecture: Importance of Software architecture, Different views of Software
Architecture, Popular Architecture Styles, Introduction to Design Patterns, Pattern based
Design.
Unit IV
• Software Testing: Errors , Faults and failure, Difference between verification and
validation testing, Introduction to verification and Validation testing techniques, levels of
testing, White box testing, static and structural testing, Basis path testing-Flow graph
notation, cyclomatic complexity, deriving test cases, Black Box testing-Boundary value
analysis method, Equivalence class testing method, state table based testing methods,
Decision table based testing method, cause effect graphing method, Agile Testing Test
Driven Development in Agile Processes
Unit V
• Software project Management: Cost estimation, Project scheduling, Staffing, Software
configuration management, Quality assurance, Project Monitoring, Risk management,
Risk Management in Agile Processes, Agile Project Planning etc.
• Software Quality: Software Quality Models like McCall’s Quality model, Quality
frameworks like Capability Maturity Model, ISO9001, Software quality metrics, Software
Reliability
• Software Maintenance: Different Types of maintenance, Risk management.
• Current trends and future directions for Software Engineering
SUGGESTED READINGS
• Sommerville, “Software Engineering”, 10th Edition
Published by Pearson, 2017
• R . S. Pressman, and Bruce R. Maxim, “Software
Engineering – A practitioner’s approach”, McGraw Hill
Education: Eighth Edition, 2019
• Rajib Mall, “Fundamentals of Software Engineering” ,
Fifth Edition, PHI learning Pvt Ltd, 2018
• Sangeeta Sabharwal, “Software Engineering:
Principles and Techniques”, Second Edition, Published
by New Age International Publishers, 2020
Name of the Experiment
Choose a problem domain and textually write the Functional and Non-Functional requirements of the
domain. While writing make use of elicitation techniques discussed in the class
For a Problem domain develop a Mind-Map.
Draw the static View of the Problem domain of exercise 1 using ER diagram
Draw the functional view of the problem domain of exercise 1 using Data Flow Diagram
Write down the data dictionary and process specifications of the processes of DFD using different
techniques discussed in the class
To determine the nature of roots of quadratic equations, its inputs is triple of +ve integers (say x, y,z) and
values may be from interval [1,100]. The output of the program may be one of the following [Imaginary
roots, Real roots, Equal Roots, not a quadratic equation]. Perform Boundary value analysis, Robust case
testing
For experiment at [Link]. 5 generate the following a. Control flow Graph. B. Cyclomatic complexity C.
Independent paths
Draw the Dynamic view of working of an ATM Machine or Microwave Oven
Generate SRS as per IEEE std-830 using structured analysis techniques for the problem domain you have
described in exercise 1
Develop the Structure chart from the DFD developed in exercise 4
Develop a Use Case Model (use Case diagram and Use case Narratives) for a problem domain
Perform Effort estimation activity and Implement Critical path method using an open- source Tool for a
case study.
Hardware vs. Software
Hardware Software
• Manufactured • Developed/ engineered
• wear out • deteriorate
• Built using components • Custom built
• Relatively simple • Complex
Manufacturing vs. Development
• Once a hardware product has been manufactured, it is difficult or
impossible to modify. In contrast, software products are routinely
modified and upgraded.
• In hardware, hiring more people allows you to accomplish more work, but
the same does not necessarily hold true in software engineering.
• Unlike hardware, software costs are concentrated in design rather than
production.
Software characteristics
• Software is developed or engineered; it is not
manufactured.
• Software does not “wear out” but it does
deteriorate.
• Software continues to be custom built, as industry is
moving toward component based construction.
Changing nature of software
• 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.
• It 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; and multiple external
interfaces.
For eg. Compilers, operating system, drivers etc.
Application Software :
• Application software consists of standalone programs that solve a specific business
need.
• Application software is used to control the business function in real-time.
Engineering /Scientific software:
• Characterized by "number crunching" algorithms.
• Applications range from astronomy to volcano logy, from automotive stress analysis to
space shuttle orbital dynamics, and from molecular biology to automated
manufacturing.
For eg. Computer Aided Design (CAD), system stimulation etc.
Embedded Software:
• It resides in read-only memory and is used to control products and systems
• Embedded software can perform limited and esoteric functions.
For eg. keypad control for a microwave oven.
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 marketplace.
For eg. Word processing, spreadsheet, CG, multimedia, etc.
Web Applications:
• Web apps can be little more than a set of linked hypertext files.
• It evolving into sophisticated computing environments that not only provide standalone
features, functions but also integrated with corporate database 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
For eg. Robotics, expert system, game playing, etc.
Software Process
Overview
• What? A software process – as a framework for the tasks that are
required to build high-quality software.
• Who? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization to an otherwise
chaotic activity.
• Steps? A handful of activities are common to all software processes,
details vary.
• Work product? Programs, documents, and data.
WhatDefinition
•
is software
:
engineering?
• (1) The application of 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) above
• Its a discipline that is concerned with all aspects of software
production.
• Software engineers should adopt
• Systematic and organized approach to their work
• Use appropriate tools and techniques depending on the
problem to be solved
• The development constraints and the resources available
• Apply Engineering Concepts to developing Software
• Challenge for Software Engineers is to produce high quality software
with finite amount of resources & within a predicted schedule
Software Engineering – Layered Technology
Layered Technology
Tools: CASE preferred
Methods: technical “how to’s”
Process model: the “framework”
A quality focus: the “bedrock”
Layered Technology
A quality Focus
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to
development of increasingly more effective approaches to software
engineering.
• The bedrock that supports software engineering is a quality focus.
Process:
• It’s a foundation layer for software engineering.
• It’s define framework for a set of key process areas (KPA) for
effectively manage and deliver quality software in a cost effective
manner
• The processes define the tasks to be performed and the order in
which they are to be performed
Layered Technology
Methods:
• It provide the technical how-to's for building software.
• Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing,
and support.
• There could be more than one technique to perform a task and
different techniques could be used in different situations.
Tools:
• Provide automated or semi-automated support for the
process, methods and quality control.
• 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 (CASE)
Process framework
Why process :
A process defines who is doing what, when and how
to reach a certain goal.
• To build complete software process.
• Identified a small number of framework activities that
are applicable to all software projects, regardless of
their size or complexity.
• It encompasses a set of umbrella activities that are
applicable across the entire software process.
Generic• Communication:
Process Framework Activities
• Heavy communication with customers, stakeholders, team
• Encompasses requirements gathering and related activities
• Planning:
• Workflow that is to follow
• Describe technical task, likely risk, resources will require, work
products to be produced and a work schedule.
• Modeling:
• Help developer and customer to understand requirements (Analysis of
requirements) & Design of software
• Construction
• Code generation: either manual or automated or both
• Testing – to uncover error in the code.
• Deployment:
• Delivery to the customer for evaluation
• Customer provide feedback
Umbrella Activities
• Software project tracking and control
• Assessing progress against the project plan.
• Take adequate action to maintain schedule.
• Formal technical reviews
• Assessing software work products in an effort to uncover and remove errors before goes into
next action or activity.
• Software quality assurance
• Define and conducts the activities required to ensure software quality.
• Software configuration management
• Manages the effects of change.
• Document preparation and production
• Help to create work products such as models, documents, logs, form and list.
• Reusability management
• Define criteria for work product reuse
• Mechanisms to achieve reusable components.
• Measurement
• Define and collects process, project, and product measures
• Assist the team in delivering software that meets customer’s needs.
• Risk management
• Assesses risks that may effect that outcome of project or quality of product (i.e. software)
Capability Maturity Model Integration
(CMMI)
• The Software Engineering Institute (SEI) has developed
process meta-model to measure organization different level
of process capability and maturity.
• CMMI – developed by SEI
• The CMMI defines each process area in terms of “specific
goals” and the “specific practices” required to achieve these
goals.
• Specific goals establish the characteristics that must exist if
the activities implied by a process area are to be effective.
• Specific practices refine a goal into a set of process-related
activities.
CMMI Level
Level 0 (Incomplete) –
• Process are not perform or not achieve all the goals and objectives defined by the CMMI for Level I
capability.
Level 1 (Performed) – All specific goals are performed as per defined by CMMI
Level 2 (Managed) –
• All level 1 criteria have been satisfied
• In addition to Level I;
• People doing work have access to adequate resources to get job done,
• Stakeholders are actively involved,
• Work tasks and products are monitored, controlled, reviewed, and evaluated for conformance to
process description.
Level 3 (Defined) –
• All level 2 criteria have been achieved.
• In addition;
• management and engineering processes documented
• standardized and integrated into organization-wide software process
CMMI Level (cont.)
Level 4 (Quantitatively Managed) -
• All level 3 criteria have been satisfied.
• Software process and products are quantitatively understood
• Controlled using detailed measures and assessment.
Level 5 (Optimized) –
• Continuous process improvement is enabled by quantitative feedback from the process and testing
innovative ideas.
Software Process Models
Software process model
• Process models prescribe a distinct set of activities, actions,
tasks, milestones, and work products required to engineer
high quality software.
• Process models are not perfect, but provide roadmap for
software engineering work.
• Software models provide stability, control, and organization
to a process that if not managed can easily get out of control
• Software process models are adapted to meet the needs of
software engineers and managers for a specific project.
Build and Fix Model
Build and Fix Model
The earlier approach
• Product is constructed without specification or any attempt at design.
• developers simply build a product that is reworked as many times as necessary to
satisfy the client.
• model may work for small projects but is totally unsatisfactory for products of
any reasonable size.
• Maintenance is high.
• Source of difficulties and deficiencies
• impossible to predict
• impossible to manage
Waterfall Model or Classic Life Cycle
Waterfall Model or Classic Life Cycle
Limitations of the waterfall model
• The nature of the requirements will not change very much During development;
during evolution
• The model implies that you should attempt to complete a given stage before
moving on to the next stage
• Does not account for the fact that requirements constantly change.
• It also means that customers can not use anything until the entire system is
complete.
• The model implies that once the product is finished, everything else is
maintenance.
• Surprises at the end are very expensive
• Some teams sit ideal for other teams to finish
• Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the design process.
Problems:
• Real projects are rarely follow the sequential model.
• Difficult for the customer to state all the requirement explicitly.
• Assumes patience from customer - working version of program will not available
until programs not getting change fully.
34
V-Model
Incremental Process Model
Incremental Process Model
C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment
Delivers software in small but usable pieces, each piece builds on
pieces already delivered
The Incremental Model
• Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering
part of the required functionality.
• First Increment is often core product
• Includes basic requirement
• Many supplementary features (known & unknown) remain undelivered
• A plan of next increment is prepared
• Modifications of the first increment
• Additional features of the first increment
• It is particularly useful when enough staffing is not available for the whole
project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product with each
increment.
The Incremental Model
• User requirements are prioritised and the highest priority requirements are
included in early increments.
• Once the development of an increment is started, the requirements are frozen
though requirements for later increments can continue to evolve.
• Customer value can be delivered with each increment so system functionality is
available earlier.
• Early increments act as a prototype to help elicit requirements for later
increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most testing.
Rapid Application Development (RAD) Model
Makes heavy use of reusable software components with an extremely short
development cycle
RAD model
• Communication – to understand business problem.
• Planning – multiple s/w teams works in parallel on diff. system.
• Modeling –
• Business modeling – Information flow among business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?
• Data modeling – Information refine into set of data objects that are needed
to support business.
• Process modeling – Data object transforms to information flow necessary to
implement business.
• Construction – it highlighting the use of pre-existing software
component.
• Deployment – Deliver to customer basis for subsequent iteration.
• RAD model emphasize a short development cycle.
• “High speed” edition of linear sequential model.
• If requirement are well understood and project scope is constrained
then it enable development team to create “ fully functional system”
within a very short time period.
RAD Model
• If application is modularized (“Scalable Scope”), each major
function to be completed in less than three months.
• Each major function can be addressed by a separate team
and then integrated to form a whole.
Problems:
• For large but scalable projects
• RAD requires sufficient human resources
• Projects fail if developers and customers are not committed
in a much shortened time-frame
• Problematic if system can not be modularized
• Not appropriate when technical risks are high ( heavy use of
new technology)
Evolutionary Process Model
•Produce an increasingly more complete version of the
software with each iteration.
•Evolutionary Models are iterative.
•Evolutionary models are:
• Prototyping
• Spiral Model
• Concurrent Development Model
• Fourth Generation Techniques (4GT)
Evolutionary Process Models :
Prototyping
Prototyping cohesive
• Best approach when:
• Objectives defines by customer are general but does not have details like
input, processing, or output requirement.
• Developer may be unsure of the efficiency of an algorithm, O.S., or the form
that human machine interaction should take.
• It can be used as standalone process model.
• Model assist software engineer and customer to better understand what is to be
built when requirement are fuzzy.
• Prototyping start with communication, between a customer and software engineer
to define overall objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement and that is how iteration
occurs during prototype to satisfy the needs of the customer.
Prototyping (cont..)
• Prototype can be serve as “the first system”.
• Both customers and developers like the prototyping paradigm.
• Customer/End user gets a feel for the actual system
• Developer get to build something immediately.
Problem Areas:
• Customer cries foul and demand that “a few fixes” be applied to make
the prototype a working product, due to that software quality suffers
as a result.
• Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.
Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
Evolutionary Model: Spiral Model
Spiral Model
❑ Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model
• It provide potential for rapid development of increasingly more complete
version of the software.
• Using spiral, software developed in as series of evolutionary release.
• Early iteration, release might be on paper or prototype.
• Later iteration, more complete version of software.
• Divided into framework activities (C,P,M,C,D). Each activity represent one
segment.
• Evolutionary process begins in a clockwise direction, beginning at the
center risk.
• First circuit around the spiral might result in development of a product
specification. Subsequently, develop a prototype and then progressively
more sophisticated version of software.
• Unlike other process models that end when software is delivered.
• It can be adapted to apply throughout the life of software.
Spiral Model
Spiral Model (cont.)
Concept Development Project:
• Start at the core and continues for multiple iterations until it is
complete.
• If concept is developed into an actual product, the process
proceeds outward on the spiral.
New Product Development Project:
• New product will evolve through a number of iterations around the
spiral.
• Later, a circuit around spiral might be used to represent a “Product
Enhancement Project”
Product Enhancement Project:
• There are times when process is dormant or software team not
developing new things but change is initiated, process start at
appropriate entry point.
• Spiral models uses prototyping as a risk reduction
mechanism but, more important, enables the developer to
apply the prototyping approach at each stage in the
evolution of the product.
• It maintains the systematic stepwise approach suggested by
the classic life cycle but also incorporates it into an iterative
framework activity.
• If risks cannot be resolved, project is immediately terminated
Problems:
• It may be difficult to convince customers (particularly in
contract situations) that the evolutionary approach is
controllable.
• If a major risk is not uncovered and managed, problems will
undoubtedly occur.
Component Based Development
• component-based development (CBD) model incorporates many of
the characteristics of the spiral model.
• It is evolutionary by nature and iterative approach to create software.
• CBD model creates applications from prepackaged software
components (called classes).
CBD Model
CBD model (cont.)
• Modeling and construction activities begin with identification of candidate
components.
• Classes created in past software engineering projects are stored in a class library
or repository.
• Once candidate classes are identified, the class library is searched to determine if
these classes already exist.
• If class is already available in library extract and reuse it.
• If class is not available in library, it is engineered or developed using
object-oriented methods.
• Any new classes built to meet the unique needs of the application.
• Now process flow return to the spiral activity.
CBD model (cont.)
• CBD model leads to software reusability.
• Based on studies, CBD model leads to 70 % reduction in development
cycle time.
• 84% reduction in project cost.
• Productivity is very high.