Software Engineering

(2-0-2)

CS 3212
Dr. N. Raghu Kisore,
Associate Professor, MEC
 Agile Modelling
➢ practice-based methodology for effective modelling
and documentation of software-based systems.
➢ Model With a Purpose
➢ Multiple Models
➢ Quality Work
➢ Aim for rapid feedback
➢ Software Is Your Primary Goal
➢ Travel Light
 Model With a Purpose
➢Which is more important Product or Process?

➢IBM Way Vs Apple way.

➢Best employees focus on content not process.

--Steve Jobs in ~1998
 Focus points
➢Building models through iterative process

➢Communicate the idea behind the model

through better representation.

The Key is Unified Modeling language (UML)

 Key Points
➢Model with a purpose.
➢Content is more important than representation.
➢Use multiple models.
 How to use it?
➢As Agile Modelling only focusses on the
modelling aspects of the projects, needs to
rely on some other SE process for practical
application.
Process Based Models
 Why is software development so
difficult?
➢ Communication ➢ Project characteristics
– Between customer and – Novelty
developer – Changing requirements
• Poor problem definition is • 5 x cost during development
largest cause of failed
• up to 100 x cost during
software projects
maintenance
– Within development team – Hardware/software
• More people = more configuration
communication
• New programmers need – Security requirements
training – Real time requirements
– Reliability requirements
 Rational Unified Process
➢The critical idea in the Rational Unified Process is
Iterative Development.
➢Iterative Development is successively enlarging
and refining a system through multiple iterations,
using feedback and adaptation.
➢Each iteration will include requirements, analysis,
design, and implementation.
 Unified Process best practices
➢ Get high risk and high value first
➢ Constant user feedback and engagement
➢ Early cohesive core architecture
➢ Test early, often, and realistically
➢ Apply use cases where needed
➢ Do some visual modeling with UML
➢ Manage requirements and scope creep
➢ Manage change requests and configuration
 Steps
➢Inception

➢Elaboration

➢Construction

➢Transition
 Inception
➢The life-cycle objectives of the project are
stated, so that the needs of every stakeholder
are considered. Scope and boundary
conditions, acceptance criteria and some
requirements are established.
 Inception - Entry criteria
➢The expression of a need, which can take any of
the following forms:
• an original vision
• a legacy system
• an RFP (request for proposal)
• the previous generation and a list of enhancements
• some assets (software, know-how, financial assets)
• a conceptual prototype, or a mock-up
 “an original vision”
➢Every hardware and software feature developed at
Apple will have it’s iMac at the centre. -- in 1998.

➢ Every hardware and software feature developed at

Apple will have it’s MacBook at the centre. -- in
2003.

➢Every hardware and software features developed at

Apple will have it’s iPhone/iPad at the centre. -- in
2008.
 Inception - Activities
➢ Formulate the scope of the project.
• Needs of every stakeholder, scope, boundary
conditions and acceptance criteria established.
➢ Plan and prepare the business case.
• Define risk mitigation strategy, develop an initial
project plan and identify known cost, schedule, and
profitability trade-offs.
➢ Synthesize candidate architecture.
• Candidate architecture is picked from various
potential architectures
➢ Prepare the project environment.
 Inception - Exit criteria
➢An initial business case containing at least a
clear formulation of the product vision - the
core requirements - in terms of functionality,
scope, performance, capacity, technology base.
➢Success criteria (example: revenue projection).
➢An initial risk assessment.
➢An estimate of the resources required to
complete the elaboration phase.
 Elaboration
➢An analysis is done to determine the risks,
stability of vision of what the product is to
become, stability of architecture and
expenditure of resources.

iTunes software allows people to copy songs from

MacBook/iMac to iPod in 2001.

iTunes software allows people to copy songs from

any computer to iPod in 2003.
 Elaboration - Entry criteria
➢The products and artifacts described in the
exit criteria of the previous phase.
➢The plan approved by the project
management, and funding authority, and the
resources required for the elaboration phase
have been allocated.
 Elaboration - Activities
➢Define the architecture.
• Project plan is defined. The process, infrastructure
and development environment are described.
➢Validate the architecture.
➢Baseline the architecture.
• To provide a stable basis for the bulk of the design
and implementation effort in the construction
phase.
 Elaboration - Exit criteria
➢A detailed software development plan, with an
updated risk assessment, a management plan, a
staffing plan, a phase plan showing the number
and contents of the iteration , an iteration plan,
and a test plan
➢The development environment and other tools
➢A baseline vision, in the form of a set of
evaluation criteria for the final product
➢A domain analysis model, sufficient to be able
to call the corresponding architecture
‘complete’.
➢An executable architecture baseline.
 Construction
➢The Construction phase is a manufacturing
process. It emphasizes managing resources
and controlling operations to optimize costs,
schedules and quality. This phase is broken
into several iterations.
 Construction - Entry criteria
➢The product and artifacts of the previous
iteration. The iteration plan must state the
iteration specific goals
➢Risks being mitigated during this iteration.
➢Defects being fixed during the iteration.
 Construction - Activities
➢Develop and test components.
• Components required satisfying the use cases,
scenarios, and other functionality for the iteration
are built. Unit and integration tests are done on
Components.

➢Manage resources and control process.

➢Assess the iteration
• Satisfaction of the goal of iteration is determined.
 Construction - Exit Criteria
➢A release description document, which
captures the results of an iteration
➢Test cases and results of the tests conducted
on the products,
➢An iteration plan, detailing the next iteration
➢Objective measurable evaluation criteria for
assessing the results of the next iteration(s).
 Transition
➢The transition phase is the phase where the
product is put in the hands of its end users. It
involves issues of marketing, packaging,
installing, configuring, supporting the user-
community, making corrections, etc.
 Transition - Entry criteria
➢The product and artifacts of the previous
iteration, and in particular a software product
sufficiently mature to be put into the hands of
its users.
 Transition - Activities
➢Test the product deliverable in a customer
environment.
➢Fine tune the product based upon customer
feedback.
➢Deliver the final product to the end user.
➢Finalize end-user support material.
 Transition - Exit criteria
➢An update of some of the previous
documents, as necessary, the plan being
replaced by a “post-mortem” analysis of the
performance of the project relative to its
original and revised success criteria;
➢A brief inventory of the organization’s new
assets as a result this cycle.
Capability Maturity Model
Integration

CMMI
 CMMI
➢ Developed by the Software Engineering Institute of
the Carnegie Mellon University
➢ Framework that describes the key elements of an
effective software process.
➢ Describes an evolutionary improvement path for
software organizations from an ad hoc, immature
process to a mature, disciplined one.
➢ Provides guidance on how to gain control of
processes for developing and maintaining software
and how to evolve toward a culture of software
engineering and management excellence
 Process Maturity Concepts
➢Software Process
• set of activities, methods, practices, and
transformations that people use to develop and
maintain software and the associated products (e.g.,
project plans, design documents, code, test cases,
user manuals)
➢Software Process Capability
• describes the range of expected results that can be
achieved by following a software process
• means of predicting the most likely outcomes to be
expected from the next software project the
organization undertakes
 Process Maturity Concepts
➢Software Process Performance
• actual results achieved by following a software
process
➢Software Process Maturity
• extent to which a specific process is explicitly
defined, managed, measured, controlled and
effective
• implies potential growth in capability
• indicates richness of process and consistency with
which it is applied in projects throughout the
organization

Product Vs Process debate?

 CMMI: two variants
➢Staged
• Built on Maturity levels

➢Continuous
• Built on capability levels
 CMM Levels
➢Maturity level indicates level of process
capability:
1. Initial
2. Repeatable
3. Defined→ officially labelled as CMMI Level 3
4. Managed
5. Optimizing→ officially labelled as CMMI Level 5
 Why measure software and
software process?
➢Obtain data that helps us to better control
• schedule
• cost
• quality of software products

You can’t improve something that you can’t measure.

Consistent measurement provide
data for
➢Quantitatively expressing requirements,
goals, and acceptance criteria.
➢Monitoring progress and anticipating
problems.
➢Quantifying tradeoffs used in allocating
resources.
➢Predicting schedule, cost and quality.
Progression
 Level 1: Initial
➢Initial: The software process is characterized as
ad hoc, and occasionally even chaotic. Few
processes are defined, and success depends on
individual effort.
• At this level, frequently have difficulty making
commitments that the staff can meet with an orderly
process
• Products developed are often over budget and
schedule
• Wide variations in cost, schedule, functionality and
quality targets
• Capability is a characteristic of the individuals, not of
the organization
 Level 2: Repeatable
➢Basic process management processes are
established to track cost, schedule, and
functionality. The necessary process discipline is
in place to repeat earlier successes on projects
with similar applications.
• Realistic project commitments based on results
observed on previous projects.
• Software project standards are defined and faithfully
followed
• Processes may differ between projects
• Process is disciplined
• earlier successes can be repeated
 Level 3: Defined
➢The software process for both management
and engineering activities is documented,
standardized, and integrated into a standard
software process for the organization. All
projects use an approved, tailored version of
the organization’s standard software process
for developing and maintaining software.
 Level 4: Managed
➢Detailed measures of the software process and
product quality are collected. Both the
software process and products are
quantitatively understood and controlled.
• Narrowing the variation in process performance to
fall within acceptable quantitative bounds
• When known limits are exceeded, corrective action
can be taken
• Quantifiable and predictable
o predict trends in process and product quality
 Level 5: Optimizing
➢Continuous process improvement is enabled
by quantitative feedback from the process and
from piloting innovative ideas and
technologies.
➢Goal is to prevent the occurrence of defects
• Causal analysis
➢Data on process effectiveness used for cost
benefit analysis of new technologies and
proposed process changes
 Level 2 KPAs
➢Requirements Management
• Establish common understanding of customer
requirements between the customer and the
software project
• Requirements is basis for planning and managing the
software project
• Not working backwards from a given release date!

➢Software Project Planning

• Establish reasonable plans for performing the
software engineering activities and for managing the
software project
 Level 2 KPAs
➢Software Project Tracking and Oversight
• Establish adequate visibility into actual progress
• Take effective actions when project’s performance
deviates significantly from planned

➢Software Subcontract Management

• Manage projects outsourced to subcontractors

➢Software Quality Assurance

• Provide management with appropriate visibility into
o process being used by the software projects
o work products
 Level 2 KPAs
➢Software Configuration Management
• Establish and maintain the integrity of work
products
• Product baseline
• Baseline authority
 Level 3 KPAs
➢ Organization Process Focus
• Establish organizational responsibility for software process
activities that improve the organization’s overall software
process capability

➢ Organization Process Definition

• Develop and maintain a usable set of software process
assets
o stable foundation that can be institutionalized
o basis for defining meaningful data for quantitative process
management
 Level 3 KPAs
➢ Training Program
• Develop skills and knowledge so that individual can
perform their roles effectively and efficiently
• Organizational responsibility
• Needs identified by project
➢ Integrated Software Management
• Integrated engineering and management activities
• Engineering and management processes are tailored from
the organizational standard processes
• Tailoring based on business environment and project
needs
 Level 3 KPAs
➢ Software Product Engineering
• technical activities of the project are well defined (SDLC)
• correct, consistent work products
➢ Intergroup Coordination
• Software engineering groups participate actively with
other groups
➢ Peer Reviews
• early defect detection and removal
• better understanding of the products
• implemented with inspections, walkthroughs, etc
 Level 4 KPAs
➢Quantitative Process Management
• control process performance quantitatively
• actual results from following a software process
• focus on identifying and correcting special causes
of variation with respect to a baseline process

➢Software Quality Management

• quantitative understanding of software quality
oproducts
oprocess
 Level 5 KPAs
➢Process Change Management.
• continuous process improvement to improve
quality, increase productivity, decrease cycle time.
➢Technology Change Management.
• identify and transfer beneficial new technologies.
otools
omethods
oprocesses
➢Defect Prevention.
• causal analysis of defects to prevent recurrence.
 What are the benefits?
➢Helps forge a shared vision of what software
process improvement means for the
organization.
➢Defines set of priorities for addressing
software problems.
➢Supports measurement of process by
providing framework for performing reliable
and consistent appraisals.
➢Provides framework for consistency of
processes and product.
 Measurements
➢Historical
➢Plan
➢Actual
➢Projections
 Requirement Specifications
➢MIL-STD-498
• 22 Data Item Descriptions

➢IEEE Std 830-1998

 MIL-STD-498
➢ Plans
• Design, Installation and Transition
➢ Concept/requirements [Specifications]
• Operational concept, system/sub system, SRS, Interface
requirement specifications
➢ Design [Descriptions]
• System/Subsystem Design, Software Design, Database Design,
Database Design, Interface Design
➢ Qualification/test products
• Software Test Plan, Software Test Description, Software Test
report
➢ User/operator manuals
➢ Support manuals
➢ Software
• Software product specification and version description
Interfaces
 Software Design
➢Architectural Design
➢Frameworks
• Qt

➢ToolKits
• Gnu Toolkit

➢Design Patterns
➢Design Diagrams
➢ The reference for
design patterns
➢ “Gang of four”
➢ Based on Erich
Gamma’s Ph.D. thesis
 Design Patterns
➢OO systems exhibit recurring structures that
promote
o abstraction
o flexibility
o modularity
o elegance
 Design Pattern
➢abstracts a recurring design structure
➢Comprises class and/or object
• dependencies
• structures
• interactions
• conventions
 Four Basic Parts
1. Name
2. Problem (including “forces”)
3. Solution
4. Consequences & trade-offs of application

Language- & implementation-independent

 Motivation & Concept
➢ Codify good design
• distill & generalize experience.
• aid to novices & experts alike.
➢ Give design structures explicit names
• common vocabulary
• reduced complexity
• greater expressiveness
➢ Capture & preserve design information
• articulate design decisions succinctly
• improve documentation
➢ Facilitate restructuring/refactoring
• patterns are interrelated
• additional flexibility
 Benefits
➢Design reuse.
➢Uniform design vocabulary.
➢Enhance understanding, restructuring, & team
communication
➢Basis for automation
➢Transcends language-centric biases/myopia
➢Abstracts away from many unimportant
details
Design Space for GoF Patterns

➢ Scope: domain over which a pattern applies

➢ Purpose: reflects what a pattern does
 Class Vs Object Patterns
➢Class Patterns:
• tend to use inheritance to establish relationships.
• generally fix the relationship at compile time.
• are less flexible and dynamic and less suited to
polymorphic approaches.
➢Object Patterns:
• the more common of the two, specify the
relationships between objects.
• avoid fixing the class that accomplishes a given task at
compile time.
• Object patterns mostly use object composition to
establish relationships between objects.
 Patterns based on Purpose
➢Creational Patterns: provide ways to create
objects while hiding the creation logic.
➢Structural Patterns: deal with class and object
composition. The concept of inheritance is used to
compose interfaces and define ways to compose
objects to obtain new functionality.
➢Behavioral Patterns: are specifically concerned
with communication between objects.
 Design Pattern Template
NAME Scope Purpose
Intent
short description of the pattern & its purpose
Also Known As
Any aliases this pattern is known by
Motivation
motivating scenario demonstrating pattern’s use
Applicability
circumstances in which pattern applies
Structure
graphical representation of the pattern using modified UML notation
Participants
participating classes and/or objects & their responsibilities
 Design Pattern Template
Collaborations
how participants cooperate to carry out their responsibilities
Consequences
the results of application, benefits, liabilities
Implementation
pitfalls, hints, techniques, plus language-dependent issues
Sample Code
sample implementations in C++, Java, C#, Smalltalk, C, etc.
Known Uses
examples drawn from existing systems
Related Patterns
discussion of other patterns that relate to this one
 Important Patterns
➢Factory Method
➢Adapter(class and object)
➢Chain of responsibility
➢Iterator
➢Observer
➢Singleton
 Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

➢ generalization: an inheritance relationship

o inheritance between classes
o interface implementation

➢ association: a usage relationship

o dependency
o aggregation
o composition

Software Design (UML)

 Car

Association types
➢aggregation: "is part of" aggregation

– Weak relationship Engine

– symbolized by a clear white diamond

➢composition: "is entirely made of" Book

composition
– stronger version of aggregation
1
– the parts live and die with the whole
*
– symbolized by a black diamond
Page
➢dependency: "uses temporarily"
– symbolized by dotted line
– often is an implementation dependency
detail, not an intrinsic part
of that object's state Lottery Random
Ticket
Observer Object Behavioral

Intent
define a one-to-many dependency between objects so that when
one object changes state, all dependents are notified & updated

Applicability
• an abstraction has two aspects, one dependent on the other
• a change to one object requires changing untold others
• an object should notify unknown other objects
 Observer Object Behavioral

Structure
Observer Pattern
Observer Pattern: Sequence Diagram

https://howtodoinjava.com/design-patterns/behavioral/observer-design-pattern/
• ConcereteObserver myobserver(mySubject)
• ConcereteSubject mySubject;
An object registers with it’s subject in the
constructor
myobserver(ConcereteSubject Subj){
Subj.attach(this);
}
 Observer Object Behavioral

Consequences
+ modularity: subject & observers may vary independently
+ extensibility: can define & add any number of observers
+ customizability: different observers offer different views of subject
– unexpected updates: observers don’t know about each other
– update overhead: might need hints or filtering

Implementation
– subject-observer mapping
– dangling references
– update protocols: the push & pull models
– registering modifications of interest explicitly

Known Uses
– Smalltalk Model-View-Controller (MVC)
– InterViews (Subjects & Views, Observer/Observable)
– Andrew (Data Objects & Views)
– Pub/sub middleware (e.g., androidOS, CORBA Notification Service, Java Messaging Service)
– Mailing lists
ITERATOR Object Behavioral
Intent
access elements of a container without exposing its representation

Applicability
– require multiple traversal algorithms over a container
– require a uniform traversal interface over different containers
– when container classes & traversal algorithm must vary independently

Structure
Iterator Pattern
Iterator Sample code
(C++ STL)
 ITERATOR Object Behavioral
Iterators are used heavily in the C++ Standard
Template Library (STL)
int main (int argc, char *argv[]) {
vector<string> args;
for (int i = 0; i < argc; i++)
args.push_back (string (argv[i]));
for (vector<string>::iterator i (args.begin ()); i != args.end (); i++)
cout << *i;
cout << endl;
return 0;
}

for (Glyph::iterator i = glyphs.begin ();

i != glyphs.end ();
i++)
...
ITERATOR Object Behavioral
Consequences
+ flexibility: aggregate & traversal are independent
+ multiple iterators & multiple traversal algorithms
– additional communication overhead between iterator & aggregate

Implementation
– internal versus external iterators
– violating the object structure’s encapsulation
– robust iterators
– synchronization overhead in multi-threaded programs
– batching in distributed & concurrent programs

Known Uses
– C++ STL iterators
– JDK Enumeration, Iterator
– Unidraw Iterator
SINGLETON Object Creational
SINGLETON Object Creational

Consequences
+Controlled access to sole instance
+Reduced name space.
+Permits a variable number of instances
 Implementation (Java)
// Classical Java implementation of singleton
// design pattern
class Singleton
{
private static Singleton obj;

// private constructor to force use of

// getInstance() to create Singleton object
private Singleton() {}

public static Singleton getInstance()

{
if (obj==null)
obj = new Singleton();
return obj;
}
}
Implementation (C++)
SINGLETON Object Creational

Other Challenges: (pg 148 and 149)

Model-View-Controller Pattern
➢MVC consists of three kinds of objects:
• Model – the application object used to move data
• View – UI (screen presentation)
• Controller – defines the way the UI reacts to user
inputs

➢MVC is useful when you have to update

multiple views using the same data.
 MVC – What Is the Problem?
➢The same enterprise data needs to be
accessed when presented in different views:
e.g. HTML, JFC/swing, XML
➢The same enterprise data needs to be
updated through different interactions
➢Supporting multiple types of views and
interactions should not impact the
components that provide the core
functionality of the enterprise application
MVC Structure
 Software Quality
Chap 19, 20, 21 from Roger Pressman

➢Difficult to Define.
➢user satisfaction = compliant product + good
quality + delivery within budget and schedule
 ISO 9126 Quality Factors
➢ Functionality
– suitability, accuracy, interoperability, compliance, and
security.
➢ Reliability
– maturity, fault tolerance, recoverability.
➢ Usability
– Under standability, learnability, operability.
➢ Efficiency
– time behaviour, resource behaviour.
➢ Maintainability
– analysability, changeability, stability, testability.
➢ Portability
– adaptability, installability, conformance, replaceability.
 Software Quality Dilemma
➢ If you produce a software system that has terrible
quality, you lose because no one will want to buy
it.
Vs
➢ on the other hand you spend infinite time,
extremely large effort, and huge sums of money
to build the absolutely perfect piece of software,
then it’s going to take so long to complete and it
will be so expensive to produce that you’ll be out
of business anyway.
“Good Enough” Software ?
 Good Enough Software?
➢Automotive Domain
• Autonomous Driving
• Electric Vehicles

➢Aerospace industry
➢Defense Industry
➢Security Risks.
 Software Quality Assurance
➢Impact of Management Actions
• Estimation decisions.
• Scheduling decisions.
• Risk-oriented decisions.
 Achieving Software Quality
➢Software Engineering Methods
➢Project Management Techniques
➢Quality Control
➢Quality Assurance
 Software Reviews
➢Review Metrics:
• Preparation effort, Ep
• Assessment effort, Ea
• Rework effort, Er
• Work product size, WPS
• Minor errors found, Errminor
• Major errors found, Errmajor
 Analyzing Metrics
➢Ereview = Ep + Ea + Er

➢Errtot = Errminor + Errmajor

𝐸𝑟𝑟𝑡𝑜𝑡
➢Error density =
𝑊𝑃𝑆
 Software Quality Assurance
Elements
➢ Standards.
➢ Reviews and audits.
➢ Testing.
➢ Error/defect collection and analysis.
➢ Change management.
➢ Education.
➢ Vendor management.
➢ Security management.
➢ Safety.
➢ Risk management.
 SQA Tasks for SQA group
➢ Prepares an SQA plan for a project.
➢ Participates in the development of the project’s software
process description.
➢ Reviews software engineering activities to verify
compliance with the defined software process.
➢ Audits designated software work products to verify
compliance with those defined as part of the software
process.
➢ Ensures that deviations in software work and work
products are documented and handled according to a
documented procedure.
➢ Records any noncompliance and reports to senior
management.
Goals, Attributes, and Metrics
➢Requirements quality.
➢Design quality.
➢Code quality.
➢Quality control effectiveness.
What does this code do?

Approx. Value of PI
What does this code do?
Prints “Hello World”
 Assuring Software Quality
Challenge:
Software is not a tangible entity to
physically measure quality!!!

How do you assure quality for something that

you can’t physically hold?

Formal Methods !?!?!

 Statistical SQA
➢ Information about software errors and defects is collected
and categorized.
➢ An attempt is made to trace each error and detect to its
underlying cause (e.g., non conformance to specifications,
design error, violation of standards, poor communication
with the customer).
➢ Using the Pareto principle (80 percent of the defects can be
traced to 20 percent of all possible causes), isolate the 20
percent (the vital few ).
➢ Once the vital few causes have been identified, move to
correct the problems that have caused the errors and
defects.

You can’t improve something that you can’t measure.

 Real Life Observations
➢ Incomplete or erroneous specifications (IES).
➢ Misinterpretation of customer communication (MCC).
➢ Intentional deviation from specifications (IDS).
➢ Violation of programming standards (VPS).
➢ Error in data representation (EDR).
➢ Inconsistent component interface (ICI).
➢ Error in design logic (EDL).
➢ Incomplete or erroneous testing (IET).
➢ Inaccurate or incomplete documentation (IID).
➢ Error in programming language translation of design (PLT).
➢ Ambiguous or inconsistent human/computer interface (HCI).
• Function1(int a , int b)
• Function1(int a, int b, int c= 0)

• Fucntion1(10,11)
Software Reliability
 Software Reliability
Measures of Reliability and Availability:
MTBF = MTTF + MTTR
➢MTBF:
Mean Time between Failure
➢MTTF
Mean Time to Failure
➢MTTR:
Mean Time to Repair
 Others
➢failures-in-time (FIT)
• a statistical measure of how many failures a
component will have over 1 billion hours of
operation.

➢Software availability
𝑀𝑇𝑇𝐹
• Availability = * 100
𝑀𝑇𝑇𝐹+𝑀𝑇𝑇𝑅