Hardware	Software
Manufactured wear out Built using components Relatively simple	Developed/ engineered deteriorate Custom built Complex

11 of 350

System Software:

System software is a collection of programs written to service other programs.
It is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and sophisticated process management; complex data structures; and multiple external interfaces.

Ex. Compilers, operating system, drivers etc.

Application Software :

Application software consists of standalone programs that solve a specific business need.
Application software is used to control the business function in real-time.

Engineering /Scientific software:

Characterized by "number crunching" algorithms.
Applications range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics, and from molecular biology to automated manufacturing.

Ex. Computer Aided Design (CAD), system stimulation etc.

12 of 350

Embedded Software:

It resides in read-only memory and is used to control products and systems
Embedded software can perform limited and esoteric functions.

Ex. keypad control for a microwave oven.

Product line software:

Designed to provide a specific capability for use by many different customers, product line software can focus on a limited and esoteric marketplace.

Ex. Word processing, spreadsheet, CG, multimedia, etc.

Web Applications:

Web apps can be little more than a set of linked hypertext files.
It evolving into sophisticated computing environments that not only provide standalone features, functions but also integrated with corporate database and business applications.

Artificial Intelligence software

AI software makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis

Ex. Robotics, expert system, game playing, etc.

13 of 350

Software Myths

Definition: Beliefs about software and the process used to build it. Myths have number of attributes that have made them insidious (i.e. dangerous).

Misleading Attitudes - caused serious problem for managers and technical people.

Management myths

Managers in most disciplines, are often under pressure to maintain budgets, keep schedules on time, and improve quality.

Myth1: We already have a book that's full of standards and procedures for building

software, won't that provide my people with everything they need to know?

Reality :

Are software practitioners aware of existence standards?
Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to delivery while still maintaining a focus on quality?

14 of 350

Myth2: If we get behind schedule, we can add more programmers and catch up

Reality: Software development is not a mechanistic process like manufacturing. Adding people to a late software project makes it later.

People can be added but only in a planned and well-coordinated manner

Myth3: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.

Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsource software projects

15 of 350

Customer Myths

Customer may be a person from inside or outside the company that has requested software under contract.

Myth: A general statement of objectives is sufficient to begin writing programs— we can fill in the details later.

Reality: A poor up-front definition is the major cause of failed software efforts. A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints, and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer.

Myth: Project requirements continually change, but change can be easily accommodated because software is flexible.

Reality: Customer can review requirements and recommend modifications with relatively little impact on cost. When changes are requested during software design, the cost impact grows rapidly. Below mentioned figure for reference.

16 of 350

Practitioner's myths

Myth1: Once we write the program and get it to work, our job is done.

Reality: Someone once said that "the sooner you begin 'writing code', the longer it'll take you to get done." Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.

Myth2: Until I get the program "running" I have no way of assessing its quality.

Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project—the formal technical review.

Myth3: The only deliverable work product for a successful project is the working program.

17 of 350

Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and, more important, guidance for software support.

Myth4 : Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

Reality: Software engineering is not about creating documents. It is about creating

quality. Better quality leads to reduced rework. And reduced rework results in faster delivery times.

18 of 350

Software Engineering – Layered Technology

Layered Technology

A quality focus: the “bedrock”

Process model: the “framework”

Methods: technical “how to’s”

Tools: CASE preferred

19 of 350

Layered Technology

A quality Focus

Every organization is rest on its commitment to quality.
Total quality management, Six Sigma, or similar continuous improvement culture and it is this culture ultimately leads to development of increasingly more effective approaches to software engineering.
The bedrock that supports software engineering is a quality focus.

Process:

It’s a foundation layer for software engineering.
It’s define framework for a set of key process areas (KRA) for effectively manage and deliver quality software in a cost effective manner
The processes define the tasks to be performed and the order in which they are to be performed

20 of 350

Layered Technology

Methods:

It provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis, design, program construction, testing, and support.
There could be more than one technique to perform a task and different techniques could be used in different situations.

Tools:

Provide automated or semi-automated support for the process, methods and quality control.
When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering (CASE)

21 of 350

Process Framework

22 of 350

Software Process

A software process is the set of activities and associated outcome that produce a software product. A process defines who is doing what, when and how to reach a certain goal.
To build complete software process in software engineering, it is divided the work into smaller, parallel or sequential steps or subprocesses to improve design, product management, and project management.
Software Process has a set of Umbrella activities.
Umbrella Activities has a set of small number of framework activities that are applicable to all software projects, regardless of their size or complexity.
It encompasses a set of umbrella activities that are applicable across the entire software process.
The software process framework is a collection of task sets.
Task sets consist of a collection of small work tasks, project milestones, work productivity and software quality assurance points.

23 of 350

Generic Process Framework Activities

Communication:

Heavy communication with customers, stakeholders, team
Encompasses requirements gathering and related activities

Planning:

Workflow that is to follow
Describe technical task, likely risk, resources will require, work products to be produced and a work schedule.

Modeling:

Help developer and customer to understand requirements (Analysis of requirements) & Design of software

Construction

Code generation: either manual or automated or both
Testing – to uncover error in the code.

Deployment:

Delivery to the customer for evaluation
Customer provide feedback

24 of 350

Umbrella Activities

Software project tracking and control

Assessing progress against the project plan.
Take adequate action to maintain schedule.

Formal technical reviews

Assessing software work products in an effort to uncover and remove errors before goes into next action or activity.

Software quality assurance

Define and conducts the activities required to ensure software quality.

Software configuration management

Manages the effects of change.

Document preparation and production

Help to create work products such as models, documents, logs, form and list.

Reusability management

Define criteria for work product reuse
Mechanisms to achieve reusable components.

Measurement

Define and collects process, project, and product measures
Assist the team in delivering software that meets customer’s needs.

Risk management

Assesses risks that may effect that outcome of project or quality of product (i.e. software)

25 of 350

Framework activities

The framework activities will always be applied on every project ... BUT
The tasks for each activity will vary based on:

The type of project (an “entry point” to the model)
Characteristics of the project
Common sense judgment; concurrence of the project team

The software process framework is a collection of task sets.
Task sets consist of a collection of small work tasks, project milestones, work productivity and software quality assurance points.

26 of 350

CMMI

CMMI (Capability Maturity Model Integration) is a proven industry framework to improve product quality and development efficiency for both hardware and software
It is Sponsored by US Department of Defence in cooperation with Carnegie Mellon University and the Software Engineering Institute (SEI)
Many companies have been involved in CMMI definition such as Motorola and Ericsson.
CMMI, staged, uses 5 levels to describe the maturity of the organization

27 of 350

CMMI OBJECTIVES

Produce quality products or services
Enhance customer satisfaction
Increase market share
Gain an industry – wide recognition for excellence
Focuses on business needs, integration and institution improvement
CMMI has been established as a model to improve business results

28 of 350

CMMI

CMMI have 5 maturity levels:

29 of 350

CMMI Level

Level 1 (Intial) – All specific goals are performed as per defined by CMMI

Level 2 (Managed) –

All level 1 criteria have been satisfied
In addition to Level I;

People doing work have access to adequate resources to get job done,
Stakeholders are actively involved,
Work tasks and products are monitored, controlled, reviewed, and evaluated for conformance to process description.

Level 3 (Defined) –

All level 2 criteria have been achieved.
In addition;

management and engineering processes documented
standardized and integrated into organization-wide software process

30 of 350

CMMI Level (cont.)

Level 4 (Quantitatively Managed) -

All level 3 criteria have been satisfied.
Software process and products are quantitatively understood
Controlled using detailed measures and assessment.

Level 5 (Optimized) –

Continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas.

31 of 350

The CMMI represents a process meta-model in two different ways: (1) as a

“continuous” model and (2) as a “staged” model.

CMMI

32 of 350

The continuous representation is the approach used in the SECM and the IPD-CMM. This approach allows an organization to select a specific process area and improve relative to it.

CMMI REPRESENTATION as Continuous Stage

33 of 350

CMMI REPRESENTATION as Staged Stage

The staged representation is the approach used in the Software CMM. It is an approach that uses predefined sets of process areas to define an improvement path for an organization.

34 of 350

CMMI Components

Within each of the 5 Maturity Levels, there are basic functions that need to be performed – these are called Process Areas (PAs).
For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
Given the interactions and overlap, it becomes more efficient to work the Maturity Level 2 and 3 issues concurrently.
Within each PA there are Goals to be achieved and within each Goal there are Practices, work products, etc. to be followed that will support each of the Goals.

Slide 34 of 146

36 of 350

REPRESENTATION OF PROCESS AREA IN CMMI

37 of 350

The CMMI defines each process area in terms of “Specific goals and their Specific practices” and “Generic goals and related Generic practices” required to achieve these goals.
Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective.
Specific practices refine a goal into a set of process-related activities.
5 Generic goals are their to achieve a particular capability level

CMMI SPECIFIC GOALS AND GENERIC GOALS

38 of 350

SG 1 Establish Estimates

SP 1.1-1 Estimate the Scope of the Project

SP 1.2-1 Establish Estimates of Work Product and Task Attributes

SP 1.3-1 Define Project Life Cycle

SP 1.4-1 Determine Estimates of Effort and Cost

SG 2 Develop a Project Plan

SP 2.1-1 Establish the Budget and Schedule

SP 2.2-1 Identify Project Risks

SP 2.3-1 Plan for Data Management

SP 2.4-1 Plan for Project Resources

SP 2.5-1 Plan for Needed Knowledge and Skills

SP 2.6-1 Plan Stakeholder Involvement

SP 2.7-1 Establish the Project Plan

SG 3 Obtain Commitment to the Plan

SP 3.1-1 Review Plans That Affect the Project

SP 3.2-1 Reconcile Work and Resource Levels

SP 3.3-1 Obtain Plan Commitment

Project Planning Example for Specific Goals and Specific Practices

For example, project planning is one of Seven process areas defined by the CMMI for “project management”

39 of 350

GG 1 Achieve Specific Goals

GP 1.1 Perform Base Practices

GG 2 Institutionalize a Managed Process

GP 2.1 Establish an Organizational Policy

GP 2.2 Plan the Process

GP 2.3 Provide Resources

GP 2.4 Assign Responsibility

GP 2.5 Train People

GP 2.6 Manage Configurations

GP 2.7 Identify and Involve Relevant Stakeholders

GP 2.8 Monitor and Control the Process

GP 2.9 Objectively Evaluate Adherence

GP 2.10 Review Status with Higher-Level Management

Project Planning Example for Generic Goals and Generic Practices

40 of 350

GG 3 Institutionalize a Defined Process

GP 3.1 Establish a Defined Process

GP 3.2 Collect Improvement Information

GG 4 Institutionalize a Quantitatively Managed Process

GP 4.1 Establish Quantitative Objectives for the Process

GP 4.2 Stabilize Subprocess Performance

GG 5 Institutionalize an Optimizing Process

GP 5.1 Ensure Continuous Process Improvement

GP 5.2 Correct Root Causes of Problems

41 of 350

Waterfall Model or Classic Life Cycle

42 of 350

Waterfall Model

Requirement Analysis & Specification

To understand customer requirements & document them properly
SRS (Software Requirement Specification) Document
Used as a contract between the developer & the customer

43 of 350

Waterfall Model

Design

Transforms requirements into a structure suitable for implementation in some programming language
SRS

44 of 350

Waterfall Model

Implementation & Unit Testing

Design implemented
SRS used
Coding Phase
Each and every module is separately tested to check if they are providing desired functionality

45 of 350

Waterfall Model

Integration & System Testing

Integration is bringing together all the modules and testing them
Interfaces between the modules are tested
System testing is testing the s/w with h/w (environment after deploying)

46 of 350

Waterfall Model

Operation & Maintenance

Started operating in user environment
To preserve the value of s/w overtime to add / remove functionalities
Done after delivering/deployment of s/w to customer
Error correction, enhancement, etc.

47 of 350

Waterfall Model

Problems with this model

“Follows the idea of Define before Design and Design before Code”

Waterfall model expects complete and accurate requirements early in s/w development process
Not suitable for accommodating changes during development as the requirements once specified in level 1 cannot be changed through out the development
No realistic in today’s world and this model is not suitable for large projects.

48 of 350

Waterfall Model

When to use waterfall model

When the requirements are very clearly understood and they will not change during SDLC
It can be used by an organization

That has an experience in developing a particular kind of s/w.
When it wants to build a new s/w based on an existing s/w.

49 of 350

Spiral Model

50 of 350

Spiral Model

Proposed by Barry Boehm in 1986
It follows a spiral nature
Risk analysis is in every spiral and is an important feature
One circle around the axis is one phase
In each phase 4 different activities are performed.
In each phase we have risk analysis and reviews to make sure risk does not exist.

51 of 350

Spiral Model

Lets see what happens in each phase
Phase 1:

Planning -> Analysis Risk -> Prototype is built -> Customer evaluation & feedback

Phase 2:

Prototype is refined -> Requirements are documented -> Validated by customer -> final prototype is developed

Phase 3:

Risks are known well + Traditional approach to development is followed.

52 of 350

Spiral Model

Focus Areas:

Identifying problem -> classify into different risk levels -> eliminate them before they effect s/w.
Continuous validation (review) by concerned people (designers/developers) to check the work product
Plan for next cycle before hand

53 of 350

Spiral Model

Advantages:

Accommodate good features of other models
Software quality maintained during development by

Continuous risk analysis
Reviews conducted

Disadvantages:

Requires expertise in risk handling + carrying out spiral model

54 of 350

Spiral Model

When to use?

When project is large
When releases are required to be frequent
When creation of prototype is applicable
For medium to high risk projects
When requirements are unclear and complex
When changes may require at any time

55 of 350

An Agile View Of Process

What is Agility?

An agile team is an active team able to appropriately respond to the changes in software development.
Changes of all kinds that may have an impact on the product they build or the project that creates the product.
An agile team recognizes that s/w is developed by individuals working in teams and that the skills of these people, their ability to collaborate for the success of the project.

56 of 350

An Agile View Of Process

The 12 principles to achieve agility:

Our highest priority is to satisfy the customer through early and continuous delivery of s/w.
Welcome changing requirements, even late in the development.
Deliver working s/w frequently, from a couple of weeks to months.
Business people and developers must work together daily throughout the project

57 of 350

An Agile View Of Process

The 12 principles to achieve agility:

5.Motivated individuals and Give them the environment and support they need, and trust them to get the job done

6. The most efficient and effective method of conveying information and within a development team is face – to – face conversation.

7. Working software is the primary measure of progress.

8. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

58 of 350

An Agile View Of Process

The 12 principles to achieve agility:

9. Continuous attention to technical excellence and good

design enhances agility.

10.Simplicity, the art of maximizing the amount of work not done essential.

11. The best architectures, requirements and designs emerge from self organizing teams.

12. At regular intervals, the team reflects on how to become more effective.

59 of 350

Agile Process Model

Agile model is a combination of iterative and incremental process models
Agile methods break the product into small incremental builds.

60 of 350

Agile Process Model

Every iteration involves cross functional teams working simultaneously (iteratively) on various area like planning, requirement analysis, design, coding, testing.
E.g. AM1 = Library management system
AM2 = Staff management system

In AM2 we can have Sweeper Management system.
S/w is divided incrementally and executed iteratively.

61 of 350

Agile Process Model

Advantages:

Customer satisfaction by rapid continuous delivery of useful software
Customers, developers and testers constantly interact with each other (no rely on documentation)
Late changes in the requirements are welcome
Regular adaptation to changing circumstances

62 of 350

Agile Process Model

Disadvantages:

In case of some s/w, it is difficult to access the effort required at the beginning of the SDLC
Lack of emphasis on necessary design & documentation (e.g. no risk analysis)
Only senior programmers are capable of taking the decisions required during the development process.

63 of 350

UNIT - II

Software Requirements

Functional and non-functional requirements

User requirements

System requirements

Interface Specifications

Software requirements document.

Requirements engineering process

Feasibility studies,

Requirements elicitation and analysis

Requirements validation

Requirements management.

64 of 350

Software Requirements

65 of 350

Software requirements

The different types of requirements are

Functional Requirements
Non Functional Requirements
Domain requirements
user requirements
system requirements

66 of 350

SOFTWARE requirements

THE SOFTWARE REQUIREMNTS ARE REPRESENTED AS THE BELOW:

Functional requirements

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Non-functional requirements

constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Domain requirements

Requirements that come from the application domain of the system and that reflect characteristics of that domain.

67 of 350

EXAMPLE OF The LIBSYS system

A library system that provides a single interface to a number of databases of articles in different libraries.
Users can search for, download and print these articles for personal study.

68 of 350

Functional requirements FOR LIBSYS

The user shall be able to search either all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

69 of 350

Non-functional requirements

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

70 of 350

Non-functional classifications

Product requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirements

Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirements

Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

71 of 350

Non-functional requirement types

72 of 350

Non-functional requirements for lib sys

Product requirement

The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.

Organisational requirement

The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.

External requirement

The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

75 of 350

Domain requirements

Derived from the application domain and describe system characteristics and features that reflect the domain.
Domain requirements be functional requirements, constraints on existing requirements or define specific computations.
If domain requirements are not satisfied, the system may be unworkable.
Examples of Domain requirements train operation, medical records, e-commerce etc that reflect the environment in which the system operates

76 of 350

User requirements

They should only specify the external behavior of the system and should avoid, as far as possible, system design characteristics.
Should describe functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.
Consequently, if you are writing user requirements, you should not use software jargon, structured notations or formal notations, or describe the requirement by describing the system implementation.
You should write user requirements in simple natural language, with simple tables and forms and intuitive diagrams

77 of 350

USER REQUIREMENT EXAMPLE FOR �LIBSYS requirement

4..5 LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.

78 of 350

Problems with natural language

however, various problems can arise when requirements are written in natural language sentences in a text document:

Lack of clarity

ACCURACY SHOULD BE MAINTAINED WHILE making the document .

Requirements confusion

Functional and non-functional requirements tend NOT BE to be mixed-up.

Requirements amalgamation

Several different requirements may be expressed together.

79 of 350

Guidelines for writing requirements

Invent a standard format (template) and use it for all requirements.
Use language consistently. You should always distinguish between mandatory and desirable requirements.
Use text highlighting (bold, italic or colour) to pick out key parts of the requirement.
Avoid, as far as possible, the use of computer jargon

80 of 350

System requirements

More detailed specifications of system functions, services and constraints than user requirements.
They are intended to be a basis for designing the system.
It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

81 of 350

Problems with NL specification

Ambiguity

The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.

Over-flexibility

The same thing may be said in a number of different ways in the specification.

Lack of modularisation

NL structures are inadequate to structure system requirements.

82 of 350

Alternatives to NL specification

83 of 350

INTERFACE SPECIFICATIONS

Interface specification, in the context of software development and computer systems, refers to a detailed description or set of rules that define how different software components or modules should interact with each other. It acts as a contract or agreement that ensures seamless communication and integration between various parts of a software system.
In simpler terms, an interface specification outlines the rules and guidelines for how different parts of a software application should "talk" to each other, exchange data, and cooperate to perform specific tasks. These interfaces can be between software modules, software and hardware components, or even between different software systems.
Key Points about Interface Specification:
Standardization: Interface specifications standardize the communication between components, making it easier for developers to understand how to interact with other parts of the system.
Abstraction: Interfaces hide the implementation details of a component, allowing other parts of the system to interact with it without needing to know the internal complexities.
Encapsulation: Interface specifications help enforce encapsulation, separating the concerns of different components and promoting modular design.
Flexibility: By defining clear interfaces, components can be easily replaced or upgraded without affecting other parts of the system, as long as they adhere to the same interface specification.
Interoperability: Interface specifications facilitate interoperability, enabling components from different vendors or systems to work together seamlessly.

84 of 350

The requirements document

The requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements.
It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

85 of 350

Users of a requirements document

86 of 350

IEEE requirements standard

Defines a generic structure for a requirements document that must be instantiated for each specific system.

Introduction.
General description.
Specific requirements.
Appendices.
Index.

87 of 350

Requirements document structure FOR LARGE PROJECTS

Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index

89 of 350

Requirements Engineering Processes

The goal of requirement engineering process is to create and maintain a system requirements document.
The overall process include four level process.

90 of 350

Requirements engineering process

91 of 350

Requirements engineering process

(1) Feasibility Study: These are concerned with assessing whether the system is useful to the business or not. It produces Feasibility Report.

(2)Requirement Elication and Analysis: It discovers requirements and produces system models.

(3)Requirements Specification : Converting these requirements in to standard format.

(4) Requirement Validation: checking that the requirements actually define the system that customer wants . It produces SRS document.

92 of 350

Requirements engineering process

Ion Sommerville found an alternative perspective ,with 3 stage activities.
All these 3 activities are organized as an iterative process around a spiral .
The following Spiral diagram shows how the requirements are developed in different levels in detail.

94 of 350

Topics covered

Feasibility studies
Requirements elicitation and analysis
Requirements validation
REQUIREMENTS MANAGEMENT

95 of 350

Feasibility studies

A feasibility study decides whether or not the proposed system is worthwhile. The study checks

if the system contributes to organizational objectives
if the system can be engineered using current technology and within budget
if the system can be integrated with other systems that are used
It helps us to start a business, purchase of an existing system,or an expansion of system required.

96 of 350

Feasibility studies

Feasibility study involves in 3 steps:

(a) Information Assessment : It has 3 types

(1) Economic Feasibility – cost of equipments,budget

(2) Operational Feasibility – Easy to use or any training

(3) Technical Feasibility.- discuss about H/w aNd s/w req

97 of 350

Feasibility studies(Cont..)

(b) Information Collection: The software engineering organization discover answers for the following sample questions

What are the problems with current processes and how would a new system help alleviate these problems?
What direct contribution will the system make to the business objectives and requirements
Does the system require technology that has not previously been used in the organisation?

98 of 350

Feasibility studies(cont..)

(3) Report writing: Based on these questions, the report is developed .The organization will take decision whether to continue the project or cancel the project

Normally Feasibility study will take 2 or 3 weeks.

99 of 350

Topics covered

Feasibility studies
Requirements elicitation and analysis
Requirements validation
Requirements management

100 of 350

Requirement elicitation and analysis

Involves technical staff with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints
Involves many stakeholders, such as end-users, managers, engineers, domain experts, trade unions, etc.

101 of 350

Banking ATM system – An example

Services include cash and check deposit, cash withdrawal, message passing , ordering a statement and transferring funds

102 of 350

Banking ATM system – An example

For example, system stakeholders for a bank ATM include:

I. Current bank customers who receive services from the system

2. Representatives from other banks who have reciprocal agreements that allow each other's ATMs to be used

3. Managers of bank branches

4. Counter staff at bank branches who are involved in the day-to-day running of the system

5. Database administrators who are responsible for integrating the system with the bank's customer database

103 of 350

Banking ATM system – An example

6. Bank security managers who must ensure that the system will not pose a security hazard

7. The bank's marketing department who are likely be interested in using the system as a means of marketing the bank

8. Hardware and software maintenance engineers who are responsible for maintaining and upgrading the hardware and software

9. National banking regulators who are responsible for ensuring that the system conforms to banking regulations

104 of 350

Problems of requirements analysis

Stakeholders don’t know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organizational and political factors may influence the system requirements
The requirements change during the analysis process, because new stakeholders may emerge and the business environment may change

105 of 350

The requirements analysis process

106 of 350

The process activities are:

1. Requirements discovery This is the process of interacting with stakeholders in the system to collect their requirements. It uses different types of techniques like Viewpoints, Scenarios, Interviewing, Use cases, Ethanography

and documentation are also discovered during this activity.

2. Requirements classification and organisation This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters.

The requirements analysis process

107 of 350

3. Requirements prioritization and negotiation Inevitably, where multiple stakeholders are involved, requirements will conflict. This activity is concerned with finding and resolving requirements conflicts through negotiation.

4. Requirements documentation The requirements are documented and input into the next round of the spiral. Formal or informal requirements documents may

be produced.

The requirements analysis process

108 of 350

Techniques for requirements elicitation and analysis

Viewpoint-oriented elicitation
Scenarios
Ethnography
Interviewing
Use cases

109 of 350

Viewpoint-oriented elicitation

Stakeholders represent different ways of looking at a problem or problem viewpoints
There are 3 different types of view points.

a) Interactive Viewpoints

b) Indirect viewpoints

c) Domain Viewpoints

110 of 350

Example of LIB SYS Viewpoint

111 of 350

Interviewing

Interviews may be of two types:

1. Closed interviews where the stakeholder answers a predefined set of questions.

2. Open interviews where there is no predefined agenda. The requirements engineering team explores a range of issues with system stakeholders and hence develops a better understanding of their needs.

112 of 350

Scenarios

Scenarios are descriptions of how a system is used in real time(the interaction)
They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system
Scenarios are particularly useful for adding detail to an outline requirements description

113 of 350

Scenario descriptions

Including

System state description at the beginning of the scenario
Normal flow of events in the scenario
What can go wrong and how this is handled
Other concurrent activities
System state on completion of the scenario

114 of 350

Event scenario - start transaction

115 of 350

Use cases

Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself
A set of use cases should describe all possible interactions with the system
Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system

116 of 350

Library use-cases

117 of 350

Ethnography

A social scientists spends a considerable time observing and analysing how people actually work
People do not have to explain or articulate their work
Social and organizational factors of importance may be observed
Requirements that are derived from cooperation and awareness of other people’s activities

118 of 350

Topics covered

Feasibility studies
Requirements elicitation and analysis
Requirements validation
Requirement management

119 of 350

Requirements validation

Requirements validation is concerned with showing that the requirements actually define the system that the customer wants.
Requirements validation is important because errors in a requirements document can rework costs when they are discovered during development or after the system is in service.
During the requirements validation process, checks should be carried out on the requirements in the requirements document.

120 of 350

Requirements validation

These checks include:

Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability

121 of 350

1. Validity checks A user may think that a system is needed to perform certain functions which are mostly given by stakeholders with distinct needs so we have to keep validity checks wherever needed at every stage.

2. Consistency checks Requirements in the document should not conflict and will not change never. There we have to keep Consistency checks .

Example : Login ,Registration pages.

3. Completeness checks The requirements document should include all functions, and constraints intended by the system user.

Requirements validation

122 of 350

4.Realism checks :The requirements should be checked to ensure that they could actually be implemented by existing technology, These checks should also take account of the budget and schedule for the system development

5. Verifiability To reduce the dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

123 of 350

Requirements validation techniques

Requirements reviews

Systematic manual analysis of the requirements

Prototyping

Using an executable model of the system to check requirements.

Test-case generation

Developing tests for requirements to check testability

124 of 350

Requirements Management

The requirements for large software systems are always changing, It is hard for users and system customers to anticipate what effects the new system will have on the organization.
Once end-users have experience of a system, they discover new needs and priorities
Requirements management is the process of understanding and controlling changes to system requirements

125 of 350

Requirements fall into two classes:

1.Enduring requirements These are relatively stable requirements that derive from the core activity of the organization and which relate directly to the domain of the system. For example, in a hospital, there will always be requirements concerned with patients, doctors, nurses and treatments.

2. Volatile requirements These are requirements that are likely to change during the system development process or after the system has been become operational. An example would be requirements resulting from government healthcare policies.

126 of 350

Requirements Management Planning

Planning is an essential first stage in the requirements management process. For each project, the planning stage establishes the level of requirements management detail that is required. During the requirements management stage, you have to decide on:

Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced by other requirements and so that it may be used in traceability assessments.
A change management process This is the set of activities that assess the impact and cost of changes.

.3. Traceability policies These policies define the relationships between requirements, and system

design that should be recorded and how these records should be maintained.

4. CASE tool support Requirements management involves the processing of large amounts of

information. Tools that may be used range from specialist requirements management systems to

spreadsheets and simple database systems.

127 of 350

(1) Requirements identification :

Each requirement must be uniquely identified so that it can be cross-referenced by other requirements and so that it may be used in traceability assessments.

(2) Requirement Change Management

1. Problem analysis and change specification During this stage, the problem or the change proposal is analyzed to check that it is valid.

2. Change analysis and costing The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. The cost of making the change is estimated and Once this analysis is completed, a decision is made whether to proceed with the requirements change..

3. Change implementation The requirements document and, where necessary, the system design and implementation are modified. Individual sections can be changed and replaced without affecting other parts of the document.

128 of 350

There are three types of traceability information that may be maintained:

1. Source traceability information links the requirements to the stakeholders who proposed the requirements ,When a change is proposed, you use this information to find and consult the stakeholders about the change

2. Requirements traceability information links dependent requirements within the requirements document. You use this information to assess how many requirements are likely to be affected by a proposed change and the extent of consequential requirements changes that may be necessary.

3. Design traceability information links the requirements to the design modules where these requirements are implemented.

(3) Traceability policies

129 of 350

Figure 7.12 shows a simple traceability matrix that records the dependencies between requirements.

A 'D' in the row/column intersection illustrates that the requirement in the row depends on the requirement named in the column; an 'R' means that there is some other, weaker relationship between the requirements.

130 of 350

Requirements management needs automated support; the CASE tools for this should be chosen during the planning phase. You need tool support for:

l. Requirements storage The requirements should be maintained in a secure, managed data store that is accessible to everyone involved in the requirements engineering process.

2. Change management The process of change management is simplified if active tool support is available.

3. Traceability management : Some tools use natural language processing techniques to help you discover possible relationships between the requirements..

(4) CASE tool support

131 of 350

Unit 3

Chapter 1 : Design Engineering

Design process and Design quality

Design concepts

Design model

Chapter 2 :Creating an architectural design

software architecture

Data design

Architectural styles and patterns,

Architectural design,

Chapter 3: Conceptual model of UML

Basic structural modeling

Class diagram

Sequence diagrams

Collaboration diagrams

Use case diagrams

Component diagrams.

132 of 350

Chapter : Design Engineering

133 of 350

Design Model

What is a Design Model?

A design model in Software Engineering is an object-based picture or pictures that represent the use cases for a system. Or to put it another way, it is the means to describe a system's implementation and source code in a diagrammatic fashion.
This type of representation has a couple of advantages.

First, it is a simpler representation than words alone.
Second, a group of people can look at these simple diagrams and quickly get the general idea behind a system.

134 of 350

Software design model consists of 4 designs:

Data/class Design
Architectural Design
Interface Design
Component Design

135 of 350

Data/class design - Created by transforming the analysis model class-based elements into classes and data structures required to implement the software
Architectural design - defines the relationships among the major structural elements of the software, it is derived from the class-based elements and flow-oriented elements of the analysis model
Interface design - describes how the software elements, hardware elements, and end-users communicate with one another, it is derived from the analysis model scenario-based elements, flow-oriented elements, and behavioral elements
Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components using information obtained from the analysis model class-based elements, flow-oriented elements, and behavioral elements

136 of 350

Difference between Analysis model and Design model

Model:

A model is some kind of simplification that is used to better understand the problem (“analysis model”) or the solution (“design model”).
Analysis:

Is all about understanding of requirements, problems within requirements by – breaking a whole into its component parts. Diagrams can be made to understand and point problems in requirements.

Design:

Is related to creation of a solution for the analyzed problem by – making a blueprint of something before developing it.

137 of 350

Translating Requirement analysis Model in to Design Model

138 of 350

Design Quality

The design must be readable, understandable guide for those who generate code and for those who test and subsequently support the software.
The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

139 of 350

Quality Attributes

(1) Functionality:

* It is accessed by evaluating

=> the feature set(capacity) and capabilities of the program

=> the generality (majority) of the functions that are delivered

=> the security of overall system

(2) Usability:

* It is accessed by considering

=> human factors

=> overall aesthetics (art)

=> consistency

=> documentation

140 of 350

Quality Attributes

(3) Reliability:

* It is evaluated by

=> Measuring the frequency and severity of failure

=> the accuracy of output results

=> the Mean-Time-To-Failure [MTTF]

=> the ability to recover from failure

=> the predictability of the program

(4) Performance:

* It is measured by

=> Processing speed

=> Response time

=> Resource consumption

=> Throughput (amount of data being moved successfully)

=> Efficiency

141 of 350

Quality Attributes

(5) Supportability:

* It combines the ability to

=> extend the program [extensibility]

=> Adaptability

=> Serviceability

142 of 350

Design concepts

Design concepts provide the necessary framework for “to get the thing on right way”.

Abstraction
Architecture
Patterns
Modularity
Information Hiding
Refinement
Refactoring
Functional Independence

143 of 350

Design concepts

(1) Abstraction - Many levels of abstraction can be used to find a modular solution to any problem

Procedural Abstraction
Data Abstraction

144 of 350

Design concepts

Procedural Abstraction

* It refers to a sequence of instructions that have a specific and limited function
* The name of procedural abstraction implies these functions, but specific details are suppressed
Example:

* The word Open for a door

* Open implies a long sequence of procedural steps [e.g. Walk to the door, reach out and grasp knob, turn knob and pull door , step away from moving door etc..]

145 of 350

Design concepts

Data Abstraction

* It is a named collection of data that describes a data object
Example:

* We can define a data abstraction called ‘Door’

* The ‘door’ would encompass a set of attributes that describe the door [e.g. door type, swing direction, opening mechanism, weight etc..]

146 of 350

Design concepts

(2) Architecture

* It is the

=> Structure or organization of how program components interact

=> Structure of data that are used by the components

* The architectural design can be represented using one (Or) more number of different models

(i) Structural Models: It represents architecture as an organized collection of program components

(ii) Dynamic Models: It indicates how the structure (Or) system configure may change as a function of external events

(iii) Process models: It focus on the design of the business process that the system must accommodate

(iv) Functional Models: It can be used to represent the functional hierarchy of a System

147 of 350

Design concepts

(3) Patterns:

* A design pattern describes a design structure that solves a particular design problem with in a specified context

* The purpose of each design pattern is to provide a description that enables a designer to determine

=> Whether the pattern is applicable to the current work

=> Whether the pattern can be reused [to save design time]

=> Whether the pattern can serve as a guide for developing a similar but functionality (Or) structurally different pattern

148 of 350

Design concepts

(4) Modularity:

* It is the process of dividing the software into separately named and addressable components sometimes called ‘Modules’ that are integrated to satisfy problem requirements
* As the number of modules increases the cost to develop decreases
* If we divide software indefinitely the effort required to develop it will become negligibly small

149 of 350

Design concepts

(4) Modularity:

* As the number of modules increases the cost to integrate the modules also increases

i.e.

As number of modules , the cost to develop and the cost to integrate the modules

Example: A desktop computer

* We modularize a design so that,

=> Development can be more easily planned

=> Software increments can be defined and delivered

=> Changes can be more easily accommodated

=> Testing and debugging can be conducted more efficiently

=> Long term maintenance can be conducted without series effects

150 of 350

Design concepts

(5) Information hiding:

* It suggests that “modules should be specified and designed so that information contained with in a module is in accessible to other modules that have no need for such information

The use of information hiding provides the greatest benefits when

=> Modifications are required during testing and later

=> during software maintenance

151 of 350

Design concepts

(6) Functional Independence:

* It is achieved by design a software that each module address a specific sub function of requirements and has a simple interface when viewed from other parts of program structure

* Why independence is so important?

=> Independent modules are easier to maintain

=> Error propagate is reduced

=> Reusable modules are possible

* Independence is assessed [estimated ] using two qualitative criteria:

=> Cohesion

=> Coupling

152 of 350

Module 1

Module 3

Module 2

The interconnection between A and B i.e. elements of each module is cohesion(yellow line)
We have to increase cohesion in intra dependency
The red line is called coupling
We have to decrease coupling in inter dependency

153 of 350

COHESION:

* It is a measure of the closeness of the relationship between its components

* A component should implement a single logical function (Or) should implement a single logical entity

* All parts of the component should contribute to this implementation

If a component includes parts that are not directly related to its logical function then it has Low Cohesion
Example: Calculator class has different functions which perform individual task

Seven Levels of Cohesion:

(i) Coincidental Cohesion:

* The part of a component are not related, but simply bundled into a single component

(ii) Logical Association:

* Components that perform similar functions such as input, error handling and so on are put together in a single component

154 of 350

Design concepts

(iii) Temporal Cohesion:

* All of the components that are activated at a single time such as

=> Start up (Or) Shut down are brought together

Example: deleting data in all functions at a time

(iv) Procedural Cohesion:

* The elements in a component make up a single control sequence E.g. recursion function

(v) Communication Cohesion:

* All of the elements of a component operate the same input data (Or) produce the same output data, e.g. components will know the status of each other or request among them

(vi) Sequential Cohesion:

* The output from one element in the component serves as input for some other element

(vii) Functional Cohesion:

* Each part of the component is necessary for the execution of a single function

155 of 350

Design concepts

COUPLING:

* It is an indication of the strength of interconnections between the components in a design (how components are dependent on each other)

* Highly coupled systems, have strong systems with program units dependent on each other

* Loosely coupled systems are made up of components which are independent or almost independent

156 of 350

Design concepts

* Modules are tightly coupled, if they make use of shared variables (Or) if they interchange control information.

* Tightly coupling is also referred as common coupling and control coupling

* Loose coupling is achieved by ensuring that

=> Details of the data representation are held with in a component

* Its interface with other components should be through a parameter list

* If shared information is necessary, the sharing should be limited to those components

* Globally accessible information should be avoided wherever possible

157 of 350

Design concepts

Types of coupling:

Content coupling: when modules are sharing the content of each other. When one module changes the data of other module.
Common coupling: When modules are accessing the whole global data but not at same time.
Control coupling: Communicating among themselves with help of flag.
Stamp coupling: Taking only necessary data for each module from global data. Almost similar to common coupling. Two modules are sharing same data structure
Data coupling: Passing parameters among modules e.g. one module is giving input, other processing and third printing.

158 of 350

“An important design objective is to maximize the module cohesion and minimize coupling”

COHESION	COUPLING
Functional	Data
Sequential	Stamp
Communicational	Control
Procedural	Common
Temporal	Content
Logical
Coincidental

Best

Worst

Best

Worst

159 of 350

Design concepts

(7) Refinement:

* It is actually a process of elaboration

* Refinement enables a designer to specify low-level details, as design progresses

* i.e. The statement describes information conceptually but provide no information about internal workings

* Refinement causes the designer to provide more and more details as each successive refinement occurs

160 of 350

Design concepts

(8) Refactoring:

* It is a process of changing a software system in such a way that it does not alter the external behavior of the code [design], yet improves its internal structure

* The existing system is checked for

=> Unused design elements

=> Inefficient (Or) Unnecessary algorithms

=> Poorly constructed (Or) inappropriate data structures

=> Any other design failures that can be corrected to yield a better design

161 of 350

Creating an Architectural design

Software Architecture
Data design
Architectural styles and patterns
Architectural Design

162 of 350

What is Architecture?

162

Software architecture is the structure of the systems, which comprises

(1) a set of components (e.g., a database, computational modules) that perform a function required by a system,
(2) a set of connectors that enable “communication, coordination and cooperation” among components,
(3) constraints that define how components can be integrated to form the system, and
(4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

163 of 350

Data Design:

* It is an action that translates data objects defined as part of the analysis model into data structure at the software component level

* If necessary a database architecture at the application level.

1) Data design at the architectural level

2) Data design at the component level�

164 of 350

Architectural Styles

Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures

164

165 of 350

Data-Centered Architecture

165

166 of 350

Data-Centered Architecture

A data store [e.g. a file or database] resides at the centre of this architecture and is accessed frequently by other components that Update, Add, delete (Or) Modify data within the data store
In the figure client software accesses a central repository
Integrability [i.e. existing components can be changed and a new Client components added to the architecture, without concern about Other clients]
Data can be passed among clients using the black board mechanism [i.e. the black board component serves to coordinate the transfer of Information between clients]

166

167 of 350

Data Flow Architecture

167

168 of 350

Data Flow Architecture

It is applied when input data are to be transformed through a series of computational (Or) manipulative components into output data
A pipe and filter structure has a set of components called Filter connected by pipes
The pipes transmit data from one component to the next
Each filter works independently
The filter does not require knowledge of the working of its neighboring filters�

168

169 of 350

Call and Return Architecture

169

170 of 350

This architectural style enables a software designer to achieve a program structure that is relatively easy to modify and scale
Two sub styles exist with in this category:
(i) Main program / Sub program architecture:
This program structure decomposes function into a control hierarchy, where a ‘Main’ program invokes a number of program components, which in turn may invoke other component
(ii) Remote procedure calls architecture
The components of a main program / subprogram architecture are distributed across multiple computers on a network

170

171 of 350

Object – Oriented architecture:�

171

172 of 350

Object – Oriented architecture:�

The components of a system encapsulate data and the operations that must be applied to manipulate the data
Communication and coordination between components is accomplished via Message Passing

172

173 of 350

Layered Architecture

173

174 of 350

Architectural Patterns�

The architectural pattern shows how a solution can be used to solve a re-occurring problem.
In another word, it reflects how a code or components interact with each other.
Moreover, the architectural pattern is describing the architectural style of our system and provides solutions for the issues in our architectural style.
For example: how to separate the UI of the data module in our architectural style? How to integrate a third-party component with our system? how many tires will we have in our client-server architecture?

174

175 of 350

Architectural Patterns(contd..)

For example, an e-commerce business that sells golf equipment to consumers will operate in a different context than an e-commerce business that sells high-priced industrial equipment to medium and large corporations. In addition, a set of limitations and constraints may affect the way in which you address the problem to be solved.
Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints. The pattern proposes an architectural solution that can serve as the basis for architectural design.

176 of 350

Architectural Design

Architectural design involves three main tasks:

Represent the system in context

Define the external entities (other systems, devices, people) that the software interacts with Use architectural context diagram (ACD)

Define archetypes

An archetype is an abstraction (similar to a class) that represents one element of system behavior
Four architectural archetypes should be identified

Node, Detector, indicator, controller

Use UML

Refine the architecture into components

The designer specifies the structure of the system by defining and refining software components that implement each archetype

176

177 of 350

Architectural Context

177

Actors

Subordinate systems

Superordinate systems

target system:

Security Function

uses

peers

homeowner

Safehome

Product

Internet-based

system

surveillance

function

sensors

control

panel

sensors

Depends on

Used by

178 of 350

(1) Representing the system Context:

At the architectural design level, a software architect uses an Architectural Context Diagram [ACD] to modeled the manner in which the software interacts with entities external to its boundaries
Referring to the below fig, system are represented as:
(i) Super Ordinate Systems:
System that uses the target system as part of some higher level processing scheme
(ii) Sub Ordinate Systems:
Systems that are used by the target system and provide data that are necessary to complete target system functionality
(iii) Peer – Level – Systems:
The systems that interact on a peer-to-peer basis [i.e. information is either produced or consumed by the peers and the target system]
(iv) Actors:
Those entities [people, devices] that interact with the target system, by producing (Or) consuming information that is necessary for requisite processing

178

179 of 350

(2) DEFINING ARCHETYPES:

An archetypes is a pattern (Or) class that represents a core abstraction, that is critical to the design of an architecture for the target system .The target system architecture is composed of archetypes

Example:

For a safe home security function the following archetypes are defined:

(i) Node: Represents a cohesive collection on input and output elements

Example:* A node might be

=> Various sensors

=> Variety of alarm indicators

(ii) Detector: An abstraction that encompasses all sensing equipment that feeds information into the target system Indicator: It represents all mechanisms for indicating that an alarm condition is occurring

Example: => Alarm Siren => Flashing light => Bells

(iii) Controller: An abstraction that depicts the mechanism that allows the arming (Or) disarming of a node,If the controller resides on network, they have the ability to communicate with one another

179

DEFINING ARCHETYPES:

An archetypes is a pattern (Or) class that represents a core abstraction, that is critical to the design of an architecture for the target system

The target system architecture is composed of archetypes

Example:

* For a safe home security function the following archetypes are defined:

Node: Represents a cohesive collection on input and output elements Example:

* A node might be

=> Various sensors

=> Variety of alarm indicators

(ii) Detector:

An abstraction that encompasses all sensing equipment that feeds information into the target system

Indicator: It represents all mechanisms for indicating that an alarm condition is occurring

Example:

=> Alarm Siren => Flashing light => Bells

Controller:

An abstraction that depicts the mechanism that allows the arming (Or) disarming of a node

If the controller resides on network, they have the ability to communicate with one another

181 of 350

(3) Refining the architecture into components:�

181

As the software architecture is refined into components the structure of the system begins to emerge

One source for the derivation and refinement of components is the application domain

For example, in a safe home security system function, we might define the set of top level components that address the following functionality:

(i) External Communication Management:

* It coordinates communication of the security system function with external entities

(ii) Control Panel Processing:

* It manages all control panel functionality

(iii) Detector Management:

* It coordinates access to all detectors attached to the system

(iv) Alarm Processing:

* It verifies and acts on all alarm conditions

184 of 350

What is the UML?

184

“The Unified Modeling Language is a family of graphical notations, backed by a single meta- model, that help in describing and designing software systems, particularly software systems built using the object-oriented style.”
UML first appeared in 1997
UML is standardized. Its content is controlled by the Object Management Group (OMG), a consortium of companies.

185 of 350

IMPORTANCE OF MODELING :

A model is a simplification of reality: We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims

Models help us to visualize a system as it is or as we want it to

be.

Models permit us to specify the structure or behavior of a

system.

Models give us a template that guides us in constructing a

system.

4. Models document the decisions we have made.

186 of 350

Conceptual Model of the UML

186

Building Blocks of the UML:

The vocabulary of the UML encompasses three kinds of building blocks:

Things
Relationships
Diagrams

187 of 350

Conceptual Model of the UML

187

Things in the UML
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

188 of 350

Conceptual Model of the UML

Structural 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.
Classes
Interface
Use Cases
Active Classes
Components
Nodes
Collabrations

189 of 350

Conceptual Model of the UML

Figure : Classes

Classes:

a class is a description of a set of objects that share the same attributes, operations,relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations

189

190 of 350

Conceptual Model of the UML

an interface is a collection of operations that specify a service of a class or component. An interface rarely stands alone. Rather, it is typically attached to the class or component that realizes the interface

Interface:

Figure :Interfaces

190

191 of 350

Conceptual Model of the UML

Collaborations:
a collaboration defines an interaction .These collaborations therefore represent the implementation of patterns that make up a system. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name

Figure:

Collaborations

191

192 of 350

Conceptual Model of the UML

Use Cases:

Figure :Use Cases

Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name

192

193 of 350

Conceptual Model of the UML

Active Classes:

an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations

Figure :Active Classes

193

194 of 350

Conceptual Model of the UML

Components:

A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations. Graphically, a component is rendered as a rectangle with tabs, usually including only its name

Figure :Components

194

195 of 350

Conceptual Model of the UML

Nodes:
a 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. A set of components may reside on a node and may also migrate from node to node. Graphically, a node is rendered as a cube, usually including only its name

Figure :Nodes

195

196 of 350

Conceptual Model of the UML

196

Behavioral Things:

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.

Messages
States

197 of 350

Conceptual Model of the UML

Messages:
an interaction is a behavior that comprises a set of messages exchanged among a set ofobjects within a particular context to accomplish a specific purpose. Graphically, a message is rendered as a directed line, almost always including the name of its operation.

States:
a 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.

197

198 of 350

Conceptual Model of the UML

Grouping Things:

Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages.
Packages:
A package is a general-purpose mechanism for organizing elements into groups.Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents

Figure: Packages

198

199 of 350

Conceptual Model of the UML

Annotational Things:
Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model.
There is one primary kind of annotation thing, called a note. A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements.

Figure 2-11 Notes

200 of 350

RELATIONSHIPS

Dependency

A dependency is a using relationship that states that a change in specification of one thing (for example, class Event) may affect another thing that uses it (for example, class Window), but not necessarily the reverse.

Graphically, a dependency is rendered as a dashed directed line

201 of 350

Generalization

-A generalization is a relationship between a general thing (called the superclass or parent)and a more specific kind of that thing (called the subclass or child).

-Generalization is sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind- of a more general thing (for example, the class Window).

202 of 350

Association

-An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Given an association connecting two classes, you can navigate from an objectof one class to an object of the other class, and vice versa.

203 of 350

Aggregation

-A plain association between two classes represents a structural relationship between peers, meaning that both classes are conceptually at the same level, no one more important than the other. Sometimes, you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation, which represents a "has-a" relationship,

204 of 350

DIAGRAMS

204

205 of 350

UML DIAGRAMS (as per your syllabus)

Class diagram
Sequence diagram
Collaboration diagram
Use case diagram
Component diagram

206 of 350

Class diagram

Class diagram
It’s a diagram that shows set of classes ,interfaces ,collaboration and either relationships .
Class diagrams are also the foundation for a couple of related diagrams: component diagrams and deployment diagrams.

Contents
Class diagram contain the following things
Classes
Interfaces
Collaboration
Dependency ,Generalization, association

207 of 350

Example :

When you build a house, you start with a vocabulary that includes basic building blocks, such as walls, floors, windows, doors, ceilings, and joists.
In fact when you build your house, you must consider how they interact.
The process of architecting your house thus involves assembling these things in a unique and pleasing manner intended to satisfy all your functional and nonfunctional requirements.
The blueprints you create to visualize your house and to specify its details to your contractors for construction are, in effect, graphical presentations of these things and their relationships.
With the class diagrams to visualize the static aspects of these building blocks and their relationships and to specify their details for construction

208 of 350

Example of a House Plan class Diagram

209 of 350

Fig: sample class diagram of online order

210 of 350

Modelling Techniques of class diagram

Modelling Simple Collaborations
Modelling a logical database schema
Forward Engineering
Reverse Engineering�

211 of 350

Modelling Simple Collaborations

To model a collaboration,

Identify the mechanism you'd like to model.
For each mechanism, identify the classes, interfaces, and other collaborations and Identify the relationships among these things.

∙ Use scenarios to walk through these things.

Be sure to populate these elements with their contents. For classes, start

with getting a good balance of responsibilities. Then, over time, turn these

into concrete attributes and operations.

Common modelling Techniques

212 of 350

For example, Figure 8-2 shows a set of classes drawn from the implementation of an autonomous robot.
The figure focuses on the classes involved in the mechanism for moving the robot along a path.
You'll find
one abstract class (Motor)
with two concrete children, SteeringMotor and MainMotor.

(c) Both of these classes inherit the five operations of their parent, Motor. The two classes are, in turn, shown as parts of another class, Driver. The class PathAgent has a one-to-one association to Driver and a one-to-many association to CollisionSensor. No attributes or operations are shown for PathAgent, although its responsibilities are given.

214 of 350

Modeling a logical database schema �

To model a schema

Identify those classes in the model whose state must transcend the lifetime of their application.
Explain structural details of these classes .
Watch for common pattern that complicate physical database design .
Consider the behavior of these classes by expending operations .
Use tools to transform logical design to physical design .

216 of 350

INTERACTION DIAGRAMS

Interaction diagrams are not only important for modeling the dynamic aspects of a system, but also for constructing executable systems through forward and reverse engineering.

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 objects that send and receive messages.

217 of 350

SEQUENCE DIAGRAM

A sequence diagram emphasizes the time ordering of messages.
As Figure shows, you form a sequence diagram by first placing the objects that participate in the interaction at the top of your diagram, across the X axis.
Typically, you place the object that initiates the interaction at the left, and increasingly more subordinate objects to the right.
Next, you place the messages that these objects send and receive along the Y axis, in order of increasing time from top to bottom.
This gives the reader a clear visual cue to the flow of control over time.

219 of 350

COLLABORATION DIAGRAM

A collaboration diagram emphasizes the organization of the objects that participate in an interaction.
As Figure 18-3 shows, you form a collaboration diagram by first placing the objects that participate in the interaction as the vertices in a graph. Next, you render the links that connect these objects as the arcs of this graph.
Finally, you adorn these links with the messages that objects send and receive.
This gives the reader a clear visual cue to the flow of control in the
context of the structural organization of objects that collaborate

221 of 350

Interaction diagrams can be used −

To model the flow of control by time sequence.
To model the flow of control by structural organizations.
For forward engineering.
For reverse engineering.

Common modelling Techniques of Interaction diagram

222 of 350

Modeling flow control by Time ordering

Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration.

Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the sequence diagram from left to right, placing the more important objects to the left and their neighboring objects to the right.

Set the lifeline for each object For those objects that are created and destroyed during the interaction, set their lifelines, as appropriate, and explicitly indicate their birth and death with appropriately stereotyped messages

223 of 350

Eg. Modeling Flows of Control by Time Ordering

224 of 350

Modeling Flows of control by organization

Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration.

Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the collaboration diagram as vertices in a graph, placing the more important objects in the center of the diagram and their neighboring objects to the outside.
Specify the links among these objects, along which messages may pass.

Lay out the association links first; these are the most important ones,

because they represent structural connections.

Lay out other links next, and adorn them with suitable path stereotypes (such as global and local) to explicitly specify how these objects are related to one another.

225 of 350

Modeling Flows of control by organization

226 of 350

Use Case Diagrams

A use case diagram is a diagram that shows a set of use cases

and actors and their relationships.

Common Properties

A use case diagram is just a special kind of diagram and shares the same common properties as do all other diagrams,What distinguishes a use case diagram from all other kinds of diagrams is its particular content.

Contents

Use case diagrams commonly contain
Use cases
Actors
Dependency, generalization, and association relationships

227 of 350

Common Modeling Techniques

Modeling the Context of a System
To model the context of a system,

Identify the actors that surround the system by considering which groups require help from the system to perform their tasks; which groups are needed to execute the system's functions; which groups interact with external hardware or other software systems; and which groups perform secondary functions for administration and maintenance.

Organize actors that are similar to one another in a generalization/specialization hierarchy.

228 of 350

Modeling the Context of a System�contd..

229 of 350

Modeling the Requirements of a System

To model the requirements of a system,

Establish the context of the system by identifying the actors

that surround it.

For each actor, consider the behavior that each expects or requires the system to provide.
Model these use cases, actors, and their relationships in a use

case diagram.

Adorn these use cases with notes that assert nonfunctional requirements; you may have to attach some of these to the whole system.

230 of 350

Modeling the Requirements of a System

231 of 350

Component Diagrams

A component diagram shows a set of components and their relationships. Graphically, a component diagram is a collection of vertices and arcs.
Contents
Components
Interfaces
Dependency, generalization, association, and realization relationships Like all other diagrams, component diagrams may contain notes and constraints.

234 of 350

Common uses

When you model the static implementation view of a system, you'll typically use component diagrams in one of four ways.
To model source code
To model executable releases
To model physical databases
To model adaptable systems

235 of 350

Common Modeling Techniques

Modeling Source Code

To model a system's source code,

Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotyped as files.
For larger systems, use packages to show groups of source code files.
Consider exposing a tagged value indicating such information as the version number of the source code file, its author, and the date it was last changed. Use tools to manage the value of this tag.
Model the compilation dependencies among these files using dependencies. Again, use tools to help generate and manage these dependencies.

236 of 350

Modeling Source Code�contd….

model executable releases

237 of 350

Modeling an Executable Release

To model an executable release
Identify the set of components you'd like to model. Typically, this will involve some or all the components that live on one node, or the distribution of these sets of components across all the nodes in the system.

Consider the stereotype of each component in this set. For most systems, you'll find a small number of different kinds of components (such as executables, libraries, tables, files, and documents). You can use the UML's extensibility mechanisms to provide visual cues for these stereotypes.

238 of 350

Modeling an Executable Release�contd….

For each component in this set, consider its relationship to its neighbors. Most often, this will involve interfaces that are exported (realized) by certain components and then imported (used) by others. If you want to expose the seams in your system, model these interfaces explicitly. If you want your model at a higher level of abstraction, elide these relationships by showing only dependencies among the components.

240 of 350

Modeling a Physical Database

Identify the classes in your model that represent your logical database schema.
Select a strategy for mapping these classes to tables. You will also want to consider the physical distribution of your databases.
To visualize, specify, construct, and document your mapping, create a component diagram that contains components stereotyped as tables.

241 of 350

Modeling a Physical Database contd…

242 of 350

Modeling Adaptable Systems

Consider the physical distribution of the components that may migrate from node to node.
Create a corresponding interaction diagram that contains component instances.
You can illustrate a change of location by drawing the same instance more than once, but with different values for its location tagged value.

243 of 350

Modeling Adaptable Systems contd…

244 of 350

UNIT – IV

Testing Strategies

A strategic approach to software testing[2M]
Test strategies for conventional software [8M]

(a) Unit Testing

(b) Integration Testing

(d) System Testing

Art of Debugging [5M]
Black-box and white-box testing[8M]

Metrics for Process and Products

Software measurement
Metrics for software quality.

245 of 350

Strategic approach to Software Testing

Generic characteristics of strategic software testing:

To perform effective testing, a software team should conduct effective formal technical reviews.
Testing begins at the component level and works "outward" toward the integration of the entire computer-based system.
Different testing techniques are appropriate at different points in time.
Testing is conducted by the developer of the software and (for large projects) an independent test group.

246 of 350

Strategic approach to Software Testing

Generic characteristics of strategic software testing:

Verification and Validation
Organising for Software testing
Software Testing Strategy—The Big Picture
Software Testing Steps

247 of 350

(1) Verification and Validation

Verification refers to the set of activities that ensure that software correctly implements a specific function.
Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
State another way:

Verification: "Are we building the product right?"
Validation: "Are we building the right product?“

248 of 350

V&V encompasses a wide array of SQA activities that include

Formal technical reviews,
quality and configuration audits,
performance monitoring,
feasibility study,
documentation review,
database review,
algorithm analysis,
development testing,
qualification testing, and installation testing

249 of 350

(2) Organising for Software testing

The software engineer is always responsible for testing the individual units (components) of the program

In many cases the developer also conducts integration testing – a testing step that leads to the construction of the complete software architecture

The role of an Independent Test Group [ITG] is to remove the inherent problems associated with letting the builder test the thing that has been built

The developer and the ITG work closely throughout a software project to ensure that through test will be conducted ,While testing is conducted the developer must available to correct errors that are uncovered

250 of 350

(3) Software Testing Strategy for conventional software architecture

251 of 350

Test Strategy for Conventional Software: � �

Unit testing begins at the vortex of the spiral and concentrates on unit [i.e. components] of the software as implemented in the source code
Taking another turn by moving along the spiral to integrate testing which focus on design and the construction of software architecture
Next turn we encounter validation testing which validate requirements established as part of software requirements analysis against software that has been constructed
Finally we arrive at system testing, where the software and other system elements are tested as whole

252 of 350

(4) Software Testing Steps:

253 of 350

(1) Unit Testing

Focuses verification effort on the smallest unit of software design – component or module. Unit test consists of

Unit Test Considerations
Unit Test Procedures

254 of 350

Unit Test Considerations

255 of 350

Unit test Considerations:

* The test that occurs as part of unit tests are shown below

(1)Interface:

* It is tested to ensure that;

=> Information properly flows into and out of the program unit under test

(2)Local Data structures:

These are examined to ensure that Data stored temporarily maintains its integrity during all steps in an algorithm execution

(3) Independent Paths:

All basis paths through the control structures are examined to ensure that
=> All statements in a module have been executed at least once

(4)Boundary Conditions:

* These are tested to ensure that the module operates properly at boundaries established to limit (Or) restrict processing

256 of 350

Errors are commonly found during unit testing

More common errors in computation are

misunderstood or incorrect arithmetic precedence
mixed mode operations,
incorrect initialization,
precision inaccuracy,
incorrect symbolic representation of an expression.

257 of 350

Unit Test Procedures

Unit Test Environment

258 of 350

Driver:

In most applications a driver is nothing more than a “main program”, It accepts;

=> Test Cases data

=> Passes these data to the component [to be tested]

Print relevant results

Stub (Or) Dummy Programs:

It replaces modules that are called by the component to be tested

* Stub uses

=> the subordinate module’s interface

=> do minimal data manipulation

=> provides verification of entry

=> returns control to the module undergoing testing

Both drivers and stubs are software that must be written but that is not delivered with the final software product

259 of 350

(2) Integration testing

The objective is to take unit tested components and build a program structure that has been dictated by design.
Incremental Integration:

It is the mechanism of putting all the modules together , The problems that

occur during integrating are

=> Data can be lost across an integrating

=> One module can have an in advertent adverse affect on another

=> Sub functions, when combined may not produce the desired major

Function

=> Individually acceptable imprecision may be magnified to unacceptable

levels

=> Global data structures can present problems

260 of 350

Integration testing involves in 2 types
Top Down Integration

(i) Depth First Search

(ii) Breadth First Search

(b) Bottom Up integration

(d) Smoke Testing

261 of 350

(a) Top-down Integration

Top-down integration testing is an incremental approach to construction of program structure.
Modules subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

262 of 350

Depth First integration

Depth-first integration would integrate all components on a major control path of the structure.
For example, selecting the left hand path,
Components M1, M2 , M5 would be integrated first.
Next, M8 or M6 would be integrated
The central and right hand control paths are built.

263 of 350

Breadth-first integration incorporates all components directly subordinate at each level, moving across the structure horizontally.
Step would be:

components M2, M3, and M4 would be integrated first
next control level, M5, M6, and so on follows.

Breadth-first integration

264 of 350

(b) Bottom-up Integration

Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., components at the lowest levels in the program structure)
Because components are integrated from the bottom up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated.

265 of 350

Bottom up integration

Components are combined to form clusters 1, 2, and 3. Each of the clusters is tested using a driver.
Components in clusters 1 and 2 are subordinate to Ma.
Drivers D1 and D2 are removed and the clusters are interfaced directly to Ma. Similarly, driver D3 for cluster 3 is removed prior to integration with module Mb.
Both Ma and Mb will ultimately be integrated with component Mc, and so forth.

266 of 350

Each time a new module is added as part of integration testing

New data flow paths are established
New I/O may occur
New control logic is invoked

Due to these changes, may cause problems with functions that previously worked flawlessly.
Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.

267 of 350

(d)Smoke Testing

Smoke testing is an integration testing approach that is commonly used when “shrink wrapped” software products are being developed.
It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a frequent basis.

Smoke testing approach activities

Software components that have been translated into code are integrated into a “build.”

A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions.

A series of tests is designed to expose errors that will keep the build from properly performing its function.

268 of 350

(3) Validation Testing

Validation testing succeeds when software functions in a manner that can be reasonably expected by the customer.
Reasonable expectations are defined in the Software Requirements Specification— a document that describes all user-visible attributes of the software.
Validation testing comprises of

Validation Test criteria
Configuration review
Alpha & Beta Testing

269 of 350

(a) Validation Test criteria

It is achieved through a series of tests that demonstrate agreement with requirements.

all functional requirements are satisfied,
all behavioral characteristics are achieved,
all performance requirements are attained,
documentation is correct,

270 of 350

(b)Configuration Review

The intent of the review is to ensure that all elements of the software configuration have been properly developed, are cataloged, and have the necessary detail to the support phase of the software life cycle.
The configuration review, sometimes called an audit.

271 of 350

(c)Alpha testing

It is conducted at the developers’ site by End – Users
The software is used in a natural setting
The developer is present along with the End – Users
The developer records errors and usage problems
Alpha Tests are conducted in a controlled environment

�

272 of 350

(d) Beta testing

It is conducted at End – User sites here the developer is not present
The beta test is a “Live” application of the software in an environment, that cannot be controlled by the developer
The end – User records all problems that are encountered during beta testing
This error reports are send to the developer at regular interval
Based on the error report the software engineer makes modifications and then prepare for release of the software product to entire customer base

273 of 350

(4) System Testing

System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system.
Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions.
Types of system tests are:

Recovery Testing
Security Testing
Stress Testing
Performance Testing
Sensitive Testing

274 of 350

Recovery Testing: It is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed.
if recovery is automatic [i.e. performed by system itself] then Reinitialization, Data recovery & Restart are evaluated for correctness

(2) Security Testing: It verifies that protection mechanism built into a system will in fact protect it from improper penetration

Stress Testing: Stress testing executes a system in a manner that demands resources in abnormal quality, frequency (Or) volume

Example:

Input data rates may be increased by an order of magnitude to determine how input functions will respond

Performance Testing: It is designed to test the Run tike performance of software within the context of an integrated system
Sensitivity Testing: Sensitivity testing attempts to uncover data combinations within valid inputs classes that may cause instability (Or) improper processing

275 of 350

THE ART OF DEBUGGING

Debugging is the process that results in the removal of the error.
Debugging is not testing but always occurs as a consequence of testing.

276 of 350

Debugging Approaches or strategies

Three categories for debugging approaches

Brute force
Backtracking
Cause elimination

Brute Force:

probably the most common and least efficient method for isolating the cause of a software error.
Apply brute force debugging methods when all else fails.
Using a "let the computer find the error" philosophy, memory dumps are taken, run-time traces are invoked, and the program is loaded with WRITE or PRINT statements
It more frequently leads to wasted effort and time.

277 of 350

Backtracking:

common debugging approach that can be used successfully in small programs.
Beginning at the site where a symptom has been open, the source code is traced backward (manually) until the site of the cause is found.

Cause elimination

Is cleared by induction or deduction and introduces the concept of binary partitioning (i.e. valid and invalid).
A list of all possible causes is developed and tests are conducted to eliminate each.

278 of 350

White box testing

White-box testing of software is predicated on close examination of procedural detail.
White-box testing, sometimes called glass-box testing
Using this method, SE can derive test cases that
Guarantee that all independent paths within a module have been exercised at least once
Exercise all logical decisions on their true and false sides,
Execute all loops at their boundaries and within their operational bounds
Exercise internal data structures to ensure their validity.

279 of 350

Black box testing

Also called behavioral testing, focuses on the functional requirements of the software.
Black-box testing is not an alternative to white-box techniques but it is complementary approach.
Black-box testing attempts to find errors in the following categories:

Incorrect or missing functions,
Interface errors,
Errors in data structures or external data base access.
Behavior or performance errors,
Initialization and termination errors.

280 of 350

Black box testing methods

Graph-Based Testing Methods
Equivalence partitioning
Boundary value analysis (BVA)
Orthogonal Array Testing

281 of 350

Graph-Based Testing Methods

To understand the objects that are modeled in software and the relationships that connect these objects.
Stated in other way:

Create a graph of important objects and their relationships
Develop a series of tests that will cover the graph

So that each object and relationship is exercised and errors are uncovered.
Begin by creating graph –

a collection of nodes that represent objects
links that represent the relationships between objects
node weights that describe the properties of a node
link weights that describe some characteristic of a link.

282 of 350

Nodes are represented as circles connected by links that take a number of different forms.
A directed link (represented by an arrow) indicates that a relationship moves in only one direction.
A bidirectional link, also called a symmetric link, implies that the relationship applies in both directions.
Parallel links are used when a number of different relationships are established between graph nodes.

283 of 350

Example

Object #1 = new file menu select

Object #2 = document window

Object #3 = document text

Referring to example figure, a menu select on new file generates a document window.

The link weight indicates that the window must be generated in less than 1.0 second.

The node weight of document window provides a list of the window attributes that are to be expected when the window is generated.

284 of 350

Equivalence Partitioning

Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition.
An equivalence class represents a set of valid or invalid states for input conditions.
Typically, an input condition is either a specific numeric value, a range of values, a set of related values, or a Boolean condition.

EXAMPLES:

area code—blank or three-digit number
prefix—three-digit number not beginning with 0 or 1
password—six digit alphanumeric string

285 of 350

Boundary Value Analysis (BVA)

Boundary value analysis is a test case design technique that complements equivalence partitioning.
Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class.

286 of 350

Orthogonal Array Testing

It is used as a statistical technique to generate the permutation of inputs, resulting in test cases with optimal test coverage to derive effort reduction in Test planning and Test design phase.
When functionality spanning with many permutations & combinations on various inputs, it would be difficult to ensure the coverage in manual way.

287 of 350

Example

Example of Orthogonal Array Technique
Optimal Testing Coverage is required for the combinations of the following inputs.

Exhaustive testing requires 48(4 Mobile Phones * 4 Web Browsers * 3 OS) test cases.

Mobile Phones	Web browsers	OS
Apple	Safari	iOS
Samsung	Chrome	Android
HTC	I.E	Windows mobile
Nokia	Firefox

288 of 350

SOFTWARE MEASUREMENT

Measurements in the physical world can be categorized in two ways:

Direct measures (e.g., the length of a bolt)
Indirect measures (e.g., the “quality” of bolts produced, measured by counting rejects)

Direct measures of the software process include : Cost and effort applied, Lines of code (LOC) produced, Execution speed, Memory size, Defects
Indirect measures of the product include Functionality ,Quality, Complexity, Efficiency, Reliability, maintainability

289 of 350

To illustrate, consider a simple example. Individuals on two different project teams record and categorize all errors that they find during the software process. Individual measures are then combined to develop team measures.
Team A found 342 errors during the software process prior to release.
Team B found 184 errors.
All other things being equal, which team is more effective in uncovering errors throughout the process?
Because you do not know the size or complexity of the projects, you cannot answer this question. However, if the measures are normalized, it is possible to create software metrics that enable comparison to broader organizational averages.

290 of 350

Process metrics for Software Measurement [5m]

The process metrics for software measurement are calculated based on

size oriented metrics
Function Oriented metrics
Restore LOC and FP metrics
Object Oriented metrics
Use case Design Metrics

291 of 350

Size-Oriented Metrics : Size-oriented software metrics are derived size of the software that has been produced.

Example : If a software organization maintains simple records, a table of size-oriented measures, such as the one shown in Figure can be created.

Referring to the table entry for project alpha,

Three people worked on the development of software for project alpha

12,100 lines of code were developed with 24 person-months of effort at a cost of $168,000..
365 pages of documentation were developed, 134 errors were
29 defects were encountered after release to the customer within the first year of operation.

.i.e. the size oriented metrics are calculated by

• Errors per KLOC (thousand lines of code)

• Defects per KLOC

• $ per KLOC

• Pages of documentation per KLOC

293 of 350

(a) Function Oriented Metrics:

Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity
Information domain values are defined in the following manner:

Number of external inputs (eis)
Number of external outputs (eos)
Number of external inquiries (eqs)
Number of internal logical files (ilfs)
Number of external interface files (eifs)

To compute functional point the following relationship is used

FP = count total * [0.65 + 0.01 * ∑ (fi)]

Where count total is the sum of all FP entries

294 of 350

External Inputs => 3 [Password, Panic Button, activate / deactivate]

External Inquires => 2 [Zone and Sensor Inquiry]

ILF => 1 [System Configuration File]

External Outputs => 2 [Messages and Sensor status]

External interfaces => 4 [Test sensor, zero setting, activate / deactivate and alarm alert]

295 of 350

FP = Count Total * [0.65 + 0.01 * ∑ (Fi)]

Where,

Count Total => the sum of all FP entries obtained

∑Fi => 46 [a moderately complex product]

FP = 50 * [0.65 + (0.01 * 46) = 56

296 of 350

The fi [i =1 to 14] are value adjustment factors [VAF] based on responses to the following questions

(1) does the system require reliable backup and recovery?

(2) are specialized data communication required to )or) from the application

(3) are there distributed processing functions?

(4) is performance critical?

(5) will the system run in an existing heavily utilized operational environment

(6) does the system require on-line data entry?

(7) does the on-line data entry require the input transaction to be built over multiple screens (or) operations?

(8) are the ilf’s updated online?

(9) are the inputs, outputs, files (or) inquires complex?

(10)is the internal processing complex?

296

297 of 350

(11) is the code designed to be reusable?

(12) are conversion and installation included in the design?

(13) is the system designed for multiple installations in different organization?

(14) is the application designed to facilitate change and for ease of use by the user?

Each question is answered using a scale ranges from 0 [not important (or) applicable] to 5 [absolutely essential]

�

298 of 350

(c)Restore LOC and FP metrics:

The relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the design.

The following table provides rough estimates of the average number of lines of code required to build one function point in various programming languages:

A review of these data indicates that one LOC of C++ provides approximately 2.4 times the “functionality” (on average) as one LOC of C. Furthermore, one LOC of Smalltalk provides at least four times the functionality of an LOC for a conventional programming language such as Ada, COBOL, or C. we have to restore the LOC to work properly.

299 of 350

(d)Object Oriented Metrics

Conventional software project metrics (LOC or FP) can be used to estimate object oriented software projects. However, these metrics do not provide enough granularity Lorenz and Kidd suggest the following set of metrics for OO projects:

Number of Classes
Number of Support classes
Average number of support classes with keys
Number of objects
Number of functions

300 of 350

(e)Use case oriented metrics:

The use case is independent of programming language.
The number of use cases is directly proportional to the size of the application in LOC
Because use cases can be created at vastly different levels of abstraction, there is no standard “size” for a use case.
The UCP is a function of the number of actors and transactions implied by the use-case models and is analogous to the FP in some ways.

301 of 350

Metrics for Software Quality

(a)Measuring Defect removal Efficiency:

All the above product metrics are used to compute the defect removal efficiency (DRE) for a Good quality product. When considered for a project as a whole, DRE is defined in the following manner:

DRE = E /( E + D)

where E is the number of errors found before delivery of the software to the end

D is the number of defects found after delivery.

The ideal value for DRE is 1. That is, no defects are found in the software. Realistically,

302 of 350

(b)Measuring Quality

There are many measures for software quality. They are

Correctness
maintainability
usability

Correctness. The most common measure for correctness is defects per KLOC, When considering the overall quality of a software product, defects are those problems reported by a user of the program after the program has been released for general use.

Maintainability.: There is no way to measure maintainability directly; therefore, you must use indirect measures. A simple indirect time-oriented metric is mean-time-to-change (MTTC),.The MTTC include the time it takes to analyze the change request, design an appropriate modification, implement the change,

303 of 350

Usability. If a program is not easy to use, it is often doomed to failure, even if the functions that it performs are valuable. Usability is an attempt to quantify ease of use and can be measured in terms of the characteristics

304 of 350

UNIT 5

Risk management

Reactive Vs proactive risk strategies

Software risks

Risk identification

Risk Projection

Risk Refinement,

RMMM,

RMMM plan

Quality Management

Quality concepts

Software quality assurance

Software reviews

Formal technical reviews

Statistical software quality assurance

Software reliability

ISO 9000 quality standards.

305 of 350

Definition of Risk

305

A risk is a potential problem – it might happen and it might not .
Risk concerns future happenings
Risk involves change in mind, opinion, actions, places, etc.
Two characteristics of risk

Uncertainty – the risk may or may not happen, that is, there are no 100% risks

Loss – the risk becomes a reality and unwanted consequences or losses occur

–

306 of 350

Risk Categorization – Approach #1

306

•

Project risks

–

They threaten the project plan

If they become real, it is likely that the project schedule will slip and that costs will increase

•

Technical risks

–

They threaten the quality of the software to be produced If they become real, implementation may become difficult or impossible

•

Business risks

–

They threaten the viability of the software to be built

If they become real, they jeopardize the project or the product

307 of 350

Risk Categorization – Approach #1 (continued)

307

•

Sub-categories of Business risks

–

^–Market risk – building an excellent product or system that no one really wants

Strategic risk – building a product that no longer fits into the overall business strategy for the company

Sales risk – building a product that the sales force doesn't understand how to sell

Management risk – losing the support of senior management due to a change in focus or a change in people

Budget risk – losing budgetary or personnel commitment

308 of 350

Risk Categorization – Approach #2

308

Known risks

Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date)

Predictable risks

Those risks that are extrapolated from past project experience (e.g., past turnover)

Unpredictable risks

Those risks that can and do occur, but are extremely difficult to identify in advance

309 of 350

Reactive vs. Proactive Risk Strategies

309

•

Reactive risk strategies

–

"Don't worry, I'll think of something"

The majority of software teams and managers rely on this approach Nothing is done about risks until something goes wrong

•

Proactive risk strategies

–

Steps for risk management are followed (see next slide)

Primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risks in a controlled and effective manner

310 of 350

Steps for Risk Management

310

Identify possible risks; recognize what can go wrong
Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it will do if it does occur
Rank the risks by probability and impact

- Impact may be negligible, marginal, critical, and catastrophic

Develop a contingency plan to manage those risks having high probability and high impact

311 of 350

Risk Identification

312 of 350

Background

312

•

Risk identification is a systematic attempt to specify threats to the project plan

By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary

Generic risks

^–Risks that are a potential threat to every software project

Product-specific risks

^–Risks that can be identified only by those a with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built.

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:

–

313 of 350

Known and Predictable Risk Categories

313

•

Product size – risks associated with overall size of the software to be built

Business impact – risks associated with constraints imposed by management or the marketplace

Customer characteristics – risks associated with sophistication of the customer and the developer's ability to communicate with the customer in a timely manner

Process definition – risks associated with the degree to which the software process has been defined and is followed

Development environment – risks associated with availability and quality of the tools to be used to build the project

Technology to be built – risks associated with complexity of the system to be built and the "newness" of the technology in the system

Staff size and experience – risks associated with overall technical and project experience of the software engineers who will do the work

314 of 350

Assessing Overall Project Risks

The following questions have been derived from risk data, obtained from experienced software project managers

The questions are ordered by relative importance to the success of as project

Questionnaire on Project Risk

(Questions are ordered by their relative importance to project success)

Have top software and customer managers formally committed to support the project?
Are end-users enthusiastically committed to the project and the system/product to be built?
Are requirements fully understood by the software engineering team and its customers?
Have customers been involved fully in the definition of requirements?
Do end-users have realistic expectations?
Is the project scope stable?

315 of 350

Questionnaire on Project Risk (continued)

315

Does the software engineering team have the right mix of skills?
Are project requirements stable?
Does the project team have experience with the technology to be implemented?
Is the number of people on the project team adequate to do the job?
Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

316 of 350

Risk Components and Drivers:

316

•

The project manager identifies the risk drivers that affect the following risk components

–

^–Performance risk - the degree of uncertainty that the product will meet its requirements and be fit for its intended use

Cost risk - the degree of uncertainty that the project budget will be maintained

Support risk - the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance

Schedule risk - the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time

•

The impact of each risk driver on the risk component is divided into one of four impact levels

^–Negligible, marginal, critical, and catastrophic

Risk drivers can be assessed as impossible, improbable, probable, and frequent

317 of 350

Risk Projection (Estimation)

318 of 350

Risk projection, also called risk estimation, attempts to rate each risk in two ways—

(1) the likelihood or probability that the risk is real and (2) the consequences of the

problems associated with the risk, should it occur. You work along with other managers

and technical staff to perform four risk projection steps:

1. Establish a scale that reflects the perceived likelihood of a risk.

2. Delineate the consequences of the risk.

3. Estimate the impact of the risk on the project and the product.

4. Assess the overall accuracy of the risk projection so that there will be no

misunderstandings.

319 of 350

Background

319

Risk projection (or estimation) attempts to rate each risk in two ways

- The probability that the risk is real

- The consequence of the problems associated with the risk, should it occur

The project planner, managers, and technical staff perform four risk projection steps :

Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)
Delineate the consequences of the risk
Estimate the impact of the risk on the project and product
Note the overall accuracy of the risk projection so that there will be no misunderstandings

320 of 350

(a)Developing a Risk Table

•

A risk table provides you with a simple technique for risk projection.2 A sample risk table is illustrated in Figure 28.2.

It consists of five columns

–

Risk Summary – short description of the risk

Risk Category – one of seven risk categories (slide 12) Probability – estimation of risk occurrence based on group input Impact – (1) catastrophic (2) critical (3) marginal (4) negligible

RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and Management Plan

322 of 350

322

List all risks in the first column (by way of the help of the risk item checklists)
Mark the category of each risk
Estimate the probability of each risk occurring
Assess the impact of each risk based on an averaging of the four risk components to determine an overall impact value (See next slide)
Sort the rows by probability and impact in descending order
Draw a horizontal cutoff line in the table that indicates the risks that will be given further attention

323 of 350

(b) Assessing Risk Impact

323

–

Example

P = 80% probability that 18 of 60 software components will have to be developed C = Total cost of developing 18 components is $25,000

RE = .80 x $25,000 = $20,000

Returning once more to the risk analysis approach proposed by the U.S. Air Force

you can apply the following steps to determine the overall consequences of a risk: (1) determine the average probability of occurrence value for each risk component; (2) using the risk table Figure, determine the impact for each component based on the criteria shown, and

(3) complete the risk table and analyze the results as described in the preceding sections.

The overall risk exposure formula is RE = P x C

P = the probability of occurrence for a risk

C = the cost to the project should the risk actually occur

324 of 350

RISK REFINEMENT

325 of 350

RISK REFINEMENT

During early stages of project planning, a risk may be stated quite generally.

As time passes and more is learned about the project and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage.

One way to do this is to represent the risk in condition-transition-consequence

(CTC) format [Glu94]. That is, the risk is stated in the following form:

Given that <condition> then there is concern that (possibly) <consequence>

This general condition can be refined in the following manner:

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.

The consequences associated with these refined subconditions remain the same

(i.e., 30 percent of software components must be custom engineered), but the

refinement helps to isolate the underlying risks and might lead to easier analysis and

response.

326 of 350

Risk Mitigation ,Monitoring, and �Management

327 of 350

Background

•

An effective strategy for dealing with risk must consider three issues

(Note: these are not mutually exclusive)

Risk mitigation (i.e., avoidance) Risk monitoring

Risk management and contingency planning

Risk mitigation (avoidance) is the primary strategy and is achieved through a plan .Example: Risk of high staff turnover (see next slide)

Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market)
Mitigate those causes that are under our control before the project startsDefine documentation standards and establish mechanisms to ensure that documents are developed in a timely manner
Conduct peer reviews of all work (so that more than one person is "up to speed")
Assign a backup staff member for every critical technologist

328 of 350

328

Risk Monitoring : During risk monitoring, the project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely.

Risk management and contingency planning : That mitigation efforts have failed and that the risk has become a reality

For Example:

The project is well under way and a number of people announce that they will be leaving.
If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team.
In addition, you can temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to “get up to speed.”
Those individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer mode.” This might include video-based knowledge capture, the development of “commentary documents or Wikis,” and/or meeting with other team members who will remain on the project.

329 of 350

QUALITY MANAGEMENT

330 of 350

The solution

Quality Management

What is Quality Management?

A management process to develop and manage the quality of a software to make sure that the product satisfies the user.

It has four main components:

Quality Planning

Quality Control
Quality Assurance
Quality Improvement

331 of 350

Components of Quality Management

Quality

Planning

Requirements must be identified, a criteria needs to be set, and important procedure must be recognized as a part of the plan.

Quality Control

To review the quality of the product or service. Inspection and testing is necessary to identify problems and defects that need correction.

Through quality improvement, the results can be measured and possible improvements in products can be made.

Quality Assurance

Quality Improvement

Companies need to assure defects and mistakes are avoided in the manufacturing of good and quality assurance guarantees consistent results.

332 of 350

Software Quality

It is defined as “a characteristic (Or) attribute of something”
Software quality product is defined in term of its fitness of purpose. That is, For software products, the fitness of use is generally explained in terms of satisfaction of the requirements laid down in the SRS document. not consider it to be a quality product.
Quality methods such as the following should be satisfied: Portability, Usability, Reusability, Correctness

Software Quality Management System

A quality management system is the principal methods used by organizations to provide that the products they develop have the desired quality. The quality system activities encompass the following:

Auditing of projects
Review of the quality system
Development of standards, methods, and guidelines, etc.
Production of documents for the top management summarizing the effectiveness of the quality system in the organization.

333 of 350

SQA Software Quality Assurance

Umbrella activity applied throughout the software process
Planned and systematic pattern of actions required

to ensure high quality in software

Responsibility of many stakeholders (software engineers, project managers, customers, salespeople, SQA group)

334 of 350

SQA Tasks

Prepares an SQA plan for a project.

The plan identifies

evaluations to be performed
audits and reviews to be performed
standards that are applicable to the project
procedures for error reporting and tracking
documents to be produced by the SQA group
amount of feedback provided to the software project team

Participates in the development of the project’s software process description.

The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan.

335 of 350

Reviews software engineering activities to verify compliance with the defined software process.

- The SQA group identifies, documents, and tracks deviations from the process

and verifies that corrections have been made.

Audits designated software work products to verify compliance with those defined as part of the software process.

- The SQA group reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made; and periodically reports the results of its work to the project manager.

Ensures that deviations in software work and work products are documented and handled according to a documented procedure.

- Deviations may be encountered in the project plan, process description,

applicable standards, or software engineering work products.

Records any noncompliance and reports to senior management.

- Noncompliance items are tracked until they are resolved.

336 of 350

Software Review

A process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval

337 of 350

Varieties of Software Reviews

Software peer reviews are conducted by the author of the work product, or by one or more colleagues of the author, to evaluate the technical content and/or quality of the work

Software management reviews are conducted by management representatives to evaluate the status of work done and to make decisions regarding activities.

Software Audit Review is a type of external review in which one or more critics, who are not a part of the development team, organize an independent inspection of the software product and its processes to assess their compliance with stated specifications and standards. This is done by managerial level people.

338 of 350

* It is performed by software engineers

Objectives:

To uncover errors in function, logic (Or) implementation for any representation of the software

To verify that the software under review meets its requirements

To ensure that the software has been represented according to predefined statements

To achieve software that is developed in a uniform manner

To make projects more manageable

Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled and attended

Formal Technical Review

339 of 350

(a) The Review Meeting:

* The review meeting should abide by the following constraints

Between three and five people should be involved in the review
Advance preparation should occur but should require no more than two hours of work for each person

=> The duration of the review meeting should be less than two hours

One of the reviewers should take on the role of the Recorder [i.e. Individual who records (in writing) all important issues raised during the review

The FTR begins with an introduction of the agenda, and a brief introduction by the producer ,valid problems (Or) errors are discovered.

At the end of the review all attendees of the FTR must decide whether to

Accept the product without further modification

Reject the product due to severe errors

Accept the product provisionally [minor errors have been encountered and must be corrected but no additional reviews will be required]

The decision made all FTR attendees complete a sign Off, indicating their participation in the review

340 of 350

Review Report:

A review summary form is a Single page form ,It becomes part of the project historical record and may be distributed to the project leader and other interested parties

The review issue list serves two purposes:

To identify problem areas with in the product

(ii) To serve as an action item check list that guides the producer as corrections made and issues list normally attached to the summary report

Review Guidelines:

The following represents a minimum set of guidelines for formal technical reviews

Review the product, Set an agenda and maintain it
Enunciate problem areas but don’t attempt to solve every problem noted
Take written notes
Limit the number of participants and insist upon advance preparation
Develop a check list for each product and that is likely to be reviewed

Allocate resources and schedule items for FTRs

Conduct meaningful training for all reviewers

Reviews your early reviews

341 of 350

Statistical Software Quality Assurance

Information about software defects is collected and categorized
An attempt is made to trace each defect to its

underlying cause

Isolate the vital few causes of the major source of all errors
Then move to correct the problems that have

caused the defects

342 of 350

Statistical SQA – Categories of Errors

• 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)

• Miscellaneous (MIS)

All the above Errors are noted in the form Table for every project and solve those defects for the next project

344 of 350

Statistical SQA – Six Sigma

Most widely used strategy for statistical SQA Three core steps

Define customer requirements, deliverables and project goals via customer communication

Measure the existing process and its output to determine quality

If an existing software process is in place, but

improvement is required, six sigma suggests

Improve the process by eliminating the root causes

of defects

345 of 350

Statistical SQA – Six Sigma (cont...)

Control the process to ensure that future work does not reintroduce the cases of defects
Design the process to
avoid the root causes of defects
to meet customer requirements
Verify that the process model will, in fact, avoid

defects and meet customer requirements

346 of 350

It is defined in statistical terms as “the probability of failure-free operation of a computer program in a specified environment for a specified time”

Whenever software reliability is discussed, a pivotal question arises:

What is meant by the term failure?

In the context of any discussion of software quality and reliability, failure is nonconformance to software requirements. One failure can be corrected within seconds, while another requires weeks or even months to correct.

Correcctions(measures) of Reliability and Availability:

Most hardware-related reliability models are predicated on failure due to wear rather than failure due to design defects. In hardware, failures due to physical wear (e.g., the effects of temperature, corrosion, shock) are more likely than a design-related failure. Unfortunately, the opposite is true for software. In fact, all software failures can be traced to design or implementation problems;

SOFTWARE RELIABILITY

347 of 350

* If we consider a computer – based system a simple measure of reliability is Mean – Time – Between – Failure [MTBF]

MTBF = MTTF + MTTR

MTTF => Mean Time To Failure

MTTR => Mean Time To Repair

Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as

Availability = MTTF / (MTTF + MTTR)] * 100%

348 of 350

ISO 9000 Standards

349 of 350

ISO 9000 Quality Standards

A quality assurance system may be defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.
Quality assurance systems are created to help organizations ensure their products and services satisfy customer expectations by meeting their specifications.
These systems cover a wide variety of activities encompassing a product’s entire life cycle including planning, controlling, measuring, testing and reporting, and improving quality levels throughout the development and manufacturing process.
ISO 9000 describes a quality assurance system in generic terms that can be applied to any business regardless of the product (Or) services offered
To become registered to one of the quality assurance system models contained in ISO 9000, a company quality system and operations and operations are scrutinized by third party auditors .
Upon successful registration, a company is issued a certificate from a registration body represented by the auditors. Semi annual surveillance audits ensure continued compliance to the standard.