B.TECH (R-22 Regulation) (Ii Year - I Sem) (2023-24) : Department of CSE
B.TECH (R-22 Regulation) (Ii Year - I Sem) (2023-24) : Department of CSE
Department of CSE
(Emerging Technologies)
B.TECH(R-22 Regulation)
SOFTWARE ENGINEERING
(R22A0505)
LECTURE NOTES
MALLA REDDY COLLEGE OF ENGINEERING & TECHNOLOGY
(Autonomous Institution – UGC, Govt. of India)
Recognized under 2(f) and 12(B) of UGC ACT 1956
(Affiliated to JNTUH, Hyderabad, Approved by AICTE-Accredited by NBA & NAAC – ‘A’ Grade - ISO 9001:2015 Certified)
Maisammaguda, Dhulapally (Post Via. Hakimpet), Secunderabad–500100, Telangana State, India
Software Engineering
B.Tech – CSE (Emerging Technologies) R-22
SOFTWARE ENGINEERING
(R22A0505)
Prepared by
G.Gayatri
Assistant Professor
31.07.2023
Software Engineering
B.Tech – CSE (Emerging Technologies) R-22
EMERGING TECHNOLOGIES
Vision
Mission
The department of CSE (Emerging Technologies) is committed to:
To offer highest Professional and Academic Standards in terms of Personal growth and
satisfaction.
Make the society as the hub of emerging technologies and thereby capture
opportunities in new age technologies.
To create a benchmark in the areas of Research, Education and Public Outreach.
To provide students a platform where independent learning and scientific study are
encouraged with emphasis on latest engineering techniques.
QUALITY POLICY
To pursue continual improvement of teaching learning process of Undergraduate and
Post Graduate programs in Engineering & Management vigorously.
To provide state of art infrastructure and expertise to impart the quality education and
research environment to students for a complete learning experiences.
To offer quality relevant and cost- effective programs to produce engineers as per
requirements of the industry need.
Software Engineering
SYLLABUS
SOFTWARE ENGINEERING
(R22A0505)
COURSE OBJECTIVES:
1. To learn the idea of decomposing the given problem into Analysis, Design, Implementation,
Testing and Maintenance phases.
2. To understand software process models such as waterfall and evolutionary models and software
requirements and SRS document.
3. To understand different software design and architectural styles & software testing approaches such as
unit testing and integration testing.
4. To understand quality control and how to ensure good quality software through quality assurance.
5. To gain the knowledge of how Analysis, Design, Implementation, Testing and Maintenance
processes are conducted in a real time software projects.
UNIT - I:
Introduction to Software Engineering: The evolving role of software, Changing Nature of Software,
Software myths.
A Generic view of process: Software engineering- A layered technology, a process framework, The
Capability Maturity Model Integration (CMMI).
Process models: The waterfall model, Spiral models, Agile Methodology.
UNIT – II:
Software Requirements: Functional and non-functional requirements, User requirements, System
requirements, Interface specification, the software requirements document.
Requirements engineering process: Feasibility studies, Requirements elicitation and analysis,
Requirements validation, Requirements Management.
UNIT - III
Design Engineering: Design process and Design quality, Design concepts, the design model.
Creating an architectural design: Software architecture, Data design, Architectural styles and patterns,
Architectural Design, Conceptual Model of UML, Basic Structural Modeling, Class Diagrams, Sequence
Diagrams, Collaboration Diagrams, Usecase Diagrams, Component Diagrams.
UNIT - IV
Testing Strategies: A strategic approach to software testing, test strategies for conventional software,
Black-Box and White-Box testing, Validation testing, System testing, the art of Debugging.
Metrics for Process and Products: Software Measurement, Metrics for Software quality.
UNIT – V
Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk identification, Risk projection,
Risk refinement, RMMM.
Quality Management: Software Quality, Quality concepts, Software quality assurance, Software Reviews,
Formal-technical reviews, Statistical Software quality Assurance, Software reliability, The ISO 9000 quality
standards.
TEXT BOOKS:
1. Software Engineering, A practitioner’s Approach-Roger S. Pressman, 6th Edition, McGraw Hill International Edition.
2. SoftwareEngineering-Sommerville,7thedition, Pearson Education.
COURSE OUTCOMES:
1. Understand software development life cycle Ability to translate end-user requirements into system and
software requirements.
2. Structure the requirements in a Software Requirements Document and Analyze Apply various process
models for a project, Prepare SRS document for a project
3. Identify and apply appropriate software architectures and patterns to carry out high level design of a system
and be able to critically compare alternative choices.
4. Understand requirement and Design engineering process for a project and Identify different principles to
create an user interface
5. Identify different testing methods and metrics in a software engineering project
INDEX
II
Software requirement 23
III
Design engineering 41
IV
Testing strategies and risk management 49
V Quality management 62
UNIT - I
INTRODUCTION:
Software Engineering is a framework for building software and is an engineering approach to software
development. Software programs can be developed without S/E principles and methodologies but they are
indispensable if we want to achieve good quality software in a cost effective manner.
Software is defined as:
Engineering is the branch of science and technology concerned with the design, building, and use of
engines, machines, and structures. It is the application of science, tools and methods to find cost effective
solution to simple and complex problems.
SOFTWARE ENGINEERING is defined as a systematic, disciplined and quantifiable approach for the
development, operation and maintenance of software.
Characteristics of software
• Software is developed or engineered, but it is not manufactured in the classical sense.
• Software does not wear out, but it deteriorates due to change.
• Software is custom built rather than assembling existing components.
System software. System software is a collection of programs written to service other programs
Embedded software-- resides in read-only memory and is used to control products and systems forthe
consumer and industrial markets.
Artificial intelligence software. Artificial intelligence (AI) software makes use of nonnumeric
algorithms to solve complex problems that are not amenable to computation or straightforward analysis
Engineering and scientific software. Engineering and scientific software have been characterized by
"number crunching" algorithms.
Page5
Software Myths
Software myths are preconceived notions about software and its creation that people hold to be true but are
in fact untrue. Professionals in Software Engineering have now identified the software myths that have
persisted throughout the years.
These fallacies are common knowledge to managers and software developers. However, it might be
challenging to change old behaviours.
Types of Software Myths
There are three kinds of software myths that are busted down in the article.
Management Myths
Customer Myths
Practitioner’s Myths
Management Myths
Managers are often under pressure for software development under a tight budget, improved quality, and a
packed schedule, often believing in some software myths. Following are some management myths.
Myth 1
Manuals containing simple procedures, principles, and standards are enough for developers to acquire all
the information they need for software development.
Reality 1
Standards discussed in modules are often outdated, inadaptable, and incomplete. Not all the standards in the
manual are known to developers as not all means tend to decrease delivery time and maintain high quality.
Most of the time, developers are unaware of these standards.
Myth 2
Falling behind on schedule could be taken care of by adding more programmers.
Reality 2
Adding more human resources to already late projects worsens the problem. Developers working on the
project have to educate the newcomers, further delaying the project. Also, newcomers are far less
productive than developers already working on them. As a result, time spent on educating newcomers
could not meet the immediate reduction in work.
Myth 3
If a project is outsourced to a third party, we could just relax and wait for them to build it.
Page6
Reality 3
If an organisation is not able to manage and control software projects internally, then the organisation will
suffer invariably when they outsourced the project.
Customer Myths
Customer Myths are generally due to false expectations by customers, and these myths end up leaving
customers with dissatisfaction with the software developers. Following are some customer myths.
Myth 1
Not only detailed conditions a vague collection of software objectives is enough to begin programming
with.
Reality 1
If the objectives of software are vague enough to become ambiguous, then it's inevitable that software will
not do what the customer wants. Often when software development starts without a complete picture
in mind,
it results in software failure.
Myth 2
Softwares are flexible, and developers could accommodate any change later. Developers can quickly take
care of these changes in requirements.
Reality 2
Longer the time for which software has proceeded for development, it becomes more and more difficult to
accommodate any changes. Any change causes an increase in additional costs because incorporating
changes at later stages needs redesigning and extra resources.
Practitioner’s Myths
Developers often work under management pressure to complete software within a timeframe, with fewer
resources often believing in these software myths. Following are some practitioners’ myths.
Myth 1
Once the software is developed or the code is delivered to the customer, the developer's work ends.
Reality 1
A significant chunk of developers' work, i.e., 50-60 % of all the efforts expended on software, will be spent
after the customer provides the software. Major requirements would get found missing, and new bugs may
get discovered, and so on.
Page7
Myth 2
Software testing could only be possible when the software program starts running.
Reality 2
Quality of software could be measured at any phase of development by applying some QA mechanism.
Myth 3
Unnecessary Documentation slows down the process of software development.
Reality 3
Software engineering is about creating a quality product at every level and not about adding unnecessary
work. Proper documentation of software helps us guide the user and enhance the quality, which reduces the
amount of rework.
SOFTWARE APPLICATIONS
System Software –
System Software is necessary to manage the computer resources and support the execution of
application programs. Software like operating systems, compilers, editors and drivers, etc., come
under this category. A computer cannot function without the presence of these. Operating systems are
needed to link the machine-dependent needs of a program with the capabilities of the machine on
which it runs. Compilers translate programs from high-level language to machine language.
Application Software –
Application software is designed to fulfill the user’s requirement by interacting with the user directly.
It could be classified into two major categories:- generic or customized. Generic Software is the
software that is open to all and behaves the same for all of its users. Its function is limited and not
customized as per the changing requirements of the user. However, on the other hand, Customized
software the software products which are designed as per the client’s requirement, and are not available
for all.
Embedded Software –
This type of software is embedded into the hardware normally in the Read-Only Memory (ROM) as a
part of a large system and is used to support certain functionality under the control conditions.
Examples are software used in instrumentation and control applications like washing machines,
satellites, microwaves, etc.
Page8
Reservation Software –
A Reservation system is primarily used to store and retrieve information and perform transactions
related to air travel, car rental, hotels, or other activities. They also provide access to bus and railway
reservations, although these are not always integrated with the main system. These are also used to
relay computerized information for users in the hotel industry, making a reservation and ensuring that
the hotel is not overbooked.
Business Software –
This category of software is used to support business applications and is the most widely used
category of software. Examples are software for inventory management, accounts, banking, hospitals,
schools, stock markets, etc.
Entertainment Software –
Education and entertainment software provides a powerful tool for educational agencies, especially
those that deal with educating young children. There is a wide range of entertainment software such as
computer games, educational games, translation software, mapping software, etc.
Scientific Software –
Scientific and engineering software satisfies the needs of a scientific or engineering user to perform
enterprise-specific tasks. Such software is written for specific applications using principles,
techniques, and formulae specific to that field. Examples are software like MATLAB, AUTOCAD,
PSPICE, ORCAD, etc.
Utilities Software –
The programs coming under this category perform specific tasks and are different from other software
in terms of size, cost, and complexity. Examples are anti-virus software, voice recognition software,
compression programs, etc.
Page9
A GENERIC VIEW OF PROCESS SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
Page10
A PROCESS FRAMEWORK
A PROCESS FRAMEWORK :
Common process framework Umbrella activities Framework activities Tasks, Milestones, deliverables
SQApoints.
Page11
A PROCESS FRAMEWORK
Used as a basis for the description of process models Generic process activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
A PROCESS FRAMEWORK
Generic view of engineering complimented by a number of umbrella activities
Software project tracking and control
Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management
Page12
CMMI process meta model can be represented in different ways
1.A continuous model
2.A staged model
Continuous model:
-Lets organization select specific improvement that best meet its business objectives and minimize risk-
Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated according to the following
capability levels.
• Incomplete -Process is adhoc . Objective and goal of process areas are not known
• Performed -Goal, objective, work tasks, work products and other activities of software process
arecarried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
• Quantitatively Managed -Metrics and indicators are available to measure the process and quality
• Optimized - Continuous process improvement based on quantitative feed back from the user
-Use of innovative ideas and techniques, statistical quality control for process improvement.
Page13
CMMI - Staged model
- This model is used if you have no clue of how to improve the process for quality software.
- It gives a suggestion of what things other organizations have found helpful to work first
- Levels are called maturity levels
PROCESS PATTERNS
Software Process is defined as collection of Patterns. Process pattern provides a template. It comprises of
• Process Template
-Pattern Name
-Intent
-Types
-Task pattern
- Stage pattern
-Phase Pattern
• Initial Context
• Problem
• Solution
• Resulting Context
• Related Patterns
PROCESS ASSESSMENT
Does not specify the quality of the software or whether the software will be delivered on time or will it stand
up to the user requirements. It attempts to keep a check on the current state of the software process with the
intention of improving it.
PROCESS ASSESSMENT Software Process Software Process Assessment Software Process Improvement
Motivates Capability determination.
ISO 9001:2000 for software Personal and Team Software Process Personal software
processPLANNING
HIGH LEVEL DESIGN
HIGH LEVEL DESIGN REVIEW
DEVELOPMENT
POSTMORTEM
Page14
Incremental: PSP is incremental, meaning that it breaks down the development process into
smaller, more manageable pieces that can be completed in a step-by-step fashion.
PROCESS MODELS
This Model suggests a systematic, sequential approach to SW development that begins at the
system leveland progresses through analysis, design, code and testing
.
Page15
Communication
Planning
Modeling
Construction
Deployment
Page16
INCREMENT N
Communication
Planning
Modeling
Construction
Deployment
Page17
THE RAD MODEL
• Multiple software teams work in parallel on different functions
• Modeling encompasses three major phases: Business modeling, Data modeling and process modeling
• Construction uses reusable components, automatic code generation and testing
Problems in RAD
• Requires a number of RAD teams
• Requires commitment from both developer and customer for rapid-fire completion of activities
• Requires modularity
• Not suited when technical risks are high
EVOLUTIONARY PROCESSMODEL
PROTOTYPING
Page18
– human/machine interaction
STEPS IN PROTOTYPING
• Begins with requirement gathering
• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of customer
•
LIMITATIONS OF PROTOTYPING
• In a rush to get it working, overall software quality or long term maintainability are generally overlooked
• Use of inappropriate OS or PL
• Use of inefficient algorithm
An evolutionary model which combines the best feature of the classical life cycle and
the iterative nature of prototype model. Include new element : Risk element. Starts in middle and
continually visits the basic tasks of communication, planning, modeling, construction and deployment
Page19
THE SPIRAL MODEL
Page20
Does not focus on flexibility and extensibility (more emphasis on high quality)
• Requirement is balance between high quality and flexibility and extensibility
Evolved by Rumbaugh, Booch, Jacobson. Combines the best features their OO models. Adopts additional
features proposed by other experts. Resulted in Unified Modeling Language (UML). Unified process
developed Rumbaugh and Booch. A framework for Object-Oriented Software
Engineering using UML
• INCEPTION PHASE
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE
2. Elaboration Phase
*Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model
3. Construction Phase
*Design model
Page21
*System components
*Test plan and procedure
*Test cases
*Manual
4. Transition Phase
*Delivered software increment
*Beta test results
*General user feedback
Page22
UNIT-II
SOFTWARE REQUIREMENTS
IEEE defines Requirement as :
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or a system
component tosatisfy constract, standard, specification or formally imposed document
3. A documented representation of a condition nor capability as in 1 or 2
SOFTWARE REQUIREMENTS
• Encompasses both the User’s view of the requirements( the external view ) and the Developer’s
view( inside characteristics)
User’s Requirements
--Statements in a natural language plus diagram, describing the services the system is expected to provide
and the constraints
• System Requirements --Describe the system’s function, services and operational condition
SOFTWARE REQUIREMENTS
• System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
• Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development process and standards
--Apply to system as a whole
• Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system
FUNCTIONAL REQUIREMENTS
• Should be both complete and consistent
• Completeness
-- All services required by the user should be defined
• Consistent
-- Requirements should not have contradictory definition
• Difficult to achieve completeness and consistency for large system
NON-FUNCTIONAL REQUIREMENTS
2. Organizational Requirements
Page23
--Derived from policies and procedures
--Include the following:
• Delivery
• Implementation
• Standard
3. External Requirements
-- Derived from factors external to the system and its development process
--Includes the following
• Interoperability
• Ethical
• Legislative
•
PROBLEMS FACED USING THE NATURAL LANGUAGE
1. Lack of clarity-- Leads to misunderstanding because of ambiguity of natural language
2. Confusion-- Due to over flexibility, sometime difficult to find whether requirements are same or
distinct.
3. Amalgamation problem-- Difficult to modularize natural language requirements
Interface Specification
• Working of new system must match with the existing system
• Interface provides this capability and precisely specified
Purpose of SRS
• Communication between the Customer, Analyst, system developers, maintainers,
• firm foundation for the design phase
• support system testing activities
• Support project management and control
• controlling the evolution of the system
Page25
SPIRAL REPRESENTATION OF REQUIREMENTS ENGINEERING PROCESS
Process represented as three stage activity. Activities are organized as an iterative process around a spiral.
Early in the process, most effort will be spent on understanding high-level business and the use requirement.
Later in the outer rings, more effort will be devoted to system requirements engineering and system
modeling
Three level process consists of: 1.Requirements elicitation
1. Requirements specification
2. Requirements validation
FEASIBILITY STUDIES
Starting point of the requirements engineering process
• Input: Set of preliminary business requirements, an outline description of the system and how the
system is intended to support business processes
• Output: Feasibility report that recommends whether or not it is worth carrying out further
Feasibility report answers a number of questions:
1. Does the system contribute to the overall objective
2. Can the system be implemented using the current technology and within given cost and schedule
3. Can the system be integrated with other system which are already in place.
Page26
Process activities
1. Requirement Discovery -- Interaction with stakeholder to collect their requirements including
domain and documentation
2. Requirements classification and organization -- Coherent clustering of requirements from
unstructured collection of requirements
3. Requirements prioritization and negotiation -- Assigning priority to requirements
--Resolves conflicting requirements through negotiation
4. Requirements documentation -- Requirements be documented and placed in the next round of
spiral
5. The spiral representation of Requirements Engineering
2. Interviewing--Puts questions to stakeholders about the system that they use and the system to be
developed. Requirements are derived from the answers.
Two types of interview
– Closed interviews where the stakeholders answer a pre-defined set of questions.
– Open interviews discuss a range of issues with the stakeholders for better understanding their
needs.
Effective interviewers
a) Open-minded: no pre-conceived ideas
b) Prompter: prompt the interviewee to start discussion with a question or a proposal
3. Scenarios --Easier to relate to real life examples than to abstract description. Starts with an outline
Page27
of the interaction and during elicitation, details are added to create a complete description of that
interaction
Scenario includes:
1. Description at the start of the scenario
2. Description of normal flow of the event
3. Description of what can go wrong and how this is handled
4. Information about other activities parallel to the scenario
5. Description of the system state when the scenario finishes
LIBSYS scenario
• Initial assumption: The user has logged on to the LIBSYS system and has located the journal
containing the copy of the article.
• Normal: The user selects the article to be copied. He or she is then prompted by the system to either
provide subscriber information for the journal or to indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an organizational account number.
• The user is then asked to fill in a copyright form that maintains details of the transaction and they
then submit this to the LIBSYS system.
• The copyright form is checked and, if OK, the PDF version of the article is downloaded to the
LIBSYS working area on the user’s computer and the user is informed that it is available. The user is asked
to select a printer and a copy of the article is printed
LIBSYS scenario
What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form should
be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s request
for the article is rejected.
• The payment may be rejected by the system. The user’s request for the article is rejected.
• The article download may fail. Retry until successful or the user terminates the session..
4. Use cases -- scenario based technique for requirement elicitation. A fundamental feature of UML,
notation for describing object-oriented system models. Identifies a type of interaction and the actors
involved. Sequence diagrams are used to add information to a Use case
Article printing use-case Article printing LIBSYS use cases Article printing Article search
User administration Supplier Catalogue services Library
REQUIREMENTS VALIDATION
Concerned with showing that the requirements define the system that the customer wants. Important
because errors in requirements can lead to extensive rework cost
Validation checks
1. Validity checks --Verification that the system performs the intended function by the user
2. Consistency check --Requirements should not conflict
3. Completeness checks --Includes requirements which define all functions and constraints intended
by the system user
4. Realism checks --Ensures that the requirements can be actually implemented
5. Verifiability -- Testable to avoid disputes between customer and developer.
Page28
VALIDATION TECHNIQUES
1. REQUIREMENTS REVIEWS
Reviewers check the following:
(a) Verifiability: Testable
(b) Comprehensibility
(c) Traceability
(d) Adaptability
2. PROTOTYPING
An essential first stage in requirement management process. Planning process consists of the following
1. Requirements identification -- Each requirement must have unique tag for cross reference and
traceability
2. Change management process -- Set of activities that assess the impact and cost of changes
3. Traceability policy -- A matrix showing links between requirements and other elements of
software development
4. CASE tool support --Automatic tool to improve efficiency of change management process.
Automated tools are required for requirements storage, change management and traceability management
Traceability
Maintains three types of traceability information.
1. Source traceability--Links the requirements to the stakeholders
2. Requirements traceability--Links dependent requirements within the requirements document
3. Design traceability-- Links from the requirements to the design module
Page29
2. Change analysis and costing--Impact analysis in terms of cost, time and risks
3. Change implementation--Carrying out the changes in requirements document, system design andits
implementation
SYSTEM MODELS
Used in analysis process to develop understanding of the existing system or new system. Excludes details.
An abstraction of the system
Types of system models
1. Context models
2. Behavioural models
3. Data models
4. Object models
5. Structured models
CONTEXT MODELS
A type of architectural model. Consists of sub-systems that make up an entire system
First step: To identify the subsystem.
Represent the high level architectural model as simple block diagram
• Depict each sub system a named rectangle
• Lines between rectangles indicate associations between subsystems Disadvantages
--Concerned with system environment only, doesn't take into account other systems, which may take data
or give data to the model
The context of an ATM system consists of the following Auto-teller system Security system Maintenance
system Account data base Usage database Branch accounting system Branch counter system
BEHAVIOUR MODELS
Data flow models --Concentrate on the flow of data and functional transformation on that data. Show the
processing of data and its flow through a sequence of processing steps. Help analyst understand what is
going on
Advantages
-- Simple and easily understandable
-- Useful during analysis of requirements
STATE MACHINE MODELS
Describe how a system responds to internal or external events. Shows system states and events that cause
transition from one state to another. Does not show the flow of data within the system. Used for modeling
of real time systems
Exp: Microwave oven
Assumes that at any time, the system is in one of a number of possible states. Stimulus triggers a
transitionfrom on state to another state
Disadvantage
-- Number of possible states increases rapidly for large system models
DATA MODELS
Page30
Used to describe the logical structure of data processed by the system. An entity-relation- attribute model
sets out the entities in the system, the relationships between these entities and the entity attributes. Widely
used in database design. Can readily be implemented using relational databases. No specific notation
provided in the UML but objects and associations can be used.
OBJECT MODELS
An object oriented approach is commonly used for interactive systems development. Expresses the systems
requirements using objects and developing the system in an object oriented PL such as c++ A object class:
An abstraction over a set of objects that identifies common attributes. Objects are instances of object class.
Many objects may be created from a single class.
Analysis process
-- Identifies objects and object classes Object class in UML
--Represented as a vertically oriented rectangle with three sections
(a) The name of the object class in the top section
(b) The class attributes in the middle section
(c) The operations associated with the object class are in lower section.
Page31
UML Diagrams
The UML is a graphical language for visualizing, specifying, constructing, and documenting the
artifacts of a software-intensive system. The UML gives you a standard way to write a system's
blueprints, covering conceptual things, such as business processes and system functions, as well as
concrete things, such as classes written in a specific programming language, database schemas, and
reusable software components.
Model
A model is a simplification of reality. A model provides the blueprints of a system. A model may be
structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the
dynamics of the system.
Why do we model
We build models so that we can better understand the system we are developing.
We build models of complex systems because we cannot comprehend such a system in its entirety.
Principles of Modeling
There are four basic principles of model
1. The choice of what models to create has a profound influence on how a problem is attacked
and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models.
An Overview of UML
Page32
The Unified Modeling Language is a standard language for writing software blueprints. The
UML may be used to visualize, specify, construct, and document the artifacts of a software-
intensive system.
The UML is appropriate for modeling systems ranging from enterprise information systems to
distributed Web-based applications and even to hard real time embedded systems. It is a very
expressive language, addressing all the views needed to develop and then deploy such systems.
Constructing the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages
Documenting a healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include
o Requirements
o Architecture
o Design
o Source code
o Project plans
o Tests
o Prototypes
o Releases
To understand the UML, you need to form a conceptual model of the language, and this requires
learning three major elements:
1. Things
2. Relationships
3. Diagrams
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things
Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. In all, there are seven kinds of structural
things.
1. Classes
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes
Page33
Class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle,
usually including its name, attributes, and operations.
Interface
Interface is a collection of operations that specify a service of a class or component.
An interface therefore describes the externally visible behavior of that element.
An interface might represent the complete behavior of a class or component or only a part of that
behavior.
An interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it
is typically attached to the class or component that realizes the interface
Collaboration defines an interaction and is a society of roles and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. Therefore,
collaborations have structural, as well as behavioral, dimensions. A given class might participate in
several collaborations.
Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its
name
Use case
Use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor
Use case is used to structure the behavioral things in a model.
A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with
solid lines, usually including only its name
Active class is just like a class except that its objects represent elements whose behavior is concurrent
with other elements. Graphically, an active class is rendered just like a class, but with heavy lines,
usually including its name, attributes, and operations
Component is a physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs
Page34
Node is a physical element that exists at run time and represents a computational resource, generally
having at least some memory and, often, processing capability. Graphically, a node is rendered as a
cube, usually including only its name
Behavioral Things are the dynamic parts of UML models. These are the verbs of a model, representing
behavior over time and space. In all, there are two primary kinds of behavioral things
Interaction
state machine
Interaction
Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a
particular context to accomplish a specific purpose
An interaction involves a number of other elements, including messages, action sequences and links
Graphically a message is rendered as a directed line, almost always including the name of its operation
State Machine
State machine is a behavior that specifies the sequences of states an object or an
interaction goes through during its lifetime in response to events, together with its
responses to those events
State machine involves a number of other elements, including states, transitions,
events and activities
Graphically, a state is rendered as a rounded rectangle, usually including its name and
its substates
Grouping Things:-
1. are the organizational parts of UML models. These are the boxes into which a model can be
decomposed
2. There is one primary kind of grouping thing, namely, packages.
Package:-
A package is a general-purpose mechanism for organizing elements into groups. Structural things,
behavioral things, and even other grouping things may be placed in a package
Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents
Annotational things are the explanatory parts of UML models. These are the comments you may
apply to describe about any element in a model.
A note is simply a symbol for rendering constraints and comments attached to an element or a
collection of elements.
Page35
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or
graphical comment
Relationships in the UML: There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:-
Dependency is a semantic relationship between two things in which a change to one thing may
affect the semantics of the other thing
Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label
Association is a structural relationship that describes a set of links, a link being a connection among
objects.
Graphically an association is rendered as a solid line, possibly directed, occasionally including a label,
and often containing other adornments, such as multiplicity and role names
Aggregation is a special kind of association, representing a structural relationship between a whole and
its parts. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead
pointing to the parent
Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract
that another classifier guarantees to carry out. Graphically a realization relationship is rendered as a
cross between a generalization and a dependency relationship
Diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and arcs (relationships).
In theory, a diagram may contain any combination of things and relationships.
For this reason, the UML includes nine such diagrams:
Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
State chart diagram
Activity diagram
Component diagram
Deployment diagram
Page36
Class diagram
A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
Class diagrams that include active classes address the static process view of a system.
Object diagram
Object diagrams represent static snapshots of instances of the things found in class diagrams
These diagrams address the static design view or static process view of a system
An object diagram shows a set of objects and their relationships
Page37
Interaction Diagrams
Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams
Interaction diagrams address the dynamic view of a system
A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the
Page38
Statechart diagram
A statechart diagram shows a state machine, consisting of states, transitions, events, and activities
Statechart diagrams address the dynamic view of a system
They are especially important in modeling the behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of an object
Page39
Component diagram
A component diagram shows the organizations and dependencies among a set of components.
Component diagrams address the static implementation view of a system
They are related to class diagrams in that a component typically maps to one or more classes,
interfaces, or collaborations
Deployment diagram
A deployment diagram shows the configuration of run-time processing nodes and the components that
live on them
Deployment diagrams address the static deployment view of an architecture
Page40
UNIT III
DESIGN ENGINEERING
QUALITY GUIDELINES
• Uses recognizable architectural styles or patterns
• Modular; that is logically partitioned into elements or subsystems
• Appropriate data structures for the classes to be implemented
• Independent functional characteristics for components
• Repeatable method
QUALITY ATTRIBUTES
• Functionality
* Feature set and capabilities of programs
* Security of the overall system
• Usability
* user-friendliness
* Documentation
• Reliability
* Evaluated by measuring the frequency and severity of failure
• Supportability
* Extensibility
* Adaptability
* Serviceability
DESIGN CONCEPTS
1. Abstractions
2. Architecture
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Re-factoring
9. Design Classes
ABSTRACTION
Many levels of abstraction.
Highest level of abstraction: Solution is slated in broad terms using the language of the problem
environment Lower levels of abstraction: More detailed description of the solution is provided
• Procedural abstraction-- Refers to a sequence of instructions that a specific and limited function
• Data abstraction-- Named collection of data that describe a data object
PATTERNS
Provides a description to enables a designer to determine the followings:
(a). whether the pattern is applicable to the current
work(b). Whether the pattern can be reused
(c). Whether the pattern can serve as a guide for developing a similar but functionally or structurally
different pattern
MODULARITY
Divides software into separately named and addressable components, sometimes called modules. Modules
are integrated to satisfy problem requirements. Consider two problems p1 and p2. If the complexity of p1
iscp1 and of p2 is cp2 then effort to solve p1=cp1 and effort to solve p2=cp2 If cp1>cp2 then ep1>ep2
The complexity of two problems when they are combined is often greater than the sum of the perceived
complexity when each is taken separately.
• Based on Divide and Conquer strategy : it is easier to solve a complex problem when broken into sub-
modules
INFORMATION HIDING
Information contained within a module is inaccessible to other modules who do not need such information.
Achieved by defining a set of Independent modules that communicate with one another only that
information necessary to achieve S/W function. Provides the greatest benefits when modifications are
required during testing and later. Errors introduced during modification are less likely to propagate to other
location within the S/W.
FUNCTIONAL INDEPENDENCE
A direct outgrowth of Modularity. abstraction and information hiding. Achieved by developing a module
with single minded function and an aversion to excessive interaction with other modules. Easier to develop
and have simple interface. Easier to maintain because secondary effects caused b design or code
modification are limited, error propagation is reduced and reusable modules are possible. Independence is
assessed by two quantitative criteria:
(1) Cohesion
(2) Coupling
Cohesion -- Performs a single task requiring little interaction with other components Coupling--Measure of
interconnection among modules. Coupling should be low and cohesion should be high for good design.
DESIGN CLASSES
Class represents a different layer of design architecture. Five types of Design Classes
1. User interface class -- Defines all abstractions that are necessary for human computer interaction 2.
Business domain class -- Refinement of the analysis classes that identity attributes and services to implement
some of business domain
Page42
3. Process class -- implements lower level business abstractions required to fully manage the business
domain classes
4. Persistent class -- Represent data stores that will persist beyond the execution of the software
5. System class -- Implements management and control functions to operate and communicate within the
computer environment and with the outside world.
2. Identification of attribute and functions and their encapsulation of these within a class 3.Mechanism for
representation of the content of each data object. Class diagrams may be used 4. Refinement of data design
elements from requirement analysis to component level design. 5.Information hiding
6. A library of useful data structures and operations be developed.
7. Software design and PL should support the specification and realization of abstract data types.
ARCHITECTURAL STYLES
Describes a system category that encompasses:
(1) a set of components
(2) a set of connectors that enables “communication and coordination
(3) Constraints that define how components can be integrated to form the system
(4) Semantic models to understand the overall properties of a system
Data-flow architectures
Shows the flow of input data, its computational components and output data. Structure is also called pipe
and Filter. Pipe provides path for flow of data. Filters manipulate data and work independent of its
neighboring filter. If data flow degenerates into a single line of transform, it is termed as batch sequential.
Call and return architectures
Achieves a structure that is easy to modify and scale .Two sub styles
(1) Main program/sub program architecture
-- Classic program structure
- Main program invokes a number of components, which in turn invoke still other components
(2) Remote procedure call architecture
-- Components of main program/subprogram are distributed across computers over network
Object-oriented architectures
The components of a system encapsulate data and the operations. Communication and coordination
between components is done via message
Layered architectures
Page44
A number of different layers are defined Inner Layer( interface with OS)
• Intermediate Layer Utility services and application function) Outer Layer (User interface)
Page45
ARCHITECTURAL PATTERNS
A template that specifies approach for some behavioral characteristics of the system Patterns are imposed
on the architectural styles
Pattern Domains
1. Concurrency
--Handles multiple tasks that simulate parallelism.
--Approaches (Patterns)
(a) Operating system process management pattern
(b) A task scheduler pattern
2. Persistence
--Data survives past the execution of the process
--Approaches (Patterns)
(a) Data base management system pattern
(b) Application Level persistence Pattern( word processing software)
3. Distribution
-- Addresses the communication of system in a distributed environment
--Approaches (Patterns)
(a) Broker Pattern
-- Acts as middleman between client and server.
Performing User interface design: Golden rules, User interface analysis and design, interface
analysis,interface design steps, Design evaluation.
Golden Rules
1. Place the user in control
2. Reduce the user’s memory load
3. Make the interface consistent
Place the User in Control
• Define interaction modes in a way that does not force a user into unnecessary or undesired actions.
• Streamline interaction as skill levels advance and allow the interaction to be customized.
• Design for direct interaction with objects that appear on the screen.
Make the Interface Consistent. Allow the user to put the current task into a meaningful context. Maintain
consistency across a family of applications. If past interactive models have created user expectations, do not
make changes unless there is a compelling reason to do so.
The overall process for analyzing and designing a user interface begins with the creation of different models
of system function. There are 4 different models that is to be considered when a user interface is to be
analyzed and designed.
User Interface Design Models
User model —Establishes a profile of all end users of the system
Page46
Design model — A design model of the entire system incorporates data, architectural, interface and
procedural representation of the software.
A design realization of the user model User’s Mental model (system perception). the user’s mental image
of what the interface is Implementation model — the interface “look and feel” coupled with supporting
information that describe interface syntax and semantics
Users can be categorized as
1. Novice – No syntactic knowledge of the system and little semantic knowledge of the application or
computer usage of the system
2. Knowledgeable, intermittent users- Reasonable semantic knowledge of the application but low recall of
syntactic information to use the system
3. Knowledgeable, frequent users- Good semantic and syntactic knowledge User interface analysis and
design process
• The user interface analysis and design process is an iterative process and it can be represented as a spiral
model
It consists of framework activities 1.User, task and environment analysis 2.Interface design 3.Interface
construction 4.Interface validation
Page47
Interface analysis
-Understanding the user who interacts with the system based on their skill levels.i.e, requirement
gathering
-The task the user performs to accomplish the goals of the system are identified, described and elaborated.
Analysis of work environment.
Interface design
In interface design, all interface objects and actions that enable a user to perform all desired task are
defined
Implementation
A prototype is initially constructed and then later user interface development tools may be used to
complete the construction of the interface.
Validation
The correctness of the system is validated against the user requirement
Interface Analysis
Interface analysis means understanding
– (1) the people (end-users) who will interact with the system through the interface;
– (2) the tasks that end-users must perform to do their work,
– (3) the content that is presented as part of the interface
– (4) the environment in which these tasks will be conducted.
Page48
UNIT– IV
Testing Strategies
Software is tested to uncover errors introduced during design and construction. Testing often accounts for
More project effort than other s/e activity. Hence it has to be done carefully using a testing strategy.
The strategy is developed by the project manager, software engineers and testing specialists. Testing is the
process of execution of a program with the intention of finding errors Involves 40% of total project cost
Testing Strategy provides a road map that describes the steps to be conducted as part of testing. It should
incorporate test planning, test case design, test execution and resultant data collection and execution
Validation refers to a different set of activities that ensures that the software is traceable to the Customer
requirements. V&V encompasses a wide array of Software Quality Assurance
A strategic Approach for Software testing
Testing is a set of activities that can be planned in advance and conducted systematically. Testing strategy
Should have the following characteristics:
-- usage of Formal Technical reviews(FTR)
-- Begins at component level and covers entire system
-- Different techniques at different points
-- conducted by developer and test group
-- should include debugging
Software testing is one element of verification and validation.
Verification refers to the set of activities that ensure that software correctly implements a specific
function. ( Ex: Are we building the product right? )
Validation refers to the set of activities that ensure that the software built is traceable to customer
requirements. ( Ex: Are we building the right product ? )
Testing Strategy
Testing can be done by software developer and independent testing group. Testing and debugging are
different activities. Debugging follows testing Low level tests verifies small code segments. High level tests
validate major system functions against customer requirements
Test Strategies for Conventional Software:
Testing Strategies for Conventional Software can be viewed as a spiral consisting of four levels of testing:
1) Unit Testing
2)Integration Testing
3)Validation Testing and
4) System Testing
Unit Testing begins at the vortex of the spiral and concentrates on each unit of software in source code. It
uses testing techniques that exercise specific paths in a component and its control structure to ensure
complete coverage and maximum error detection. It focuses on the internal processing logic and data
Page49
structures. Test cases should uncover errors.
Boundary testing also should be done as s/w usually fails at its boundaries. Unit tests can be designed before
coding begins or after source code is generated.
Integration testing: In this the focus is on design and construction of the software architecture. It addresses
the issues associated with problems of verification and program construction by testing inputs and outputs.
Though modules function independently problems may arise because of interfacing. This technique
uncovers errors associated with interfacing. We can use top-down integration wherein modules are
integrated by moving downward through the control hierarchy, beginning with the main control module.
The other strategy is bottom –up which begins construction and testing with atomic modules which are
combined into clusters as we move up the hierarchy. A combined approach called Sandwich strategy can be
used i.e., top down for higher level modules and bottom-up for lower level modules.
Validation Testing: Through Validation testing requirements are validated against s/w constructed. These
are high-order tests where validation criteria must be evaluated to assure that s/w meets all functional,
behavioural and performance requirements. It succeeds when the software functions in a manner that can
be reasonably expected by the customer.
1)Validation Test Criteria
2)Configuration Review
3)Alpha And Beta Testing
The validation criteria described in SRS form the basis for this testing. Here, Alpha and Beta testing is
performed. Alpha testing is performed at the developers site by end users in a natural setting and with a
controlled environment. Beta testing is conducted at end-user sites. It is a “live” application and environment
is not controlled. End-user records all problems and reports to developer. Developer then
Page50
makes modifications and releases the product.
System Testing: In system testing, s/w and other system elements are tested as a whole. This is the last
high-order testing step which falls in the context of computer system engineering. Software is combined
with other system elements like H/W, People, Database and the overall functioning is checked by conducting
a series of tests. These tests fully exercise the computer based system.
The types of tests are:
1. Recovery testing: Systems must recover from faults and resume processing within a prespecified time. It
forces the system to fail in a variety of ways and verifies that recovery is properly performed. Here the Mean
Time To Repair (MTTR) is evaluated to see if it is within acceptable limits.
2. Security Testing: This verifies that protection mechanisms built into a system will protect it from improper
penetrations. Tester plays the role of hacker. In reality given enough resources and time it is possible to
ultimately penetrate any system. The role of system designer is to make penetration cost more than the value
of the information that will be obtained.
3. Stress testing: It executes a system in a manner that demands resources in abnormal quantity, frequency
or volume and tests the robustness of the system.
4. Performance Testing: This is designed to test the run-time performance of s/w within the context of an
integrated system. They require both h/w and s/w instrumentation.
Testing Tactics: The goal of testing is to find errors and a good test is one that has a high probability of
finding an error.
A good test is not redundant and it should be neither too simple nor too complex. Two major categories of
software testing
Black box testing: It examines some fundamental aspect of a system, tests whether each function of
product is fully operational.
White box testing: It examines the internal operations of a system and examines the procedural detail.
2) Equivalence partitioning: This divides the input domain of a program into classes of data from which test
Cases can be derived. Define test cases that uncover classes of errors so that no. of test cases are reduced.
This is based on equivalence classes which represents a set of valid or invalid states for input conditions.
Reduces the cost of testing
Example
Input consists of 1 to 10 Then classes are n<1,1<=n<=10,n>10 Choose one valid class with value within
Page51
the allowed range and two invalid classes where values are greater than maximum value and smaller than
minimum value.
3) Boundary Value analysis
Select input from equivalence classes such that the input lies at the edge of the equivalence classes. Set of
data lies on the edge or boundary of a class of input data or generates the data that lies at the boundary of a
class of output data. Test cases exercise boundary values to uncover errors at the boundaries of the input
domain.
Example If 0.0<=x<=1.0
Then test cases are (0.0,1.0) for valid input and (-0.1 and 1.1) for invalid input
4)Orthogonal array Testing
This method is applied to problems in which input domain is relatively small but too large for exhaustive
testing
Example Three inputs A,B,C each having three values will require 27 test cases. Orthogonal testing will
reduce the number of test case to 9
Page52
Basis path testing is simple and effective It is not sufficient in itself
a) Condition testing: Exercises the logical conditions contained in a program module. Focuses on testing
each condition in the program to ensure that it does not contain errors Simple condition
E1<relation operator>E2 Compound condition
simple condition<booleon operator>simple condition
Types of errors include operator errors, variable errors, arithmetic expression errors etc.
Page53
Debugging has two outcomes: -
Page54
This may cause problems with the functions which worked properly before. This testing is the re- execution
of some subset of tests that are already conducted to ensure that changes have not propagated unintended
side effects. It ensures that changes do not introduce unintended behaviour or errors. This can be done
manually or automated. Software Quality Conformance to explicitly stated functional and performance
requirements, explicitly documented development standards, and implicit characteristics that are expected
of all professionally developed software.
Factors that affect software quality can be categorized in two broad groups:
Factors that can be directly measured (e.g. defects uncovered during testing)
Factors that can be measured only indirectly (e.g. usability or
maintainability)McCall’s quality factors 1.Product operation
Correctness
Reliability
Efficiency Integrity
Usability
2. Product Revision
Maintainability
Flexibility
3. Product Transition
Portability
Reusability
Interoperability
Risk Management
Risk is an undesired event or circumstance that occur while a project is underway It is necessary for the
project manager to anticipate and identify different risks that a project may be susceptible to Risk
Management. It aims at reducing the impact of all kinds of risk that may effect a
Project by identifying, analyzing and managing them.
Page55
Predictable risk: Risks are identified by past project experience.
Unpredictable risk: Risks that occur and may be difficult to identify.
Risk Identification
It concerned with identification of risk
Step1:Identify all possible risks
Step2:Create item checklist
Step3:Categorize into risk components-Performance risk, cost risk, support risk and schedule
risk
Step4:Divide the risk into one of 4 categories
Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible
so that the impact of risk can be reduced by making effective risk management planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might affect a
project. It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:
1. Technology risks: Risks that assume from the software or hardware technologies that are usedto
develop the system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where thesoftware
is being developed.
Page56
1. Tools risks: Risks that assume from the software tools and other support software used tocreate
the system.
1. Requirement risks: Risks that assume from the changes to the customer requirement and the
process of managing the requirements change.
2. Estimation risks: Risks that assume from the management estimates of the resources required
to build the system
· · The consequences of the problems associated with the risk, should it occur.
Project planner, along with other managers and technical staff, performs four risk projection activities:
(3) estimate the impact of the risk on the project and the product
(4) note the overall accuracy of the risk projection so that there will be no misunderstandings.
Risk table provides a project manager with a simple technique for risk projection
Page57
Steps in Setting up Risk Table
(1) Project team begins by listing all risks in the first column of the table. Accomplished with the help
of the risk item checklists.
(3) The probability of occurrence of each risk is entered in the next column of the table. The probability
value for each risk can be estimated by team members individually.
(4) Individual team members are polled in round-robin fashion until their assessment
of risk probability begins to converge.
Page58
Risk Refinement
Given that all reusable software components must conform to specific design standards and that some
do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may
actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30
percent of components.
Subcondition 1. Certain reusable components were developed by a third party with no knowledge of
internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified and may not
conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that is not supported
on the target environment.
Page59
Risk Mitigation, Monitoring, and Management
A risk management technique is usually seen in the software Project plan. This can be divided into Risk
Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are done as part of risk
analysis. As part of the overall project plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information Sheet (RIS). This RIS is
controlled by using a database system for easier management of information i.e creation, priority ordering,
searching, and other analysis. After documentation of RMMM and start of a project, risk mitigation and
monitoring steps will start.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project manager
when risk becomes reality and causes severe problems. If the project manager effectively uses project
mitigation to remove risks successfully then it is easier to manage the risks. This shows that the response
that will be taken for each risk by a manager. The main objective of the risk management plan is the risk
register. This risk register describes and focuses on the predicted threats to a software project.
· · Risk Mitigation, Monitoring and Management Plan (RMMM) - documents all work performed as part
of risk analysis and is used by the project manager as part of the overall project plan.
RIS is maintained using a database system, so that creation and information entry, priority ordering,
searches, and other analysis may be accomplished easily.
· Problems that occur during a project can be traced to more than one risk.
Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which
problems throughout the project).
Page61
UNIT – V
QUALITY MANAGEMENT
Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product does
The modern view of a quality associated with a software product several quality methods
Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.
Usability: A software product has better usability if various categories of users can easily invoke the
Reusability: A software product has excellent reusability if different modules of the product can quickly
be
Correctness: A software product is correct if various requirements as specified in the SRS document have
Maintainability: A software product is maintainable if bugs can be easily corrected as and when they
show
up, new tasks can be easily added to the product, and the functionalities of the product can be easily
modified, etc.
Quality Concepts
Variation control is the heart of quality control
Form one project to another, we want to minimize the difference between the predicted resources
needed tocomplete a project and the actual resources used, including staff, equipment, and calendar
time Quality of design
Refers to characteristics that designers specify for the end product
Quality Management
Quality of conformance
Degreetowhichdesignspecificationsarefollowedinmanufacturingtheproduct
Quality controlSeries of inspections, reviews, and tests used to ensure
conformance of a work product toits specifications
62 | P a g e
Quality assurance
Consists of a set of auditing and reporting functions that assess the
effectivenessand completeness of quality control activities
SQA Activities
Software quality assurance is composed of a variety of functions associated with two different
constituencies?
the software engineers who do technical work and an SQA group that has responsibility for quality
1. Prepares an SQA plan for a project: The program is developed during project planning and is
2. reviewed by all stakeholders. The plan governs quality assurance activities performed by the
3. software engineering team and the SQA group. The plan identifies calculation to be performed,
4. audits and reviews to be performed, standards that apply to the project, techniques for error
5. reporting and tracking, documents to be produced by the SQA team, and amount of feedback
provided
6. to the software project team.
7. Participates in the development of the project's software process description: The software team
selects a process for the work to be performed. The SQA group reviews the process description for
63 | P a g e
compliance with organizational policy, internal software standards, externally imposed standards
8. Reviews software engineering activities to verify compliance with the defined software process:
The SQA group identifies, reports, and tracks deviations from the process and verifies that
9. Audits designated software work products to verify compliance with those defined as a part
of the software process: The SQA group reviews selected work products, identifies, documents
and tracks deviations, verify that corrections have been made, and periodically reports the results
10. Ensures that deviations in software work and work products are documented and handled
11. Records any noncompliance and reports to senior management: Non- compliance items are
Software Review is systematic inspection of a software by one or more individuals who work together
to
find and resolve errors and defects in the software during the early stages of Software Development Life
Cycle (SDLC).
Formal Technical Review (FTR) is a software quality control activity performed by software
engineers.
The review meeting: Each review meeting should be held considering the following constraints-
64 | P a g e
Involvement of people:
1. Between 3, 4 and 5 people should be involve in the review.
2. Advance preparation should occur but it should be very short that is at the most 2 hours of work
for every person.
3. The short duration of the review meeting should be less than two hour. Gives these constraints,
it should be clear that an FTR focuses on specific (and small) part of the overall software.
Review guidelines :- Guidelines for the conducting of formal technical reviews should be established in
advance. These guidelines must be distributed to all reviewers, agreed upon, and then followed. A review
that is unregistered can often be worse than a review that does not minimum set of guidelines for FTR.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
5. Allocate resources and time schedule for FTRs in order to maintain time schedule.
6. Conduct meaningful training for all reviewers in order to make reviews effective.
7. Reviews earlier reviews which serve as the base for the current review being conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
10. Limit debate and rebuttal.
Move to correct the problems that caused the defects in the "vital few”
Six Sigma for Software Engineering The most widely used strategy for statistical quality
assurance Threecore steps:
Define customer requirements, deliverables, and project goals via well-defined methods of customer
communication.
Measure each existing process and its output to determine current quality performance (e.g.,
computedefect metrics)
Analyze defect metrics and determine vital few causes.
65 | P a g e
requirements
Software Reliability Defined as the probability of failure free operation of a computer program in a
specified environment for a specified time period
Can be measured directly and estimated using historical and developmental data
Software reliability problems can usually be traced back to errors in design or
implementation.Measures of Reliability
Mean time between failure (MTBF) = MTTF + MTTR MTTF = mean time
to failureMTTR = mean time to repair
Availability = [MTTF / (MTTF + MTTR)] x 100%
Software Reliability
Software Reliability means Operational reliability. It is described as the ability of a system or component to
perform its required functions under static conditions for a specific period.
Software reliability is also defined as the probability that a software system fulfills its assigned task in a given
environment for a predefined number of input cases, assuming that the hardware and the input are free of error.
Software Reliability is an essential connect of software quality, composed with functionality, usability,
performance, serviceability, capability, installability, maintainability, and documentation. Software Reliability
is hard to achieve because the complexity of software turn to be high. While any system with a high degree of
complexity, containing software, will be hard to reach a certain level of reliability, system developers tend to
push complexity into the software layer, with the speedy growth of system size and ease of doing so by
upgrading the software.
fosters standardization. ISO declared its 9000 series of standards in 1987. It serves as a reference for the
contract between independent parties. The ISO 9000 standard determines the guidelines for
1. ISO 9001: This standard applies to the organizations engaged in design, development,
production, and servicing of goods. This is the standard that applies to most software
66 | P a g e
development organizations.
2. ISO 9002: This standard applies to those organizations which do not design products but
are only involved in the production. Examples of these category industries contain steel
and car manufacturing industries that buy the product and plants designs from external
sources and are engaged in only manufacturing those products. Therefore, ISO 9002 does
3. ISO 9003: This standard applies to organizations that are involved only in the installation
and
67 | P a g e
1. Application: Once an organization decided to go for ISO certification, it applies to the
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews the
4. Compliance Audit: During this stage, the registrar checks whether the organization has
5. Registration: The Registrar awards the ISO certification after the successful completion
6. Continued Inspection: The registrar continued to monitor the organization time by time.
68 | P a g e
CASE STUDY--ATM MANAGEMENT SYSTEMS
69 | P a g e
Use case diagram for ATM
Enter pin
Withdraw
User ATM
Deposit
Balance enquiry
Cancel
Check
Admin
70 | P a g e
Sequence diagram for ATM
ATM ADMIN
Check pin no
Pin valid/invalid
Check account
Display status
Check amount
Display status
Update account
71 | P a g e
Activity diagram for ATM
72 | P a g e
Component diagram
73 | P a g e
Deployment diagram for ATM
74 | P a g e