💭

213 - Software Eng.

Study Guide
1. Software Engineering and Development Models
Definition of Software Engineering: Software engineering is the
systematic development of large software, which cannot be created in
isolation [1].

Software Evolution: The software industry has changed significantly,

moving from machine code in the 1960s to software reuse in the 1990s
[2].

Common Misunderstandings: Correcting errors in large software

systems is complex, and achieving perfect functionality on the first
attempt is practically impossible [3].

Software Development Life Cycle (SDLC): SDLC encompasses all the

steps involved in software creation, from requirements gathering to
maintenance [4].

Requirements Analysis: The initial phase involves understanding and

documenting the user's needs [4].

Design: This stage translates requirements into a logical system design,

outlining the system's architecture and modules [5].

Coding: This phase transforms the design document into high-level

language code, adhering to coding standards [6].

Testing and Debugging: This phase involves identifying and rectifying

errors in the software before deployment [7].

Maintenance: Post-deployment activities include error correction,

feature enhancements, and system optimization to meet evolving
requirements [8].

213 - Software Eng. 1

 Software Process Models

Waterfall Model: A linear model where phases are executed

sequentially. Feedback from later phases might be incorporated in
earlier phases [9].

Iterative Enhancement Model: This model develops the software in

iterations, with each iteration adding incremental features. Each iteration
follows the Waterfall model phases [9].

Spiral Model: This model combines elements of iterative development

with risk management. Each cycle involves planning, risk analysis,
development, and evaluation [10].

RAD (Rapid Application Development) Approach: This model focuses

on rapid development through component-based construction and
parallel development by multiple teams [11].
2. Software Requirements Analysis
Requirements Engineering: Requirements analysis is crucial for
understanding user needs and ensuring the software meets those
needs [12].

Software Requirements Specification (SRS): This document outlines

the software's functionality, performance requirements, and constraints
[13].

Problems in Requirements Analysis:

Complete requirements are difficult to uncover because of the complex

nature of modern software systems [14].

Requirements are constantly evolving as user needs and technological

advancements occur [14].

Ambiguous requirements, often arising from communication gaps, can

lead to misunderstandings and incorrect implementations [14].

Requirements Gathering Tools: These tools facilitate the elicitation and

documentation of user requirements [15].

Record Review: Analyzing existing documents like procedures and

manuals to understand the current system's functionality [15].

213 - Software Eng. 2

 On-Site Observation: Visiting the actual work environment to gain
firsthand insights into the system's operation and identify potential
issues [15].

Interviews: Gathering information directly from stakeholders through

structured conversations to understand their needs and perspectives
[15].

Questionnaires: Using surveys to collect information from a larger

group of stakeholders in a structured format [15].

System Architecture Modeling

Elementary Modeling Techniques: Modeling approaches focus on

capturing the essential elements of the system [16].

Essential Model: This model represents the system's core functionality

with minimal details [16].

Environmental Model: This model defines the system's context and its
interactions with external entities [16].

Data Flow Diagrams (DFDs): Graphical representations illustrating data

flow and processing within the system [17].

Context Diagram: A high-level DFD showing the system as a single

entity and its interactions with external entities [18].

Data Dictionary: A repository defining all data elements used in the

system, ensuring consistent terminology and understanding [19].

Entity-Relationship (E-R) Diagrams: A detailed, logical representation

of data entities, attributes, and relationships within a system [20].

Structured Requirements Definition: A comprehensive approach to

analyzing and documenting system and subsystem requirements [21].

Software Prototyping

Definition: Prototyping involves creating a simplified model of the

software to gather feedback and refine requirements [21].

Throwaway Prototype: This prototype is discarded after use, and the

final system is built from scratch [22].

213 - Software Eng. 3

 Evolutionary Prototype: This prototype is iteratively refined until it
evolves into the final system [23].

Benefits: Improved communication, early identification of missing

requirements, and better understanding of ambiguous requirements
[23].

Software Metrics

Definition: Quantitative measures used to assess software

characteristics and processes [24].

Lines of Code (LOC): A basic metric measuring the size of the software
based on the number of lines of code [25].

Importance: Software metrics provide insights into the software

development process and the product's quality [24].
3. Software Design
Purpose: Software design translates requirements into implementable
models, defining the system's architecture, modules, and interfaces
[26].

Importance: A good design is crucial for software quality,

maintainability, and future enhancements [27].

Data Design:

Purpose: Data design focuses on structuring and organizing data within

the software system [28].

Data Structure: Defines the logical relationship between data elements,

impacting algorithm design and system efficiency [28].

Architectural Design:

Purpose: Defines the high-level structure of the software, outlining

major components and their interactions [29].

Modular Design:

Purpose: Breaks down the software into smaller, manageable modules

with well-defined interfaces [30].

213 - Software Eng. 4

 Benefits: Improved maintainability, reusability, and reduced complexity
[30].

Cohesion: Measures a module's functional strength; high cohesion

(modules with closely related functions) is desirable [31].

Coupling: Measures the interdependence between modules; low

coupling (minimal interaction between modules) is desirable [31].

Human-Computer Interface (HCI) Design:

Purpose: HCI design aims to create user-friendly interfaces that are

intuitive and efficient to use [32].

Importance: A well-designed HCI enhances user satisfaction and

productivity [32].

User Experience (UX) Design:

Purpose: UX design focuses on the overall experience of the user while

interacting with the software [33].

Principles: Consistency, error prevention, recognition rather than recall,

flexibility, user control, efficiency, aesthetics, help and documentation
[33].

Mobile Design: Software design should consider the constraints and

opportunities of mobile devices [34].

Design Patterns: Reusable solutions to common design problems,

providing proven approaches to specific design challenges [34].
4. Software Quality and Security
Software Quality

Definition: Conformance to explicitly stated and implicitly stated

functional requirements, including maintainability [35].

Software Quality Assurance (SQA): Systematic activities ensuring the

software development process and products meet established quality
standards [36].

Formal Technical Review (FTR): A structured review process to identify

and address defects in software artifacts [37].

213 - Software Eng. 5

 Verification: Evaluates whether the software development process
adheres to defined methodologies and standards [37].

Validation: Ensures the software product meets the user's needs and
intended use [37].

Software Reliability: The probability of the software functioning

correctly for a specific period under defined conditions [38].

Software Quality Standards: Guidelines and best practices promoting

consistency and quality in software development [39].

Capability Maturity Model Integration (CMMI): A framework for

assessing and improving the maturity of software development
processes [40].

ISO 9001:2000: A quality management system standard applicable to

software development organizations [41].

Security Engineering

Importance: Security considerations should be integrated into every

phase of software development to mitigate risks and vulnerabilities [42].

This study guide provides a starting point for understanding key concepts in
software project management. You may want to independently verify the
information from this study guide to ensure accuracy.
Table of Contents
Block 1
1.0 INTRODUCTION
1.2 EVOLUTION OF SOFTWARE ENGINEERING
Software Engineering and its Model
Common Misunderstandings Regarding Software Development

Iterative Enhancement Model

Spiral Model
RAD Approach
Software Development Life Cycle (SDLC)

213 - Software Eng. 6

 Design
Coding
Testing and Debugging
Maintenance
Problems in SRS

Requirements Gathering Tools

MODELING THE SYSTEM ARCHITECTURE
Elementary Modeling Techniques
Data Flow Diagrams (DFD's)

Data Dictionary
Cardinality & Optionally

Attributes

Types of Prototype
Benefits of Prototyping

Software Metric
Lines of Code (LOC)

Block 2

Definition of Metrics

Types of Project Metrics

Lines of Code (LOC)

Function Point

Estimating Effort

Estimating Schedule

Statistical Model

Estimation Tools

Problems with Models

213 - Software Eng. 7

 Problems in Estimation Process

Block 3

9.0 INTRODUCTION

9.1 OBJECTIVES

Client-Server Architecture

9.2.2 Development, Testing and Deployment

Challenges in Web Application Testing

Deployment Considerations

9.2.3 Usage of Web Applications

Internationalization

9.3 MANAGING WEB BASED SOFTWARE PROJECTS

9.3.1 Requirements

9.3.2 Project Planning

Subordinate Plans

Communication

Configuration Management

Content Management System (CMS)

9.3.3 Content Development

9.4 Metrics

9.7 Reviews and Testing

Block 4

13.2 Software Engineering Institute Capability Maturity Model Integrated

(SEI CMMi)

Key Advantages of SEI CMMi Model

213 - Software Eng. 8

 Chapter 1
Software Engineering & its models

Overview
Initially, software was developed using machine code, which was difficult to
manage for large projects. With the advent of higher-order languages,
software development became more structured, leading to the
establishment of software houses focused on producing software as a
product.
The 1990s saw a shift towards software reuse and a focus on both
the process and the product of software development. This evolution has
led to the current state of software engineering, where software is
developed and maintained using various process models and adhering to
established standards.
Software process models provide a structured framework for developing
and maintaining software. Some of the widely used models are:

Models in Software Developmen

Build & Fix Model:
It is a simple two phase model. In one phase, code is developed and in
another, code is fixed.

Waterfall Model:

This model follows a linear, sequential approach where each phase

depends on the completion of the previous phase. It is simple to

213 - Software Eng. 9

 understand and implement but lacks flexibility in accommodating
changes during the development process.

In this model, complete requirements should be available at the time

of commencement of the project, but in actual practice, the
requirements keep on originating during different phases.

The water fall model can accommodate the new requirements only
in maintenance phase

It does not incorporate any kind of risk assessment.

213 - Software Eng. 10

 A slight modification of the waterfall model is a model with feedback.
Once software is developed and is operational, then the feedback to
various phases may be given.

Iterative Enhancement Model:

This model addresses the limitations of the waterfall model by

incorporating iterations. Each iteration delivers a working product with
incremental functionalities, allowing for flexibility in incorporating
feedback and changes.

In the first iteration, a less capable product is developed and

delivered for use. This product satisfies only a subset of the

213 - Software Eng. 11

 requirements.

In the next iteration, a product with incremental features is

developed. Every iteration consists of all phases of the waterfall
model.

The complete product is divided into releases and the developer

delivers the product release by release.

This model is useful when less manpower is available for software

development and the release deadlines are tight.

The cost estimation is also tedious because it is difficult to relate

the software development cost with the number of requirements.

Prototyping Model:
Prototyping enables developers to build a small model of software. The
IEEE 610.12 standard defines a prototype as a preliminary form or
instance of a system that serves as a model for later stages for the final
complete version of the system. Prototyping allows users to experiment
with and critique a proposed system before a full-scale system is
developed. This helps identify software requirements

Throwaway prototyping, also called close-ended prototyping,

involves building a prototype that is used only to gather user
feedback before it is discarded.2 The final system is built from
scratch, without incorporating elements of the prototype.2

In evolutionary prototyping (also known as breadboard

prototyping) the prototype is continually refined, incorporating user
feedback in each iteration.3 This process is repeated until the
complete system, embedded with all requirements, is evolved.

Benefits of Prototyping

213 - Software Eng. 12

 Helps identify communication gaps between software developers
and clients

Can reveal missing user requirements

Provides a method for depicting ambiguous user requirements

Demonstrates the feasibility and usefulness of an application to

management

Can be used as the basis for writing system specifications

Spiral Model:

The spiral model combines the iterative approach with risk analysis and
prototyping. It emphasises risk management by incorporating risk
analysis at each stage of the spiral, ensuring early identification and
mitigation of potential issues.

The following are the primary activities in this model

Finalising Objective: The objectives are set for the particular phase
of the project.

Risk Analysis: The risks are identified to the extent possible. They
are analysed and necessary steps are taken.

Development: Based on the risks that are identified, an SDLC model

is selected and is followed.

Planning: At this point, the work done till this time is reviewed. Based
on the review, a decision regarding whether to go through the loop
of spiral again or not will be decided. If there is need to go, then
planning is done accordingly.

213 - Software Eng. 13

 In this model, Software development starts with lesser requirements
specification,
lesser risk analysis, etc
The radical dimension this model represents cumulative cost. The
angular dimension represents progress made in completing the cycle.
The inner cycles of the spiral model represent early phases of
requirements analysis and after prototyping of software, the
requirements are refined.

After each phase a review is performed regarding all products

developed upto that point and plans are devised for the next cycle. This
model is a realistic approach to the development of large scale
software.

RAD Approach
This model gives a quick approach for software development and is
based on a linear sequential flow of various development processes.

213 - Software Eng. 14

 The software is constructed on a component basis. Thus multiple teams
are given the task of different component development. It increases the
overall speed of software
development. It gives a fully functional system within very short time.
This approach emphasises the development of reusable program
components. It follows a modular approach for development. The
problem with this model is that it may not work when technical risks are
high.
Capability Maturity Model Integration (CMM)
CMM is a model developed by the Software Engineering Institute (SEI) to
assess and improve the software development process maturity of an
organisation. It consists of five maturity levels, each representing a higher
level of process capability and maturity

Level 1 (Initial):

Characterised by ad-hoc and unpredictable processes.

No sound engineering approach is followed, the time and cost of the

project are not critical issue.

SEI‟s assessment indicates that the vast majority of software

organisations are Level 1
organisations.

Level 2 (Repeatable):

Basic project management practices are established.

The institutions achieving this maturity level learn with experience of

earlier projects and reutilise the successful practices in on-going
projects.

The process of development is much disciplined in this maturity

level.

Level 3 (Defined):

Standardised processes are implemented across the organisation.

213 - Software Eng. 15

 Software development processes are well defined, managed and
documented.

Training is imparted to staff to gain the required knowledge.

The standard practices are simply tailored to create new projects.

Level 4 (Managed):

Quantitative metrics are used to track and control the process.

The project analysis is done at integrated organisational level and

collective database is created.

The performance is measured at integrated organisation level. The

Software development is performed with well defined instruments.

The quality of software is high

Level 5 (Optimising):

Focus on continuous process improvement.

The entire organisation continuously works for process

improvement with the help of quantitative feedback obtained from
lower level.

The organisation analyses its weakness and takes required

corrective steps proactively to prevent the errors.

Based on the cost benefit analysis of new technologies, the

organisation changes their software development processes.

The CMM helps organisations identify areas for improvement and provides
a roadmap for achieving higher levels of software development maturity,
leading to better quality software and more predictable project outcomes.

KPA’s (Key Process Areas)

Level 1: No KPAs are associated with this level.

Level 2: This level focuses on basic project management and

includes six KPAs

1. Software Project Planning: Creating concrete plans for

managing software projects.

213 - Software Eng. 16

 2. Software Project Tracing & Oversight: Establishing visibility into
the actual development process to allow for corrective action if
needed.

3. Requirements Management: Ensuring requirements are well-

defined to establish a clear agreement between developers and
customers.

4. Software Subcontract Management: Selecting and effectively

managing qualified software subcontractors.

5. Software Quality Assurance (SQA): Ensuring the quality of the

developed software product.

6. Software Configuration Management (SCM): Establishing and

maintaining the integrity of the software product throughout its
entire lifecycle.

Level 3: This level focuses on establishing standardised processes

and includes seven KPAs

1. Organisation Process Focus (OPF): Establishing organisational

responsibility for software process activities to improve overall
software process capability.

2. Training Program (TP): Providing training to develop the skills

and knowledge of the organisation's staff.

3. Organisation Process Definition (OPD): Developing a workable

set of software processes to improve process performance and
provide long-term benefits to the organisation.

4. Integrated Software Management (ISM): Defining software

management and engineering activities to create tailored
software processes that meet organizational needs.

5. Software Product Engineering (SPE): Integrating well-defined

software engineering activities to produce correct and consistent
software products efficiently and effectively.

6. Intergroup Coordination (IC): Creating and actively engaging

software engineering groups to effectively meet customer needs.

213 - Software Eng. 17

 7. Peer Reviews (PR): Conducting peer reviews to identify and
remove defects from software engineering work products.

Level 4: This level focuses on quantitative management and includes

two KPAs

1. Quantitative Process Management (QP): Defining and using

quantitative standards for software processes.

2. Software Quality Management (SQM): Developing a quantitative

understanding of software product quality and achieving specific
quality goals.

Level 5: This level focuses on continuous process improvement and

includes three KPAs.

1. Defect Prevention (DP): Identifying the root causes of defects

and implementing strategies to prevent them from recurring.

2. Technology Change Management (TCM): Continuously

adapting to new technologies, tools, and processes to stay up-
to-date and improve software development practices.

3. Process Change Management (PCM): Continuously improving

the software development processes to enhance software
quality, increase productivity, and shorten development cycles.
Software Development Life Cycle (SDLC)
A software development project requires two types of activities viz.,
development and project management activities. These activities together
comprise of a software process. The SDLC encompasses the various
phases (steps) involved in software development process. The primary
phases are:

1. Requirement Analysis: This phase involves understanding and

documenting the user requirements for the software. The output of this
phase is SRS (Software Requirements Specification).

213 - Software Eng. 18

 2. Design: This phase translates the user requirements into a logical
system design, outlining the software's architecture and components.
Normally, design is performed in the following two steps:

1. Primary Design Phase: During this phase, the system is designed at

the block level. The blocks are created based on the analysis
conducted in the problem identification phase. Each block is
assigned a specific function, with an emphasis on minimizing
information flow between blocks. Activities that require more
interaction are grouped within a single block.

2. Secondary Design Phase: In this phase, the detailed design of each

block is carried out.

The input to the design phase is Software Requirements Specification

(SRS) document and the output is Software Design Document (SDD)

3. Coding: This phase involves translating the design into a

programming language, resulting in the actual software code.
This phase transforms the SDD document into a high level language
code. At present major software companies adhere to some well
specified and standard style of coding called coding standards. Once a
module is developed, a check is carried out to ensure that coding
standards are followed.

4. Testing: This phase verifies the functionality of the software and

identifies and corrects any defects or errors.
The testing process involves running the software with various inputs,
including those designed to uncover errors, to ensure that it functions
correctly. In the process of testing, an attempt is made to detect errors,
to correct the errors in order to develop error free software.

There are several levels of testing, including unit testing (individual

components), module testing, subsystem testing, and system testing
(the entire software system)

Testing can be performed using different strategies, such as code

testing, which examines the program's logic by testing every

213 - Software Eng. 19

 instruction and path, and specification testing, which tests specific
cases or conditions outlined in the software's requirements.

Testing cannot guarantee the absence of errors but rather aims to

uncover their presence. Even with rigorous testing, it is important to
note that achieving completely error-free software is highly challenging.

Testing v/s Debugging

Testing is the process of executing a program with the intention of
finding errors.
Normally, while developing the code, the software developer also
carries out some testing. This is known as debugging. This unearths the
defects that must be removed from the program. Testing and debugging
are different processes. Testing is meant for finding the existence of
defects while debugging stands for locating the place of errors and
correcting the errors during the process of testing.

Black Box v/s White box testing

Black box testing focuses on the system's functionality without

considering its internal workings. Test cases are designed based on the
system's functional specifications, aiming to verify if the system
behaves as expected for different inputs12. This testing is beneficial as
it can be conducted before the design or coding of the program, helping
to ensure the final product aligns with the specifications2. However, this
method may not detect additional functions or code that deviate from
the specifications, which is crucial for safety and security-critical
systems.

White box testing, also known as glass-box testing, requires

knowledge of the program's internal structure, including design
specifications and code. Test cases are designed to examine the
internal details of the code, aiming to test all possible execution paths.
The advantage of this method is its ability to identify issues within the

213 - Software Eng. 20

 code and check for functionalities not included in the specifications.
However, one drawback is the need to wait until after the design and
coding phases to select test cases

5. Maintenance: This phase involves making necessary changes or

enhancements to the software after its deployment to ensure its continued
functionality and address any emerging issues or requirements.
There are three categories of maintenance:

Corrective Maintenance

Adaptive Maintenance

Perfective Maintenance

Software maintenance is a very broad activity that includes error

correction, enhancement of capabilities, deletion of obsolete
capabilities, and optimisation

The various phases of the software development life cycle are tightly
coupled, and the
output of one phase governs the activity of the subsequent phase. Thus, all
the phases
need to be carefully planned and managed and their interaction requires
close
monitoring. The project management becomes critical in larger systems.
Intermittent Topics
Black Box v/s White Box Testing

Code v/s Specification Testing

Chapter 2
Principles of Software Requirement Analysis

Overview

213 - Software Eng. 21

 Requirements analysis is crucial for understanding the software's purpose.
It involves:

Identifying user needs.

Creating a Software Requirements Specification (SRS) document.

Analysing and validating the SRS for consistency, completeness, and

feasibility.

Discovering additional requirements during analysis.

Requirements Engineering
The complexity of software development necessitates an engineering
approach, leading to Requirements Engineering. This systematic approach
utilises proven principles, techniques, and tools for cost-effective analysis,
documentation, and evaluation of user needs.

Requirements Definition:
It is gathering, analysing, modeling, documenting (RDD and SRS), reviewing,
and validating requirements.

Requirements Management:
It is controlling, tracking, ensuring complete implementation, and managing
changes to requirements

Types of Requirements
Based on Priority

1. Essential

2. Highly desirable

3. Possible but eliminable.

Based on Functionality

1. Functional Requirements
Define specific system behavior, such as I/O formats, storage,
computations, timing, and synchronisation

213 - Software Eng. 22

 2. Non-Functional Requirements
Describe overall system qualities like usability, efficiency,
performance, size, reliability, and portability

Requirement Gathering Tools

The most important aspect of requirements gathering is understanding
what information to gather, when to gather it, and how to gather it.
Information needs to be gathered about the organization, the users, and
the functions of the organization.

1. Record Review:
This involves studying the organization's existing documentation,
such as procedures, manuals, forms, and records. This helps in
understanding the format and functions of the current system.
However, this method can be time-consuming

2. On-Site Observation:
Directly observing the system in its operational environment can help
identify problems and gain a deeper understanding of the system's
actual use.

3. Interview:
Personal interactions with staff members provide insights into their
specific requirements and expectations from the system.
This method requires careful planning and execution, including skilful
interviewing techniques, to ensure effective information gathering.

4. Questionnaire:
This method employs written questionnaires to efficiently gather
information from a larger group of people simultaneously.
It allows respondents time to provide considered responses and
offers a structured way to collect data
Software Requirements Specification
The SRS document, is the output from requirements analysis. It outlines the
software's functionality. An effective SRS ensures:

213 - Software Eng. 23

 Consistency: All requirements align without contradictions.

Correctness: Requirements accurately reflect user needs.

Unambiguity: Requirements have a single, clear interpretation.

Completeness: All necessary requirements are included.

An SRS clearly defines,

1. External Interfaces to the System → Information required to flow from and

to the system.

2. Functional & Non-Functional Requirements → Identify Run time

requirements.

3. Design Constraints

SRS Outline
1. Introduction

1. Purpose
The purpose of the SRS.

2. Scope
The scope of the SRS.

3. Definition, Acronyms, & Abbreviations

A table defining all terms, acronyms, and abbreviations used in
the SRS.

4. References
A list of all documents referenced in the SRS

5. Overview
A brief overview of the SRS.

2. Overall Description

1. Product Perspective: The context of the product.

2. Product Functions: The product's functions.

3. User Characteristics: The product's intended users.

213 - Software Eng. 24

 4. Constraints: The product's constraints.

5. Assumptions and Dependencies: The product's assumptions

and dependencies.

3. Specific Requirements

1. External Interfaces: How information will flow into and out of the
system.

2. Functional Requirements: I/O formats, storage structure,

computational capabilities, timing, and synchronisation.

3. Performance Requirements

4. Logical Database Requirements

5. Design Constraints

6. Software system Attributes

7. Organizing the specific Requirements

8. Additional Comments

4. Supporting Information

1. Table of Contents

2. Index
Software Modelling
System architecture modeling, crucial before design, visually represents the
system's structure and behavior.

Essential Model
A model showing bare minimum requirements. It has two components -

1. Environmental Model

Illustrates the system's context within a larger system and its

interaction with external entities.

213 - Software Eng. 25

 The tools of the environmental model are -

1. Statement of purpose: It indicates the basic objectives of

system.

2. Event list: It describes the different events of system and

indicates functionality of the system.

3. Context diagram: It indicates the environment of various sub-

systems.

2. Behavioural Model

It describes operational behaviour of the system. It describes the

system's operations using tools like Data Flow Diagrams (DFDs),
Entity-Relationship (ER) diagrams, Data Dictionaries, and Process
Specifications. It develops a systems logical model.

The behavioural model defines, Data of proposed system.

(i) The internal functioning of proposed system,

(ii) Inter-relationship between various data.

213 - Software Eng. 26

 Data Flow Diagrams
DFDs visually depict data flow within a system, representing it as
interconnected processes that transform data.

DFDs are created in a layered manner to represent the system at any

level of abstraction. The first layer is created at the block level, and
subsequent layers provide more details.

A level 0 DFD, also called a context diagram, views the entire software
element as a single bubble with an indication of only input and output
data.

Rules of DFD

1. Number the processes.

2. Keep a note of all processes and external entities and give them
unique names

3. Identify how processes and external entities interact

213 - Software Eng. 27

 4. Avoid Complex DFD’s (if possible).

5. Ensure the DFD is internally consistent

6. Every process should have at least one input and one output

7. The data store should contain all the data elements that flow as
input and output

Why is system modelling done?

System modeling is essential for simplifying complex systems and
improving communication during the software development process.
Instead of creating a complete model that depicts all of a system's
functionality at once, system modeling uses a layered approach, with
Data Flow Diagrams (DFDs) being a key tool.
DFDs graphically represent the flow of data through a system, breaking
down the system into levels of detail.2 This layered approach allows for
a clearer understanding of the system, starting with a high-level
overview and progressively revealing more details at lower levels. DFDs
are just one example of a system modeling technique, and the specific
methods employed may vary depending on the project.

DFD for Production Management System

213 - Software Eng. 28

 Data Dictionary
A data dictionary complements DFDs by providing detailed information
about each data element in the system, including:

Name

213 - Software Eng. 29

 Description

Characteristics

Ownership

Relationships with other data elements

A data dictionary is a catalog of all elements of a system. DFD depicts flow

of data whereas data dictionary gives details of that information like
attribute, type of attribute, size, names of related data items, range of
values, data structure definitions etc.
Some of the symbols used in data dictionary are given below:

X= [a/b] x consists of either data element a or b

X=a x consists of an optional data element a

X=a+b x consists of data element a & b.

x consists of some occurrences of data elements a which are

X=y{a}z
between y and z.

| Separator

** Comments

@ Identifier

() Options

213 - Software Eng. 30

 E-R Diagram
Entity-relationship (E-R) diagrams provide a detailed visual
representation of an organization's data, focusing on data organization.
This contrasts with DFDs, which emphasise process flow.
The ER diagram represent data at rest while DFD tracks the motion of data.
ERD does not provide any information regarding functionality of data.
E-R diagrams consist of three main components: — data entities, their
relationships, and attributes.

Entity
The fundamental elements of an organization about which data is
maintained, each with a unique identity. In an E-R diagram, entities are
represented by rectangular boxes.

213 - Software Eng. 31

 Relationship
The connections between entities, indicating how they are associated.
Relationships are represented by diamond shapes.

Attributes
The properties or characteristics associated with entities. Attributes are
represented by oval shapes and connected to their respective entities.

Cardinality & Optionally

E-R diagrams use cardinality to represent the relationship between two
entities, indicating the minimum and maximum number of instances of
one entity that can be associated with another entity.

Relationships have a "degree," which specifies how many entity types

participate in a particular relationship.
The text describes three degrees of relationship:

One-to-one (or unary)

One-to-many

Many-to-many

213 - Software Eng. 32

 The example of "Class" and "Student" entities illustrates a one-to-many
relationship, where one class can have multiple students, but each
student is typically associated with only one class for that particular
course.

The minimum cardinality of a relationship is the minimum number of

instances of second entity (student, in this case) with each instance of
first entity (class, in this case). In a situation where there can be no
instance of second entity, then, it is called as optional relationship.

Software Requirements Definition

213 - Software Eng. 33

 This approach analyzes the entire system, including subsystems, inputs,
outputs, and functionality. It involves:

1. Creating individual user-level DFDs.

2. Merging them into a combined user-level DFD.

3. Developing an application-level DFD.

4. Defining system and subsystem functionalities.

Software Prototyping
Prototyping involves creating a simplified model of the software to better
understand and refine requirements.
Prototyping is a software development process that enables the creation of
a scaled-down model of the intended software. This prototype acts as a
preliminary representation of the system and serves as a model for later
stages of development, ultimately leading to the final, complete version.

Purpose & Benefits of Prototyping

The primary purpose of prototyping is to facilitate learning and improve
understanding among customers, users, and developers regarding the
software's intended functionality and requirements.
It allows for exploration and critique of the proposed system before
substantial resources are invested in developing the full-scale software.

Types of Prototype

213 - Software Eng. 34

 1. Paper Prototype

A model that visually represents the interaction between the user and
the system, typically focusing on the user interface and how users
will engage with the software.

2. Working Prototype

Implements a limited set of the complete features, providing a

functional, but potentially simplified, representation of the software's
core capabilities.

3. Existing Program Enhancement

Utilizes an existing program that performs the desired functions as a

starting point, with additional features added incrementally to
enhance its capabilities and align it with the evolving requirements.

Prototyping Techniques
1. Throw-Away Prototype
Created with the understanding that it will be discarded once its
purpose is fulfilled.
The final system is then built from scratch, incorporating the
knowledge gained during the prototyping phase. This approach
prioritises speed and rapid user interaction, even if it means
sacrificing maintainability or fault tolerance in the prototype itself.

2. Evolutionary Prototype

Developed with the intention of continuous refinement and

expansion. It starts with a basic implementation of a few
requirements and iteratively adds more features until the complete
system is realised. This method emphasises learning from each
iteration and applying that knowledge to the prototype's evolution.

213 - Software Eng. 35

 Advantages of Prototyping
Improved Communication: Helps identify and bridge communication
gaps between software developers and clients, ensuring a shared
understanding of the system's goals and functionality.
Uncovering Missing Requirements: Allows users to interact with a
tangible representation of the system, often revealing missing or
overlooked requirements that were not apparent during initial analysis.
Clarifying Ambiguous Requirements: Provides a platform to clarify
ambiguous requirements by demonstrating different interpretations and
enabling users to provide concrete feedback.
Demonstrating Feasibility: A working prototype, even if limited, can
serve as proof of concept, demonstrating the feasibility and potential
value of the application to stakeholders.
Specification Basis: The insights and validated requirements derived
from the prototyping phase can form a solid foundation for writing the
system's formal specifications.

Drawbacks of Prototyping
Clients may misinterpret the prototype as a final product or become
attached to features that were not intended for the final version.

Rapid prototyping can sometimes lead to design decisions that prioritise

speed over maintainability, potentially causing issues in the long run

Software Metrics ➕
Software metrics are quantitative measures of software development life
cycle attributes. They function as software measures, which map objects
from the software engineering world into mathematical constructs such as
numbers. Software engineers use these metrics to measure software
processes and their requirements.
Software metrics provide a structured approach to quantifying various
aspects of the software development process and the resulting software
product. They offer a way to measure what might seem intangible, like

213 - Software Eng. 36

 productivity or complexity, and transform those concepts into concrete data
points that can be tracked, analysed, and used to guide decision-making.

Parameters used for Software Measurements

The objective of the software and problems associated with current
activities.

The cost of software required for relevant planning relative to future

projects.

The testability and maintainability of various processes and

products.

The quality of software attributes like reliability, portability, and

maintainability.

The utility of the software product.

The user-friendliness of a product.

Characteristics of Software Measures (Basili, 1989)

Objects of measurement: The products and processes to be
measured.

Source of measurement: Who will measure the software (e.g.,

software designer, software tester, software manager).

Property of measurement: The attribute to be measured, such as

cost, reliability, maintainability, size, and portability.

Context of measurement: The environments in which the software

measurements are applied.

Categories of Software Metrics

Product Metrics
These metrics focus on quantifying characteristics of the software
product itself, often at various stages of development.

Lines of Code

213 - Software Eng. 37

 One of the most commonly used metrics, LOC counts the number of
lines of source code in a program or module. While straightforward
to calculate, it has limitations as a measure of complexity or effort, as
it does not account for variations in programming language
efficiency or design elegance.

Function Points
This metric aims to measure the functionality delivered by a software
system from the user's perspective. It quantifies the system's size
and complexity based on the number and type of user inputs,
outputs, inquiries, files, and interfaces.
Function points offer a more implementation-independent measure
than LOC, making them suitable for comparing projects that use
different programming languages or development methodologies.

Process Metrics
These metrics shift the focus from the software product to the
process of creating that product.

Effort
Often measured in person-months or person-hours, this metric
tracks the amount of human resources invested in a project or a
specific development task

This data is essential for project planning, cost estimation, and

evaluating team productivity.

Schedule
This metric measures the time taken to complete a project or a
defined phase of development, typically tracked in calendar days,
months, or years.

213 - Software Eng. 38

 Accurate schedule estimation is critical for meeting deadlines and
managing client expectations.

Other Metrics
Defect Metrics
These metrics quantify the number of defects found in the software
at different stages of testing or development. They provide insights
into the software's quality and can help identify areas where
development processes need improvement.

Reliability Metrics

These metrics focus on measuring the software's ability to function

correctly and consistently over time. This often involves tracking the
meantime-to-failure (MTTF), which represents the average time
between software failures.

Significance of Software Metrics

Estimate Project Costs and Schedules: Metrics like effort, size (LOC or
function points), and historical data from past projects can be used to
create more accurate estimates for future projects.
Track Progress and Identify Potential Issues: By monitoring metrics like
schedule adherence and defect rates, project managers can identify
potential problems early on and take corrective action.
Improve Software Quality: Analyzing defect metrics can help teams
pinpoint weaknesses in their development processes and implement
changes to prevent similar defects in future projects.
Enhance Communication and Accountability: Having clear metrics in
place can improve communication between developers, project

213 - Software Eng. 39

 managers, and stakeholders by providing a shared language and a basis
for objective evaluation.
Limitations of Software Metrics
Subjectivity: Some metrics, like function points, can be subjective and
open to interpretation, particularly during the initial stages of
development when requirements may still be evolving.
Context Dependency: The meaning and usefulness of a metric can vary
depending on the specific project, the development methodology used,
and the organization's overall goals.

By using a combination of different metrics and interpreting them within the

context of a specific project and organization, software development teams
can gain valuable insights that help them deliver higher-quality software on
time and within budget.

Chapter 3
Software Design

Overview
Software design is the process of applying software engineering techniques
to develop models that define a software system, which provides sufficient
details for the actual realisation of the software.
The goal of software design is to translate user requirements into an
implementable program. Software design forms the foundation for the
implementation of a software system and helps in the maintenance of
software.
Software quality and the software design process are highly interrelated,
since quality is built into the software during the design phase.

213 - Software Eng. 40

 There are several fundamental concepts that are important in software
design:

The design should follow a hierarchical organization.

Design should be modular. Modules are logically partitioned into

components that are relatively independent and perform independent
tasks.

Designs should lead to interfaces that facilitate interaction with external

environments.

Stepwise refinement leads to more detailed design, which provides the

necessary details for code developers.

While modularity is encouraged to facilitate parallel development, it is

important to strike a balance, as too many modules can increase the effort
involved in integrating them

Data Design

213 - Software Eng. 41

 Data design is the first activity of system design. The primary objective of
data design is to select the logical representation of data items identified in
the requirements analysis phase. Data describes real-world information
resources that are important for the application. Examples of data include
customers, people, assets, and student records.
Data design is an iterative process where the focus moves from a high-
level overview of data to the specific types and properties of data as the
application is expanded upon. Identifying data is iterative: beginning at the
highest level and moving to more detailed properties as the application
expands.
When documenting data requirements, the description of each data item
typically includes:

Name

General Description

Characteristics

Ownership

Logical events, processes, and relationships

Data structures
define the logical relationships between individual data elements. The
structure of information affects the design of procedures and algorithms,
making proper selection critical.

Scalar items, like the name of a month, are the simplest form of data.

Vector items are a sequence of scalar items stored in contiguous

memory locations. For example, a list of months in a year.

Linked Lists are similar to vectors, but items are stored non-
contiguously.

Trees, implemented using linked lists, are an example of a hierarchical

data structure.q
Architectural Design

213 - Software Eng. 42

 The objective of architectural design is to develop a model of the software
architecture that depicts the program modules' overall organization within
the software product.
This encompasses both the structure of the data and the hierarchical
structure of the software components. Architectural design defines the
organization of these program components but does not specify the details
of each component or its implementation.

A key objective of architectural design is to manage the relationships

between modules, which can control or be controlled by other modules.
This characteristic is defined by a module's fan-in (number of incoming
edges) and fan-out (number of outgoing edges). The organization of
modules can be visualised as a tree-like structure.

Modular Design
Modular design is a key principle in software engineering, making software
products more maintainable and manageable. It involves breaking down
software into smaller, independent units called modules, which are named,
addressable, and can be developed and integrated separately.

213 - Software Eng. 43

 This approach, stemming from the "divide and conquer" principle, enables
parallel development, saving time and cost. However, it's crucial to strike a
balance, as excessive modules can increase integration costs
Modules are typically activated through references or external system
interrupts. There are three main types of modules.

Types of Modules
1. Incremental modules

Activated by interrupts and can be interrupted during execution

2. Sequential modules

Referenced by other modules and execute without external

interruption

3. Parallel modules

Run concurrently with other modules

Coupling & Cohesion

Cohesion
Measures a module's functional strength, representing how closely its
elements are related. High cohesion is desirable as it indicates that a
module focuses on a single, well-defined task.

Cohesion from Worst to best:

Coincidental Cohesion: This is the least desirable type of cohesion,

where a module encompasses unrelated tasks

Logical Cohesion: In this type, modules perform a series of actions,

but the calling module determines the specific action to be executed

Procedural Cohesion: Modules exhibiting this type of cohesion

execute a sequence of steps in a specific order. The elements within
the module follow a single control sequence

213 - Software Eng. 44

 Communicational Cohesion: Here, all elements within a module
operate on the same input data set and produce the same output
data set

Sequential Cohesion: In this type, the output of one element within

the module serves as input to another element. These modules
typically operate on the same data structure

Functional Cohesion: This is the most desirable type of cohesion.

Modules with functional cohesion consist of elements that
collaborate to perform a single, well-defined function4

Coupling
Measures the interdependence between modules, indicating the degree
to which they rely on each other4. Low coupling is preferable as it
signifies that modules are more independent and changes in one are less
likely to affect others
The types of coupling from best (lowest level of coupling) to worst (high
level of coupling) are described below:

Data coupling: Modules interact through parameters.

Example: Module X passes parameter A to module Y.

Stamp coupling: Modules shares composite data structure.

Control coupling: One module control logic flow of another module.

213 - Software Eng. 45

 Example: Passing a flag to another module which determines the
sequence of action to be performed in the other module depending
on the value of flag such as true or false.

External coupling: Modules shares external data format. Mostly

used in communication protocols and device interfaces.

Common coupling: Modules shares the same global data.

Content coupling: One module modifies the data of another module

Coupling v/s Cohesion

Coupling and cohesion are two fundamental principles in modular
software design that are inherently contrasting .While modularity
enhances software manageability and maintainability, the level of
independence between modules is even more critical for software
quality. This independence is measured by cohesion and coupling.
Cohesion measures a module's functional strength, indicating how
closely related its elements are. High cohesion is desirable because it
signifies that a module is focused on a single, well-defined task, making
it easier to understand, maintain, and reuse.
On the other hand, coupling measures the degree of interdependence
between modules. It represents how much one module relies on others
to perform its function. Low coupling is preferable because it indicates
that modules are more independent, and changes in one module are less
likely to have a ripple effect on others.

213 - Software Eng. 46

 In essence, high cohesion promotes modularity by ensuring each
module has a clear, singular purpose, while low coupling enhances this
modularity by minimising dependencies between modules. Therefore,
the objective in software design is to achieve high cohesion with low
coupling, resulting in a more maintainable, understandable, and robust
software product.

Interface Design
Interface design deals with the personnel issues of the software and is one
of the most important parts of software design. It is crucial because user
interaction with the system takes place through various interfaces provided
by the software product. Interface design has evolved a lot from the days of
text-based systems where users had to type commands on the command
line to execute tasks, to menu-based interfaces, and now, modern graphical
user interfaces that provide tools for easy navigation and interactivity.
Interface design deals with the personnel issues of the software and is one
of the most important parts of software design. It is crucial because user
interaction with the system takes place through various interfaces provided
by the software product. Interface design has evolved a lot from the days of
text-based systems where users had to type commands on the command
line to execute tasks, to menu-based interfaces, and now, modern graphical
user interfaces that provide tools for easy navigation and interactivity.

Here are some elements of good interface design:

Identify the goal and intention of the task.

Maintain consistency in the color scheme, messages, and terminologies

used.

Develop and adhere to standards for good interface design.

Use icons to provide appropriate messages.

Allow users to undo commands to help them fix mistakes.

Provide context-sensitive help to guide users.

213 - Software Eng. 47

 Use a proper navigational scheme for easy navigation within the
application.

Consult with current users to improve the interface.

Consider the user's perspective.

Avoid abbreviations and use clear language when communicating with

the user, especially about errors.

Design navigation, especially for data entry screens, to be easy to use.

Use color strategically, keeping in mind that some users may be

accessing the application on a monochrome screen.

Anticipate user errors and provide appropriate measures to handle them

through interface design.

Group related data items accordingly.

Justify the data items.

Avoid dense screen layouts and keep a significant amount of screen

space blank.

Ensure that accidental double clicks don't have unintended

consequences.

Provide a file browser instead of expecting the user to remember file

paths.

Provide keyboard shortcuts for frequently performed tasks.

Provide an online manual to help users operate the software.

Always allow users to cancel an action, even if it has already been

completed.

Warn users about critical tasks, such as deleting files or updating critical
information.

Consider bringing in expert professionals who understand human

perception to help design interfaces.

Include all possible features in the application, even if they're available

in the operating system.

213 - Software Eng. 48

 Use clear and understandable language in messages.

Develop navigational procedures before developing the user interface.

Human Interface Design
Human Interface Design, also known as Human-Computer Interaction (HCI),
focuses on creating effective and user-friendly interfaces for software
applications. A well-designed interface improves user experience and
productivity.
Here are some key principles and considerations for effective Human
Interface Design:

Goal Orientation: The primary goal of the interface and the user's
intended tasks should be clear and easily understood.

Consistency: A consistent design helps users quickly learn and

navigate the interface. This includes using uniform color schemes,
terminology, and layout throughout the application.

User Expertise: Interfaces should cater to different user groups,

including expert, average, and novice users. Provide shortcuts for
experienced users while offering guidance for beginners.

Error Handling: The interface should be designed to minimize user

errors. When errors occur, clear and constructive messages should
guide the user toward resolution.

Reversible Actions: Users should be able to easily undo actions to

mitigate mistakes.

Minimize Memory Load: The interface should not require users to

memorize complex information. Use menus, icons, and clear labels to
present options and information.

Contextual Relevance: Information displayed on the screen should be

relevant to the user's current task.

A well-designed HCI considers the user's mental model of the system and
strives to bridge the gap between the user's expectations and the system's
functionality. This involves:

Clear mapping between user actions and system responses.

213 - Software Eng. 49

 Understandable representation of system status.

Intuitive navigation and interaction mechanisms.

Sources do not explicitly define "personnel issues," it likely refers to the

human factors and considerations when designing user interfaces.
Understanding user needs, workflows, and potential challenges during
interaction is crucial for creating user-centered designs. This involves:

Considering user diversity in terms of experience, skills, and

preferences.

Conducting user testing to gather feedback and identify usability issues.

Iteratively refining the interface based on user input.

User Experience Design
User Experience (UX) design focuses on enhancing user satisfaction by
improving the usability, accessibility, and pleasure provided in the
interaction between the user and the product. A good UX design considers
the user's entire journey with the product, aiming to create a positive
experience.
While User Interface (UI) design focuses primarily on the interface's look
and feel, UX design encompasses the broader user experience, including UI
as one of its components. A poorly designed UI will negatively impact the
overall UX. Sources highlight the crucial role of UX design in web
applications, stating that user interface design can significantly impact a
website's success. Websites often cater to users with varying levels of
computer skills. Therefore, web application design should prioritize ease of
use and ergonomic considerations.

Designing for Mobility

When designing for mobile devices, it's important to consider various
mobile operating systems in the design phase. A key consideration is
whether to develop a hybrid application that runs across multiple mobile
operating systems or to develop separate applications for each operating
system.

Patterns for Design

213 - Software Eng. 50

 Design patterns provide general, reusable solutions to commonly
occurring problems in software design. They are like pre-made blueprints
that can be customized to solve a specific design problem. There are
different kinds of design patterns, including:

Architectural patterns

Data patterns

Component patterns

Interface design patterns

Webapp patterns

Creational patterns

Structural patterns

Behavioral patterns

When designing a technical solution, it's important to consider using design

patterns. This can improve productivity, turnaround time, and quality. For
instance, an architect designing an application might consider using
patterns like a headless design, stateless integration, or token-based
security.

Chapter 4
Software Quality & Security

Overview
This unit focuses on ensuring that software is developed to a high standard
and is secure.

Software quality assurance is a critical process within software

engineering that aims to produce high-quality software that meets customer
needs. It involves applying procedures and standards throughout the entire
software development life cycle.
Key aspects of software quality include:

213 - Software Eng. 51

 Conformance to requirements: The software should meet both
explicitly stated functional requirements outlined by the customer and
implicit requirements such as maintainability and industry standards.

Measurable characteristics: Software quality can be evaluated based

on measurable characteristics like correctness, reliability, efficiency,
integrity, usability, maintainability, testability, flexibility, portability,
reusability, and interoperability.

Complexity metrics: These metrics, like cyclomatic complexity, are

used to assess the maintainability of the software by analyzing its
control flow.

Formal technical reviews (FTRs): FTRs, including structured

walkthroughs and inspections, are formal quality assurance activities
used to identify defects and ensure the software meets standards.

Software reliability is a crucial aspect of quality, defined as the probability

that the software will function without failure for a specified time under
specific conditions.
Software quality standards, such as the Capability Maturity Model (CMM)
and ISO 9001:2000, provide guidelines and best practices for organizations
to establish and maintain quality management systems.
Security engineering focuses on developing software that is secure from
threats and vulnerabilities.
Software Quality
Software quality is a multifaceted concept defined as the software's ability
to meet stated and implied customer needs. It encompasses measurable
characteristics compared against established standards. The sources
primarily discuss software quality in terms of conformance to
requirements: both explicit requirements documented from customer
specifications and implicit requirements like maintainability. High-quality
software must fulfill both.

Simply increasing testing cannot guarantee software quality. Instead, a

high-quality software development process throughout the entire lifecycle is
crucial.

213 - Software Eng. 52

 Attributes of Quality Software
Sources identify numerous attributes that contribute to software quality:

Auditability: Can the software be effectively tested against established

standards?

Compatibility: Can the software function alongside other systems or

components in the same environment?

Completeness: Are all required functions and design constraints

present and fully developed across requirement specifications, design
documents, and code?

Consistency: Is there uniformity, standardization, and a lack of

contradictions across the different system documents and components?

Correctness: Does the software perform its intended functions

accurately?

Efficiency: Does the software utilize resources like processing power

and memory effectively?

Flexibility: Can the software be modified or adapted to changing needs

with minimal effort?

Integrity: Is the software protected from unauthorized access and

modification?

Maintainability: Can the software be easily understood, corrected, and

enhanced? This is influenced by the complexity of the code, which can
be measured using metrics like cyclomatic complexity.

Portability: Can the software be easily transferred and operate across

different operating environments?

Reliability: How likely is the software to perform without failure over a

specified time?

Reusability: Can components of the software be reused in other

systems or applications?

Testability: Can the software be easily and effectively tested?

213 - Software Eng. 53

 Traceability: Can the design be linked back to the original
requirements?

Usability: How easy is the software for users to learn, operate, and
understand?

Verifiability: Have the specifications, designs, and code been written to

make verification and testing easier?

Causes of Software Errors

Sources identify a range of potential causes for errors:

Miscommunication or misinterpretation of customer requirements

Incomplete or inaccurate system specifications

Errors in logic or coding

Not following established programming and software development

standards

Insufficient testing

Inaccurate or absent documentation

Deviations from approved specifications

Errors in data modeling and representation

Measuring Software Quality

Quantifying software quality requires various metrics applied throughout the
development lifecycle. Some examples include:

Defect Metrics: Tracking the number of design changes, coding errors,

and bugs discovered during testing.

Reliability Metrics: Measuring the average time between failures (Mean

Time To Failure - MTTF).

Maintainability Metrics: Using complexity metrics, particularly those

based on control flow analysis like cyclomatic complexity, to gauge the
ease of maintaining the software.

213 - Software Eng. 54

 Software Quality Assurance (SQA)
Software quality assurance aims to develop high-quality software products
by evaluating and verifying the software development process and its
outputs. It ensures conformance with both explicit and implicit
requirements, employing methods like:

Process Monitoring: Regularly observing and analyzing the software

development process to identify potential issues and deviations from
established procedures.

Product Evaluation: Assessing the software product at various stages,

verifying its adherence to requirements and quality standards.

Audits: Formal examinations of the software development process and

products to ensure compliance with agreed-upon standards,
procedures, and regulations.

Key Takeaways on Software Quality

Software quality is not an add-on but an inherent characteristic that
must be built into the development process from the outset.

A good design is more likely to result in good-quality software.

Software quality is a shared responsibility among software engineers,

project managers, customers, and quality assurance teams.

The sources provide a comprehensive foundation for understanding

software quality, emphasizing its multi-dimensional nature and the
importance of a quality-driven development process.
Formal Technical Review
Formal Technical Review (FTR) is a software quality assurance activity
performed by software engineering practitioners to improve software
product quality. The purpose of FTR is to have the product scrutinized for
completeness, correctness, consistency, technical feasibility, efficiency,
and adherence to established standards and guidelines by the client
organization.

Each FTR is conducted as a meeting, requiring well-coordinated planning

and commitments. For a successful FTR, the schedule and agenda should

213 - Software Eng. 55

 be distributed to members well in advance, members should review the
material, and reviewers should review the material independently in
advance. The meeting should be limited to 2 hours and consist of 2-5
people. The aim of the review is to review both the product/work and the
performance of the people.

The Result of an FTR

Meeting decision: Outlines whether to accept the product/work without

modification, accept it with changes, or reject it.

Review summary report: Details what was reviewed, who reviewed it,
the findings, and the conclusion.

Typical activities for review at each phase:

Software Concept and Initiation Phase: The SQA team is involved in

writing and reviewing the project management plan.

Software Requirement Analysis Phase: This phase ensures software

requirements are complete, testable, and properly expressed. The
output of this phase, the Software Requirements Specification (SRS), is
a major review input.

Software Design Phase: Reviewers determine if design features are

consistent with the requirements. The System Design Document (SDD)
is the output of this phase, and it is used as input for an FTR.

Review of Source Code: The source code is reviewed based on various

standards.

Software Testing and Implementation Phase: This phase involves

testing deliverables and ensuring the test plans are sufficient.

Installation Phase: The components required for installation are

reviewed.
Software Reliability
Software reliability is defined as the probability that software will operate
without failure in a specific environment for a predetermined period. Unlike
hardware reliability, software reliability is challenging to measure. Software
reliability is typically measured per unit of time. Probability of failure,

213 - Software Eng. 56

 however, is generally time-independent. Mean-time-to-failure (MTTF) is the
average time between failures, also known as mean-time-before-failure.
Definitions of Software Reliability:

IEEE Definition: The probability that software will not fail in a system for
a specific time under certain conditions, where probability is determined
by system inputs and usage. The system inputs influence whether
existing faults are encountered.

General Definition: The ability of a program to execute its required

functions accurately and repeatedly under specific conditions for a set
duration.

Software Reliability Models:

Software reliability models define software defects and failures as a
function of time to determine reliability. They operate on the assumptions
that:

Failures occur independently of each other.

Inputs are random samples.

Failure intervals are independent, and all software failures are observed.

Time between failures is exponentially distributed.

The following formula calculates the cumulative number of defects found at

a specific time:
D(t) = Td (1 – e –bct)
Where:

D(t) represents the total number of defects observed at time "t."

Td represents the total number of defects.

"b" and "c" are constants derived from the historical data of similar
software.

The mean time to failure (MMFT) can be calculated as follows:

MTTF(t) = e bct / c Td
Software Quality Standards

213 - Software Eng. 57

 Software quality standards provide a framework for organizations to
develop and maintain high-quality software. Standards ensure that
organizations adopt a uniform approach to software engineering tasks,
ultimately leading to improved products and processes. There are
numerous standards for software quality and software quality assurance.
One widely recognized set of standards is the Software Engineering
Institute Capability Maturity Model Integration (SEI-CMM). The SEI-CMM
helps organizations improve their software processes by providing a
framework for assessing their maturity level. Each maturity level consists of
specific practices and goals that contribute to overall software quality. The
SEI-CMM levels range from Level 1 (Initial) to Level 5 (Optimizing).

At Level 1, the organization's software process is typically ad hoc and

reactive, with success often dependent on individual efforts.

Level 2 focuses on managing software projects through basic project

management practices.

Level 3 emphasizes well-defined and documented software processes.

Level 4 utilizes quantitative metrics to track productivity, processes, and

product quality.

Level 5 represents the highest maturity level, where organizations

prioritize continuous process improvement.

Another important standard is ISO 9001:2000, which outlines requirements

for quality management systems. Unlike SEI-CMM, which focuses on
software process maturity, ISO 9001:2000 provides a generic standard
applicable to various organizations, including those that provide software
services. Achieving ISO 9001:2000 certification indicates that an
organization adheres to a well-documented and established process but
doesn't guarantee high-quality products.

The sources also provide a table listing various software quality standards
and their titles, including standards from ISO/IEC and IEEE. These standards
cover a wide range of aspects, such as software life cycle processes,
product quality, risk management, and software quality assurance plans.

213 - Software Eng. 58

 Security Engineering
Security engineering is essential during software development to create
secure software that can withstand attacks. A crucial aspect of security
engineering is analyzing software security requirements, which involves:

Eliciting security requirements

Developing a security policy

Designing security measures

Performing security checks throughout the software development

lifecycle

During project planning, identifying and analyzing security risks is crucial.

One approach to understanding potential security threats is creating a
threat model. A threat model typically involves:

Identifying assets

Creating an architecture overview

213 - Software Eng. 59

 Decomposing the application

Identifying threats

Documenting threats

Rating threats

Security is paramount in various domains, including social media, mobile

applications, Internet of Things (IoT) applications, and cloud-based
applications.

213 - Software Eng. 60