Lecture Notes for Software Engineering

UNIT – I

Introduction to Software Engineering: Software characteristics, changing nature of software,

software myths.

A Generic view of Process: Software Engineering, Software engineering-A layered technology,

process framework, The Capability Maturity Model Integration (CMMI)

Software: “It is defined as an organized set of instructions to deliver a desired output by considering
various processes and functions.”
Now-a-days software acts both as product (Application Software) and vehicle for delivering a
product (System Software).
➢ As product, software delivers computing potential embodied by computer hardware (or) by a
network of computers that are accessible by local hardware.
➢ As the vehicle used to deliver product, software acts as basis for control of PC (OS),
Communication of information (Networks) and Creation and Control of other programs (Software
Tools, Environments).

Software Development: “It is a creative activity, where a software system is developed from initial
concept through a working system”.
Software Maintenance: “Process of changing a developed system once it is delivered”.

Software Evolution: “Evolutionary process where software is conceptually changed over its lifetime in
response to the changing requirements”.

Software Characteristics:

1. Software is developed (or) engineered, it is not manufactured.

2. Software doesn’t “wear out”. Sometimes, it may deteriorate with too many changes.

3. Most of soft wares continue to be custom build, component-based assembly. [As software is
bothproduct and vehicle to carry product].

1
 Lecture Notes for Software Engineering

Functionality:
It refers to the degree of performance of the software against its intended purpose.
Functionality refers to the set of features and capabilities that a software program or system provides to its
users.
The more functionality a software has, the more powerful and versatile it is, but also the more complex it can
be. It is important to balance the need for functionality with the need for ease of use, maintainability, and
scalability.
Required functions are:

2
 Lecture Notes for Software Engineering
Reliability:
A set of attributes that bears on the capability of software to maintain its level of performance under the
given condition for a stated period of time.
Reliability is a characteristic of software that refers to its ability to perform its intended functions correctly
and consistently over time. Reliability is an important aspect of software quality, as it helps ensure that the
software will work correctly and not fail unexpectedly.
Examples of factors that can affect the reliability of software include:

➢ Bugs and errors in the code

➢ Lack of testing and validation

➢ Poorly designed algorithms and data structures

➢ Inadequate error handling and recovery

➢ Incompatibilities with other software or hardware

➢ To improve the reliability of software, various techniques, and methodologies can be used, such as
testing and validation, formal verification, and fault tolerance.
Software is considered reliable when the probability of it failing is low and it is able to recover from the
failure quickly, if any.
Required functions are:

Types of Software Applications: Various types of software include:

1) System Software: “A collection of programs written to service other programs.”

2) Application Software: “It consists of stand-alone programs that solve a specific business need.”
3) Engineering/Scientific Software: “Characterized by numerical algorithm.” Ex: Astronomy etc.

4) Embedded Software: “Resides within a product/system to implement and control features and
functions for end user.” (Ex: keypad control for oven.)
5) Web-Applications: “Set of linked hyper text files which provide e-commerce and B2B (Business
to Business) application.”
6) AI Software: “Makes use of non-numerical algorithms to solve complex problems.” Ex: Robotics.

7) Product-line Software: “Capable to be used by many different customers.” (Ex: DBMS in BSE.)

8) Open Source: “Available for all customers and can be modified.”

9) Net Sourcing: “WWW is used as a content provider. So Software Engineers can develop simple
and sophisticated applications.”
3
 Lecture Notes for Software Engineering
10) Ubiquitous Computing: “Allows small devices to communicate across vast networks.”
Changing nature of software
Nowadays, seven broad categories of computer software present continuing challenges for software
engineers. Which is given below:
1.System Software: System software is a collection of programs that are written to service other
programs. Some system software processes complex but determinate, information structures. Other
system application processes largely indeterminate data. Sometimes when, the system software area is
characterized by the heavy interaction with computer hardware that requires scheduling, resource
sharing, and sophisticated process management.
2.Application Software: Application software is defined as programs that solve a specific business
need. Application in this area processes business or technical data in a way that facilitates business
operation or management technical decision-making. In addition to conventional data processing
applications, application software is used to control business functions in real-time.
3.Engineering and Scientific Software: This software is used to facilitate the engineering function and
task. however modern applications within the engineering and scientific area are moving away from
conventional numerical algorithms. Computer-aided design, system simulation, and other interactive
applications have begun to take a real-time and even system software characteristic.
4.Embedded Software: Embedded software resides within the system or product and is used to
implement and control features and functions for the end-user and for the system itself. Embedded
software can perform limited and esoteric functions or provide significant function and control
capability.
5.Product-line Software: Designed to provide a specific capability for use by many customers, product-
line software can focus on the limited and esoteric marketplace or address the mass consumer market.
6.Web Application: It is a client-server computer program that the client runs on the web browser. In
their simplest form, Web apps can be little more than a set of linked hypertext files that present
information using text and limited graphics. However, as e-commerce and B2B applications grow in
importance. Web apps are evolving into a sophisticated computing environment that not only provides a
standalone feature, computing function, and content to the end user.
7.Artificial Intelligence Software: Artificial intelligence software makes use of a nonnumerical
algorithm to solve a complex problem that is not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert systems, pattern recognition, artificial neural
networks, theorem proving, and game playing.
4
 Lecture Notes for Software Engineering
Software Myths:
Most, experienced experts have seen myths or superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates major problems for management and technical
people. The types of software-related myths are listed below.

`Types of Software Myths

(i) Management Myths:

Myth 1:
We have all the standards and procedures available for software development.

Fact:
• Software experts do not know all the requirements for the software development.
• And all existing processes are incomplete as new software development is based on new
and different problem.
Myth 2:
The addition of the latest hardware programs will improve the software development.

Fact:
• The role of the latest hardware is not very high on standard software development;
instead (CASE) Engineering tools help the computer, they are more important than
hardware to produce quality and productivity.
• Hence, the hardware resources are misused.

5
 Lecture Notes for Software Engineering
Myth 3:
• With the addition of more people and program planners to Software development can
help meet project deadlines (If lagging behind).
Fact:
• If software is late, adding more people will merely make the problem worse. This is
because the people already working on the project now need to spend time educating the
newcomers, and are thus taken away from their work. The newcomers are also far less
productive than the existing software engineers, and so the work put into training them
to work on the software does not immediately meet with an appropriate reduction in
work.
(ii)Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) &
that’s why you create dissatisfaction with the developer.

Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of
objectives can be done over time.

Fact:
• Official and detailed description of the database function, ethical performance,
communication, structural issues and the verification process are important.
• Unambiguous requirements (usually derived iteratively) are developed only through
effective and continuous
communication between customer and developer.
Myth 2:
Software requirements continually change, but change can be easily accommodated because
software is flexible

Fact:

6
 Lecture Notes for Software Engineering
• It is true that software requirements change, but the impact of change varies with the
time at which it is introduced. When requirements changes are requested early (before
design or code has been started), the cost impact is relatively small. However, as time
passes, the cost impact grows rapidly—resources have been committed, a design
framework has been established, and change can cause upheaval that requires additional
resources and major design modification.

Different Stages of Myths

(iii)Practitioner’s Myths:
Myths 1:
They believe that their work has been completed with the writing of the plan.

Fact:
• It is true that every 60-80% effort goes into the maintenance phase (as of the latter
software release). Efforts are required, where the product is available first delivered to
customers.
Myths 2:
There is no other way to achieve system quality, until it is “running”.

Fact:
• Systematic review of project technology is the quality of effective software verification
method. These updates are quality filters and more accessible than test.
Myth 3:

7
 Lecture Notes for Software Engineering
An operating system is the only product that can be successfully exported project.

Fact:
• A working system is not enough, the right document brochures and booklets are also
required to provide guidance & software support.
Myth 4:
Engineering software will enable us to build powerful and unnecessary document & always delay
us.

Fact:
• Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster
delivery times
A GENERIC VIEW OF PROCESS

Software Engineering-A Layered Technology: According to IEEE, “Software Engineering is the

application of a systematic, disciplined, quantifiable approach to the development, operation and
maintenance of software i.e., application of engineering to software.
Software engineering is a layered technology. The foundation for software engineering is the
process layer. The software engineering process is the glue that holds the technology layers together and
enables timely development of software. Process defines a framework that must be established for
effective delivery of software engineering technology. The software process forms the basis for
management control of software projects and establishes the context in which technical methods are
applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are
established, quality is ensured, and change is properly managed.

Fig: Software Engineering Layers

8
 Lecture Notes for Software Engineering

Software engineering methods provide the technical how-to’s for building software. Methods
encompass a broad array of tasks that include communication, requirements analysis, design modeling,
program construction, testing, and support.

Software engineering tools provide automated or semi-automated support for process and the
methods. 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),
is established.

A Process Framework: “It establishes a foundation for complete software process by identifying a small
number of framework activities and umbrella activities that are applicable to all software projects.”
✓ Each framework activity is populated by a set of Software Engineering actions (Ex: Design) –
collection of related tasks.
✓ Each action is populated with individual work tasks.

✓ Software is determinate if order and timing of inputs, processing and outputs is predictable,
otherwise it is referred an indeterminate.

Fig: Process Framework

9
 Lecture Notes for Software Engineering
Framework Activities:
1. Communication: It involves heavy communication and collaboration with customer and other
stakeholders. It encompasses requirements gathering and related activities.
2. Planning: It plans for Software Engineering work that follows. It describes technical tasks to be
conducted, resources that will be required, likely risks, work products to be produced and a work
schedule.
3. Modeling: This activity focuses on creation of models that allow stakeholders (customer, developer)
to better under software requirements and design that will achieve requirements.
4. Construction or Development: It combines code generation and testing to uncover errors in the code.
(Manual, automated actions).
5. Deployment: The software (completed/partial increment) is delivered to the customer for evaluation
andfeedback of it.

Umbrella Activities:
1. Software Project Tracking and Control – Assess progress against the project plan and maintain
schedule.
2. Risk Management – Assesses risk that effect project outcome (or) Quality of product.

3. Software Quality Assurance – Activities to ensure software quality.

4. Formal Technical Reviews - Assess work products to uncover and remove errors before next action.

5. Software Configuration Management – Manages effects of changes throughout the software process.

6. Measurement – Defines and collects process, project, product measures to meet customer
requirements.
7. Reusability Management – Defines criteria for work product reuse and establishes mechanisms to
achieve reusable components.
8. Work Product Preparation and Production – Focuses on activities required to create work product
such as models, documents, logs, forms and lists.

Product and Process: If process is weak, the end products will undoubtedly suffer. But an obsessive
over- reliance on process is also dangerous.

Process Technology: “Process Technology tools are used to help software organizations to analyze their
current process, organize work tasks, controls and monitor progress, manage technical quality”.

10
 Lecture Notes for Software Engineering
Process Assessment: It is required to ensure that the process meets set of basic principles that are needed
for a successful software engineering.
Approaches:

➢ CMM-Based Appraisal for Internal Process Improvement (CBA IPI): It provides a diagnostic
technique for assessing the relative maturity of a software organization; uses the SEI CMM as the
basis for the assessment

➢ SPICE: Software Process Improvement and Capability determination.

➢ SCAMPI: Standard CMMI Assessment Method for Process Improvement. It provides a five step
process assessment model that includes: Initiating, Diagnosing, Establishing, Acting, and Learning.
➢ ISO 9001:2000 for software: Generic standard to improve the overall quality of products, system
and services of software organization. It adopted a plan-do-check-act cycle for continuous process
improvement
CMMI

Capability Maturity Model Integration is a maturity model used to rank software development
organizations. It is proposed by Software Engineering Institute (SEI). It represents process model as 1.
Continuous Model 2. Staged Model
CMM: “It is maturity framework strategy that focuses on continuously improving the development and
management of organization workforce.”
Capability Levels: The Capability levels depend on Key Process Areas (KPA). These are given as:

1. Level 0 (Incomplete): The process area (Ex; Requirement Management) is not performed or does
not achieve all goals and objectives defined by CMMI for level 1 capability.
2. Level 1 (Initial/Performed): All specific goals of process area have been satisfied. Work tasks
required to produce defined work products are being conducted.
3. Level 2 (Repeatable/Managed): All level 1 criteria have been satisfied.

✓ All work related to PA is up-to-date with organization expectations.

✓ All people doing work have access to adequate resources to get the job done i.e., stakeholders
are actively involved.
✓ Work task and work products are “monitored, controlled, reviewed and evaluated”.

4. Level 3 (Defined): All level 2 criteria are achieved. “The process is tailored from organization’s set
of standard other processes and contributes work products, measures and other process
improvement information to organizational process assets”
11
 Lecture Notes for Software Engineering
5. Level 4 (Quantitatively managed): All level 3 criteria are satisfied. Quantitative objectives for
quality and process performance are established and used as criteria in managing the process.
6. Level 5 (Optimized): All level 4 criteria are satisfied. Process Area (PA) is adapted and optimized
using quantitative needs to meet changing customer needs and continually improve efficiency of
Process Area.

SEI has associated key process areas (KPAs) with each of the maturity levels. KPAs describe those
software engineering functions (e.g., software project planning, requirements management) that must be
present to satisfy good practice at a particular level. Each KPA is described by identifying the following
characteristics:
• Goals—the overall objectives that the KPA must achieve.

• Commitments—requirements (imposed on the organization) that must be met to achieve the goals or
provide proof of intent to comply with the goals.

• Abilities—those things that must be in place (organizationally and technically) to enable the
organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.

• Methods for monitoring implementation—the manner in which the activities are monitored as they
are put into place.
• Methods for verifying implementation—the manner in which proper practice for the KPA can be
verified.

Eighteen KPAs are defined across the maturity model and mapped into different levels of process
maturity. The following KPAs should be achieved at each process maturity level:
12
 Lecture Notes for Software Engineering
Process maturity level 2

✓ Software configuration management

✓ Software quality assurance

✓ Software subcontract management

✓ Software project tracking and oversight

✓ Software project planning

✓ Requirements management

Process maturity level 3

✓ Peer reviews

✓ Intergroup coordination

✓ Software product engineering

✓ Integrated software management

✓ Training program

✓ Organization process definition

✓ Organization process focus

Process maturity level 4

✓ Software quality management

✓ Quantitative process management

Process maturity level 5

✓ Process change management

✓ Technology change management

✓ Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its goals. The key
practices are policies, procedures, and activities that must occur before a key process area has been fully
instituted. The SEI defines key indicators as “those key practices or components of key practices that
offer the greatest insight into whether the goals of a key process area have been achieved”.
CMMI defines each process area in terms of:

✓ Specific Goals: Essential characteristics which must exist in all the activities implied by a given

13
 Lecture Notes for Software Engineering
Process Area.
✓ Specific Practices: Set of tasks to be accomplished to achieve specific goals.

Ex: SG and SP for “Project Planning”

SG1: Establish Estimates
SP 1.1 – Establish Project Scope

SP 1.2 – Establish Work Product Estimation

SP 1.3 – Define Project Life Cycle
SP 1.4 – Determine estimates of effort cost.

SG2: Develop a Project Plan

SG3: Obtain commitment to the plan

✓ Generic Goals: These are used to achieve a particular capability.

✓ Generic Practices: Practices that correspond to the level goal must be achieved.
PROCESS PATTERNS: Software process can be a collection of patterns that define a set of activities,
work tasks, work products and relational behaviors. Template to describe a process pattern contains:
✓ Pattern Name: It should describe function within software process. (Ex: Customer-
Communication).
✓ Intent: Purpose of pattern. Can be explained with diagrams.

✓ Type: Three types of patterns are there:

1. Task Patterns: Software Engineering action or work task that is part of process and relevant to
successful Software Engineering practice defined.
2. Stage Patterns: Defines “a framework activity with multiple work tasks in it”, for the process.
Ex: Communication contains Requirement Gathering
3. Phase Pattern: Defines “sequence of framework activities that occur with the purpose”, may
be iterative. Ex: Spiral Model

✓ Initial Context: Condition under which pattern applies are described.

✓ Problem: Problem to be solved by pattern is described.

✓ Resulting Context: Conditions that result after implementation.

✓ Related Patterns: List of process patterns that are related.

✓ Known Uses/Examples: Instances where patterns are applicable.

14
 Lecture Notes for Software Engineering

PERSONAL AND TEAM PROCESS MODELS: These models were proposed by Watts Humpry.
Each software engineer can create a process that best fits his or her needs. A team can also create a
process that meets narrower needs of individuals and broader needs of organization.
Personal Software Process (PSP): Every developer uses some process o build the computer software.
The process may be Adhoc, may change daily and may not be efficient. PSP process model defines 5
framework activities:
1. Planning

2. High-Level Design

3. High-Level Design Review

4. Development

5. Post-mortem.

Team Software Process (TSP): An ideal software team can be of 3-20 Software Engineers (Integrated
Product Teams). Its goal is to build a “self-directed” project team to produce high-quality software.
Objectives:

1. Build self-directed teams that plan and track their work, establish goals and own their processes and
plans.
2. Show managers how to motivate their teams and sustain peak performance.

3. Accelerate software project improvement to achieve CMM level-5 targets.

4. Guide high-maturity organization to improve process standards.

Framework Activities:

1. Launch (Communication and Planning).

2. High-level Design.

3. Implementation.

4. Integration and Test.

5. Post-mortem.

Note: TSP uses scripts (sequence of Tasks), forms, and standards to guide team members.

15
 Lecture Notes for Software Engineering

UNIT – II

Process Models: The waterfall model, spiral model, Incremental process model, evolutionary process
model, agile process

Software Requirements: Functional and non-functional requirements, the software requirements

document.

Requirements Engineering Process: Feasibility studies, requirements elicitation and analysis,

requirements validation, requirements management, and forward and reverse engineering.

PRESCRIPTIVE MODELS

Prescribes set of process elements such as framework activities, Software Engineering actions, tasks, work
products, assurance and charge control mechanism. Each process model prescribes a work flow. Various
Prescriptive models include:

1) THE WATERFALL MODEL: This model is proposed by Winston Royce. It is also called as classic
life cycle. It is the oldest paradigm (model) in Software Engineering.
It suggests a systematic, sequential approach to software development that begins with customer
specification of requirements and progresses through planning, then with Modeling, construction and
deployment.

Fig: Waterfall Model

The framework activities of the Waterfall model include:
1. Communication: It involves heavy communication and collaboration with customer and other
stakeholders. It encompasses requirements gathering and related activities.
2. Planning: It plans for Software Engineering work that follows. It describes technical tasks to be

16
 Lecture Notes for Software Engineering
conducted, resources that will be required, likely risks, work products to be produced and a work
schedule.
3. Modeling: This activity focuses on creation of models that allow stakeholders (customer,
developer) to better under software requirements and design that will achieve requirements.
4. Construction: It combines code generation and testing to uncover errors in the code. (Manual,
automated actions).
5. Development: The software (completed/partial increment) is delivered to the customer for
evaluation and feedback of it.
Problems:

• Real projects rarely follow the sequential flow.

• It’s often difficult for customer to state all requirements explicitly.

• Working version of program(s) will not be available until late in project time-span.

A variation in the representation of the waterfall model is called the V-model. The V-model
depicts the relationship of quality assurance actions to the actions associated with communication,
modeling, and early construction activities.

Fig: The V – Model

17
 Lecture Notes for Software Engineering
As software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem and its solution.
Once code has been generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models created as the team moved down
the left side. In reality, there is no fundamental difference between the classic life cycle and the V-model.
The V-model provides a way of visualizing how verification and validation actions are applied to earlier
engineering work.
2) INCREMENTAL PROCESS MODEL: “It divides the software development process into certain
number of increments with each increment comprising 5 phases of waterfall model”. Each linear
sequence produces “deliverable increments” of software. Ex: WORD software (Entering Data,
Editing, Spell check etc.)
First increment is often a core product i.e., basic requirements are addressed, supplementary
features are not delivered. The core product is used and evaluated by the customer, based on that plans for
next increment development. This process is repeated till complete product is produced.

The framework activities of the Incremental Process model include:

1. Communication: It involves heavy communication and collaboration with customer and other
stakeholders. It encompasses requirements gathering and related activities.
2. Planning: It plans for Software Engineering work that follows. It describes technical tasks to be
conducted, resources that will be required, likely risks, work products to be produced and a work
schedule.

3. Modeling: This activity focuses on creation of models that allow stakeholders (customer,
developer) to better under software requirements and design that will achieve requirements.
4. Construction: It combines code generation and testing to uncover errors in the code.

5. Development: The software (completed/partial increment) is delivered to the customer for

evaluation and feedback of it.

18
 Lecture Notes for Software Engineering

Figure: Incremental Process model.

Advantages:

✓ Technical risks reduced, with each increment.

✓ When team size is small, it is the correct choice.

✓ Customer can expect a core product in short time-span.

3) RAD MODEL: RAD stands for Rapid Application Development. It is an incremental software
process model that emphasizes short development cycle. It is a version of waterfall model with rapid
development. If requirements are well understood and project scope is constrained RAD process
enables development team to create a “fully functional system” within a very short time period (60- 90
days). Each major function can be addressed by a separate RAD team and then integrated to form a
whole project.
The framework activities of RAD model include:

1. Communication: It involves heavy communication and collaboration with customer and other
stakeholders. It encompasses requirements gathering and related activities.
2. Planning: It plans for Software Engineering work that follows. It describes technical tasks to be
conducted, resources that will be required, likely risks, work products to be produced and a work
schedule.
3. Modeling: This activity focuses on creation of models that allow stakeholders (customer,
developer) tobetter under software requirements and design that will achieve requirements.

19
 Lecture Notes for Software Engineering
4. Construction: It combines code generation and testing to uncover errors in the code.

5. Development: The software (completed/partial increment) is delivered to the customer for

evaluation andfeedback of it.

Fig: RAD Process model

Advantages:

▪ Project with 2-3 months deadline opt for RAD.

▪ Task is divided among teams to fasten development process.

Disadvantages:
▪ Large projects using RAD may not work.

▪ If high performance is an issue, RAD may not work.

▪ RAD may not be appropriate when technical risks are high.

EVOLUTIONARY PROCESS MODELS

These models are specially designed to accommodate a product that evolves over time. These are iterative
and enable software engineers to develop more complete software versions.

1) PROTOTYPING: Prototyping model is used when customer defines a set of objectives, but does not
identify detailed input, processing output requirements, developer is unsure of efficiency of algorithm,
adaptability of operating system etc, where phased model is inappropriate.
Prototyping model can be used as a standalone process model. Prototyping paradigm assists the

20
 Lecture Notes for Software Engineering
software engineer and customer to better understand what is to be built when requirements are fuzzy.
Prototype helps to identify software requirements.
Prototyping paradigm begins with communication, then quickly planning the prototyping iteration,
modeling quick design, construction of prototype, and the prototype is deployed and then evaluated by the
customer/user. Feedback is used to refine requirements for the software.

Prototype can serve as “the first system”, where users get a feel of actual system and developers
get to build something immediately.

Fig: Prototyping Model

Prototyping can be problematic for following reasons:

• Developers may not consider overall software quality. (Few “fixes” are applied to satisfy customer).

• The developer often compromises in the implementation to get a prototype working quickly.

2) THE SPIRAL MODEL: The Spiral model is proposed by “Boehm”. This model was developed to
encompass the best features of waterfall model and prototyping.
Features:
1) It is a risk-driven process model with the risk analysis feature.

2) Cyclic Approach for increasing system’s degree of definition and implementation while
decreasing degree of risk-Risk is considered as each revolution is made.
3) Anchor Point Milestone for ensuring stakeholders commitment to feasible and mutually
satisfactory systems solution. (Milestone is a combination of work products and conditions).

Spiral model may be viewed as a Meta model, as it can accommodate any process development
model. Software is developed as a series of evolutionary releases. Project manager adjusts planned

21
 Lecture Notes for Software Engineering
number of iterations to complete the software. During early iterations prototype is generated and during
later iterations complete version is developed.

In Spiral model, the first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral model might be used to develop a prototype and then
progressively more sophisticated versions of the software. Unlike other process models that end when
software is delivered, the spiral model can be adapted to apply throughout the life of the software.
✓ The first circuit around the spiral might represent a “Concept Development Project” that starts at the
core of the project and continues till concept development isover.

✓ Then with the next spiral “New Product Development Project” commences. New product will
evolve through a number of iterations around spiral.
✓ Next circuit around the spiral might be used to represent a “Product Enhancement Project”. The
spiral, when characterized in this way, remains operative until software is retired.

Fig: Spiral Model

Advantages:

▪ It is a realistic approach to the development of large-scale systems and software. (Software

evolvesas the process progresses).
▪ It uses and enables the developer to apply the prototyping approach to any stage in evolution of
product.

22
 Lecture Notes for Software Engineering
▪ Considers technical risks at all the stages of the project, and reduces risks before they become
problematic.
❖ Like other paradigms, spiral model is not a panacea (Medicine).It demands considerable risk
assessment expertise for success. If a major risk is not covered and managed, problems will occur.

4) CONCURRENT DEVELOPMENT MODEL: It is also called as “Concurrent Engineering”. This

model is represented schematically as a series of framework activities, Software Engineering actions
and tasks, and their associated states concurrently. It strives to make all software development
activities to be concurrently implemented.
❖ This model defines a series of events which will trigger transition from state to state for each of
Software Engineering activities, actions/tasks.

Ex: “Modeling” activity for spiral model is accomplished by invoking prototyping and/or analysis

Modeling and specification and design.

Fig: One element of concurrent model development model

All activities (communication/modeling/construction etc) exist concurrently but reside in different states.
State is an externally observable mode of behavior). For example, early in a project, the communication

23
 Lecture Notes for Software Engineering
activity has completed its first iteration and exists in the awaiting changes state. Modeling activity which
was in none state will now move to under development state.
Advantages:
✓ Applicable to all types of software development, provides accurate picture of current state of a
project.
✓ The software engineering activities, tasks and actions are defined as a network of activities, rather
than sequence of events.

Evolutionary Models Drawbacks:

▪ Prototyping poses a problem to project planning because of uncertain number of cycles
required to construct product.
▪ Do not establish maximum speed of evolution.

▪ May not give flexibility and extensibility for the software process.

SPECIALIZED PROCESS MODELS

These models are used when a narrowly defined Software Engineering approach is chosen.

1. COMPONENT-BASED DEVELOPMENT: Commercial Off-The-Shelf (COTS) software

components are used when software is to be build. These components provide targeted functionality so
that component to be integrated into the software.
➢ It incorporates many characters of the spiral model. It is evolutionary in nature, composes
applications from pre-packaged (COTS) software components.
Steps:
1. Available component-based products are researched and evaluated for the application domain in
question.
2. Component integration issues are considered.

3. Software architecture is designed to accommodate the components.

4. Components are integrated into the architecture.

5. Comprehensive testing is used (conducted to ensure proper functionality).

Advantage: Software reuse-Important to produce high quality software.

24
 Lecture Notes for Software Engineering
2. FORMAL METHODS MODEL: Specialized software development approach that uses mathematical
based techniques for specifying, developing and verifying the computer softwares. Formal Methods
Model helps the software developers to apply correct mathematical notations to create the issue of
insufficiency, inconsistency and uncertainty of the software by applying mathematical analysis.
During design phase, formal methods model acts as a program verifier and help Software Engineers to
detect and correct these errors, which are otherwise very difficult to be detected. This model assures
defect free software.
Drawbacks:

1. Time consuming and expensive.

2. Software Engineers need extensive training to apply this model.

3. Clients needed to be technically sound for proper communication.

❖ Because of these reasons Formal Methods Models are used only in development of high integrity
software applications where safety and security is of utmost importance.

3. ASPECT-ORIENTED SOFTWARE DEVELOPMENT (AOSD): As modern computer based

systems become more sophisticated and complex, some concerns (security, fault tolerance, memory
management etc) span the entire architecture. When concern cut across multiple system functions,
features and information, they are referred as crosscutting concerns. Aspectual Requirements define
those crosscutting concerns that have impact across the software architecture.
AOSD, often referred to as Aspect-Oriented Programming (AOP), is a relatively new software
engineering paradigm which provides a process for defining, specifying, designing and constructing
aspects (crosscutting concerns).

Presently there is no distinct Aspect-Oriented Process. If such an approach is developed, then it

must integrate the characteristics of both spiral and concurrent model, because of their evolutionary and
parallel natures respectively.
THE UNIFIED PROCESS MODEL: This model is also referred as RUP (Rational Unified Process).
Unified Process refers to a methodology of extracting the most essential activities of conventional
software development phases (communication, planning, Modeling, construction and deployment) and
characterizing them, so that they can be applied in the Agile (highly valued) software development.
History: Jacobson, Rumbaugh and Greedy Booch developed the Unified Process, a framework for
Object- Oriented Software Engineering using UML. Today, Unified Process and UML are used on
Object- Oriented projects of all kinds.
25
 Lecture Notes for Software Engineering
• The iterative, incremental model proposed by the Unified Process can and should be adapted to
meet specific project needs.
Phases of the Unified Process:
1. Inception Phase: The Inception Phase encompasses both customer communication and planning
activities. By collaborating with customer and end-users, business requirements are identified and
described through a set of use cases (sequence of actions that are performed by an actor such as a
person or a machine). As actor interacts with the software, use cases provide project scope.
The Inception Phase must:

i. Produce a business case.

ii. Identify business requirements, business and process risks.

iii. Give overall vision for the project, as the outputs result in various documents/work products.

Work Products:

1) Vision Documents 5) Initial Risk Assessment

2) Initial use-case model 6) Project Plan [Phases and Interaction]

3) Initial Project Glossary7) Business Model (if necessary)

4) Initial Business case 8) One or more Prototypes

2. Elaboration Phase: The Elaboration Phase encompasses planning and Modeling activities. This
phase refines and expands preliminary use-cases that were developed in inception phase. The
Elaboration Phase expands the architectural representation to five views: 1) Use case Model, 2)
Analysis Model, 3) Design Model, 4) Implementation Model, 5) Deployment Model.

Elaboration Phase creates an “executable architectural baseline” that represents “first cut” executable
system-prototype. Architectural baseline provides viability of the project but not all features and functions
required to use the system. Modifications to the plan may be made at this time.

26
 Lecture Notes for Software Engineering
Work Products:
7) Revised Risk List
1) Use case Model
8) Project plan, includes
2) Supplementary Requirements
a) Iteration Plan
3) Analysis Model
b) Adapted workflow
4) Software Architecture Prototype
c) Milestones
5) Executable Architecture Description
d) Technical work products
6) Preliminary Design Model
9) Preliminary User Manual

Fig: Unified Process Model.

3. Construction Phase: The Construction Phase is same as construction activity, where the application
is coded and tested. The Construction Phase develops suitable code for each component of the
software. To do this, analysis and design models started in the elaboration phase are completed to
reflect the final version of software increment.
• All necessary and required features and functions of software increment (release) are
implemented in source code.
• Unit tests are designed and executed for each software increment.

• Integration activities (Component Assembly and Integration Testing) are conducted.

27
 Lecture Notes for Software Engineering
Work Products:

28
 Lecture Notes for Software Engineering
1) Design Model.

2) Software Components

3) Integrated Software Increment

4) Test Plan and Procedure.

5) Test Cases

6) Support Document

a. User Manuals

b. Installation Manuals

c. Description of Current Increment

4. Transition Phase: The Transition Phase encompasses latter stages of construction and first part of
deployment activities. Software is given to end-users for beta testing and user feedback about both
defects and necessary changes. Software team creates necessary support information (Ex: user
manuals, installation procedures) required for release.
Work Products:
1) Delivered software increment

2) General User Feedback

3) Beta Test Report

5. Production Phase: In the Production Phase, on-going use of software is monitored, support for
operating environment is provided and defect reports and request for changes are submitted and
evaluated.

❖ Construction, Transition and Production phases are being conducted concurrently sometimes. So, five
Unified Process phases do not occur in a sequence.

29
 Lecture Notes for Software Engineering
AN AGILE VIEW OF PROCESS

Q: What is Agility?

Ans: Agility is dynamic, content specific, aggressively change and growth oriented. Agile software is
highly valued software. Agile team is a nimble team able to respond to changes appropriately.
The Agile Alliance defines 12 principles to achieve agility:

1. Our highest priority is to satisfy customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even later in development. Agile processes harness change for
customer’s competitive advantage.
3. Deliver working software frequently, from couple of weeks to months.

4. Business people and developers must daily work together throughout the project.

5. Build projects around motivated individuals.

6. Most efficient and effective method of conveying information in a development team is face-to face
conversation.
7. Working software is primary measure of progress.

8. Agile processes promote sustainable development. (Users, sponsors, developers should maintain a
constant pace).
9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity is essential. (Art of maximum amount of work not done).

11. Self-organizing teams are required for best architectures, requirements and designs.

12. At regular intervals, team will tune and adjust its behavior to become more effective.

Q: What is an Agile Process?

Ans: Any Agile software process has 3 assumptions about software projects:

i. It is difficult to predict in advance which software requirements, customer priorities will change and
which will persist.
ii. For many types of software, design and construction are interleaved (performed together). It is
difficult to predict how much design is necessary before construction is used.
iii. Analysis, design, construction and testing are not as predictable as we might like.

30
 Lecture Notes for Software Engineering
Q: How do we create a process that can manage unpredictability?

Ans: Agile process must be adaptable, to have process adaptability. An agile software process must adapt
incrementally. Customer feedback will make the process effective. Software increments must be delivered
in short time periods, so that adaption keeps pace with change (unpredictability).
Human Factors: Agile development focuses on the talents and skills of individuals, modeling the process
to specific people and teams.
Traits that must exist among people of Agile Team:

1. Competence: It encompasses innate talent, specific software knowledge of the process which the
team applies. Skill and knowledge of process should be taught to all agile team members.
2. Common Focus: Although, Agile team members perform different tasks and bring different skills
to be project, all should be focused on one goal-to deliver a working software increment to the
customer within the time promised.
3. Collaboration: Team members must collaborate with one another, with customer and with business
managers, as Software Engineering is
1) Assessing, analysing, using information that is communicated to software team.

2) Creating information that will help customer.

3) Building information (DBs) that provides business value for customer.

4. Decision Making Ability: Agile team is given autonomy decision making authority for both
technical and project issues.
5. Fuzzy Problem-Solving Ability: Agile team will continually have to deal with ambiguity and
changes. Lesson learned any problem solving activity benefits the team later in the project.
6. Mutual Trust and Respect: Agile team should be a “Jelled” team. Jelled team exhibits the trust
and respect requirement for the project.
7. Self-Organisation: It implies 3 things:

a) Agile team organises itself for the work to be done.

b) Agile team organises the process to best accommodate its environment.

c) Agile team organises the work schedule to achieve project delivery.

31
 Lecture Notes for Software Engineering
AGILE PROCESS MODELS: Many similarities among these approaches.

1) EXTREME PROGRAMMING (XP): XP uses Object-Oriented approach for development. The four
Framework activities are: Planning, Design, Coding and Testing.
1. Planning: Planning begins with creation of a set of stories that describe required features and
functionality for software to be built. Each story is written by customer and is placed on an index card.
Customer assigns a value (priority) to it based on business value of it. XP team members then assess
each story and assign a cost measured in development weeks to it. If the story will require more than 3
development weeks, customer is asked to split it into smaller stories, assignment of value and cost will
occur again.
Once a basic commitment (agreement on stories to be included, delivery date and other project
matters) is made for a release, XP team orders stories that will be developed in one of three ways:
1. All stories will be implemented immediately.

2. Stories with highest value will be implemented first.

3. Riskiest stories will be moved up in schedule and implemented first.

After first project release (software increment) has been delivered, XP team computes project
velocity. Project velocity is number of customer stories released during first release. It is used to:
a) Estimate delivery dates and schedule for subsequent releases.

b) Determine whether an over-commitment has been made for all stories across development
project. If so, content of releases is modified or end-delivery dates are changed.

2. Design: XP design follows KIS (Keep It Simple) principle. A simple design is always preferred over
more complex representation. XP encourages use of CRC (Class-Responsibility Collaborator) to
identify and organise object-oriented classes that are relevant to current software increment. CRC cards
are only designwork produce in XP process.
If a difficult design problem of software is encountered as part of design of a story, XP recommends
the immediate creation of an operational prototype of that portion of the design, called a Spike Solution.
XP encourages refactoring, a construction technique which can rapidly improve the design.
“Refactoring is the process of changing a software system so that it does not alter external behaviour of
code yet improves the internal structure”. With refactoring the design occurs continuously as the system is
constructed.

32
 Lecture Notes for Software Engineering
3. Coding: According to XP after stories are developed and design work is done, the team should not
move to coding, but develop unit tests on stories to be included in the current release. So, the
developer can focus on what must be implemented to pass the unit tested immediately.
XP recommends that two people work together at one workstation (system) to create code for a
story. This concept is known as pair programming. This helps in real-time problem solving and real-time
quality assurance. For example, one person might think about cooling details, while other ensures coding
standards are high.

Figure: XP Model

As pair programmers complete their work, their code is integrated within the work of others. This
“Continuous Integration” helps to avoid compatibility and interfacing problem and provides a “smoking
testing/ smoke testing” environment that helps to uncover errors early.

4. Testing: The unit tests that are created should be implemented easily and repeatedly. This encourages a
Regression Testing strategy whenever code is modified.
• Regression Testing is the re-execution of same subset of tests that have already been conducted to

33
 Lecture Notes for Software Engineering
ensure that changes have not propagated unintended side effects.
• Integration and validation testing can occur on a daily basis.

• XP acceptance tests, also called customer tests are specified by the customer and focus on overall
system features and functionality.

2) ADAPTIVE SOFTWARE DEVELOPMENT (ASD): This model was proposed by Jim HighSmith.
This is the best technique for building complex software and systems. ASD focus on human
collaboration and self-organization. ASD life cycle has 3 phases:

1. Speculation: Project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning
uses customer is mission statement, project constraints (delivery dates etc) and basic requirements to
define set of release cycle in the project.
2. Collaboration: Motivation of people to work together in a way that multiples their talent and creative
output. Collaboration is not easy, as it is not just communication. It is a matter of trust. People working
together must trust one another to:
a. Criticize without animosity (strong dislike)

b. Assist without resentment (feeling of displeasure)

c. Work as harder as they do

d. Have the skill set to contribute to the work at hand

e. Communication problems (concerns in a way that leads to effective action).

3. Learning: Software development may often over estimate their own understanding and learning will
help them to improve their level of real understanding. ASD teams learn in 3 ways:
a) Focus Groups: The customer lends users provide feedback on software increments that are being
delivered. This provides direct indication of whether the product is satisfying business needs or not.
b) Formal Technical Reviews (FTRS): ASD team members review the software components that are
developed, improving quality and learning as they proceed.
c) Post-mortems: ASD team becomes introspective (self thinking) addressing its performance and
process. (With the intent of learning and then improving its approach).

34
 Lecture Notes for Software Engineering

Fig: Adaptive Software Development

3) DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM): This approach “provides a

framework for building and maintaining systems which meet tight time constraints through the use of
incremental prototyping in a controlled project environment”.
Ex: 80% of an application can be delivered in 20% of time it takes to deliver complete application.

✓ Like XP, ASD, DSDM also suggests an iterative software process. DSDM approach to each iteration
follows 80% rule, where much of the detail can be completed when more business
requirement/changes are known.
✓ DSDM Consortium is worldwide group of member companies, which uses DSDM approach.

DSDM lifecycle defines 3 different iterative cycles, preceded by 2 additional life cycle activities.

1. Feasibility Study: Establishes business requirements and application constraints and then assesses
whether the application is viable candidate for DSDM process.
2. Business Study: Establishes functional information requirements that allow the application to
provide business value. Defines basic application architecture and identifies maintainability
requirements for the application.
3. Functional Model Iteration: Produces a set of incremental prototypes that demonstrate
35
 Lecture Notes for Software Engineering
functionality for the customer. It helps in gathering additional requirements from user feedback who
exercises the prototype.
4. Design and Build Iteration: Revisits prototypes built during functional model iteration to ensure
that they provide business value for end-users. Often occurs concurrently with Functional Model
Iteration.
5. Implementation: Places latest software increment into operational environment. It should be noted
that
a) Increment may not be 100% complete.

b) Changes may be requested as increment is put in place.

In both cases, DSDM development work continues by returning to Functional Model Iteration activity.

✓ DSDM can be combined with XP to provide a combination approach that defines a solid process
model.
4) CRYSTAL: Alistair Cockburn and Jim Highsmith created the “crystal family of agile methods”, to
achieve a software development approach that focuses on “manoeuvrability”-“a resource-limited,
cooperative game of invention and communication, with a primary goal of delivering useful, working
software and secondary goal of setting up for the next game”.
▪ Crystal family is a set of agile processes that are effective for different types of projects.

▪ The intent is to allow agile teams to select the member of crystal family that is most appropriate for
their software project and environment.

5) SCRUM: (Name derived from an activity during “RUGBY”). Developed by Jeff Sutherland and team
in early 1990’s.
Principles:
1. Small working teams are organized to “maximize communication, minimize overhead and
maximize sharing of tacit, informal knowledge”.
2. Process must be adaptable to both technical and business changes “to ensure best possible
product is produced.”
3. Process yields frequent software increments “that can be inspected, adjusted, tested,
documented and build on”.
4. Developed work and teams are partitioned “into clean low coupling packets”.
5. Constant testing and documentation is performed as the product is built.

36
 Lecture Notes for Software Engineering
6. Scrum process provides the “ability to declare a product ‘done’ whenever required”.

Scrum principles are used to guide development activities within a process that incorporates the
framework activities: Requirements, analysis, design, evolution and delivery. Scrum allows us to build
softer software.
❖ With each framework activity, work tasks occur within a process pattern called a Sprint.

Fig: Scrum process flow

Scrum emphasizes the use of a set of “software process patterns” that have proven effect for the projects
with tight timelines, changing requirements and business criticality. It includes following development
activities:
1) Backlog: “A prioritized list of project requirements or features that provide business value for the
customer”. Product manager assesses each backlog and updates priorities as required.
2) Sprints: “Consists of work units that have to achieve a requirement defined in the backlog that
must be fit into a predefined time-box (30 days)”.As changes are not introduced during the sprint, it
allows team members to work in a short-term, but stable environment.

3) Scrum Meeting: “Short (15 minutes) meeting held daily by the scrum team. A team leader, called a
“scrum master” leads the team meeting and assesses responses from each person. The key question
asked and answered by all team members are:
• What did you do since last meeting?

• What obstacles are you encountering?

37
 Lecture Notes for Software Engineering
• What do you plan to accomplish by next meeting?

These daily meetings help to know the problems in the team and lead to “knowledge socialization” and so
promote team structure.
Demos: “Delivers the software increment to the customer so that functionality that has been implemented
can be demonstrated and evaluated by the customer”. Demo may not contain all planned functionality.

6) FEATURE DRIVEN DEVELOPMENT (FDD): This model is also called as Features Design and
Development. This is the Process model for Object-Oriented Software Engineering (OOSE). It is an
Adaptive, Agile process that can be applied for moderately sized and largest software projects.
• In FDD, a feature “is a client-valued function that can be implemented in two weeks or less”.

Benefits:

1. As features are small blocks of deliverable finality, users can describe, understand the relation and
review them easily for ambiguity or errors.
2. Features can be organized into a hierarchical business-related grouping.

3. The team develops operational features every 2 weeks.

4. Design and code representations are easier to inspect effectively.

5. Project planning, scheduling and tracking are driven by hierarchy.

• FDD approach defines five “collaborating” framework activities. These are also called as
“Processes” in FDD.

Fig: FDD process

38
 Lecture Notes for Software Engineering
Codd and his colleagues suggested a template for defining a feature:

<Action> the<result><by/for/of/to> a(n) <object>where <object> is a person, place (or) thing.

Ex. of Features: Add the product to a shopping cart. Display technical specification of product. Store the
shipping information for a customer.

❖ A feature set group related features in to business related categories.

<action><-ing> a(n) <object> Ex: Making a product sale is feature set for above features.
FDD provides greater emphasis on project management guidelines and techniques than many other agile
methods. If deadline pressure is significant, it is critical to determine if software increments are properly
scheduled. To accomplish this, FDD defines six milestones during design and implementation of features:
“Design walk through, Design, Design Inspection, Code, Code Inspection, and Promote to build.”
AGILE MODELING (AM): There are many situations in which software engineers must build large,
business critical systems. Scope and complexity of such systems must be modeled so that,
• All constituencies can better understand what to be accomplished.

• Problem can be effectively partitioned among Software Engineers.

• Quality can be assessed at every step of system.

Agile Modeling is a practice-based methodology for effective Modeling and documentation of software-
based systems. Agile Modeling is a collection of values, principles and practices for modeling effective
software.
An Agile team must be courageous to reject any requirement, design and need to re-factor. It must
have all answers, business experts and other stakeholders should be respected and embraced.

Modeling principles that make Agile Modeling unique are:

1) Model with a Purpose: A software engineer who uses AM should have a specific goal in mind before
creating the model. Once a goal of model is identified, type of notation and level of details required
will be more obvious.
2) Use Multiple Models: Agile Modeling suggests that each model should present a different aspect of
the system and only models provide value to their developers should be used.
3) Travel Light: As Software Engineering work proceeds, keep only those models that will provide
long- term value and discard the rest. Every work product that is kept, must be maintained as changes
occur. It is required to look for best possible model from various sources.
4) Know the models and tools used to create them: Understand the tools used to create the models and
39
 Lecture Notes for Software Engineering
also strengths and weaknesses of each model.
5) Adapt Locality: Modeling approach should be adapted to the needs of agile team.

6) Content is more important than representation: A perfect model that imports little useful content
is not as valuable as a flawed notation with valuable content. So, focus should be on the content in
model.

Software Requirements: Largely software requirements must be categorized into two categories:
Functional Requirements: Functional requirements define a function that a system or system element must
be qualified to perform and must be documented in different forms. The functional requirements are
describing the behaviour of the system as it correlates to the system's functionality.

Non-functional Requirements: This can be the necessities that specify the criteria that can be used to
decide the operation instead of specific behaviours' of the system.
Non-functional requirements are divided into two main categories:

Execution qualities like security and usability, which are observable at run time.

Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the
static structure of the software system.

Functional Requirements:
User Authentication and Authorization: The system should allow users to register, log in, and log out
securely. It should also manage user roles and permissions.

User Profile Management: Users should be able to update their profiles, change passwords, and manage
personal information.

Data Input and Validation: The system should validate user inputs to ensure data integrity. This
includes validation of forms, fields, and any user-submitted content.

Data Processing: The software should process user inputs and perform necessary computations or
operations according to specified business logic.

Data Storage and Retrieval: The system should store data securely and allow for efficient retrieval of
stored data when required.

User Interface (UI): The UI should be intuitive and user-friendly, allowing users to navigate the system
easily and perform tasks efficiently.

Reporting: The system should generate reports based on user inputs or predefined criteria. Reports may

40
 Lecture Notes for Software Engineering
include various data visualizations or exports to different formats.

Search Functionality: Users should be able to search for specific information within the system
efficiently.

Notifications: The system should provide notifications to users for important events, such as updates on
their account, system changes, or alerts.

Non-Functional Requirements:
Performance: The software should respond promptly to user interactions and handle a certain number of
concurrent users without significant slowdowns.

Scalability: The system should be designed to scale horizontally or vertically to accommodate increases
in users or data volume.

Reliability: The software should be reliable and available for use during expected hours of operation. It
should have mechanisms in place to handle errors gracefully.

Security: The system should implement robust security measures to protect user data, prevent
unauthorized access, and mitigate potential threats such as SQL injection or cross-site scripting (XSS)
attacks.

Usability: The software should be easy to learn and use, even for users with minimal technical expertise.

Compatibility: The system should be compatible with various devices, browsers, and operating systems
to ensure accessibility for all users.

Maintainability: The software should be designed with clean, modular code and well-documented
architecture to facilitate future maintenance and updates.

Regulatory Compliance: The system should comply with relevant regulations and standards, such as
GDPR for data protection or HIPAA for healthcare information.

Backup and Recovery: The system should have regular backups of data and procedures in place for data
recovery in case of system failures or data loss events.

41
 Lecture Notes for Software Engineering
The software requirements document:
A Software Requirements Document (SRD) serves as a comprehensive guide outlining the functional and
non-functional requirements of a software project

Introduction

Purpose: Describe the purpose of the document and the software project.

Scope: Define the boundaries of the software project, including what is included and excluded.

Overall Description

Product Perspective: Describe how the software fits into the larger system or environment.

Product Features: List and briefly describe the major features of the software.
User Classes and Characteristics: Identify the different types of users and their characteristics.

Operating Environment: Specify the hardware, software, and network environments where the software
will operate. ulted during the requirements gathering process.

Functional Requirements

Use Cases: Describe specific interactions between users and the system to accomplish goals.

Functional Features: Provide detailed descriptions of the functionality required by the system, typically
organized by modules or components.

Data Requirements: Specify the data inputs, outputs, and storage requirements of the system.

Business Rules: Outline any rules or constraints that govern the behaviour of the system.

Non-Functional Requirements

Performance Requirements: Specify performance metrics such as response time, throughput, and
resource utilization.

Security Requirements: Detail security measures to protect data and prevent unauthorized access.

Usability Requirements: Define usability criteria such as user interface design principles and
accessibility standards.

Reliability Requirements: Specify system availability, fault tolerance, and error handling mechanisms.

Compliance Requirements: Identify regulatory, legal, or industry standards that the system must comply
with.

Maintainability Requirements: Describe requirements for code maintainability, documentation, and

42
 Lecture Notes for Software Engineering
supportability.

Scalability Requirements: Outline how the system should scale to accommodate growth in users or data
volume.

Backup and Recovery Requirements: Specify backup procedures and recovery mechanisms in case of
data loss or system failures.

System Models

Use Case Diagrams: Visual representations of system functionality and user interactions.

Sequence Diagrams: Illustrate the sequence of interactions between system components to accomplish
specific tasks.

Data Flow Diagrams: Describe the flow of data through the system and between external entities.

Constraints

Technical Constraints: Identify any technical limitations or constraints that may impact the design or
implementation of the system.

Budget and Schedule Constraints: Specify budgetary and scheduling constraints that need to be
considered during development.

Appendices

Glossary: Define key terms and acronyms used throughout the document.

References: Include any references or sources consulted during the requirements gathering process.

Requirements Engineering Process

Requirements engineering (RE): refers to the process of defining, documenting, and maintaining requirements in
the engineering design process. Requirement engineering provides the appropriate mechanism to understand what
the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the
solution clearly, validating the specifications and managing the requirements as they are transformed into a working
system. Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and
notation to describe a proposed system's intended behavior and its associated constraints.

➢ Feasibility Study

➢ Requirement Elicitation and Analysis

➢ Software Requirement Specification

➢ Software Requirement Validation

➢ Software Requirement Management

43
 Lecture Notes for Software Engineering

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software that is acceptable
to users, flexible to change and conformable to established standards.

Types of Feasibility:

Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.

Operational Feasibility - Operational feasibility assesses the range in which the required software performs a
series of levels to solve business problems and customer requirements.

Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial
profits for an organization

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with the help of
customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify

44
 Lecture Notes for Software Engineering
inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve
conflicts if any.

Problems of Elicitation and Analysis

➢ Getting all, and only, the right people involved.

➢ Stakeholders often don't know what they want

➢ Stakeholders express requirements in their terms.

➢ Stakeholders may have conflicting requirements.

➢ Requirement change during the analysis process.

➢ Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst after the
requirements collected from the various sources - the requirement received by the customer written in ordinary
language. It is the job of the analyst to write the requirement in technical language so that they can be understood and
beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams
(FDDs), data dictionaries, etc.

45
 Lecture Notes for Software Engineering

Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the
flow of data through a system. The system may be a company, an organization, a set of procedures, a computer
hardware system, a software system, or any combination of the preceding. The DFD is also known as a data flow
graph or bubble chart.

Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that the
customer and developers use the same definition and terminologies.

Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram, often
called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main
constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are validated. The user
might demand illegal, impossible solution or experts may misinterpret the needs. Requirements can be the check
against the following conditions –

If they can practically implement

If they are correct and as per the functionality and specially of software

If there are any ambiguities

If they are full

If they can describe

Requirements Validation Techniques

Requirements reviews/inspections: 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.

Automated consistency analysis: checking for the consistency of structured requirements descriptions.

.Software Requirement Management

Requirement management is the process of managing changing requirements during the requirements engineering
process and system development.

New requirements emerge during the process as business needs a change, and a better understanding of the system is
developed. The priority of requirements from different viewpoints changes during development process.

The business and technical environment of the system changes during the development.

46
 Lecture Notes for Software Engineering
Forward engineering, and reverse engineering
Forward Engineering

System Design

Implementation Plan

Testing Plan

Deployment Plan

Reverse Engineering

Existing System Analysis

Legacy System Integration Plan

Migration Strategy

Data Migration Plan

47
 UNIT – III
Modeling with UML: Modeling Concepts and Diagrams - Use Case Diagrams -
Class Diagrams - Interaction Diagrams - State chart Diagrams – Activity Diagrams
- Package Diagrams - Component Diagrams – Deployment Diagrams -Diagram
Organization- Diagram Extensions.
Design Engineering: The design process and design quality, design concepts, and
design model.

UNIFIED MODELLING LANGUAGE

INTRODUCTION
UML is a graphical notation used to visualize, specify, construct and document the artifact of software
intensive. UML is appropriate for modeling systems ranging from Enterprise Information Systems to
Distributed Web-based Application and even to Hard Real-time Embedded systems. UML effectively starts
with forming a conceptual modeling of the language.
MODEL
✓ A model is a simplification of reality.

✓ A model provides the blueprints of system.

✓ A model may be structural, emphasizing the organization of the system, or it may be behavioral,
emphasizing the dynamics of the system.
✓ We build models so that we can better understand the system we are developing.

✓ We build models of complex systems because we cannot comprehend such a system in its entirety.
Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.

3. Models give us a template that guides us in constructing as system.

4. Models document the decisions we have made

1
Principles of Modeling:

• The choice of what models to create has a profound influence on how a problem is attacked and
how a solution is shaped
• Every model may be expressed at different levels of precision

• The best models are connected to reality

• No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models
Applications of UML: UML is intended primarily for software intensive systems. It has been used
effectively for such domains as
1. Enterprise Information Systems

2. Banking and Financial Services

3. Telecommunications

4. Transportation

5. Defense and Aerospace

6. Medical Electronics

7. Distributed Web-based Services

Basic Building Blocks of UML:

The building blocks of UML can be categorized as

1. Things

2. Relationships and

3. Diagrams

THINGS:
Things are the most important building blocks of UML. Things can be

a) Structural

b) Behavioral

c) Grouping

d) Annotational

2
a) Structural Things: These define the static part of the model. These represent physical and
conceptualelements. Following are the structural things:
1. Class: It describes set of objects that share same attributes, operations, relationships and semantics.

Class name
Attributes
Operations

2. Object: It is a collection of operations that specifies the service of a class or a component.

3. Collaboration: It defines interaction between elements.

4. Use case: They are used to identify different use case components of a particular software project. It
is used to model the operation.

5. Actor: The outside entity that communicates with a system. Typically a person playing a role on an
external device.

6. Component: It is a physical and replaceable part that confirms to and provides realization of set
ofinterfaces.

7. Node: A physical resource that exists in runtime and represents a computational resource.

3
b) Behavioral Things: These consist of dynamic parts of the UML model. These are:

1. Interaction: It is defined as a behavior that consists of a group of message exchanged among

elementsto accomplish a specific task.
Message

2. State machine: It is useful when the states of an object in its life cycle. It defines the sequence of states
and object goes through in response to events.

c) Grouping Things: They can be defined as a mechanism to group elements of UML model together.
There is only one grouping thing available i.e., Package. Package is used for gathering structural and
behavioral things.

d) Annotational Things: They can be defined as a mechanism to capture remarks, description and
comments of UML model elements. There is only one annotational thing available i.e., Note. Note is
used to render comments, constraints and so on of a UML element.

RELATIONSHIPS:
The relationship is another most important building block of UML. They show how elements are
associated with each other and their association describes the functionality of application.

There are 4 types of relationships. They are:

1. Dependency: It is a relationship between two things in which one element is dependent on other
element. i.e., change in one element also affects another.

4
2. Generalization: It can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes inheritance relationship in the object. It is also called as
‘is a’ relationship.

3. Realization: It can be defined as a relationship in which two elements are connected. One element
describes some responsibility which is not implemented and the other one implements it. This
relationship exists in case of interfaces.

4. Association: It is a set of links that connects elements of an UML mode

5
 UML DIAGRAMS

There are 2 types of UML diagrams. They are:

Static Diagrams:
1. Class diagram

2. Object diagram

3. Component diagram

4. Deployment diagram

Dynamic Diagrams:
5. Use case diagram

6. Activity diagram

7. Sequence diagram

8. Collaboration diagram

9. State machine diagram

1. USE CASE DIAGRAM: A use case diagram describes a set of sequences in which each sequence
indicates the relation with outside things. A use case involves the interaction of actor and system. There
exist 3 types of relationships – Association, Dependency, Generalization .
Use case diagrams can contain

• Actors – “things” outside the system

• Use cases – system boundaries identifying what the system should do.

Use case diagram can be used during analysis to capture the system requirements and to understand how
the system should work. During the design phase, you can use use-case diagrams to specify the behavior of
the system as implemented.

Actor: An actor represents system users. They help delimit the system requirements and give a clearer
picture of what the system should do. An actor is someone or something that interacts with or uses system.
• Provides input to and receives information from the system.

• Is external to the system and has no control over the use cases.

6
 Customers/Actors are discovered by examining,
• Who directly uses the system

• Who is responsible for maintaining the system?

• External hardware used by the system.

• Other systems that need to interact with the system.

Use case: A use case is defined as a set of sequence of actions performed by an actor to achieve a specific
result. Use case can be characterized as:

• A pattern of behavior the system exhibits.

• A sequence of related transactions performed by an actor and the system.

• Delivering something of value to the actor.

Use cases provide a means to,

• Capture system requirements.

• Communicate with end users and domain experts.

• Test the system.

Note: Use cases often start with a “verb”.

Example:

7
2. ACTIVITY DIAGRAM: An activity diagram is a special case of state diagram. An activity
diagram is like a flow Machine showing the flow a control from one activity to another.An activity

diagram is used to model dynamic aspects of the system. Activity diagram contains:
• Action state: These are atomic, executable computation which represents the execution of an
action.
• Activity state: They can be decomposed. That is, their activity is represented by other activity
diagrams.
• Branching: In branching, we have one incoming transition and two or more outgoing transitions.

Decision

• Forking: It is a process of splitting a single flow of control into multiple flow of controls.
Generally afork has a single incoming flow of control but multi outgoing flow of control.

• Joining: It is exactly opposite of forking. It generally has multiple incoming flows of

control butsingle outgoing flow of control.

Swim-lanes: They represent the columns in the activity diagram to group the related activities. These are
represented in the form of partitioned region. Swim-lanes are helpful when modeling a business workflow
because they can represent organizational units or role with in business model. Swim-lanes are very similar
to an object because they provide a way to tell who is performing a certain role.

8
Example:

3. CLASS DIAGRAM: Class: A class is a set of objects that share a common structure and common
behavior (the same attributes, operations and semantics). A class is an abstraction of real-world things.
When these items exist in the real-world, they are instances of the class and are referred to as objects.

A class is represented using rectangle, which can be partitioned further.

Class name
Attributes
Operations

1. Generalization Relationship for classes: It shows that sub classes share the structure or behavior
defined in one or more super classes. Use a generalize relationship to show “is a” relationship.

9
 Super class

Subclass1 Subclass2

2. Dependency Relationship: The dependency is a relationship between two model elements in

which change in one element will affect the other model element. Typically in class diagrams, a
dependency relationship indicates that the operations of the client invoke operation of the supplier.

3. Association Relationship: An association provides a pathway of communications. The

communication can be between use cases, actors, classes or interfaces. If two classes are usually
considered independently, the relationship is an association. An association is an orthogonal or

straight line.

Unidirectional Bidirectional

Multiplicity: Multiplicity specifies how many instances of one class may be associated with single instance
of other class. When you apply a cardinality adornment to a class, you are indicating number of instances
allowed for that class. A relationship, you are indicating number of links allowed between one instance of
a class and the instances of another class.

Valid Values: Value Description

0..0 zero
0..1 zero or one
0..n zero or more
1..1 one
1..n one or more
n unlimited number

10
Aggregate Relationship: Use the aggregate relationship to show a whole or part relationship between two
classes. The diamond end represents the class which is whole.

Interface: An interface specifies the externally visible operations of a class and/or component, and has no
implementation of its own. An interface specifies only a limited part of behavior of class or a component.
It is represented using a small circle.

Example:

INTERACTION DIAGRAMS

An interaction is an important sequence of interactions between objects. There are two types of interaction

11
diagrams,
1. Sequence Diagrams.

2. Collaboration diagrams.

4. Sequence Diagram: A sequence diagram is a graphical view of a scenario that shows object
interaction in a time based sequence, what happens first, what happens next.
Sequence diagrams establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces.
A sequence diagram has two dimensions: vertical placement represents time and horizontal placement
represents different objects.

Link: Objects interact through their links to other objects. A link is an instance of an association, analogous
to an object being instance of a class. A link should exist between two objects, including class utilities, only
if there is a relationship between their corresponding classes.

Message icons: A message icon represents the communication between objects indicating that an action
will follow. The message icon is a horizontal, solid arrow connecting two lifelines together. A message icon

in a sequence diagram represents exactly one message.

Lifeline: Each object appearing on the sequence diagram contains a dashed vertical line, called lifeline,
which represents the location of an object at a particular point in time. The lifeline also serves as a place
for messages to start and stop and a place for the focus of control to reside.

Lifeline

12
Message or Event: A message is a communication carried between two objects that trigger an event. A
message is represented in collaboration and sequence diagrams by a message icon which usually indicates
its synchronization. Synchronization types that are supported are:
1. Synchronous Call

2. Asynchronous Call

3. Asynchronous Signal

4. Create

5. Delete

6. Reply

Message to self: It is a tool that sends a message from one object back to the same object. The sender of
the message is same as the receiver.

Example

5. Collaboration Diagram: A collaboration diagram is an interaction diagram that shows the order
of messages that implement an operation or a transaction. Collaboration diagrams show objects,
their links, and their messages. They can also contain simple class instances and class utility
instances. Each collaboration diagram provides a view of interactions or structural relationships
that occur between objects and object-like entities in the current model. Collaboration diagrams
contain icons representing objects.

13
 Example

Sequence and collaboration diagrams are semantically equivalent as both shows the interaction among
objects. From one diagram we can generate another diagram. To generate a collaboration diagram
from sequence diagram, right click on sequence diagram, select - Add Diagram - communication
diagram. Similarly, a sequence diagram can be generated from collaboration diagram.

6. STATE MACHINE DIAGRAM: State Machine diagrams model the dynamic behavior
of individual classes or any other kind of object. They show the sequence of states that an object
goes through the events that cause a transition from one state to another and the actions that result
from a state change. A State Machine diagram is typically used to model the discrete stages of an
objects lifetime. A State Machine diagram typically contains one start state and multiple end states.

State: A state represents a condition or situation during the life of an object during which it satisfies
some condition or waits for an event. Each state represents a cumulative history of its behavior. States
can be shared between state machines. Transitions cannot be shared.

Naming: The name of the state must be unique to its enclosing class, within the state

Actions: Actions on states can occur at one of four times on entry

On exit
Do

On event

Start state: A start state (also called an “initial state”) explicitly shows the beginning of the execution of
the state machine on the state Machine diagram or beginning of the workflow on an activity diagram.
14
Normally, one outgoing transition can be placed from the start state.
However, multiple transitions may be placed on start state, if at least one of them is labeled with a condition.
No incoming transitions are allowed.
The start state icon is a small, filled circle that may contain the name (Begin process).
Begin Process

End state: An end state represents a final or terminal state on an activity or State Machine diagram.
Transitions can only occur into an end state. The end state icon is a filled circle inside a slightly larger
unfilled circle that may contain the name (End process).
End process

State transition: A state transition indicates that an action in the source state will perform certain specified
actions and enter the destination state when a specified event occurs or when certain conditions are satisfied.
A state transition is a relationship between two states, two activities or between an activity or a state. The
icon for a state transition is a line with an arrow head pointing toward the destination state or activity.
We can show one or more state transitions from a state as long as each transition is unique. Transitions
originating from a state cannot have the same event, unless there are conditions on the event.

Example:

7. COMPONENT DIAGRAM: Component diagrams provide a physical view of the current model.
A component diagram shows the organizations and dependencies among software components,

15
 including source code component, binary code component, and executable component. These diagrams
also show the externally visible behavior of the component by displaying the interfaces of the
components.

Component diagrams contain:

1. Component package
2. Components
3. Interfaces
4. Dependency relationship

Example:

8. DEPLOYMENT DIAGRAM: A deployment diagram shows processors, devices and

connections. Each model contains a single deployment diagram which shows the connections between
nodes.

Node: A node is a hardware component capable of executing programs. Each node must have a name,
there are no constraints on the node name because nodes denote hardware rather than software entities.

16
 Example:

CASE STUDIES

COURSE REGISTRATION SYSTEM

ABSTARCT: The online course registration system is the central part of the educational administration
system, which consists of registration guidance, registration controlling, undergraduate course registration,
graduate course registration, retaking and retesting, dropping the course in the middle phase and information
exchange, etc.

By registering the course voluntarily, the new system improved registration mechanism, implemented
course registration of common course for undergraduate and graduate students, and also supported the
teaching activities across spring, summer and fall semesters. This article introduces the design and
implementation of the new online course registration system, including registration mechanism, technical
architecture, and system design, etc

17
USECASE DIAGRAM:

18
CLASS DIAGRAM:

STATE CHART DIAGRAM:

19
SEQUENCE DIAGRAM:

20
COLLOBORATION DIAGRAM:

21
ACTIVITY DIAGRAM:

22
COMPONENT DIAGRAM:

DEPLOYMENT DIAGRAM:

23
 DESIGN ENGINEERING

Design is a core engineering activity. Design creates a model of the software. Design engineering encompasses
the set of principles, concepts and practices that lead to the development of a high quality system or product.
The goal of design engineering is to produce a model or representation that exhibits firmness,
commodity and delight. Design engineering for computer software changes continually as new methods, better
analysis and broader understanding evolve.
❖ A product should be designed in a flexible manner to develop quality software.
DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING:

Software design is the last software engineering action within modeling activity and sets the stage for
development. The analysis model, manifested by scenario-based, class- based, flow-oriented and behavior
elements, feed the design task.

Design model produces a data/class design, an architectural design, an interface design, a component design
and a deployment design.
✓ The data/class design transforms the analysis class models into design class realizations and data structures
require implementing the software. Part of class design may occur as each software component is designed.
✓ The architectural design defines the relationship between major structural elements of software, the
architectural styles and design patterns and the constraints that affect the way in which architectural can be
derived from system specifications, the analysis model and interaction of subsystems defined within
analysis model.

Fig: Translating the Requirements model to Design model

24
✓ The interface design describes how the software communicates with systems that interoperate with it, and
with humans who use it. Usage scenarios and behavioral models provide much of information required for
the interface design.
✓ The component-level design transforms structural element of the software architecture into a procedural
description of software components. Information from class-based models, flow models, behavioral
models serve as basis for component design.
DESIGN PROCESS AND DESIGN QUALITY:

Importance of software design can be stated with one word QUALITY. Software design serves as foundation
for all software engineering and software support activities that follow.

Software design is an interactive process through which requirements are translated into a "blueprint" for
constructing the software. Initially, design is represented at a high level of abstraction. As iteration occurs,
subsequent refinement leads to design representations at lower levels of abstraction.

The following characteristics serve as a guide for evaluation of good design:

1. The design must implement all explicit requirements contained in analysis model, and accommodate all
implicit requirements desired by customer.
2. Design must be a readable, understandable guide for those who generate code, who test and support the
software.
3. Design should provide a complete picture of the software, addressing data, functional and behavioral
domains.
✓ Each of these characteristics is goal of the design process.

Quality Guidelines: Guidelines for quality design are:

1. A design should exhibit an architecture that

a) has been created using recognizable architectural styles/patterns.

b) composed of components that exhibit good design characteristics.

c) can be implemented in an evolutionary fashion.

2. A design should be modular; software should be logically partitioned into elements or sub-systems.

3. It should contain distinct representations of data, architecture, interfaces and components.

4. It should lead to data structures that are appropriate for the classes to be implemented.

5. It should lead to components that exhibit independent functional characteristics.

25
6. It should lead to interfaces that reduce complexity of connections between components and external
environment.
7. It should be represented using a repeatable (iterative) method.

8. It should be represented using a notation that effectively communicates its meaning.

❖ Design engineering encourages good design through the application of fundamental design principles,
systematic methodology and through review.
Quality Attributes: Hewlett-Packard (HP) developed a set software quality attributes, given by the acronym

FURPS:

1. Functionality: It is assessed by evaluating feature set and capabilities of the program, generality of
functions and security of overall system.

2. Usability: It is assessed by considering human factors, overall aesthetics, consistency and documentation.

3. Reliability: It is evaluated by measuring frequency & severity of failure, ability to recover, accuracy of
output results, Mean- Time-To-Failure (MTTF) and predictability of the program.

4. Performance: It is measured by processing speed, response time, resource consumption, throughout and
efficiency.

5. Supportability: It combines the ability to extend the program (extensibility), adaptability, serviceability,
which represent maintainability of the project.

These quality attributes must be considered as soon as design commences, but not after the design is
complete and construction has begun.
DESIGN CONCEPTS
Fundamental software design concepts provide necessary framework for "getting it right".

1. Abstraction: At highest level of abstraction, a solution for design problem is stated in broad terms using
language of the problem environment. At lower levels of abstraction, a more detailed description of
solution is provided.
✓ A data abstraction is a named collection of data that describes a data object.

✓ A procedural abstraction refers to a sequence of instructions that have a specific and limited function.
Name of procedural abstraction implies these functions, but specific details are suppressed.

2. Architecture: It is the structure or organization of program components (modules), their interaction, and
structure of data that are used by components. "Components can be generalized to represent major system
26
 elements & their interactions.
A set of architectural patterns enable a software engineer to reuse design level concepts. One goal of software
design is to derive an architectural rendering of a system, which serves as a framework to conduct detailed
design activities.
Architectural design can be represented using one or more of a number of different models:

1. Structural models: Represent architecture as collection of programcomponents.

2. Framework models: Increase the level of design abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in similar types of applications.
3. Dynamic models: Address behavioral change aspects of programarchitecture.

4. Process models: Focus on design of business or technical process that the system must accommodate.

5. Functional models: Can be used to represent functional hierarchy of a system.

3. Patterns:"A design pattern describes a design structure that solves a particular design problem within a
specific context amid "forces"(constraints) that may have an impact on the manner in which pattern is
applied and used."
Intent of each design pattern is to provide a description that enables a designer to determine:

i. Whether pattern is applicable to the current work.

ii. Whether pattern can be reused (hence, saving design time)

iii. Whether pattern can serve as a guide for developing a similar, but functionally or structurally different
pattern.

4. Modularity: Software architecture and design patterns embody modularity, i.e., software is divided into
separately named and addressable components, sometimes called modules that are integrated to satisfy
problem requirements.
Modularity is the single attribute of software that allows a program to the intellectually manageable
(by breaking big process into modules). Modularity leads to a "divide and conquer" strategy, it’s easier to solve
a complex problem when you break it into manageable pieces, hence effort required to develop becomes
negligibly small.
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 and long- term maintenance can be conducted without serious side effects.

5. Information Hiding: It suggests that "modules should be specified and designed so that information
(algorithms, data) contained within a module is inaccessible to other modules that have no need for such
27
 information."
Hiding defines and enforces access constraints to both procedural detail within a module and any local
data structure used by the module. As most data and procedure are hidden from other parts of the software,
errors during modification are less likely to propagate to other locations within the software.

6. Functional Independence: It is achieved by developing modules with "single-minded" function and an

"aversion" to excessive interaction with other modules.
Functional independence is a key to good design and design is the key to software quality. Independence is
assessed using two qualitative criteria:
❖ Cohesion: Cohesion is an indication of relative functional strength of a module. A cohesive module
performs a single task, requiring little interaction with other components.
❖ Coupling: Coupling is an indication of interconnection among modules in software architecture.
Coupling depends on the interface complexity between modules.

7. Refinement: Stepwise refinement is a top-down design strategy, which is actually a process of elaboration.
A program is developed by successively refining levels of procedural detail.
It defines/begins with a statement of function that is defined at a high level of abstraction.
Refinement helps the designer to reveal low-level details as design progresses, thus in creating a complete
design model.
8. Refactoring: “Refactoring is the process of changing a software system in such a way that it does not alter
external behavior of the code (design) yet improves its internal structure”.
When software is refactored, the existing design is examined for redundancy, unused design elements,
poorly constructed data structures, unnecessary algorithms etc for better design.

9. Design Classes: As the design model evolves, the software team must define a set of design classes that:

❖ Refine analysis classes by providing design detail that will enable the classes to be implemented.

❖ Create a new set of design classes that implement a software infrastructure to support the business
solution.
Design classes provide more technical detail as a guide for implementation. Five different types of
design classes, each representing a different layer of design architecture are suggested. They are:

1. User Interface Classes: These define all abstractions that are necessary for Human Computer Interaction
(HCI). HCI occurs within context of a metaphor (Ex: Order form, a checkbook) and design classes for
interface may be visual representations of elements of metaphor.

2. Business Domain Classes: These are often refinements of the analysis classes defined earlier. The classes
28
 identify attributes and services (operations) that are required to implement some element of the business
domain.

3. Process Classes: These implement lower-level business abstractions required to fully manage business
domain classes.

4. Persistent Classes: These represent data stores (DBs) that will persist beyond execution of the software.

5. System Classes: These implement software management and control functions that enable system to
operate and communicate. These are also known as supporting classes.
As design model evolves, software team must develop a complete set of attributes and operations for each
design class.

Four characteristics of a well-formed design class:

1. Complete and Sufficient: A design class should be the complete encapsulation of all attributes and methods
that can reasonably be expected to exist for the class. Sufficiency ensures that the design class contains only those
methods that are sufficient to achieve the intent of the class.(No more and No less).
2. Primitiveness: Methods associated with a design class should be focused on accomplishing one service
the class. Once the service has been implemented, with a method, the class should not provide another way
to accomplish same thing.
3. High Cohesion: A cohesion design class has a small, focused set of responsibilities and single- mindedly
applies attributes and methods to implement those responsibilities.
4. Low Coupling: Collaboration between design classes should be kept to an acceptable minimum. If a design
model is highly coupled, system is difficult to implement, test & maintain. So, design classes in a subsystem should
have only limited knowledge of classes in other subsystems. It is also called as "Law of Demeter", suggests that a
method should only send messages to methods in neighboring classes.

29
THE DESIGN MODEL

The design model can be viewed in two different dimensions:

✓ The process dimension indicates evolution of design model as design tasks are executed as part of the
software process.
✓ The abstraction dimension represents level of detail as each element of analysis model is transformed
into a design equivalent and then refined iteratively.

Fig: Dimensions of the Design Model

The elements of design model use many of same UML diagrams that were used in analysis model..The
difference is that these diagrams are refined and elaborated as part of design, more implementation- specific
detail is provided and emphasis is on architectural structure and style, components & interfaces.

Elements of design model:

1. Data Design Elements: Data design also sometimes referred as "Data Architecting". Data design creates
a model of data and/or information that is represented at a high level of abstraction.
In many software applications, architecture of data will have a profound influence on architecture of
software that must process it. Structure of data always plays important role in software design.
• At program component level, design of data structures and associated algorithms required to

30
 manipulate them is essential to the creation of high-quality applications.
• At application level, translation of data model into a DB is important to achieve business objectives.

• At business level, collection of information stored in DBs and reorganized into a "data warehouse"
enables data mining or knowledge discovery.

2. Architectural Design Elements: These give us an overall view of the software. It is derived from 3
sources:

i. Information about application domain for software to be built.

ii. Specific analysis model elements such as DFDs or analysis classes, their relationships and
collaborations for the problem.
iii. Availability of architectural patterns and styles.

3. Interface Design Elements: These tell how information flows into and out of the system and how it is
communicated among components designed as part of the architecture. There are 3 important elements of
interface design:

i. User Interface (UI): Design of a UI incorporates aesthetic elements (Ex: color, layout, graphics),
ergonomic elements (information layout and placement, navigation), and technical elements (UI
patterns, reusable components). In general, UI is a unique subsystem within overall application architecture.

ii. External interfaces to other systems, devices, networks, other producers/consumers of information:
The design of external interfaces requires definitive information about the entity to which information
is sent or received. In every case, this information should be collected during Requirement Engineering and
verified. This design should incorporate error checking and appropriate security features.

iii. Internal interfaces between various design components: It is closely aligned with component level
design. Design realizations of analysis classes represent all operations and messaging schemes required
to enable communication and collaboration between operations in various classes.

In some cases, an interface is modeled in same way as a class."An interface is a set of operations that
describes some part of the behavior of a class and provides access to those operations."

31
4. Component-Level Design Elements: Component level for software fully describes the internal detail of
each software component. To accomplish this, component-level design defines detail for all processing
that occurs within a component and an interface that allows access to all component operations.

Design details of a component can be modeled at many different levels of abstraction. An activity
diagram can be used to represent processing logic. Detailed procedural flow for a component can be
represented using either pseudo code or some diagrammatic form.

5. Deployment-Level Design Elements: These indicate how software functionality and subsystems will be
allocated within the physical computing environment that will support the software.
Deployment diagram shows the computing environment but does not explicitly indicate configuration
details. Each instance of deployment is identified.
During design, a UML deployment diagram is first developed, and then refined. In a deployment diagram,
each subsystem would be elaborated to indicate components that it implements.

32
 PATTERN-BASED SOFTWARE DESIGN
Throughout the design process, a software engineer should look for every opportunity to reuse existing design
patterns (when they meet needs of the design) rather than creating new ones.
Describing a Design Pattern: Mature engineering disciplines make use of thousands of design patterns, for
things such as buildings, highways, electrical circuits, factories, weapons, computers etc. A description of design
pattern may also consider a set of design forces.
Design forces describe non-functional requirements (Ex: Portability) associated the software for which
the pattern is to be applied. These also define the constraints that may restrict the manner in which design is to
be implemented. Design forces describe the environment and constraints that must exist to make design pattern
applicable.
✓ Pattern characteristics (classes, responsibilities & collaborations) indicate the attributes of the design that
may be adjusted to enable the pattern to accommodate a variety of problems.
The names of design patterns should be chosen with care and should have a meaningful name.

Using Patterns in Design: Design patterns can be used throughout software design. The problem description is
examined at various levels of abstraction to determine if it is amenable to one or more following types of patterns:
1. Architectural Patterns: These patterns,

✓ Define overall structure of the software,

✓ Indicate relationships among subsystems & software components,

✓ Define rules for specifying relationships among the elements (class, components, packages, subsystems) of
the architecture.

2. Design Patterns: These patterns address a specific element of the design such as an aggregation of
components to solve some design problem, relationships among components, or mechanisms for effecting
component-to component communication.

3. Coding Patterns: These are also called idioms; these language- specific patterns generally implement an
algorithmic element of a component, a specific interface protocol, or a mechanism for communication among
components. Each of these pattern types differs in the level of abstraction and degree to which it provides direct guidance
for construction activity of software process.

33
Frameworks: “A framework is not an architectural pattern, but rather a skeleton with a collection of "plug
points" (also called hooks and slots) that enable it to be adapted to a specific problem-domain."
Plug points enable designer to integrate problem specific classes or functionality within the skeleton.

In O-O context, framework is collection of co-operating classes.

✓ To be most effective, frameworks are applied with no changes, additional design elements may be added,
but only via plug points that allow designer to flesh out the framework selection.

34
 UNIT IV

Testing Strategies: A strategic approach to software testing, test strategies for conventionalsoftware,
Black-Box and White-Box testing, Validation testing, System testing, the art of Debugging.

Product metrics: Software Quality, Metrics for Analysis Model, Metrics for Design Model,Metrics
for source code, Metrics for testing, Metrics for maintenance.
Metrics for Process and Products: Software Measurement, Metrics for software quality.

Testing Strategies

Software is tested to uncover errors introduced during design and construction. Testingoften
accounts for
More project effort than other s/e activity. Hence it has to be done carefully using a testingstrategy.
The strategy is developed by the project manager, software engineers and testing specialists.
Testing is the process of execution of a program with the intention of finding errors Involves 40%
of total project cost
Testing Strategy provides a road map that describes the steps to be conducted as part oftesting.
It should incorporate test planning, test case design, test execution and resultant data
collection and execution
Validation refers to a different set of activities that ensures that the software is traceable tothe
Customer requirements.
V&V encompasses a wide array of Software Quality Assurance
A strategic Approach for Software testing
Testing is a set of activities that can be planned in advance and conducted systematically.Testing
strategy
Should have the following characteristics:
-- usage of Formal Technical reviews(FTR)
-- Begins at component level and covers entire system
-- Different techniques at different points
-- conducted by developer and test group
-- should include debugging
Software testing is one element of verification and validation.
Verification refers to the set of activities that ensure that software correctly
implements aspecific function.
( Ex: Are we building the product right? )
Validation refers to the set of activities that ensure that the software built is
traceable tocustomer requirements.
( Ex: Are we building the right product ? )
Testing Strategy

Page 1 of 14
 Testing can be done by software developer and independent testing group. Testing and
debugging are different activities. Debugging follows testing

Low level tests verifies small code segments. High level tests validate major
systemfunctions against customer requirements
Test Strategies for Conventional Software:
Testing Strategies for Conventional Software can be viewed as a spiral consisting of four
levelsof testing:
1) Unit Testing
2)Integration Testing
3)Validation Testing
and

4) System Testing

Spiral Representation of Testing for Conventional Software

Unit Testing begins at the vortex of the spiral and concentrates on each unit of
software insource code.

It uses testing techniques that exercise specific paths in a component and its control
structure to ensure complete coverage and maximum error detection. It focuses on the internal
processing logicand data structures. Test cases should uncover errors.

Page 2 of 14
 Fig: Unit Testing

Boundary testing also should be done as s/w usually fails at its boundaries. Unit
tests can be designed before coding begins or after source code is generated.

Integration testing: In this the focus is on design and construction of the software
architecture. It addresses the issues associated with problems of verification and program
construction by testing inputs and outputs. Though modules function independently
problems may arise because of interfacing. This technique uncovers errors associated with
interfacing. We can use top-down integration wherein modules are integrated by moving
downward through the control hierarchy, beginning with the main control module. The
other strategy is bottom –up which begins construction and testing with atomic modules
which are combined into clusters as we move up the hierarchy. A combined approach called
Sandwich strategy can be used i.e., top- down for higher level modules and bottom-up for
lower level modules.

Page 3 of 14
Validation Testing: Through Validation testing requirements are validated against
s/wconstructed. These are high-order tests where validation criteria must be
evaluated to assure that s/w meets all functional, behavioural and performance
requirements. It succeeds when the software functionsin a manner that can be
reasonably expected by the customer.
1) Validation Test
Criteria2)Configuration
Review 3)Alpha And
Beta Testing
The validation criteria described in SRS form the basis for this testing. Here, Alpha and Beta
testing is performed. Alpha testing is performed at the developers site by end users in a
natural setting and with a controlled environment. Beta testing is conducted at end-user
sites. It is a “live” application and environment is not controlled.
End-user records all problems and reports to developer. Developer then makes
modifications and releases the product.

System Testing: In system testing, s/w and other system elements are tested as a whole.
This is the last high-order testing step which falls in the context of computer system
engineering. Software is combined with other system elements like H/W, People, Database
and the overall functioning is checked by conducting a series of tests. These tests fully
exercise the computer based system. The types of tests are:
1. Recovery testing: Systems must recover from faults and resume processing within a
prespecified time.
It forces the system to fail in a variety of ways and verifies that recovery is properly
performed. Here the Mean Time To Repair (MTTR) is evaluated to see if it is within
acceptable limits.

2. Security Testing: This verifies that protection mechanisms built into a system will protect
it from improper penetrations. Tester plays the role of hacker. In reality given enough
resources and time it is possible to ultimately penetrate any system. The role of system
designer is to make penetration cost more than the value of the information that will be
obtained.
3. Stress testing: It executes a system in a manner that demands resources in abnormal
quantity, frequency or volume and tests the robustness of the system.
4. Performance Testing: This is designed to test the run-time performance of s/w within the
context of an integrated system. They require both h/w and s/w instrumentation.
Testing Tactics:
The goal of testing is to find errors and a good test is one that has a high probability of
findingan error.
A good test is not redundant and it should be neither too simple nor too
complex.Two major categories of software testing
Black box testing: It examines some fundamental aspect of a system, tests whether
eachfunction of product is fully operational.
White box testing: It examines the internal operations of a system and
examines theprocedural detail.

Page 4 of 14
Black box testing
This is also called behavioural testing and focuses on the functional requirements of software.
It fully exercises all the functional requirements for a program and finds incorrect or missing
functions,interface errors, database errors etc. This is performed in the later stages in the
testingprocess. Treatsthe system as black box whose behaviour can be determined by
studying its input and related output Not concerned with the internal. The various testing
methods employedhere are:
1) Graph based testing method: Testing begins by creating a graph of important objects and
theirrelationships
and then devising a series of tests that will cover the graph so that each object and
relationshipis exercised and errors are uncovered.

Object

Link

Fig: O-R graph.

2) Equivalence partitioning: This divides the input domain of a program into classes of
datafrom which test
Cases can be derived. Define test cases that uncover classes of errors so that no. of test
cases are reduced.This is based on equivalence classes which represents a set of valid or
invalid states forinputconditions. Reduces the cost of testing

Example

Input consists of 1 to 10
Then classes are n<1,1<=n<=10,n>10
Choose one valid class with value within the allowed range and two invalid classes
wherevalues are greater than maximum value and smaller than minimum value.

3) Boundary Value analysis

Select input from equivalence classes such that the input lies at the edge of the equivalence
classes. Set of

Page 5 of 14
data lies on the edge or boundary of a class of input data or generates the data that lies at the
boundary of a class of output data. Test cases exercise boundary values to uncover errors at the
boundaries of the input domain.
Example
If 0.0<=x<=1.0

Then test cases are (0.0,1.0) for valid input and (-0.1 and 1.1) for invalid input

4) Orthogonal array Testing

This method is applied to problems in which input domain is relatively small but too large for
exhaustive testing
Example
Three inputs A,B,C each having three values will require 27 test cases. Orthogonal testing will
reduce the number of test case to 9 as shown below
White Box testing
Also called glass box testing. It uses the control structure to derive test cases. It exercises all
independent paths, Involves knowing the internal working of a program, Guarantees that all
independent paths will be exercised at least once .Exercises all logical decisions on their true
and false sides, Executes all loops,Exercises all data structures for their validity. White box
testingtechniques

1. Basis path testing

2. Control structure
testing1.Basis path
testing

Proposed by Tom McCabe. Defines a basic set of execution paths based on

logicalcomplexity of a procedural design. Guarantees to execute every statement in
the program at least once Steps of Basis Path Testing
1. Draw the flow graph from flow chart of the program
2.Calculate the cyclomatic complexity of the resultant flow
graph3.Prepare test cases that will force execution of each
path

Two methods to compute Cyclomatic complexity number

1.V(G)=E-N+2 where E is number of edges, N is number of
nodes2.V(G)=Number of regions

The structured constructs used in the flow graph are:

Page 6 of 14
 effective
It is not sufficient in

itself2.Control

Structure testing

This broadens testing coverage and improves quality of testing. It uses the following methods:
a) Condition testing: Exercises the logical conditions contained in a program module.
Focuses on testing each condition in the program to ensure that it does not contain
errorsSimple condition
E1<relation operator>E2 Compound condition
simple condition<Boolean operator>simple
condition
Types of errors include operator errors, variable errors, arithmetic expression errors etc.
b) Data flow Testing
This selects test paths according to the locations of definitions and use of variables in
aprogram Aims to ensure that the definitions of variables and subsequent use is tested
First construct a definition-use graph from the control flow of a program
DEF(definition):definition of a variable on the left-hand side of an assignment statement
USE: Computational use of a variable like read, write or variable on the right hand
of
assignment statement Every DU chain be tested at least once.

c) Loop Testing
This focuses on the validity of loop constructs. Four categories can be defined

1. Simple
loops
2.Nested
loops

Page 7 of 14
3. Concatenated
loops
4.Unstructured
loops

Testing of simple loops

N is the maximum number of allowable passes through the loop
1. Skip the loop entirely
2. Only one pass through the
loop3.Two passes through
the loop
4.m passes through the loop where
m>N5.N-1,N,N+1 passes the loop

The Art of Debugging

Debugging occurs as a consequence of successful testing. It is an action that results in
theremoval of errors.
It is very much an art.

Fig: Debugging process

Debugging has two outcomes:
- cause will be found and corrected
- cause will not be
foundCharacteristics of
bugs:
- symptom and cause can be in different locations

Page 8 of 14
- Symptoms may be caused by human error or timing problems

Debugging is an innate human trait. Some are good at it and some are

not.

Debugging Strategies:

The objective of debugging is to find and correct the cause of a software error which is
realizedby a combination of systematic evaluation, intuition and luck. Three strategies are
proposed: 1)Brute Force Method.

2) Back Tracking
3)Cause
Elimination

Brute Force: Most common and least efficient method for isolating the cause of a s/w error.
This is applied

when all else fails. Memory dumps are taken, run-time traces are invoked and program
is loaded with output statements. Tries to find the cause from the load of information
Leads towaste of time and effort.

Back tracking: Common debugging approach. Useful for small programs

Beginning at the system where the symptom has been uncovered, the source code is
tracedbackward until the site of the cause is found. More no. of lines implies no. of paths are
unmanageable.
Cause Elimination: Based on the concept of Binary partitioning. Data related to
error occurenec are organized to isolate potential causes. A “cause hypothesis” is
devised and data is used to prove or disprove it. A list of all possible causes is
developed and tests areconducted to eliminate each

Automated Debugging: This supplements the above approaches with debugging tools
thatprovide semi-automated support like debugging compilers, dynamic debugging
aids, test casegenerators, mapping tools etc.

Regression Testing: When a new module is added as part of integration testing the software
changes.

This may cause problems with the functions which worked properly before. This testing is
there-execution of some subset of tests that are already conducted to ensure that
changes have not propagatedunintended side effects. It ensures that changes do not
introduce unintended behaviour or errors. This can be done manually or automated.
Software Quality Conformanceto explicitly stated functional andperformance
requirements, explicitly documented development standards, and implicit characteristics
that are expected of

Page 9 of 14
 All professionally developed software.

Factors that affect software quality can be categorized in two broad groups:
Factors that can be directly measured (e.g. defects uncovered during testing)
Factors that can be measured only indirectly (e.g. usability or maintainability)

McCall’s quality factors

1. ProductoperationCorrectness

Reliability
Efficiency
Integrity
Usability

2. Product Revision
Maintainability
Flexibility
3. Product
Transition
Portability
Reusability
Interoperability

ISO 9126 Quality Factors

1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability
Product metrics

Product metrics for computer software helps us to assess quality.

Measure Provides a quantitative indication of the extent, amount,
dimension, capacity or size of someattribute of a product or
processMetric(IEEE 93 definition)

Page 10 of 14
 A quantitative measure of the degree to which a system, component or process
possess agiven attribute Indicator
A metric or a combination of metrics that provide insight into the software process,
asoftware project or a product itself
Product Metrics for analysis, Design, Test and maintenance

Product metrics for the Analysis model

Function point Metric
First proposed by Albrecht
Measures the functionality delivered by the
systemFP computed from the following
parameters
1) Number of external inputs(EIS)
2) Number external outputs(EOS)

Product metrics for the Analysis model

Number of external Inquiries(EQS)
Number of Internal Logical Files(ILF)
Number of external interface
files(EIFS)
Each parameter is classified as simple, average or complex and weights are assigned as follows

Product metrics for the Analysis model

• Information
Domain Count Simple avg Complex
EIS 3 4 6
EOS 4 5 7
EQS 3 4 6
ILFS 7 10 15
EIFS 5 7 10

FP=Count total *[0.65+0.01*E(Fi)]

Metrics for Design Model

DSQI(Design Structure Quality

Index)US air force has designed
the DSQI
Compute s1 to s7 from data and architectural design

Page 11 of 14
 S1:Total number of modules
S2:Number of modules whose correct function depends on the data
inputS3:Number of modules whose function depends on prior
processing S4:Number of data base items
S5:Number of unique database
itemsS6: Number of database
segments
S7:Number of modules with single entry and exit

Calculate D1 to D6 from s1 to s7 as follows:

D1=1 if standard design is followed otherwise
D1=0D2(module independence)=(1-(s2/s1))
D3(module not depending on prior processing)=(1-
(s3/s1))D4(Data base size)=(1-(s5/s4))
D5(Database compartmentalization)=(1-
(s6/s4) D6(Module entry/exit
characteristics)=(1-(s7/s1))

DSQI=sigma of WiDi

i=1 to 6,Wi is weight assigned to Di

If sigma of wi is 1 then all weights are equal to 0.167
DSQI of present design be compared with past DSQI. If DSQI is significantly lower than
the average,further design work and review are indicated

METRIC FOR SOURCE CODE

HSS(Halstead Software science)

Primitive measure that may be derived after the code is generated or estimated once design is
complete

n1 = the number of distinct operators that appear in a

program n2 = the number of distinct operands that appear
in a program N1 = the total number of operator
occurrences.
N2 = the total number of operand
occurrence.Overall program length N can
be computed:
N = n1 log2 n1 + n2 log2 n2 V = N log2(n1+ n2)

Page 12 of 14
 METRIC FOR TESTING

n1 = the number of distinct operators that appear in a program

n2 = the number of distinct operands that appear in a program
N1 = the total number of operator occurrences.
N2 = the total number of operand
occurrence.Program Level and Effort
PL = 1/[(n1 / 2) x (N2 / n2
l)]e = V/PL

METRICS FOR MAINTENANCE

Mt = the number of modules in the current release

Fc = the number of modules in the current release that have been
changedFa = the number of modules in the current release that have
been added.
Fd = the number of modules from the preceding release that were deleted in the
currentrelease

The Software Maturity Index, SMI, is defined as:

SMI = [Mt–(Fc + Fa +Fd)/ Mt ]

Metrics for Process And Product

Software Measurement:
Software measurement can be
categorized as
1) Direct Measure and
2) Indirect Measure

Metrics for Process And

ProductDirect
Measurement
Direct measure of software process include cost and effort
Direct measure of product include lines of code, Execution speed, memory size, defects per
reporting time period.
Indirect Measurement
Indirect measure examines the quality of software product itself(e.g. :-
Functionality,complexity, efficiency, reliability and maintainability)

Reasons for measurement

To gain baseline for comparison with future
assessmentTo determine status with respect to plan
To predict the size, cost and duration estimate
To improve the product quality and process improvement

Page 13 of 14
 Software Measurement
The metrics in software Measurement
areSize oriented metrics
Function oriented
metricsObject
oriented metrics
Web based application metric

Size Oriented Metrics

It totally concerned with the measurement of software.
A software company maintains a simple record for calculating the size of the
software.It includes LOC, Effort,$$,PP document,Error,Defect ,People.
Function oriented metrics
Measures the functionality derived by the application
The most widely used function oriented metric is Function
pointFunction point is independent of programming language
Measures functionality from user point of view

Object oriented metric

Relevant for object oriented
programmingBased on the following
Number of scenarios (Similar to use cases)
Number of key classesNumber of support
classesNumber of average support class per
key class Number of subsystem

Web based application metric

Metrics related to web based application measure the following
1. Number of static pages(NSP)
2. Number of dynamic pages(NDP)
Customization(C)=NSP/NSP+NDPC should approach 1
MetricsforSoftware Quality
Measuring Software Quality
1.Correctness=defects/KLOC
2. Maintainability=MTTC(Mean-time to
change)3.Integrity=Sigma[1-(threat(1-security))]
Threat : Probability that an attack of specific type will occur within a given time
Security : Probability that an attack of a specific type will be repelled Metrics for
SoftwareQuality Usability: Ease of use
Defect Removal Efficiency(DRE) DRE=E/(E+D)
E is the no. of errors found before delivery and D is no. of defects reported after
deliveryIdeal value of DRE is 1

Page 14 of 14
 UNIT – V:
Risk Management: Reactive vs. Proactive risk strategies, Software risks, Risk
identification, Risk projection, RMMM plan
Quality Management: Quality concepts, Software quality assurance, Formal technical
reviews, ISO 9000 Quality standards.

Risk Management
Risk is an undesired event or circumstance that occur while a project is underway It is
necessary for the project manager to anticipate and identify different risks that a project may be
susceptible to Risk Management. It aims at reducing the impact of all kinds of risk that may effect
a project by identifying, analyzing and managing them

Reactive Vs Proactive risk

Reactive : It monitors the projects likely risk and resources are set aside.
Proactive: Risk are identified, their probability and impact is accessed
Software Risk
It involve 2 characteristics
Uncertainty : Risk may or may not happen
Loss : If risk is reality unwanted loss or consequences will occur It includes
1)Project Risk 2)Technical Risk 3)Business Risk 4)Known Risk 5)Unpredictable Risk
6) Predictable risk
Project risk: Threaten the project plan and affect schedule and resultant cost
Technical risk: Threaten the quality and timeliness of software to be produced
Business risk: Threaten the viability of software to be built
Known risk: These risks can be recovered from careful evaluation
Predictable risk: Risks are identified by past project experience
Unpredictable risk: Risks that occur and may be difficult to identify

Risk Identification
It concerned with identification of riskStep1: Identify all possible risks Step2: Create item check
list
Step3: Categorize into risk components-Performance risk, cost risk, support risk and schedule risk
Step4: Divide the risk into one of 4 categoriesNegligible-0
Marginal-1Critical-2
Risk Identification
Risk Identification includes Product size
Business impact Development environment Process definition Customer
characteristicsTechnology to be built Staff size and experience
Risk Projection
Also called risk estimation. It estimates the impact of risk on the project and the product.
Estimation is done by using Risk Table. Risk projection addresses risk in 2 ways

Risk Category Probability Impact RMMM

Size estimate may be

Significantly low PS 60% 2

Larger no. of users

than planned PS 30% 3
Less reuse than PS 70% 2
planned
End user resist BU 40% 3
system

Likelihood or probability that the risk is real

(Li) Consequences (Xi)
Risk Projection
Steps in Risk projection
➢ Estimate Li for each risk
➢ Estimate the consequence Xi
➢ Estimate the impact
➢ Draw the risk table
Ignore the risk where the management concern is low i.e., risk having impact high or low with low
probability of occurrence
Consider all risks where management concern is high i.e., high impact with high or moderate
probability of occurrence or low impact with high probability of occurrence
Risk Projection Projection The impact of each risk is assessed by Impact valuesCatastrophic-1 Critical-2
Marginal-3Negligible-4

Risk Refinement
Also called Risk assessment
Refines the risk table in reviewing the risk impact based on the following three factorsa. Nature:
Likely problems if risk occurs
b. Scope: Just how serious is it?c. Timing: When and how long
It is based on Risk Elaboration Calculate Risk exposure RE=P*C
Where P is probability and C is cost of project if risk occurs Risk Mitigation Monitoring And
Management (RMMM)
Its goal is to assist project team in developing a strategy for dealing with risk There are three issues
of RMMM
1.Risk Avoidance
2.Risk Monitoring and
3.Risk Management
Risk Mitigation Monitoring And Management (RMMM)
Risk Mitigation
Proactive planning for risk avoidance Risk Monitoring
Assessing whether predicted risk occur or not Ensuring risk aversion steps are being properly
applied Collection of information for future risk analysis Determine which risks caused which
problems
Risk Mitigation Monitoring And Management (RMMM)Risk Management Contingency planning
Actions to be taken in the event that mitigation steps have failed and the risk has become a live
problem Devise RMMP(Risk Mitigation Monitoring And Management Plan)

RMMM plan
It documents all work performed as a part of risk analysis.
Each risk is documented individually by using a Risk Information Sheet. RIS is maintained by using
a database system Quality Management
QUALITY CONCEPTS

Variation control is the heart of quality control

Form one project to another, we want to minimize the difference between the predicted
resources needed to complete a project and the actual resources used, including staff,
equipment, and calendar time
1. Quality of design
Refers to characteristics that designers specify for the end product Quality
Management
2. Quality of conformance
Degree to which design specifications are followed in manufacturing the product
3.Quality control
Series of inspections, reviews, and tests used to ensure conformance of a work
product to its
specifications
4.Quality assurance
Consists of a set of auditing and reporting functions that assess the effectiveness and
completeness of quality control activities

COST OF QUALITY
Prevention costs
Quality planning, formal technical reviews, test equipment, training Appraisal costs In-
process and inter-process inspection, equipment calibration and maintenance, testing
Failure costs
rework, repair, failure mode analysis
External failure costs
Complaint resolution, product return and replacement, help line support, warranty work
Software Quality Assurance
Software quality assurance (SQA) is the concern of every software engineer to reduce cost
and improve product time-to-market.
A Software Quality Assurance Plan is not merely another name for a test plan, though test
plans are included in an SQA plan.
SQA activities are performed on every software project.
Use of metrics is an important part of developing a strategy to improve the quality of both
software processes and work products.

SOFTWARE QUALITY ASSURANCE

Definition of Software Quality serves to emphasize:
Conformance to software requirements is the foundation from which software quality is
measured. Specified standards are used to define the development criteria that are used to
guide the manner in which software is engineered. Software must conform to implicit
requirements (ease of use, maintainability, reliability, etc.) as well as its explicit requirements.

SQA Activities
• Prepare SQA plan for the project.
• Participate in the development of the project's software process description.
• Review software engineering activities to verify compliance with the defined
software process.
• Audit designated software work products to verify compliance with those defined
aspart of the software process.
• Ensure that any deviations in software or work products are documented and
handled according to a documented procedure.
• Record any evidence of noncompliance and reports them to management.

SOFTWARE REVIEWS
• Purpose is to find errors before they are passed on to another software engineering
activity or released to the customer.
• Software engineers (and others) conduct formal technical reviews (FTRs) for
software quality assurance.
• Using formal technical reviews (walkthroughs or inspections) is an effective means
for improving software quality.

FORMAL TECHNICAL REVIEW

A FTR is a software quality control activity performed by software engineers and others. The
objectives are:
• To uncover errors in function, logic or implementation for any representation ofthe
software.
• To verify that the software under review meets its requirements.
 • To ensure that the software has been represented according to predefined
standards. To achieve software that is developed in a uniform manner and
• To make projects more manageable.

Review meeting in FTR

The Review meeting in a FTR should abide to the following constraints :

• Review meeting members should be between three and five.

• Every person should prepare for the meeting and should not require more than two
hours of work for each person.
• The duration of the review meeting should be less than two hours.
• The focus of FTR is on a work product that is requirement specification, a detailed
component design, a source code listing for a component.
• The individual who has developed the work product i.e, the producer informs the
project leader that the work product is complete and that a review is required.

The project leader contacts a review leader, who evaluates the product for readiness,
generates copy of product material and distributes them to two or three review members
for advance preparation.

Each reviewer is expected to spend between one and two hours reviewing the
product, making notes
The review leader also reviews the product and establish an agenda for the reviewmeeting
The review meeting is attended by review leader, all reviewers and the producer.
One of the reviewer act as a recorder, who notes down all important points discussed
in the meeting.
The meeting (FTR) is started by introducing the agenda of meeting and then the producer
introduces his product. Then the producer “walkthrough” the product, the reviewers
raise issues which they have prepared in advance.

If errors are found the recorder notes down

Review reporting and Record keeping
During the FTR, a reviewer( recorder) records all issues that have been raised A
review summary report answers three questions
What was reviewed? Who reviewed it?
Whatwere the findings and conclusions?
Review summary report is a single page form with possible attachments
 The review issues list serves two purposes To identify problem areas in the product To
serve as an action item checklist that guides the producer as corrections are made

Review Guidelines
• Review the product, not the producer

• Set an agenda and maintain it

• Limit debate and rebuttal

• Enunciate problem areas, but don’t attempt to solve every problem noted
• Take return notes
• Limit the number of participants and insist upon advance preparation.
• Develop a checklist for each product i.e likely to be reviewed
• Allocate resources and schedule time for FTRS
• Conduct meaningful training for all reviewer
• Review your early reviews Software Defects
• Industry studies suggest that design activities introduce 50-65% of all defects or
errors during the software process
• Review techniques have been shown to be up to 75% effective in uncovering
design flaws which ultimately reduces the cost of subsequent activities in the
software process
Statistical Quality Assurance Information about software defects is collected and
categorized. Each defect is traced back to its cause

Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the
"vital few" defect causes.

Move to correct the problems that caused the defects in the "vital few”
Six Sigma for Software Engineering
The most widely used strategy for statistical quality assurance
Three core steps:
➢ Define customer requirements, deliverables, and project goals via well-defined
methods of customer communication.
➢ Measure each existing process and its output to determine current quality
performance (e.g., compute defect metrics)
 ➢ Analyze defect metrics and determine vital few causes.
For an existing process that needs improvement
1. Improve process by eliminating the root causes for defects
2. Control future work to ensure that future work does not reintroduce causes of
defectsIf new processes are being developed
1. Design each new process to avoid root causes of defects and to meet customer
requirements
2.Verify that the process model will avoid defects and meet customer requirements

SOFTWARE RELIABILITY
Defined as the probability of failure free operation of a computer program in a specified
environment for a specified time period
Can be measured directly and estimated using historical and developmental data Software
reliability problems can usually be traced back to errors in design or implementation.
Measures of Reliability
Mean time between failure (MTBF) = MTTF + MTTRMTTF = mean time to failure MTTR
= mean time to repair
Availability = [MTTF / (MTTF + MTTR)] x 100%
ISO 9000 Quality Standards
ISO (International Standards Organization) is a group or consortium of 63 countries
established to plan and fosters standardization. ISO declared its 9000 series of standards in
1987. It serves as a reference for the contract between independent parties. The ISO 9000
standard determines the guidelines for maintaining a quality system. The ISO standard
mainly addresses operational methods and organizational methods such as responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not
directly concerned about the product itself.
 Types of ISO 9000 Quality Standards
The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow automatically.
The types of industries to which the various ISO standards apply are as follows.

ISO 9001: This standard applies to the organizations engaged in design, development,
production, and servicing of goods. This is the standard that applies to mostsoftware
development organizations.
ISO 9002: This standard applies to those organizations which do not design products
but are only involved in the production. Examples of these category industries contain
steel and car manufacturing industries that buy the product and plants designs from
external sources and are engaged in only manufacturing those products. Therefore, ISO
9002 does not apply to software development organizations.
ISO 9003: This standard applies to organizations that are involved only in theinstall
action and testing of the products. For example, Gas companies.

An organization determines to obtain ISO 9000 certification applies to ISO registrar

office for registration. The process consists of the following stages:

1. Application: Once an organization decided to go for ISO certification, itapplies to the

registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggest an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful completionof all
the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by time.