Software Engineering

(19CSE314)
Introduction
NOTICE: Slides are extracted from “Software Engineering – A Practitioner’s Approach” by Pressman R S & Other Internet resources.

Dr. S. Sreenivasa Chakravarthi

Associate Professor,
Department of Computer Science & Engineering,
Amrita School of Computing, Amrita Vishwa Vidyapeetham, Chennai.
1
Course Outcomes
On successful completion of the Course, students will be able to:

CO1: Understand and apply the principles of Software Engineering

CO2: Understand various software process models

CO3: Apply the appropriate software design methodology for a given scenario

CO4: Evaluate a system developed for real-world applications in Agile Mode

CO5: Understand and implement various Industry Standards

2
 Evaluation Criteria
External
Internal (70) Total
(30)
Total
Components Marks
Marks

Mid term 20 20
End Internal +
Continuous Assessment Semester External =
Quiz 10 = 30 100
(Theory)
50
Lab Assignments (4) 20
Continuous Assessment
(Lab): Capstone Project Capstone Project
20
Evaluation

3
Discussion Contents
 Unit –I
 Process Models – Introduction & Overview
 Introduction to Agile
 Agile Manifesto & its Principles
 Over-view of Various Agile methodologies - Scrum, XP, Lean, and Kanban
 Agile Requirements - User personas, story mapping, user stories, estimating
and prioritizing stories
 INVEST & Acceptance Criteria, Definition of Done
 Release planning
 Key aspects of Scrum: Roles - Product Owner, Scrum Master, Team,
Manager in scrum
 Scrum process flow: Product backlog, sprints backlog, scrum meetings,
demos
 How sprint works: Sprint Planning, Daily scrum meeting, updating sprint
backlog, Burn down chart, sprint review, sprint retrospective
 Scrum Metrics velocity, burn down, defects carried over 4
Discussion Outcomes
On successful completion of the Unit, students will be able to:

CO1: Understand and apply the principles of Software Engineering

CO2: Understand various software process models

CO3: Apply the appropriate software design methodology for a given scenario

CO4: Evaluate a system developed for real-world applications in Agile Mode

CO5: Understand and implement various Industry Standards

5
Introduction to Software
Defining a Software!!
Software is:
(1) Instructions that when executed provide desired features, function, and
performance;
(2) Data structures that enable the programs to adequately manipulate information;
(3) Descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs;
Or
The software can be best defined as a set of instructions, technically referred to as
programs, that perform operations and specific tasks based on the commands of
the user. Every single task that a user intends to perform is regulated by
software.
No wonder, there are other more relative definitions! However, more formal
definitions probably won’t measurably improve the understanding.
To accomplish that, it’s important to examine the characteristics of
software that make it different from other things that human beings build.
Introduction to Software
Characteristics of Software
1. Software is developed or
engineered; it is not
manufactured in the
classical sense.
2. Software doesn't wear out.
3. Most Software aims to be
custom built.
Introduction to Software
Types of Software
 System Software: This is a collection of programs written to service other programs and
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
 Application Software: This is software is stand-alone programs that solve a specific business need
or control business functions in real time (e.g., point-of-sale transaction processing, real-time
manufacturing process control).
 Engineering / Scientific Software: This is based on “number crunching” algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to space shuttle
orbital dynamics, and from molecular biology to automated manufacturing Computer-aided design,
system simulation, and other interactive applications
 Embedded Software: This 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, like, key pad control for a
microwave oven, digital functions in an automobile, etc.,
 Product-line Software: This is designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory
control products) or address mass consumer markets (e.g., MS Office, Multimedia, DBMS, and
personal and business financial applications).
 Web Applications: In other words, Web Apps. This network-centric software not only provide
stand-alone features, computing functions, and content to the end user but also are integrated with
corporate databases and business applications
 AI Software: This makes use of nonnumerical algorithms to solve complex problems that are not
amenable to computation or straightforward analysis
Software Engineering
Engineering & Software Engineering
Engineering is just application of scientific and practical knowledge to
design, build and create products and processes
How to Engineer the Software?
 Understand the problem before you build a solution
 Design is a pivotal software engineering activity
 Both Quality and Maintainability are an outgrowth of good design.

So, Software Engineering is……. The application of engineering to

software development; that describe what goes into the software
development process.
The term Software Engineering is coined by Margaret Hamilton.
Software Engineering
Defining Software Engineering
According to IEEE,
Software Engineering is the application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software;
Why Software Engineering?
Is Software Engineering Important?
How Software Engineering?
Software Engineering is a Layered Technology

Tools

Methods
Process Models
Quality Focus
Organizations commit to Quality!!!
Holds the technology layers together and enables
rational and timely development of the software
Provides “technical how-to’s” for building software
Provides the automated or semiautomated support for the
Process and the Methods
Software Process
A few Terminologies to understand….
A Process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
An Activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
An Action (e.g., architectural design) encompasses a set of tasks that
produce a major work product (e.g., an architectural design model).
A Task focuses on a small, but well-defined objective (e.g., conducting a
unit test) that produces a tangible outcome.

A Process Framework establishes the foundation

for a complete Software Engineering process
 Software Process Framework
Software Process Framework

 Communication  Software Project Tracking

 Planning and Control
 Modeling  Risk Management
 Construction  Software Quality Assurance
 Deployment  Technical Reviews
 Measurement
 Software Configuration
Management
 Reusability Management
 Work Product Preparation
and Production
Software Process Flows
Software Process Flows
Process Flows & SDLC
Software Process & Software Development Life Cycle (SDLC)

Deployment Communication
Model
Modeling
Software Planning
Software
Process
Validation Development
Flows
Life Cycle

Modeling
Construction
Modeling

SDLC is a structured process that enables the production of high-

quality, low-cost software, in the shortest possible production time.
SDLC Phases
Phases of Software Development Life Cycle (SDLC)
Process Models/SDLC Models
SDLC Models: Waterfall Model
Process Models/SDLC Models
SDLC Models: V-Model
Process Models/SDLC Models
SDLC Models: Incremental Model
Process Models/SDLC Models
SDLC Models: Iterative Model
Process Models/SDLC Models
SDLC Models: Prototyping Model

SDLC Models: Evolutionary Model

Process Models/SDLC Models
SDLC Models: Spiral Model
Agile Processes
Introduction to “Agile”

Obviously, anything that’s not Fragile is Agile…!

Agile Processes
Agile is a project management & software development approach that
aims to be more effective.
How??
 It focuses on delivering smaller pieces of work regularly instead
of one big launch.
 Allows teams to adapt to changes quickly and provide customer
value faster.
Agile methodologies are iterative and incremental, which means it's
known for breaking a project into smaller parts and adjusting to
changing requirements.
It facilitates to prioritize flexibility, collaboration, and customer
satisfaction.
Major companies like Facebook, Google, and Amazon use Agile because
of its adaptability and customer-focused approach.
Agile Mindset
Agile is not just a methodology; it’s a mindset.
Agile isn't about following specific rituals or
techniques. Instead, it's a bunch of methods that
show a dedication to quick feedback and
always getting better.
Agile Mindset
Agile mindset suits the Flexibility!
Why Flexibility in Software Development?
 New requirements emerge when the software is used
 It is difficult to predict all the software requirements in advance
 The business environment changes
 Defects need tobe fixed
 New equipment must be accommodated
 The performance or reliability may have to be improved
Agile Manifesto - Who & When
17th Feb, 2001, a ski resort, Utah;
•Kent Beck, who co-created eXtreme Programming (XP)
•Mike Beedle, co-author of Agile Software Development with Scrum
•Arie van Bennekum, owner of Integrated Agile
•Alistair Cockburn, IT strategist and creator of the Crystal Agile Methodology
•Ward Cunningham, inventor of wiki and first to coin term technical debt
•Martin Fowler, software practitioner, and partner at Thoughtworks
•James Grenning, author of Test-Driven Development
•Jim Highsmith, creator of Adaptive Software Development (ASD)
•Andrew Hunt, co-author of The Pragmatic Programmer
•Ron Jeffries, co-creator of eXtreme Programming (XP)
•Jon Kern, who still helps organizations with agile today
•Brian Marick, a computer scientist and author of several books on programming
•Robert C. Martin, also known as “Uncle Bob,” who consults via Clean Coding
•Steve Mellor, a computer scientist also credited with inventing Object-Oriented System Analysis (OOSA)
•Ken Schwaber, who co-created Scrum with Jeff Sutherland
•Jeff Sutherland, the inventor, and co-creator of Scrum
•Dave Thomas, programmer, and co-author of The Pragmatic Programmer
Despite having widely varying opinions on the right way to approach software
development;
The crew agreed on at least one thing: the status quo was not working.
Agile Manifesto – What
Proposed a Manifesto, built on 4 values & 12 principles
Agile Manifesto – What
Proposed a Manifesto, built on 4 values & 12 principles
Agile Process
Who, When & Why?

Sprints Use Cases

Agile Process
Characteristics of Agile Process
Agile Process
Best Practices in Agile Process
Agile Methodologies
Familiar Agile Process
Agile Methodologies
Scrum
Agile Methodologies
Kanban
Agile Methodologies
Lean
Agile Methodologies
Extreme Programming / Development
 Coding
 Testing
 Listening
 Designing
Agile Requirements
Why’s the difference
 There is NO definitive model for gathering requirements
 Concepts, process and tools available to help in gathering
requirements
 Agile requirements rooted in Flexibility
More accurate and meaningful outcome
Avoid off-target deliveries and missed schedules
 Focused on developing faster while addressing customer needs
 Collaboration critical
Everyone involved in the project have a common understanding of
the needs
Get early and continuous feedback from Customer
Agile Requirements
2 – Stages of Requirements gathering
 Big Picture
 Details
Agile Requirements
Steps for gathering Requirements
Agile Requirements
Steps for gathering Requirements
User Persona
User Persona represents fictional characteristics of the people
that are most likely to buy your product.
It provides a detailed summary of your ideal customer including
demographic traits such as location, age, job title as well as
psychographic traits such as behaviors, feelings, needs, and challenges.
Why Personas??
Team members can uncover the answers to questions like:
 Who is our target user?
 What are their goals and aspirations?
 What are their challenges?
 What stage are they in the buying journey?
 Who is the key decision-maker?
User Persona
Creating Personas
User Persona
Creating Personas
User Persona
Creating Personas
1. Use readily available data from trusted sources over embarking on user-
research
2. Ask questions of users when you need them over exploration
3. Focus Personas on motivations over comprehensive narrative
Psychological aspects
Why does he want to do an interaction in that way?
Why does he want that feature at all?
Hierarchy of Needs
Safety – does this feature help with health, employment, housing?
Community – does this feature help meeting their need to feel a part of the group?
Esteem – does this feature help to give confidence, or show them some form of
achievement
Self-actualization – does this feature help them be creative or spontaneous
4. Include values over wants and needs
5. Articulate trust relationships over generic interaction design preferences
6. Put it on an A3 over multiple written pages
Use Cases
User Cases: It is a description of the ways in which a user
interacts with a system or product.
It may establish the success scenarios, the failure scenarios,
and any critical variations or exceptions.
A use case can be written or made visual with the help of a use case
model tool.

Purpose of Use Case:

 Manage scope
 Establish requirements
 Outline the ways a user will interact with the system
 Visualize system architecture
Use Cases
How to write a use case: A use case document should establish and identify
a few key components:
System: A system is the product, service, or software under discussion.
Objective: This is the goal the use case aims to achieve.
Preconditions: These are conditions that must be true before the use case begins.
Actors: An actor is a user or anything else that exhibits behavior when interacting with
the system. The actor could be another system, a piece of hardware, or an entire
organization. Basic flow: This is the ideal sequence of actions where everything works
as expected. It’s the main, happy path of how a process should unfold.
Scenario: It is a specific sequence of actions and interactions between actors and the
system under discussion; it is also called a use case instance.
Use case: A use case outlines the success and failure scenarios that can occur when the
actor(s) interact with the system. In this section, you’d establish the main success
scenario, i.e., the most desirable outcome between the actor and the system.
Postconditions: This is the state of the system and actors after the use case has been
completed.
Use Stories
Use story: It is a short, simple description of a feature told from
the perspective of the person who desires the new capability,
usually a user or customer of the system.
User story statements are short; they are not intended to fully
describe how the software should work.
User stories are written throughout the agile project. Everyone on
the team participates with the goal of creating a product backlog
that fully describes the functionality.
General use case format: A user does (A), the system responds (B).
The user story template:
As a < WHO >, I want < WHAT > so that < WHY >.
Use Stories
User Story Examples:
As a site visitor, I can see a list of all upcoming “Certification Courses”
and can explore the page through them if there are a lot, so I can
choose the best course for me.
As a site visitor, I can access old news that is no longer on the home
page, so I can access things I remember from the past or that
others mention to me.
As a trainer, I want my profile to list my upcoming classes and include
a link to a detailed page about each so that prospective attendees can
find my courses.
As a site member, I can fill out an application to become a Certified
AWS Trainer so that I can teach Cloud Architecture course and
certify others.
Use Cases vs User Stories
Use Cases Vs User Stories
Estimating and Prioritizing
Why estimate User Stories: Why?
 Improved Decision-Making
 Better Coordination
 Better Risk Management

Absolute and Relative way of Estimating!

Tips for estimating
 Gut feel
 Comparison: This works best when you can size the work as being a
little more than job “A,” but a little less than job “B.”
 Split the work: This is a good way to handle some work that is much
larger than the rest, but becomes inaccurate when you split up the work
too finely.
Estimating and Prioritizing
Prioritizing User Stories: Deciding priority is primarily a job for customers,
because they are ultimately responsible for deciding what should be delivered to the
business and when. However, priorities also need to be set in response to technical
business issues:
 Value
 Risks
 Business
 Technical
 Resolving Dependencies

INVEST acronym stands for Independent, Negotiable,Valuable,

Estimable, Small, and Testable.
It is used to quickly review the quality of the user story presented
to the team to work.
Acceptance Criteria
Acceptance criteria are detailed specifications that define when a
product is considered complete and ready for release.
They act as a roadmap stating what success looks like for a specific task
or user story in a project.
Acceptance Criteria
Why Acceptance criteria???
Acceptance Criteria
How to write Acceptance Criteria
#1. Understand the user story
#2. Start with a clear goal
#3. Choose an acceptance criteria format
#4. Be specific and testable
#5. Include edge cases (unexpected behaviours)
#6. Collaborate with the team
#7. Prioritise and validate
#8. Review and revise regularly
#9. Keep it concise
#10. Provide examples
Acceptance Criteria
Acceptance criteria
Acceptance Criteria
Acceptance criteria
Acceptance Criteria
Acceptance criteria
Definition of Done (DoD)
The Definition of Done is a formal description of the state of the
Increment when it meets the quality measures required for the
product. Teams may define “Done” at different levels
Definition of Done (DoD)
Difference between The Definition of Done & Acceptance Criteria
Release Planning
Agile release planning is an approach to product management that
takes into account the intangible and flexible nature of software
development—as part of this approach, teams plan iterative sprints
across incremental releases.
How to create the Release Plan:
Step 1: Define your vision
Step 2: Rank the product backlog
Step 3: Hold a release planning meeting
 Review roadmap
 Review architecture
 Review velocity and iteration schedule
 Establish the “Definition of Done” for the release
Step 4: Finalize and share product release calendar
 Thank You
Books & Resources to be followed:
Pressman R S, Bruce R. Maxim “Software Engineering – A Practitioner’s Approach”, McGraw-Hill, 8th Edition, 2019,
and, Other Internet Resources.

63