INSTRUCTIONAL

MATERIALS IN SOFTWARE
ENGINEERING-1

Abstract
A compilation of instructional materials on the different topics in software engineering. It is
divided into units that contain reading materials and assessment questions or activities to meet
the specified learning objectives per unit.

Mary Jane Magno-Tan

mjmtan@pup.edu.ph
 TABLE OF CONTENTS

Unit 1. Understanding Software

Unit 2. Understanding Software Engineering
Unit 3. Software Process Models
Unit 4. Project Management
4.1 Understanding Software Project Management
4.2 Project Scheduling
4.3 Analyzing the Project Network Diagram
4.4 Software Metrics
4.5 Project Resource Estimation
4.6 Project Risk Management
Unit 5. Software Analysis
5.1 Problem Analysis
5.2 User Requirement Analysis
5.3 Software Specification
Unit 6. Software Design
Unit 7. Design Implementation
Unit 8. Software Testing
Unit 9. Software Maintenance and SCM
 1. SOFTWARE AND SOFTWARE PRODUCTS

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Explain the nature of software
➢ Classify software according to its category, sub category, and application
➢ Describe the desirable software capabilities

OVERVIEW:
The concept of software as a computer program was established by Allan Turing in the 1930s while the
word ‘software’ was coined by John Tukey in 1958. A computer program is defined as a set of written
instructions that perform certain tasks on computer hardware. However, software lacks usability without
accompanying documentation such as user manuals, installation procedures, and operating manuals.
These documents are written mainly for the target users of the software and are therefore written in a
user-friendly language. Thesesoftware are developed, reviewed and maintained by software
professionals who also need accompanying documentation such as specification, design and testing
documents. Therefore, software consists of computer program and its related documentation.

READING MATERIALS:
Software is a computer program and all documentation necessary to develop, install, use and maintain
a complete software system. Therefore, software includes computer programs, procedures, rules and
possibly associated documentation and data pertaining to operation of a computer system such as:
➢ Requirements Documents
➢ Design Specifications
➢ Source Code
➢ Test Plans
➢ Operating Manuals
➢ Quality Assurance Procedures
➢ Software Problem Reports
➢ Maintenance Procedures
➢ User's Manuals
➢ Installation Instructions/Procedures
➢ Training Aids
Types of Software Products Developed
➢ Generic Products. These are stand-alone systems, which are produced by development
organization and sold in the open market to any customer who is able to buy them. Examples are:
• Databases
• word processors
• drawing packages
• project management tools.
➢ Customized Products. These are software projects, which are commissioned by a particular
customer and developed specially by a software contractor. Examples are:
• systems for electronic devices
• air traffic control systems
• systems written to support a particular business process like Payroll, Accounting, etc.

Categories of Software
➢ System Software. These are software that deal with interfacing with hardware; and provide
services to other programs; It is characterized by heavy interaction with computer hardware,
resource sharing, multiple users, complex data structures and multiple external interfaces.
Examples are:
• operating systems
• language compilers
• editors
• assemblers
• device drivers
• debuggers
• OS components
• file management utilities
• IDE's
• networking tools

➢ Application Software. These are also referred to as end user software. These are further
categorized into the following applications:

• Real-time Systems. It monitors/analyzes/ controls real-world events as they occur and

responds within strict time constraints. Examples are CAD/CAM, electronic billboard,
barcoding system, air traffic and missile control systems, telephony software, industrial
plant monitoring and control, network firewalls and intrusion detection systems.
• Business Software. It restructures existing data in a way that facilitates business
operations or management decision-making. Examples are Transaction Processing
systems, Point-of-Sale Systems, Management Information systems, Executive
Information System.
• Engineering and Scientific Software. It is characterized by number-crunching
algorithms. Examples are software for astronomy, volcanology, space shuttle orbital
dynamics, molecular biology, and engineering.
• Embedded Software. It resides in read-only memory and is used to control products and
systems for the consumer and industrial markets. This software can perform very limited
and obscure functions such as keypad control for microwave oven, or provide significant
function and control capability such as digital functions in automobile like fuel control,
 dashboard displays, braking systems. Other examples are Barcode, BIOS, IC in electronic
parts.
• Intelligent Systems. It makes use of non- numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Areas of
Artificial Intelligence include Expert Systems, Intelligent CAIs, image and voice
recognition, theorem proving, game playing, neural networks, robotics, mobile agent
systems, business intelligence and decision support, and mining software.
• Games and Entertainment. Games for handheld devices such as mobile phones, stand
alone PC, and distributed collaborative games.
• Modeling and Simulation. Computer based training systems in the formof modeling and
simulation packages for military, financial, medical, educational and training uses.
• Productivity Tools. These help users execute tasks with ease and maximum productivity
like CAD software, word processors, project management software, data management
software, distributed collaborative software and CASE tools for software developers.
• Web-based. Applications that include content management software, web publishing, e-
commerce software, web services, web portal, web browsers.
• Educational. Applications that include school management system, online and distance
learning, training management, and educational software for children.
• Multimedia. Applications that include software for video, image and sound editing and
management, 3D and animation, virtual reality.

Attributes of Quality Software

The software capabilities determine the overall quality of the software product, although there is no
quantitative assessment of such overall quality. Quality software satisfies the needs of both the users
and developers. The features that concern the developers are flexibility, interoperability, maintainability,
portability, reusability and testability. The features that are more relevant to the users are availability,
correctness, efficiency, integrity, reliability, scalability, usability. The challenge for software engineers is
to produce high quality software using a finite number of resources and within a predictable amount of
time.

User-centered Software Capabilities

➢ Availability. Is the degree to which the software system is available when its services are
required. It is computed as the ratio of the actual availability of the software services to the
expected availability during the same period.
➢ Correctness. Is the degree to which the software meets its requirements specifications.
Factors for correctness are completeness, consistency, traceability and accuracy.
➢ Integrity. Is the degree to which the software system prevents unauthorized access to
information or programs. Both integrity and availability contribute to the security of the
software system.
➢ Efficiency. Is the degree to which the software system performs its functions using the least
amount of computational and memory resources. Efficiency includes responsiveness,
acceptable processing time, optimum memory utilization, etc.
➢ Usability. Is the degree of ease with which the software system can be used. Factors for
usability are learnability, readability, understandability, and other quality factors. It includes
having an appropriate user interface and adequate documentation.
 ➢ Reliability. Is the ability of the software system to perform its function under stated conditions
and for a specified period of time. It can be quantified using the mean time between failures.
Factors for reliability are error recoverability and fault tolerance, modularity and simplicity and
other quality factors.
➢ Scalability. Is the ability of the software system to handle a growing number of user requests
up to a certain specified limit.

Developer-centered Software Capabilities

➢ Maintainability. Is the measure of how easily the software system can be modified to fix errors,
to improve its functions, and to adapt to different environments. Factors for maintainability are
adaptability, simplicity, modularity and traceability and other quality factors.
➢ Flexibility. Is the measure of how easily the software system can be extended or expanded.
Factors for flexibility are simplicity, generality, and modularity of the software and other quality
factors.
➢ Interoperabilty. Is the ability of the software to exchange information with other external
systems.
➢ Portability. Is the ease with which the software system can be moved to a different software
or hardware environment or platform. Factors for portability are generality and modularity and
other quality factors.
➢ Reusability. Is the measure of how easily a software component can be reused in the same
software system or utilized to build new systems. Factors for reusability are generality and
modularity and other quality factors.
➢ Testability. Is the measure of how easily the test cases can be selected and executed to test
the software. Factors for testability are modularity, simplicity and traceability, and other quality
factors.

These desirable software capabilities are included in the metrics for evaluating software quality based on
international standard such as the ISO 9126.
See ISO9126 software quality characteristics http://www.sqa.net/iso9126.html.

SUMMARY:
To sum it up, software includes not just the source code but all items and documents associated to its
creation and implementation. Regardless of its use and application, quality software is written in a way
that it should be efficient, usable, maintainable, effective and dependable. Developing quality software is
therefore a great challenge to any software developer.

ASSESSMENT:
1. List down the software you use in your daily tasks at home and school and specify its category
and sub category.
2. For each software in your list, describe its desirable characteristics.
 2. UNDERSTANDING SOFTWARE ENGINEERING

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Describe what is software engineering
➢ Explain the need for software engineering
➢ Describe software engineering as a discipline

OVERVIEW:
Software Engineering is a term introduced by Friedrich Bauer during the 1968 NATO Software
Engineering Conference in Germany and was defined as the application of a disciplined approach for the
development and maintenance of computer software. This implies that the term ”engineering” is
synonymous to “a disciplined approach”. However, there are many definition of software engineering.
According to the Institute of Electrical and Electronic Engineers (IEEE), software engineering deals with
the establishment and use of sound engineering principles to economically obtain software that is reliable
and works efficiently on real machines. Software engineering is therefore defined as a technological and
managerial discipline which uses engineering principles in the development, creation and maintenance
of software. Engineering in general, applies scientific, mathematical, economic, social and practical
knowledge in the design and construction process. It encompasses the use of tools, techniques, and
methods that are useful during the execution of the steps needed for the development and maintenance
of the product being engineered. Software engineers use methods and theory from computer science
and apply this cost effectively to solve difficult problems in the development and maintenance of software
systems. There are several tools available to software developers that aid in facilitating the development
and maintenance of software systems.
Image created by Subedi extracted from IPTC Photo Metadata

READING MATERIALS:

Need for Software Engineering

Large and complex software systems built by teams of developers require engineering approach. But
even simple software systems have high inherent complexity and changing requirements that pose as a
challenge in the development of software that meets the capabilities expected by both the users and the
developers; so engineering principles that utilize tools, techniques, and methods have to be applied to
achieve high-quality software.
Producing software in a cost-effective way is a major challenge for the modern economy because there
are numerous problems which afflict software development. Aside from the challenge of developing a
quality software, this is another reason for the need to study software engineering.
Problems Which Afflict Software Development
➢ Customer dissatisfaction with the completed system is frequently encountered. Software
development is undertaken often with only a vague notion of customer's requirements.
➢ Software quality is inadequate. Often there is no systematic, complete software testing and
only recently have solid quantitative concepts of software reliability and quality assurance begun
to emerge.
➢ Existing software can be difficult to maintain. Although software maintenance accounts for
the majority of all software budgets, software maintainability has not been emphasized as
important criteria for software acceptance.
➢ Schedule and cost estimates are inaccurate. People in-charge of managing the software
project (Project Manager) lack the competence and tools in arriving at accurate project cost and
schedule, resulting to projects running over budget and time, and not delivering a functioning
product.
➢ Productivity of software people is low VS demand or service. Often, the software
development staff is engaged in other projects or works where their expertise and effort is
required.

Software Development Myths

There are myths or generally accepted incorrect notions on software development that every software
engineer or student of software engineering, should be aware of. Read
https://users.csc.calpoly.edu/~jdalbey/205/Lectures/myths.html. See also https://onix-systems.com/blog/10-
common-software-myths-dispelled.

There is a need to study and practice software engineering for the following reasons: (1) to be able to
meet the different capabilities that define software quality, (2) to address the problems which afflict
software development, (3) and to address the painful truths behind the prevailing software development
myths.

It was mentioned previously that software engineering is a managerial and technological discipline. As a
discipline, it deals with complexity in a staged manner; it ensures that errors are detected and dealt with
early in the process; and it involves gaining a better understanding of the software being developed thru
modeling. These disciplined approaches are discussed below:

Generic View of Software Engineering: A Disciplined Approach

Software engineering encompasses the use of a disciplined and systematic approach for the
development and maintenance of computer software to be able to deal with the software complexities, to
increase the reliability, and enhance the quality of the produced software. A disciplined approach deals
with complexity in a staged manner in which the initial stages tackle the software in different phases and
at higher levels of abstraction. The subsequent phases tackle software at lower levels of abstraction by
providing more details. This is called top-down and stepwise refinement.
The three (3) generic stages in software development are Definition, Implementation, and Maintenance.
These are encountered in all software development regardless of application area, project size, or
complexity.
Stage 1: Definition
This stage focuses on question “what?”. The key requirements of the system and the software are
identified by asking the following questions:
➢ What information is to be processed?
➢ What functions and performance are desired?
➢ What interfaces are to be established?
➢ What design constraints exist?
➢ What validation criteria are required?

Phases in Definition Stage

1. Requirement Phase. Provide detailed definition of the information domain and function of the software
such as defining the required input and output information. These requirements are collected from system
users with the use of information gathering techniques.
2. Specification Phase. Collected requirements are analyzed to obtain a formal software specification.

Stage 2: Implementation
➢ This stage focuses on the question “how?”. The following questions are asked:
➢ How data structure and software architecture are to be designed?
➢ How procedural details are to be implemented?
➢ How the design will be translated into programming language?
➢ How testing will be performed?

Phases in Implementation Stage

1. Design Phase. Refines the specifications to obtain a basis for a concrete implementation of the
software; Describes data structure, architecture, algorithmic procedure, and interface characteristics
2. Coding/Implementation. Design representations are translated into an artificial language.
3. Testing. Perform test to uncover defects in function, in logic, and in implementation.

Stage 3: Maintenance
This stage deals with software change requests to correct software errors, adapt to evolving environment,
or expand the software.
Phases in Maintenance Stage
1. Corrective. Changes the software to correct defects.
2. Adaptative. Modifies the software to accommodate changes to its external environment.
3. Enhancement. Extends the software beyond its original function requirements. Changes here are
termed as “perfective maintenance”
The phases involved in software engineering are analogous to those phases used in building engineering.
These phases include requirements specifications, design, construction, testing (pre-delivery approval),
and maintenance. The only difference lies in the fact that software does not change over time. Software
maintenance is warranted due to changes in technology or environment. In contrast, buildings wear out
or degrade over time due to environmental maladies.

Software Development Error Detection: A Disciplined Approach

A disciplined approach to software development should ensure that errors are detected and dealt with
early in the development process. Spending more time early in the process helps reduce the cost of
software maintenance in the long term. Software errors can be traced back to the various phases of the
software development phases. These are:
➢ Requirements and Specifications Errors. Include incorrectly captured or missing requirements,
incomplete functions or features, and input/output domain specifications. Majority of the errors
encountered are committed during this phase and failure to discover these errors early lead to
expensive maintenance, project failures and serious problems such as loss of lives for safety-
critical systems.
➢ Design Errors. Include errors in the specification of the algorithms and their related data
structures.
➢ Coding Errors. Include memory access violation, buffer overflows, arithmetic overflow or
underflow, loss of precision, typographical errors, or dataflow-related errors.
➢ Integration Errors. Include parameter mismatches, run-time stack errors, compatibility errors,
interoperability problems, and timing and synchronization problems,
➢ Data-related Errors. Include errors in data definition, input file data, and data access and
handling. This error is also more frequently encountered.
➢ Testing Errors. Involve erroneous test cases leading to the wrongful flagging of an error or the
misinterpretation of the test results, and thus, reaching an incorrect test verdict.

Understanding Software Behavior, Structure, and Architecture: A Disciplined Approach

A disciplined approach to software development involves gaining a better understanding of the software
being developed. To do this, the behavioral, structural, and architectural issues of the software must be
modeled and analyzed.
The fixed set of instructions that makes a program provides the static structure of the software. This
aspect of the software can be modeled at different levels using different tools such as flowcharts at the
implementation level, structured chart or class diagram at the design level, and use case diagrams at the
requirements specification level.
When subjected to internal events from timers and interrupts or external inputs from other systems,
devices, or users, the software behaves according to the behavioral specification by changing its internal
state and by triggering the appropriate internal or external events. The reaction of the software to the
various events depends on the state at which the software exists when the event occurs. All possible
software reactions determine the behavior of the software, and reflect the dynamic aspects of a software
system. Software behavior can be modeled by state diagram, sequence diagram, timing diagram, activity
diagram and Petri Nets.
Finally, the architectural aspect of software addresses some of the non-functional issues such as
robustness, performance, resiliency, and security. One of the main reasons for software failure is the
misunderstanding or the lack of handling of the non-functional requirements affecting the software
architecture. Software architecture can be modeled by package and component diagrams.
These diagrams or tools that model the structure, behavior and architecture of software are discussed
in detail in the chapters dedicated for software analysis and design.
For an overview of these diagrams, see https://www.process.st/uml-tutorial/ and
https://www.smartdraw.com/uml-diagram/ .

SUMMARY:
Software engineering is a disciplined approach for the development of high-quality software products
given both time and budget constraints. This disciplined approach consists of techniques, methods,
standards, guidelines, and practices that can be used during the software development process. The
challenge of achieving high-quality software is one of the reasons for studying software engineering.
Software development myths and problems that afflict software development can be addressed by the
study and application of software engineering principles.

ASSESSMENT:
1. Are there software that are not engineered? Give an example.
2. Explain why is there a need to engineer software.
3. Cite tools that are used to facilitate the software engineering process.
4. Explain what is a disciplined approach in software engineering.
 3. SOFTWARE DEVELOPMENT PROCESS MODELS

LEARNING OBJECTIVES:
➢ Describe software development life cycle models and their importance
➢ Explain the difference and similarities between the linear, iterative and evolutionary models
➢ Describe the phases, activities and deliverables of each process model
➢ Identify pre-development and ongoing life cycle activities
➢ Explain the role of software process maturity in the adaptation of process model (life cycle
strategy)

OVERVIEW:
The three cornerstones needed to produce a successful software product are people, projects, and
processes. Processes are part of a software life cycle model or methodology. Project tasks and processes
that are defined in a project schedule are developed based on the adopted process paradigm/model
or the methodology. These processes guarantee that the software product developed possess good
qualities. Failure in the selection and adoption of the most relevant or best-fit process model and software
development methodology affects the quality of the delivered project. Therefore, to manage software
activities and increase the quality of software developed, industry-proven models for software
development and maintenance must be selected, adopted and followed. These software engineering life
cycle models provide systematic and well-structured approaches and are often supported by tools that
facilitate their effective use. Depending on the size of the adopting organization, its maturity level, and
the complexity of the software to be developed, a life cycle model can be tailored to suit the particular
needs of the organization and its development team.

READING MATERIALS:

Software Engineering Process Models (Life-cycle Models/Strategies)

A process model (paradigm/strategy/method) for software engineering is chosen based on the nature of
the project and application, the methods and tools to be used, and the controls and deliverables required.
Regardless of the software engineering model chosen, the software development process contains the
three generic stages (Definition, Implementation, Maintenance) earlier defined. The software engineering
phases that include several processes can be modeled through these paradigms which can be classified
into three major categories:
1. Linear Models and Variants
Classic System Development Life Cycle (SDLC) or Waterfall Approach. Because of the cascade
from one phase to another, this model is known as the `waterfall model' and sometimes called the
Software Life Cycle, and also known as the Linear Sequential Model. It demands a systematic,
sequential approach to software development that begins at the system level and progresses through
analysis, design, coding, testing, and maintenance. The principal stages or phases of the model
mapped onto the fundamental product activities are:
 1. Analysis. In this stage, the system services, constraints and goals are established by
consultations with the system users. The main activities include definition of requirements,
definition of various interfaces between external entities and software functions to be
developed, and prioritization of identified software requirements. These requirements are
analyzed and represented before proceeding to other processes. The output of this phase is
the Requirements Specification Document. Other deliverables for this phase include
acceptance test plan document, scope and vision document, and revised project plan.
2. System/Software Design. This establishes an overall system architecture, where a solution is
planned for the problem specified in the requirements document. Activities in this phase
include high-level architectural design, database design, interface design, and detailed
designs. The main deliverables include the high-level design and detailed design documents
termed as Design Specifications Document. High-level design focuses on the identification of
software modules and their interfaces while detailed design provides details on each of the
modules identified in the high-level design, such as data structures and algorithms needed to
implement each module. Based on the data model described in the Requirements
Specifications Document of the Analysis Phase, the database design presents a detailed
description of the database schema needed to support the high-level and detailed design. The
interface design consists of design of graphical user interface components and all interfaces
between the system and other hardware/software systems, components, and devices. All
these designs can be verified by building executable design models or prototypes.
3. Implementation. The system and software design is translated into set of programs or program
units (executable code) using a suitable programming language. The database design is
implemented and properly integrated with the produced code and if required, created
database is populated with initial data.
4. Testing and Integration. The test plans previously developed are executed. The individual
program units or programs are tested (Unit Test), then these are tested as a complete system
(Integration and System Test) to ensure that the software requirements have been met.
Testing is called validation when performed against the original requirements. When
performed against design specifications, it is called verification. Obtained test results are
analyzed and errors are dealt with accordingly, resulting to the deliverable of this phase which
is the integrated software.
5. Operation and Maintenance. The system is installed and put into practical use, based on
previously developed installation and deployment plan. The client/users test the system's
usability and applicability based on the previously developed acceptance test plan. The
deliverables of this phase are the official acceptance document signed by the client and the
properly installed software system. After acceptance of the software, users begin invoking
software functions or services.

Characteristics:
• Project development phases are sequential and generally one- way
• Deadlines are determined very early in the project
• Required project results are completely and unambiguously determined
• A milestone document suite concludes each project phase that when approved, signals the start
of subsequent phase
• May be applied to large and small projects
• Ideal when resources are available
• Applicable when standard procedures are fully documented
Advantages:
• Divides a large and/or complex task into smaller, manageable tasks
 • Every project can be carefully planned
• Authorities and responsibilities can be clearly delineated
• Clear and distinctive phases, each phase with well specified inputs, deliverables, and
milestones allow management to assess project progress and take corrective action if
necessary
• Easy to apply and understand
• Large amount of detailed documents reduce future maintenance cost

Disadvantages:
• Real projects rarely follow the sequential flow that the model uses since it does not reflect the
problem-solving nature of software development that leads to rework and iterations
• It is often difficult for the customer to state all requirements explicitly.
• A working version of the system will be available late in the project life cycle; it takes too long to
see results
• Inherently linear sequential nature discourages late changes
• It depends on stable and correct requirements; a major product blunder can be disastrous
• Amount of documentation can be excessive
• Linear sequential nature may lead to "blocking state"

Figure 2.1 The Waterfall Model

The main drawback of the waterfall model is the difficulty of accommodating change after the process is
underway. One phase has to be complete before moving onto the next phase. For example, if during the
design phase, an ambiguity in the software requirements is discovered, the designer has to report this
error to the manager, and the analysis team has to deal with this ambiguity. Ignoring this error during the
design might have severe consequences, including higher repair cost to deal with the same error in the
future.
Fountain Model. It is a variant of the waterfall model where "water can flow upwards". The model
recognizes that iteration to previous phases may be necessary. This is the more realistic software
 development model which is more iterative in nature, allowing the revisiting of preceding phases if
necessary. For example, while in the coding phase, the programmer might discover a flaw in the
detailed design. This flaw is reported to the designers who will take appropriate actions to address
the error. It is a more realistic model than waterfall but is more difficult to control, hence the need for
change control procedures.

Figure 2.2 The Iterative Waterfall or Fountain Model

The Rapid Application Development(RAD) Model. It is a linear sequential software development

process model that emphasizes an extremely short development cycle achieved by using a
component-based construction approach. Each major function in a project can be addressed by a
separate RAD team and then integrated to form a whole. It encompasses the following phases:
1. Business Modeling. The information flow among business functions is modeled in a way that
answers the following questions: What information drives the process? What information is
generated? Who generates it? Where does the information go? Who processes it?
2. Data Modeling. The information flow defined as part of the business modeling phase is refined
into a set of data objects that are needed to support the business. The characteristics( attributes)
of each object are identified and the relationships between these objects are defined.
3. Process Modeling. The data objects defined in the modeling phase are transformed to achieve
the information flow necessary to implement a business function. Processing descriptions are
created for adding, modifying, deleting, or retrieving data object.
4. Application Generation. RAD assumes the use of fourth generation techniques. Rather than
creating software with the use of 3rd generation programming languages, the RAD process works
to reuse existing program component or create reusable components, and automated tools are
used to facilitate construction of the software.
 5. Testing and Turnover. Since the RAD process emphasizes reuse, many of the program
components have already been tested thus reducing overall testing time. However, new
components must be tested and all interfaces must be fully exercised.

Problems With RAD

• For large, but scalable projects, RAD requires sufficient human resources
to create the right number of RAD Teams.
• It requires customers and developers who are committed to the rapid-fire
activities necessary to complete a system in a much shorter time frame,
otherwise, the project would fail
• It is not appropriate in the following cases: (1) when system cannot be
properly modularized, (2) when high performance (which is achieved
through tuning the interfaces to system components) is an issue, (3) when
technical risks are high, like when new software requires high degree of
interoperability with existing computer programs or new technology.

Other linear life-cycle strategies customized for specific organizations include (1) Model Systems Ltd
used by NCC-UK, (2) Foundation used by Andersen Consulting, and (3) Structured Project Life-cycle
used by Yourdon group.

2. Iterative or Prototyping
It is a process that enables the developer to create a model of the software prototype that must be built
to be able to understand customer requirements before delivering the final system. The process proceeds
in the form of iterations. In every iteration, a prototype is created based on initial customer requirements.
A prototype is an executable program that mainly implements the functional aspects of the software being
developed that are related to the graphical user interface. For every iteration from the prototype onwards,
the customer gives feedbacks about the model, and this continues until the customer is satisfied with the
model developed. This model can be:
• A PC-model that depicts human-machine interactions
• A working software that implements a subset of the functions required of the system, or
• An existing program that performs all or parts of the functions desired but will be improved
in the development effort.

Characteristics:
• Development starts with incomplete requirements
• Full requirements are derived from user interaction on a prototype
• There are three types, depending on the amount of code retained in the final system:
1. Prototyping with disposable system – tests the adequacy of
proposed solution; requirements are formalized after they are
sufficiently determined through reactions on prototypes; prototypes
are disposed after formalizing requirements then further
development is done according to linear sequential model
2. Prototyping with working system – A prototype of most critical
functions is built; after acceptance, the prototype is extended to a
working system
 3. Evolutionary – prototype adapts to changing requirements;
subsequent prototypes of the systems evolve to the eventual
operational system; prototype is used for deployment
• Ideal for systems where requirements may be defined but human- computer interface
suitability( user's response) is not yet known
• Useful when developing a system the developer has not known/seen before

Advantages:
• System requirements do not have to be uniquely determined
• System requirements can be changed during the project
• Delivers clear and understandable system definition and specifications to the end user;
more effective to gather requirements
• Enhances communication regarding suitability of human- computer interfaces; Increases
end user involvement and satisfaction
• Development environment can be tested quickly
• Can be used to demonstrate technical, economic, and political feasibility

Disadvantages:
• Rising expectations of the end user. The user sees what appears to be the working version
of the software unaware that overall software quality and maintainability has not been
considered, so that customer demands just a few fixes for the product to be completed
into a full working system.
• Danger of never-ending development because of user-developer interactions during
development
• Danger of neglecting planning, verification, validation, backup procedures and
documentation
• Danger of modeling before sufficient analysis of the current and desired results
• Danger of making design and implementation compromises in order to get a prototype
working quickly
• Building on top of the prototype frequently leads to software project failure and therefore
should be avoided unless it is an accurate reflection of customer’s desires

Prototyping could be used as a tool to see how users respond by clarifying requirements and desirable
features to explore alternative design possibilities, or by testing the adequacy of the proposed solution.
This can address one of the weaknesses of the Waterfall Model wherein reliance on written
documentation for the description of requirements might be inappropriate for user-centered systems, and
wherein approved written requirements are volatile and subject to numerous revisions and changes later
in the development process. Prototyping the requirements by building a visual and executable model is
considered to be an effective way to review and approve requirements, and therefore reduces the risks
of requiring changes after approving the requirements, leading to fewer revisions and iterations during
software development.

3. Evolutionary Model
This iterative approach enables software engineers to develop increasingly more complete versions of
the software. The starting point of the evolutionary software process model is the problem domain that
 needs to be solved by means of a software system or a manual system that needs to be automated.
The evolutionary software process has the following steps: (1) A clear delineation of the functional
boundaries of the desired system is first set; (2) Then the desired system is split up into Microsystems;
(3) The microsystem is developed and put into production in 6 months or less; (4) Long term goals and
planning are reassessed and subsequent microsystems are adjusted if necessary. Steps (3) and (4)
are repeated until planned system is realized.
Characteristics:
• Product-oriented instead of project-oriented
• Iterative approach – every system goes through all the phases(from analysis to integration)
• Continuous testing and re-planning based on long term goals

Advantages:
• Developers see the results faster
• End users and management get fast response and see the product evolve
• Fast reaction to changed goals
• Better manageability of the development process through: (1) incremental construction (2)
continuous control of the system

Disadvantages:
• No recursion to previous microsystem is scheduled
• Changing environments might obliterate long-term goals
• Could be costly

Examples of the evolutionary development approach are the:

Incremental Model. This model combines elements of the linear sequential model with the iterative
philosophy of prototyping Each linear sequence produces a deliverable "increment" of the
software[McDE93] . The first increment is often the core product where basic requirements or high-priority
requirements are addressed but many supplementary features remain undelivered. After the core product
is used and evaluated by the customer, a plan is developed for the next increment or release, perhaps
containing the medium priority requirements, which addresses the modification of the core product and
the delivery of additional features and functionality. This plan is repeated following the delivery of each
increment, containing low priority requirements, until the complete product is produced.
Advantages:
• Operational product is produced with each intermediate progress/version
• Risk of failure and changing requirements is reduced
• User can adjust to new technology in incremental steps

Disadvantages:
• Lack of process visibility; cannot determine how far the product is from the final
version
• Systems are often poorly structured
• Special skills(e.g. in languages for rapid prototyping) may be required
 Recommendation:
• Applicable for small company in growing stage
• Good only for small company in a growing stage
• Useful when budget is limited / critical
• Requirements should be clearly defined
• Releases should be carefully scheduled
• Produce specifications document before coding

Figure 2.3 The Incremental Model

This incremental approach is useful when technical requirements or staffing is unavailable for a complete
implementation by the business deadline that has been established for the project.

Spiral Model. This model couples the iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model. Software is developed in a series of incremental releases. The
model is divided into typically three or six framework activities, also called task regions: (1) Customer
communication – tasks required to establish effective communication between customer and developer
(2) Planning – tasks required to define resources, timeliness, and other project related information (3)
Risk Analysis – tasks required to assess both technical and managerial risks (4) Engineering – tasks
required to build representations of the application (5) construction and release – tasks required to
construct, test, install and provide user support (6) Customer Evaluation – tasks required to obtain
customer feedback based on evaluation of software representations created and implemented. Each
pass through the planning region results in adjustments to the project plan while cost and schedules are
adjusted based on feedback derived from customer evaluation. The customer and developer better
understand and react to risks at each evolutionary level where prototyping could be applied at any stage
of the evolution. This model demands and relies on risk assessment expertise for success. It is
characterized with many throw-away prototypes as a risk reduction mechanism. These prototypes may
or may not be required in each phase.
Advantages:
• Splits a potentially large development effort into small chunks in which critical, high-risk
functions can be done first
• Takes advantage of incremental release, cumulative costs may be assessed
• Rapid application development can be used (through 4th Generation tools)
 Disadvantages:
• Model is complex, and may be too complicated and costly to use (many intermediate stages)
• No clear, distinct phase – can prove to be difficult to manage (because of high integration
of phases)
• Additional internal and external documentation are needed to follow up the large number of
intermediate stages

Recommendation:
• Ideal for large scale systems and never for small projects (because its is too costly)
• Applicable in the following situations:
- There is too much risks involved
- Procedures and technology are dynamic (due to environmental
factors)
- There is lack of expertise/knowledge
- The system could be broken down into sub-systems

Figure 2.4 The Spiral Model

The Spiral Model addresses the weakness of the Waterfall Model because phases of the Waterfall Model
do not include any reference to risk management. Formal and continuous consideration of risks
embedded within the software development process contributes to enhancing the quality of software, and
contributes to successful completion of the software project leading to complete and correct product
functionalities developed within the given budget and time constraints. This model is relatively new and
has not been widely used.
Concurrent Development Model. This model, sometimes called Concurrent Engineering allows
tracking of status of extremely complex sets of activities especially those that occur at the same time
during any one phase. It can be represented schematically as a series of major technical activities, tasks,
and their associated states. It defines a series of events that will trigger transitions from one state to state
for each of the software engineering activities. Rather than confining software engineering activities to a
sequence of events, it defines a network of activities that exist simultaneously with other activities. This
model is often used as a paradigm for the development of client/server applications although it is
applicable to all types of software development and provides an accurate picture of the current state of
the project.

4. Other Models
Other models for software engineering exists, some of which may be integrated into the other mainstream
models:

Fourth Generation Techniques. It encompasses a broad array of software tools that enables the
software engineer to specify some characteristics of software at a high level. These tools include some
or all of the following: non-procedural languages for database query, report generation, data
manipulation, screen interaction and definition, code generation; high-level graphics capability;
spreadsheet capability. It focuses on the ability to specify software using specialized language forms or
a graphic notation that describes the problem to be solved in terms that the customer can understand.
For small applications, it may be possible to move directly from requirements gathering step to
implementation using a nonprocedural fourth generation language (4GL). Advantages of this paradigm
include dramatic reduction in software development time and greatly improved productivity for people
who build the software. When coupled with component assembly approaches, the 4GT paradigm may
become the dominant approach to software development. However opponents claim that the resultant
source code produced by such tools are "inefficient" and that the maintainability of large software systems
developed using 4GT is open to question and demands as much or more analysis, design, and testing
to obtain the substantial time saving that can be achieved through the elimination of coding.
Object-oriented Model. This model is centered on the object concept in software systems. It consists of
four phases: (1) Analysis; (2) design; (3) implementation; (4) testing. Analysis starts by identifying the
types of objects needed in the software system to cover all the requirements. Objects used to build the
analysis model can be physical or logical real-life objects. Objects are then identified, together with their
respective attributes and visibilities. For each object, methods that are needed to create, define, modify,
and destroy an object are identified. Then, object relationships are defined. The three main types of
relationships among objects are communication, inheritance, and aggregation or composition. The
communication relationship indicates that one object is sending a message to the other object, normally
to change or enquire about the state of the object. The inheritance relationship indicates that one object
expands the attributes and methods of the other object. The aggregation relationship states that one
object is made of one or more objects in the analysis model. After defining relationships among objects,
methods for object communications are then identified. Also, the sequencing of interactions between the
external users and systems and the software system to be developed is specified. Design starts with
identifying classes and their interrelationships from the given analysis model. A class is a template from
which an object is created. Classes can either be (1) entity – real-life physical and logical objects that
need to remain in persistent store, (2) interface – used to define and manipulate graphical user artifacts
and components needed to interface between the software and its external users and interacting
systems, (3) behavior or control - methods that are needed to encode the business logic that manipulates
entity objects through interface objects. Once completed, the design is mapped to an implementation
using an object-oriented programming language. Object-oriented testing and integration techniques are
then used to test the implementation and integrate it with other components and systems.
Characteristics of this model are the following:
• Reduced maintenance since most of the processes within the system are encapsulated, the
behaviors may be reused and incorporated into new behaviors
• Real-world modeling is more understandable because the model is based on objects (where
objects are organized into classes of objects, and objects are associated with behaviors),
rather than on data or processing.
• Improved reliability and flexibility because new behaviors can be built from existing objects
(through instantiation and inheritance) without affecting existing system functions
• High code reusability since a new object created will automatically inherit the data attributes
and characteristics of the class from which it was spawned and from all super classes
from which it participates
• Best suited for dynamic, interactive environments such as engineering design systems and
CAD/CAM

Component Based Development Model. This object-oriented paradigm incorporates many of the
characteristics of the spiral model but composes applications from prepackaged re-usable software
components sometimes called "classes". These components (classes) created in past software
engineering projects are stored in a class library or repository and later extracted. Candidate class not in
the library is engineered using object-oriented method. This model leads to software reuse that provides
software engineers with a number of measurable benefits such as reduction in development cycle time,
project cost and increase in productivity index. The unified software development process is
representative of a number of component-based development models that have been proposed in the
industry. Using the Unified Modeling Language(UML) , the unified process defines the components that
will be used to build the system and the interfaces that will connect the components. Using a combination
of iterative and incremental development, the unified process defines the function of the system by
applying a scenario-based approach (from the user point of view). It then couples function with an
architectural framework that identifies the form that the software will take. This is an iterative model with
static framework or architecture.
Characteristics of the model are:
• A project plan is a plan of contingencies rather than a plan of actions
• It has four(4) phases:
Inception – shared understanding between developers and users
Elaboration – a framework architecture is produced
Construction – UML is used to construct the system
Transition – system implementation
• It has two forms of modeling:
1. Architectural - a static model or architecture which is developed during elaboration
2. Structural – dynamic model where the requirements in each iteration will be used
for construction
• It is well-matched to Object-oriented Programming(OOP)
Recommendation:
• Useful when present system is not tied to the new system
• More applicable when replacing a system rather than converting to a higher version
• Applicable when users are open to object-oriented language / representation and the
development team is object-oriented trained

Formal Transformation or Formal Methods. This approach is based on producing a formal

mathematical system specification and transforming this specification using mathematical methods, to a
program. In contrast to texts and diagram notations, the specifications are done using a mathematical
notation, such as Petri Nets or the Z Notation. Another software (like a compiler) will generate the program
based on the specifications. A variation on this approach, called Cleanroom Software Engineering[
MIL87, DYE92], is currently applied by some software development organizations. This model provides
a mechanism for eliminating many of the problems that are difficult to overcome using other software
engineering paradigms. The formal methods can also be used to verify systems developed in a rigorous
manner using mathematical techniques. Although not yet a mainstream approach, the formal methods
offer the promise of defect- free software and therefore will gain adherents among software developers
that must build safety critical software and developers that would suffer severe economic hardship should
software error occurs.
Concerns on this model are the following:
• Its development is currently quite time-consuming and expensive.
• Extensive training is required because few developers have the necessary background to apply
formal methods.
• It is difficult to use as a communication mechanism for technically unsophisticated customers.

Extreme Programming (XP). This is an early implementation of the agile software development method
which is based on incremental and iterative development, where requirements and solutions evolve
through collaboration between self-organizing, cross-functional teams. It is intended to improve software
quality and responsiveness to changing customer requirements. As a type of agile software development,
it advocates frequent releases in short development cycles (timeboxing) to improve productivity and
introduce checkpoints where new customer requirements can be adopted. Other elements of extreme
programming include: programming in pairs or doing extensive code review, automated unit testing of all
code, regular (i.e. end-of-week)integration testing, avoiding programming of features until they are
actually needed, a flat management structure, simplicity and clarity in code, expecting changes in
customer requirements as time passes by, and frequent communication with the customer and among
programmers. The four basic activities performed in XP are: (1) coding – the only truly important product
is code; (2) testing – every piece of code is tested before moving on to the next feature; (3) listening- to
what the customers need the system to do; (4) designing.
Advantages:
• Addresses problems of project risk by not investing in possible future
requirements that might change before they become relevant
• Manager, developers, users work together very closely with frequent verbal
communications for fast feedback
• Reduce cost of changes in requirements by having multiple short development
cycles
 • Frequent unit, integration and acceptance tests ensure high-quality software
components

Disadvantages:
• For small group of programmers only (between 2-12)
• Unstable requirements
• No documented compromises of user conflicts
• Lack of an overall design specification or document
• Must be able create automated tests (unit and functional)

Recommendation:
• Applicable to small projects only because developers are so empowered(from
analysis to deployment)
• Useful for conversion of projects
• Most applicable for web-based applications
• Well-matched to component-based programming
• Problems should be definable into smaller functions (details are known;
framework defined already) because of bottom-up approach

Some organizations utilize the mainstream models and apply modifications or variations to eliminate
identified weaknesses and adopt the best practices in software engineering.

Pre-development and Continuous Life Cycle Activities

In addition to the well-defined software engineering phases and their deliverables, there are important
and critical activities that must be performed continuously during the execution of the phases. Also called
umbrella activities, they support the proper execution of the development phases and ensure the
production of high-quality software. These ongoing activities are project management, quality assurance,
evaluation and testing, configuration management, documentation, and user-training. In addition,
operations, support, quality assurance, and training activities are continuous activities that are performed
during the post development maintenance phase.
Project Management. The progress of the activities is closely monitored by the project manager using an
appropriate reporting procedure. Risks are continuously monitored and corrective actions are taken,
project schedule is updated as needed, project-and process-related metrics are regularly collected and
assessed, tasks delegation and human resource evaluation activities are performed.
Quality Assurance. Activities are performed by the quality assurance group during each phase and at the
end of each phase, including review of deliverables of each phase, ensuring the use of and conformance
to internal and external standards, maintenance of quality reports and logs, and collection of relevant
metrics. The quality assurance plan is executed and updated as needed. Also, process improvements
are recommended after completion of the project.
Evaluation and Testing. Validation and verification activities are performed along the various product
development phases. At the end of each phase, the phase deliverable is evaluated and tested using
formal and informal processes. Informal processes include reviews that involve walkthroughs,
inspections, and audits. Formal evaluation processes include the use of formal techniques and
automated verification tools such as automated design verification and code testing tools. Formal product
validation techniques and methods can also be used to generate and document effective tests, automate
the validation process, and analyze and validate results. Once the deliverable is approved, the next phase
starts.
Configuration Management. It deals mainly with the management of software resources and the overall
support and control of the software development and maintenance processes. Activities initially include
the (1)identification of all software documents, deliverables, and artifacts that will be produced,
manipulated, and maintained during the development and maintenance of the software. Configuration
control activities such as (2) revision and version control, (3) process and workflow control, (3) build and
change control, are then performed continuously during the software development and post-development
phases. Using an integrated automated configuration management tool, a periodic (4) configuration
management audit and status report is generated, which are then analyzed by the appropriate
management team.
Technical Support and Internal Training. Support technicians help the developers in solving technical
problems that arise while developing the software, to help improve the efficiency and productivity of the
development team. They deal with training of technical staff on the development process, standards to
be followed, or new tools and technologies that are needed during the development phases.
Documentation. During development, various documents that target different audiences are produced.
Internal technical documents are produced for future software maintenance while external documents
are produced for users including user manuals, installation manuals, and operation manuals. Internal
documents are typically written by the software developers while technical writers are involved with the
production of external documents. Standards and standard templates are normally used to guide the
writing of these documents. The documents are evaluated for quality by various stakeholders including
software development team members and representatives of the software quality assurance group.
Operations, Support, and User Training. After installation, software operations are supported by providing
customer helpdesk support, technical assistance, training and consultation. Help desk request logs and
fault report logs are maintained and appropriate metrics are generated. Fault reports are used to trigger
the appropriate maintenance activities.

Software Process Maturity: Factor in Adoption of Process Model

As discussed earlier, organizations adopt and follow industry-proven models for software development
and maintenance. The level and depth of adaptation of a process model depends greatly on the type and
complexity of the application that is to be developed and the maturity of the software development firm.
Maturity assessment methodologies for life cycle models and implemented processes are developed and
used to classify the development organization as well as for the purpose of process improvement.
The Capability Maturity Model (CMM) was developed for the assessment of the development processes
at software development companies. CMM was succeeded by the CMM Integration (CMMI) as a
generalized model to assist in the assessment of the process maturity of different types of organizations
and in various areas such as systems engineering, project management, and supply-chain management.
Although the CMM does not recommend any particular set of mature processes to be followed by an
organization, the CMM however, can be used to assess the maturity of existing processes. As a result of
the process maturity assessment, an organization is placed at one of five maturity levels: (1) Initial, (2)
repeatable, (3) defined, (4) managed, (5) and optimized, the best of which is obviously the optimized
level. The basis for the placement at a particular level is based on the availability of specific process
areas defined for that level.

Image Source: Wikipedia

Level 1: Initial. The processes used are ad hoc, informal and not documented. The knowledge and
experiences are not archived and documented. Project success relies heavily on the efforts of quality
team members. Due to lack of documented development methodologies and experiences, it might be
impossible to repeat success in new projects even of similar types and complexities. Completed projects
in this level are characterized by low quality, numerous errors, and running over time and budget.
Level 2: Repeatable. The development methodology and all its phases are partially documented. The
processes involved in the documented phases are repeatable, but the successful application of the
processes is not guaranteed every time they are followed because application of documented phases
varies from project to project. Software quality assurance is considered for the documented processes.
Project management techniques and tools are used to track project progress in terms of cost, schedule,
and project deliverables.
Level 3: Defined. The development processes are documented and well defined. Internal standards and
documented methodology are used uniformly across the organization and in all development projects
undertaken. Documented processes have also been updated over time using past experiences to
improve performance. However, past experiences are assessed and documented qualitatively, not
quantitatively. In this level, risk management is in place and all aspects of project management are
thoroughly considered.
Level 4: Managed. Developmental metrics are collected during the execution of the project to provide a
quantitative basis for software quality management. These metrics allow the project manager to predict
the future performance of the remaining phases of the project, thus, allowing the manager to closely track
and control the project based on quantitative assessment. This allows the manager to manage the risks
more effectively and take the necessary and timely actions should any risk occur.
Level 5: Optimized. Using metrics collected during the execution of the project phases, and using the
documented standards and processes, modifications or improvements to both standards and processes
are implemented continuously. These changes are triggered by new technology adoption that leads to
improved performance. Collected metrics are used to optimize the processes and the organization
workflow leading to increased productivity while maintaining product quality. Performance indicators are
developed and monitored. Changes to processes and standards show improvements in performance
from project to project. Process and technology change management systems are in place.
Specifically, the Software Engineering CMMI Model is illustrated and discussed at
https://www.geeksforgeeks.org/software-engineering-capability-maturity-model-cmm/.

An organization placed at a particular level is an indication that it meets all the requirements for that level
and is showing clear indication that it is progressing toward the next higher level. The Software
Engineering Institute (SEI) is maintaining a database of appraised organizations. The SEI Appraisal
System (SAS) contains the appraisal results of hundreds of IT organizations at levels 2 to 5.

SUMMARY:
To develop high-quality software product and to deal with the management of software activities,
structured and well-documented processes must be clearly defined and used by the development team.
Industry-proven software engineering life cycle models have been introduced, and the project manager
must select the most appropriate model to be adopted by the organization. Depending on the size of the
adopting organization, its maturity level, and the complexity of the software to be developed, a life cycle
model can be tailored to suit the particular needs of the organization and its development team. The
Capability Maturity Model (CMM) is used to assess the maturity of the processes in a software
development organization. A typical software engineering lifecycle model consists of sequential phases,
including analysis, design, implementation, testing, and integration. In addition, important continuous
activities must be performed, including project management, validation and verification, configuration
management, quality assurance, and documentation.

BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

ASSESSMENT:
1. Secure a copy of a real-life software project schedule and identify the software process model
(lifecycle strategy) that may have been employed by the project development team
2. In the schedule, identify the umbrella or ongoing life cycle activities.
3. Identify the factors to consider in adapting the best fit process model for a software project.
4. Explain the difference and similarities between the linear, iterative and evolutionary models.
 4.1 UNDERSTANDING SOFTWARE PROJECT MANAGEMENT

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Describe what is software project management
➢ Explain the need for software project management
➢ Discuss the phases in project management
➢ Describe the role of a project manager

OVERVIEW:
Project Management is the first layer of the Software engineering process, meaning, it overlays the entire
development process from beginning to end. It is one of the continuous or ’umbrella’ activities in software
engineering. The focus of project management is to assure that software development projects meet
customer expectations and are delivered within budget and time constraints. It is an important aspect of
the development of software systems and a critical skill for a software engineer, specifically the team
leaders and/or systems analysts.

Image Source: programsbuzz.com

READING MATERIALS:

What Is Project Management

Project management can be defined as a controlled process of initiating, planning, executing, and closing
down a project. A Project is a planned undertaking of related activities to reach an objective that has a
beginning and an end.
Characteristics of a project are:
➢ Has definite objectives and scope
➢ Has definite start and end points
➢ Often brings about change
➢ Has a degree of risk associated with it
➢ Often staffed by people with other responsibilities
➢ Usually involves staff from different functions (for in-house projects)
➢ Has allocated resources and budget
➢ Has its own management structure

The Project Manager is an individual with a diverse set of skills – management, leadership, technical,
conflict management, and customer relationship – who is responsible for initiating, planning, executing,
and closing down a project.

The Activities of a Project Manager are:

➢ Proposal writing
➢ Project costing
➢ Project planning and scheduling
➢ Project monitoring and reviews
➢ Personnel selection and evaluation
➢ Report writing and presentation

Software project management is difficult because of the following reasons:

➢ The product is intangible. Software cannot be seen or touched. Therefore, for software
project, activities should be defined properly so that time could be estimated, resources allocated,
and progress be monitored and controlled.
➢ There is no standard process. There is no clear understanding of relationships between the
software process and product type. It means that there is no perfect software process for a
particular software product that would guarantee success.

Because of the difficulty in managing a software project, the following are factors to consider in
software project management::
➢ Scope of the work to be done
➢ Risks to be incurred
➢ Resources to be required
➢ Tasks to be accomplished
➢ Milestones to be tracked
➢ Efforts (cost) to be expended
➢ Schedules to be followed
Project management has four phases:
1. Initiating the project. Activities are performed to assess the size, scope, and complexity of the project
and to establish the procedures to support later project activities. It involves activating the project and
building the project plan. The project plan provides the basis against which to control the project. Its key
elements are work plan, schedule, staff effort estimates, budget, and milestones.
2. Planning the project. It focuses on defining clear, discrete activities and the work needed to complete
each activity within a single project. These activities are incorporated into different management plan
documents in the form of quality plan, risk management plan, validation plan, configuration management
plan, maintenance plan, and staff development plan. There may be other plans needed as part of the
project management planning process based on the ten (10) areas or body of knowledge in project
management. For details on these project plans, see PMBOK knowledge areas
https://www.projectmanager.com/blog/10-project-management-knowledge-areas.
3. Executing the project. It focuses on putting the plans developed in project initiation phase and planning
phase into action. It involves the following: (1) executing the baseline project plan, (2) monitoring project
progress against the baseline plan, (3) managing changes to the baseline plan, (4) maintaining the project
workbook, and (5) communicating the project status. An important aspect in this phase is progress
reporting which enables the project manager to understand the current state of the project, and to report
the status of the project to the project team, senior management, and the client. Project progress is often
measured and reported in two ways (1) quantitatively in terms of man-hours, costs, tasks
started/completed, milestones achieved, and elapsed time; (2) qualitatively in terms of client/user
satisfaction, staff morale, staff turnover, quality, objectives achieved, and change requests from
user/client. See project status report template at
https://www.projectmanagementdocs.com/template/project-monitoring-and-controlling/project-status-report/#axzz6R9dloerw.
Another important aspect is progress monitoring, which is the process of collating progress reports and
assessing the results against the project plan.

3. Closing down the project. It focuses on bringing the project to an end. Activities involved are formal
project closure, closing customer contract, and conducting post-implementation reviews.

For a thorough understanding and discussion of the four (4) phases, and the documents and deliverables
involved for each phase, see https://www.projectmanagementdocs.com/#axzz6R9dloerw.

SUMMARY:
To sum it up, project management is needed from the inception of the software project down to its
completion and delivery. It involves writing project proposal, costing, developing plans and schedules,
selecting and evaluating project staff; monitoring and controlling the process; and writing and presenting
reports. Software project management is difficult as the product is intangible and there is no standard
process to be followed to ensure the successful completion of the software product.
BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

ASSESSMENT:
4. Interview a software project manager and list down the top most challenges in managing a software
project and how these challenges are best dealt with.
5. *Download all the templates for the documents needed in all four (4) phases of project management
from https://www.projectmanagementdocs.com/#axzz6R9dloerw, and explain which of these
documents (templates) are the most difficult to prepare and why.

Note: * for OL mode

 4.2 SOFTWARE PROJECT SCHEDULING

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Create a work breakdown structure
➢ Develop an initial project schedule for an actual software project
➢ Describe the impact of lag and lead time for each task dependency type
➢ Describe the impact of dependency type on the project duration

OVERVIEW:
During the project initiation phase, the project manager has to produce an initial project schedule or
timetable indicating the different tasks/activities/works to be accomplished; the deliverables, period to
accomplish, in-charge, and resources required for each task. Normally, the project schedule is presented
in the form of a time table which can be converted into a graphical form, the Gantt chart. Although this
baseline plan provides a framework that guides the project team in accomplishing the tasks to complete
the project within the specified duration, there are factors in a project that need to be monitored and
analyzed such as the dependencies of the tasks with each other, the critical tasks that cannot be delayed,
the estimated project duration, and the impact of constraining the dates on each task in the project. These
factors require that the timetable be converted not just into a Gantt chart that visually shows the timeline,
but into a project network diagram which can be analyzed. The Program Evaluation Review Technique
(PERT) Chart is one of the tools that allows for critical path method/analysis.

Image Source: Pinterest

READING MATERIALS:

Developing a Project Schedule

The initial step is to produce an initial project task list, refine the task list, and transform it into a work
breakdown structure (WBS), before developing the detailed plan. First, we normally set either the whole
project start-date or the whole project end-date. Then we define the tasks/activities involved in the
project(task list), decompose and structure the tasks(WBS), and we set the start and finish dates for each
task/activity. Then we have to perform project network analysis, to determine the critical activities and
the dependencies of each task to other tasks, and to accurately determine the minimum time to complete
the project. Finally, we may now refine and complete the plan. Here are the detailed steps:

1. Prepare Initial Task List

• List down possible tasks randomly
• Don’t worry about sequence & granularity
• Never mind if a task is too trivial/general
• Include ‘hidden activities’ such as briefings, project meetings and production of minutes,
reviews, re-working, management and administration such as report preparation
2. Refine the task list
• Exclude too trivial task
• Breakdown too general task into subtasks
• Cluster interrelated tasks into one grouping
3. Transform Task into Work Breakdown Structure (WBS)
• WBS is a hierarchical presentation, breakdown, or decomposition of work to be done, which
will be the basis for project estimation and scheduling
• Tasks are broken down into a level of detail where work can be reasonably measured
• Work units, costs, and resources are assigned to lowest level of work (atomic level)
• Deliverable of parent task is sum of its child tasks’ deliverables
4. Include Project Milestones in task or WBS list
• Key events that serve as progress checkpoints or points of completion of a phase
• May or may not be a “task”
• May or may not have a deliverable
• Does not have a duration
5. Estimate time for entire project
1. Fixed Duration Estimate (based on elapsed calendar time)
Ex. “The project will require 3 months to complete”
2. Effort-driven Estimates (based on effort)
Ex. “ The project will require 2 project manager man-months, 8 programmer man-months, and 3
analyst man-weeks”
6. Convert table into Gantt chart
7. Convert Gantt chart into a project network diagram for analysis
8. Refine and complete the plan
The Work Breakdown Structure
Each task in the list can be decomposed into sub-tasks. Strategies to WBS decomposition can be:
1. Physical decomposition – Example: The whole project is divided into distinct activities such as
coding, documentation, testing, etc.
2. Logical decomposition – Example: The project is divided into Phase 1-user interface, phase 2-
business process, phase 3-controls, etc.
3. Geographical decomposition – Example: The project activities are categorized into Development
site, user site, main branch, etc.
4. Business function decomposition – Example: The Project Accounting System is divided into
General Ledger, Accounts Payable, Accounts Receivable, Cash Management, etc.
5. Departmental decomposition – Example: The project activities are divided into Human Resource,
Finance, Marketing, etc.

Task Granularity: When to stop decomposing?

• Status/completion are easily measured
• Clearly defined start and end events
• Deliverable or accomplishment impractical to decompose
• Reasonable activity duration in relation to project duration
• Clearly defined work assignment (by person)

Example of Tasks Format:

System Analysis ( Parent Task Noun Format)

* Interview users
* Gather documents
* Prepare functional specs (Parent Task Verb Object)
° Review & analyze docs (Atomic Task Verb ObjectO)
° Review & approve functional specs
* Functional specs approved (Milestone Object Verb)
System Design (Parent Task Noun Format)
Figure 1.0. Task Formats

The Gantt Chart

The Gantt chart is a graphical representation of a project that shows each task/activity, as a horizontal
bar whose length is proportional to its time for completion. See figure below 2.0 below.

The Gannt chart has the following weaknesses:

• Dependence of one activity upon another activity is not easily identified
• Many iterations may occur during the project. The chart has to be updated.
Figure 2.0. The Gantt chart

Another way to present the project schedule is through a PERT chart. PERT stands for Program
Evaluation Review Technique. It is a diagram that depicts tasks/activities (in the project) and their
interrelationships. The PERT chart is similar to the project network diagram generated using a standard
project management tool like MS Project and Visual Paradigm. PERT Chart supplements the Gantt Chart
by addressing its weaknesses cited above. Figure 3.0 illustrates a PERT chart while Fsigure 4.0 illustrate
a Project Network Diagram generated by a project management software.

Image Source: Wikipedia.org

Figure 3.0 PERT Chart

Image Source: PMHut

Figure 4.0. The Project Network Diagram

The PERT chart and Project Network Diagram readily show the predecessor activities/tasks a particular
task/activity is dependent on. However, there are different types of dependencies that exist between and
among tasks/activities, which will be discussed below. These dependency types have an impact on the
start and finish of each activity and on the total project duration as a whole.

Scheduling Activities
When we schedule our project tasks/activities the following are the things that we have to do:
1.Create Calendar. Specify duration (start-date and end-date) of each activity / task
• Project Calendar – all tasks/activities and resources
• Task Calendar – specify duration for specific task
• Resource Calendar – specify duration for specific resource needed to accomplish tasks
* Project, Task and Resource Calendars are features of Project Management Software.
2. Establish task dependencies. Define predecessors of each task according to chronological sequence

3. Refine task dependencies. Review and modify task dependencies to reduce task or activity duration.
First-pass dependency may be changed into Finish-Finish or Start-Start (if applicable) to reduce project
duration.

4. Analyze lag and lead time. The amount of wait time between start or finish of predecessor and start or
finish of successor is the Lag Time while Lead time is the amount of overlapping time between start or
finish of predecessor and start or finish of successor
Types of Task Dependencies
1. Finish-Start – most common and default dependency; successor activity cannot start until
predecessor is finished; start of successor can be delayed Ex. Site installation should be finished
first before user test can start
2. Finish-Finish – successor can start anytime; predecessor must finish before successor can finish;
finish of successor can be delayed Ex. Programming must be finished first before documentation
is finished (but documentation can start even Programming not yet finished)
3. Start-Start – successor can start only after predecessor starts; does not matter which one finishes
first; can apply in tandem with F-F; start of successor can be delayed. Example: Designing
navigational structure of website can start only after starting the gathering of information.
However, gathering of information may continue after the design of navigational structure is
finished.
4. Start-Finish - successor can finish only after predecessor has started; successor usually starts
before the predecessor; rare and can be very confusing; finish of successor can be delayed

The diagram below illustrates the different task dependencies and how predecessor and successor
activities are started and finished for each type, and the action that can be done in terms of delay.

Pr S--------F
FINISH-START
Su S--------F

Ac S---→ successor start can be delayed

Pr S--------F
FINISH-FINISH

Su S------F

Ac F---→successor finish can be delayed

Pr S--------F
START-START
Su S------F

Ac S---→ successor start can be delayed

Pr S--------F
START-FINISH
Su S--------F

Ac F---→ successor finish can be

delayed

Legend: Pr-edecessor Su-ccessor Ac-tion S-tart F-inish

Figure 5.0. Action that can be done in terms of delay for each dependency type
Impact of Lag and Lead Time for Each Dependency Type
Overall project duration can be reduced by using alternate type of dependencies instead of the default
ones (first-pass dependency). Normally, the default dependency in project management software is the
Finish-Start.
Lag and Lead times can shorten or lengthen project duration and are not optional in developing the
project plan.
The diagram below illustrates the different task dependencies and how predecessor activities are started
and finished for each type, and at which point the lag and lead time has an impact.
Pr S--------F

FINISH-START La -----S-----F

Le S---------F *impact of La & Le is on Pr Finish

Pr S--------F
FINISH-FINISH
La S------------F

Le S----F-- *impact of La & Le is on Pr Finish

Pr S--------F
START-START
La ----S------F

Le S----------F *impact of La & Le is on Su Start

Pr S--------F
START-FINISH La S-----------F

Le S------F-- *impact of La & Le is on Su Finish

Legend: Pr-edecessor S-tart F-inish La-g Le-ad

Figure 6.0. Impact of Lag and Lead Time for each dependency type

The Project Calendar

All tasks/activities are listed in the project calendar. Project Management software (like MS Project) can
automatically generate a project network using the project calendar with tasks, schedule, and
dependencies defined.
To manually convert the project calendar into a network diagram, plot the activities as a circle and arrow
diagram, where a node represents a point in time, and arrows represent the activities. By convention,
activities should go from left to right.
For the example project time table below, all activities are listed. The earliest start date, estimated length
of time it will take, whether it is parallel or sequential, and the previous activity/stage it depends on
(predecessor) are shown.
 Task Possible Start Length Type Predecessor

1. High level analysis Week 1 5 days sequential

2. Selection of hardware platform Week 1 1 day Sequential 1

3. Installation and commissioning of Week 3 2 weeks Parallel 2

hardware

4. Detailed analysis of core modules Week 1 2 weeks Sequential 1

5. Detailed analysis of supporting Week 1 2 weeks Sequential 4

utilities

6. Programming of core modules Week 4 3 weeks Sequential 4

7. Programming of supporting Week 4 3 weeks Sequential 5

modules

8. Quality assurance of core modules Week 5 1 week Sequential 6

9. Quality assurance of supporting Week 5 1 week Sequential 7

modules

10. Core module training Week 7 1 day Parallel 6

11. Development of accounting Week 6 1 week Parallel 5

reports

12. Development of management Week 6 1 week Parallel 5

reports

13. Development of management Week 6 2 weeks Sequential 5

analysis

14. Detailed training Week 7 1 week Sequential 1 – 13

15. Documentation Week 4 2 weeks Parallel 13

Table 1.0. Example Project Calendar

The project calendar can then be transformed into a project network diagram so that the activities can be
further analyzed. Below is an example of a project network diagram from the project calendar of Table 1.
0.

Core Module training

10
1 day 50
0 40
10
30 Quality Assurance of Core
Modules
Figure 7.0 Project network diagram derived from the project calendar

The Importance of Project Network

• Shows graphical relationship(dependencies) of project activities
• Identifies critical activities or those activities in the critical path
• Shows amount of slack time (lee way) you can play with for non-critical activities
• Shows impact of constraining dates on activities in the project
• Determines total project duration

To appreciate the importance of project networks, we have to perform project network and critical path
analysis. Constructing a project network diagram or PERT chart and performing network and critical path
analysis will be discussed in the succeeding lesson. Alternatively, your project management software like
MS Project can automatically generate the chart/diagram and display the result of analysis.

SUMMARY:
Developing a baseline project plan is important to serve as a framework for the software development
process. It starts with a task list that is transformed into a work breakdown structure and into a project
calendar. This calendar can be presented thru a Gantt chart which is limited in terms of showing the
dependence of one activity to other activities and the critical activities in the project. Hence, there is a
need to define the predecessor activities/tasks for each activity/task and convert the table or Gantt chart
into a project network diagram, i.e. the PERT chart.

BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman
ASSESSMENT:
1. Using the MS Project, create a project calendar for a simple software development project where
for each task, specify the duration, and the tasks it is dependent on (predecessor tasks).
2. Generate the Gantt chart and PERT chart (project network diagram). Take note of the length of
the critical path (red line) in the project network.
3. For each task/activity, analyze the dependency type and change the default dependency type
(finish-start) to other types if needed. Then take note of the length of the critical path (red line) in
the network.
4. Describe the impact of the dependency type on the project duration.
 4.3 ANALYZING THE PROJECT NETWORK DIAGRAM

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Explain the need for analyzing the project network diagram
➢ Describe the critical path in a project network
➢ Analyze the earliest time to start and earliest time to finish each activity in the calendar
➢ Analyze the latest time to start and latest time to finish each activity in the calendar

OVERVIEW:
There are factors in a project that need to be monitored and analyzed such as the dependencies of the
tasks with each other, the critical tasks that cannot be delayed, the slack time for each task and for the
entire project, and the impact of constraining the dates on each task in the project. These factors require
that the project schedule in the form of either time table or Gantt chart be converted into a project network
diagram which can be analyzed. The Program Evaluation Review Technique (PERT) Chart is one of the
tools that allows for project network analysis or critical path analysis.

See…
https://www.apm.org.uk/resources/what-is-project-management/what-is-scheduling-in-project-management/.
READING MATERIALS:
The Critical Path Method/Analysis Explained
See https://www.wrike.com/blog/critical-path-is-easy-as-123/

Below is the summary guidelines and discussion of the topics presented in the URL provided above.
Drawing the Project Network Diagram
1. Draw the project network diagram following the rules and convention: Use dummy activities to
correct error in convention and error in logic. Dummy activities are used for drawing the project
network diagram only, and are actually activities with 0 (without) duration.
2. Apply critical path analysis/method to determine the longest path, which represents the minimum
time that the project can be completed, and to determine the critical activities that lie along the
critical path.
3. Use forward pass computation and backward pass computation to analyze each activity in the
project calendar
➢ For each activity, there is:
• Duration symbolized as “t” for time
• Early Start(ES) date - earliest time an activity can begin if all previous activities are begun
at the earliest time.
• Early Finish(EF) date – earliest time an activity can be completed if it is started at the
earliest time
• Late Start(LS) date – latest time an activity can begin without delaying the completion of
the project
• Late Finish(LF) date – latest time an activity can be completed if it is started at the latest
time.
• Total Slack(TS) – the amount of time an activity can be delayed without delaying the
completion of the project.
➢ Forward Pass Computation
• Computes ES & EF of successor activities, hence for all activities
• Determines total project duration which is the length of the critical path
➢ Backward Pass Computation
• Computes LS & LF of predecessor activities, hence for all activities
• Computes slack time for all activities
• Identifies critical activities – with 0 slack time

Critical Path Analysis/Method is used to determine the start and finish dates (duration) of individual
activities in a project. In performing the Forward Pass Computation, it is important to remember the
following:
• For initial activity, ES = 0
• ES = highest EF among multiple predecessor activities
• For each activity, EF = ES + duration of current activity (t)
• EF of terminal activity is project duration
In performing the Backward Pass Computation, it is important to remember the following:
• Start with terminal activity; Set LF = EF, LS = ES
 • Walk backward across activities
• LF = lowest LS among multiple successor activities
• LS = LF – duration of current activity (t)
• Slack(TS) = LF – EF
• If slack = 0, activity is critical
In the example network diagram below, forward and backward pass computations are performed on the
example activities, to determine the earliest and latest time an activity can begin and can be completed.

1 2

0 3 4
10
2 1

Activity 1
2 days
Activity 3
Start End
10 days

Activity 2
1 day

Figure 1.0 Example project network diagram for forward pass & backward pass computation:

Forward Pass

ES=EF predecessor EF = ES + t

LS = LF – t LF = LS successor

Slack(TS) = LF – EF

Node 1 to Node 3 : 2
Node 2 to Node 3 : 1
The larger value is taken for the earliest activity time which is 2.
Node 4 has the earliest activity time (EF) of 2 + 10 = 12.

Backward Pass
Usually, the earliest completion time is taken for the latest completion time for the backward pass. A
value may also be given.
If for example, the latest completion time (LF) is given as 15…
Node 3 has the latest completion time (LS) of 15-10 = 5
Using the LS of Node 3 which is equal to 5…
Node 1 has the latest completion time (LS) of 5(Node 3) – 2 = 3
Node 2 has the latest completion time (LS) of 5(node 3) – 1 = 4
Slack refers to the time when activities can take longer without affecting the completion date of the project.
Total slack = latest time of finished activity – earliest time of start activity – duration.
There could be several paths leading from the start to the end of the project. By observation, the longest
path is the critical path.
During the project planning or scheduling phase, the project network should be analyzed by focusing on
the critical path. The critical path is the one with the minimum slack. It represents activities in the project
with minimum slack, and, are considered critical. If there are too many critical activities in the critical path,
then the project schedule is too tight and we might need to review the duration and/or dependency type
defined for each task/activity. To compensate, we can allocate additional time from the slack time of non-
critical activities. We may also transform sequential into parallel activities (if possible), by using Start-
Start or Finish-Finish dependency types instead of the default Finish-Start. It is also important to conserve
slack times for contingencies.
See
https://www.inloox.com/company/blog/articles/back-to-basics-part-10-how-to-create-a-project-network-diagram/.

During project implementation or execution, you should analyze the project network by closely monitoring
activities along the critical path. These critical activities should not be delayed, otherwise, the entire
project would be delayed. Slippage of schedules can be compensated by slack time and by reallocating
resources. The project network could also serve as a tool for analysis of impact of mandated or derived
constraints such as pre-defined deadlines, adjusted deadlines, constraints triggered by unavailability of
resources, and external dependencies. Attention should be given to activities transformed from non-
critical into critical, and activities with negative slack. You may apply compression strategies such as fast
tracking and crashing, to remove or minimize negative slack. See https://pmstudycircle.com/2012/09/fast-
tracking-crashing-schedule-compression-techniques-in-time-management/.

Other Scheduling Activities

After refining the time schedule, the next step is to complete the baseline project plan with the following
activities (which will be discussed in the succeeding lessons):
1. Estimate cost and resource requirements such as people, equipment, facilities, other resources
2. Assign resources to tasks
3. Summarize resource requirements (Resource Sheet can automatically be done by Project
Management Software)
4. Level resource requirements by updating resource calendars to specify percentage availability of
people, leaves, travels, etc. (leveling of over-allocated and under allocated resources can be
automatically done by Project Management software)
5. Fine-tune the plan (according to client priorities and mandated constraints)
6. Prepare the project budget based on the following cost components:
• Manpower Cost
• Equipment and Facilities Cost
• Material cost
• Licenses and royalties for IPRs
• Direct expenses
• Overhead expenses
• Capital expenses – especial equipment only used by the project
SUMMARY:
Analyzing the project network diagram during scheduling is important so we can accurately determine
the minimum time to complete the project, and identify the critical and non-critical activities in the project.
Critical activities have no slack time and cannot be delayed. If there are too many critical activities in the
critical path, then the project schedule is too tight and we might need to review the activity duration and/or
dependency type defined for each task/activity. To compensate, we can allocate additional time from the
slack time of non-critical activities. After the time schedule has been refined, we may now schedule other
project components like manpower, materials and equipment, facilities, and cost. The project network
diagram should also be analyzed during the project execution/implementation phase where we may apply
compression techniques like fast tracking and/or crashing.

ASSESSMENT:
1. Using the previously created PERT chart in the previous lesson, compare the length of the critical
path to your original timetable’s defined project end date. Are they aligned? Discuss.
2. By observing the critical path, list down the critical activities in you project. For each activity (critical
and non-critical, identify the earliest start time, earliest finish time, latest start time, and latest
finish time.
3. Describe the project schedule if it is too tight or acceptable. Apply the necessary adjustments so
that the project schedule would not be too tight.
 4.4 SOFTWARE METRICS

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:
➢ Explain how metrics are used during the project scheduling and resource estimation stage
➢ Explain how metrics are used during the project execution stage
➢ Compute for size-oriented metrics and function-oriented metrics
➢ Derive the project cost in terms of software size and software function

OVERVIEW:
Software metrics refers to a broad range of measures for computer software. It is defined by the IEEE
Standard Glossary of Engineering Terms as “a quantitative measure of the degree to which a system,
component, or process possesses a given attribute”. Measurement can be used throughout the software
project to assist in estimation, quality control, productivity assessment and project control. Productivity
and quality metrics are primarily used for project monitoring and control. These metrics can be stored as
historical data that can be used for planning and estimating purposes. Metrics collected from past projects
are used as a basis from which effort and time duration estimates are made for the current software
project.

Image Source: cs.odu.edu

READING MATERIALS:

Reasons for Measuring software

➢ To indicate the quality of the product
➢ To assess the productivity of the people who produce the product
➢ To assess the benefits (in terms of productivity and quality) derived from new software
engineering methods and tools
➢ To form a baseline for estimation
➢ To help justify request for new tools or additional training

Categories of Metrics
➢ Quality metrics – provide an indication of how closely software conforms to explicit customer
requirements.
➢ Productivity metrics – focus on the output of the software engineering process.

Metrics for Software Quality

Quality can be measured throughout the software engineering process and after the software has been
released to the customer or users.
Metrics derived before delivery of the software provides a quantitative basis for making design and testing
decisions. Quality metrics within this category include (but not limited to):
• program complexity
• effective modularity
• overall program size

Metrics derived after delivery focus on the number of defects uncovered in the field and the maintainability
of the system. These after-delivery measures of software quality present managers and technical staff
with a post mortem (implementation) indication of the effectiveness of the software engineering process
followed by the project team.
Quality metrics can also be indirect measures of the software product. An example is Mc Call’s software
quality factors in terms of correctness, reliability, efficiency, integrity, usability, maintainability, flexibility,
testability, portability, reusability, and interoperability. which are illustrated in the diagram below. It should
be noted that these software quality factors are also discussed as software quality attributes or
characteristics included in the ISO 9126-1 software evaluation instrument.
 -Maintainability (Can I fix it?) -Portability (will I be able to use it
in another machine?)
-Flexibility (can I change it?) -Reusability (will I be able to reuse
some of the software?)
-Testability (Can I test it?)
-Interoperability (will I be able to
interface it with another system?)

-Correctness (does it do what I want?)

-Reliability (Does it do accurately all of the
time?)
-Efficiency (will it run on my hardware as
well as it can?)
-Integrity (is it secure?)
-Usability (Is it designed for the user/)

Figure 1.0 Mc Call’s software quality factors

Metrics for Productivity

Size-oriented Metrics – are used to collect direct measures of software engineering output and quality
(product). They are derived by normalizing quality and/or productivity measures by considering the “size”
of the software that has been produced. They are measured in terms of numerical value /tangibility (based
on Lines Of Codes).
For example, an organization such as the PUP can create a table that lists each software development
project that has been completed over the past few years and corresponding measures for that project.
Referring to the table entry below, for project HRIS, 12,100 lines of code(LOC) were developed with 24
person-months of effort at a cost of Php 168,000.00. The effort and cost recorded in the table represent
all software engineering activities (analysis, design, coding, and testing). There are 365 pages of
documentation developed, 134 errors were recorded before the software was released, and 29 defects
were encountered after release to the customer with the first year of operation. Three (3) people worked
on the development of the software for project HRIS.
Table 1.0 Example table of software development projects completed and corresponding measures

Project Effort PhP KLOC Pages of Errors Defects People

Documentation
(person-months) (Thousand)

HRIS 24 168 12.1 365 134 29 3

SIS 60 340 20.2 500 256 85 5

FMIS 43 150 15.2 450 320 60 6

Here, we chose lines of codes as our normalization value. From the table, a set of size-oriented metrics
can be developed for each project such as the:

• Errors per KLOC (thousand lines of code)

• Defects per KLOC
• PhP per LOC
• Pages of documentation per KLOC

We can also compute other interesting metrics such as:

• Errors/person-month
• LOC per person-month
• PhP/page of documentation

From here, we can derive the following:

• Productivity = KLOC/person-month
• Quality = defects/KLOC
• Cost = PhP/LOC
• Documentation = pages of documentation/KLOC

Size-oriented metrics are not universally accepted as the best way to measure the process of software
development[JON86], but most of its proponents claim that LOC can be easily counted and many existing
software estimation models use LOC as a key input. Opponents give the following weaknesses of size-
oriented metrics:
➢ LOC measures are programming language dependent
➢ LOC measures penalize well-designed but shorter programs
➢ LOC measures cannot easily accommodate nonprocedural languages
➢ Their use in estimation requires a level of detail that may be difficult to achieve (the planner must
estimate the LOC to be produced before analysis and design have been completed)

Function-oriented Metrics – another productivity metrics that provide indirect measures and human-
oriented measures to collect information about the manner in which people develop computer software
and human perceptions about the effectiveness of tools and methods. They use a measure of the
functionality delivered by the application as a normalization value. It is an algorithmic approach for project
size estimation.
 ➢ Rather than counting LOC; function-oriented metrics focus on
program “functionality” or “utility.”
➢ It is based on Function points (FPs), which are derived using an empirical relationship based
on countable measures of software’s information domain and assessment of software
complexity.
➢ The system is classified into Simple, Average and Complex
➢ Function points are computed by completing the table shown below.

Five (5) information domain characteristics are determined and counts are provided in the appropriate
table location. Information domain values are defined in the following manner:
1. Number of user/external inputs. Each user input that provides distinct application oriented data
to the software is counted. These inputs affect the control flow and internal logic of the application
leading to the creation and maintenance of data.
2. Number of user/external outputs. Each user output that provides application-oriented information
to the user is counted. Output refers to reports, screens, error messages, etc. Individual data
items within report are not counted separately.
3. Number of user/external inquiries. An inquiry is defined as an on-line input that results in the
generation of some immediate software response in the form of an on-line output. Each distinct
inquiry or simple user query is counted.
4. Number of files(internal). Database files that are created and maintained in the application is
counted.
5. Number of external interfaces/files. All machine-readable interfaces (e.g., data files on tape or
disk) that are used to transmit information to another system is counted. These are files that are
owned and maintained by other applications but used by the system.

The complexity of software and the effort needed to develop it are a function of the number and type of
these five kinds of functional components that can be obtained and assessed at the requirements
specifications phase.
Measurement parameter Count Simple Average Complex
Number of user inputs [ ] x 3 4 6 = [ ]
Number of user outputs [ ] x 4 5 7 = [ ]
Number of user inquiries [ ] x 3 4 6 = [ ]
Number of lines [ ] x 7 10 15 = [ ]
Number of external interfaces [ ] x 5 7 10 = [ ]
Count-total ----------------------------------------------------------------------------→ [ ]
Once the above data has been collected, a complexity value is associated with each count. See table
below.
Table 2.0 Five functional components and fp count

PARAMETERS COUNT S = (* 3) A = (* 4) C = (* 6)

No. of user inputs [5] * 3 4 6 = 20

No. of user outputs [6] * 3 4 6 = 18

No. of user inquiries [8] * 3 4 6 = 32

No. of files [5] * 3 4 6 = 15

No. of external interfaces [2] * 3 4 6 = 12

Count Total 97

Here, FP = Count Total * [.65 + .01 * Sum(Fi)] where Count Total is the sum of all entries
The constant values in the equation and the weighting factors applied to information domains are
determined empirically.
The Fi(i = 1 to 14) are “complexity adjustment values “ based on responses to questions [ART 85]
noted in the table below.
Table 3.0 Complexity adjustment values

Rate each factor on a scale of 0 to 5:

0 1 2 3 4 5

No Influence Incidental Moderate Average Significant Essential

Fi:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, and inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?

Based on the above example where Count Total = 97, we can compute the function points with the
formula: FP = Count Total * [.65 + .01 * Sum(Fi)]
Once function points have been computed, they are used in a manner analogous to LOC to normalize
measures of software productivity, quality, and other attributes:

• Errors per FP
• Defects per FP
• PhP per FP
• Page of documentation per FP
• FP per person-month

From here, we can derive the following:

Productivity = function point(fp) / person-month
Quality = defects / fp
Cost = PhP / fp
Documentation = pages of doc / fp
The function point metric was originally designed to be applied to business information systems
applications. To accommodate these applications, the information domain values discussed above, was
emphasized to the exclusion of the functional and behavioral (control) dimensions thus, making the
function point measure inadequate for many engineering and embedded systems.
A number of extensions to the basic function point measure have been proposed to remedy this situation.
A function point extension called feature points is a superset of the function point measure that can be
applied to systems and engineering software applications. It counts a new software characteristic,
algorithms.
Another function-point extension for real-time systems and engineered products have been developed
by Boeing, the 3D Function Point. It integrates the data dimension of software with the functional and
control dimensions to provide a function-oriented measure, that is amenable to applications that
emphasize function and control capabilities.
Feature-oriented metrics have defined weighted average already and the system is not to be classified
anymore as simple, average or complex. The result is the same as in function-oriented.
Proponents claim that function-oriented (Function Points) is programming language independent, making
it ideal for applications using conventional and nonprocedural languages; that it is based on data that are
more likely to be known early in the evolution of a project, making it more attractive as an estimation
approach.
However, opponents claim the following weakness of the function-point metrics:
➢ Computation is based on subjective, rather than objective data
➢ Counts of the information domain(and other dimensions) can be difficult to collect after-the-fact
➢ FP has no direct physical meaning – its just a number.

LOC and FP measures are often used to derive productivity metrics. However, software project managers
should not compare the LOC/person-month(or fp/person-month) of one group to similar data from other
groups, and should not appraise the performance of individuals by using these metrics. The reason for
this is that many factors influence productivity such as size and expertise of organization; complexity of
problem to be solved and number of changes in design constraints; analysis and design techniques,
review techniques, CASE tools and programming languages used; reliability and performance of
computer-based system; and availability of hardware and software resources.

SUMMARY:
Software are measured in terms of quality and productivity. The measurement data termed as “metrics”
can be used throughout the software project to assist in estimation, quality control, productivity
assessment and project control. During project execution, productivity and quality metrics are used for
monitoring and control. Quality metrics can be direct or indirect measures of the product. Productivity
metrics can be size-oriented (LOC) or function-oriented (FP) and its variants. As project proceeds,
measures of effort and calendar time expended are compared to original estimates and the project
schedule. The project manager uses these data to monitor and control progress. These metrics can be
stored as historical data that can be used for planning and estimating purposes. Metrics collected from
past projects are used as a basis from which effort and time duration estimates are made for the current
software project.

BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

ASSESSMENT:
1. From Table 1.0, provide the following metrics:
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• PhP per LOC
• Pages of documentation per KLOC
2. From Table 1.0, compute for the following metrics:
• Errors/person-month
• LOC per person-month
• PhP/page of documentation
• Productivity = KLOC/person-month
• Quality = defects/KLOC
• From the metrics above, derive Cost = PhP/LOC
3. From Table 2.0, compute for the function points, then compute for the following metrics:
• Errors per FP
• Defects per FP
• PhP per FP
• Pages of documentation per FP
• FP per person-month
• Productivity = function point(fp) / person-month
• Quality = defects / fp
• From the above metrics, derive the Cost = PhP / fp
 4.5 PROJECT RESOURCE ESTIMATION

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:

➢ Describe the steps in software project estimation

➢ Predict a software project effort, schedule and cost requirement using empirical estimation
techniques
➢ Explain the difference between the different empirical estimation techniques

OVERVIEW:
When a software is planned, estimates of required human effort (usually in person-months),
chronological project duration/schedule (in calendar time), and cost must be derived. Estimates are
made using past experiences as a guide if the project is quite similar to the old ones that were developed.
There are empirical estimation techniques that use past measurements as a basis from which estimates
are made. Project scope is established in advanced; and the project is decomposed or broken into small
pieces, which are estimated individually.
READING MATERIALS:

Steps in Software Project Estimation:

1. Identify the project scope
2. Perform project decomposition
3. Compute the empirical metrics KLOC and/or FP
4. Apply an empirical model to estimate cost, effort and duration.
5. Use for comparison with automated estimation tools (optional)

Once project scope has been established, the software project is decomposed and re-characterized as
a set of smaller, more manageable sub-problems. The decomposition techniques take the "divide and
conquer" approach to software project estimation. Software estimation activities can be performed in a
stepwise fashion when the project is decomposed into major functions and related tasks. This is called
process-based decomposition. See…
https://www.tutorialspoint.com/estimation_techniques/estimation_techniques_overview.htm.

We may also perform problem-based decomposition as what was done in the previous lesson where the
following values were derived:
LOC-oriented
• LOC/person-month
• Productivity = KLOC/person-month
• Cost = PhP/LOC
FP-oriented
• FP/person-month
• Productivity = function point(fp) / person-month
• Cost = PhP / fp

Once the empirical metrics KLOC and/or FP are computed, we may apply empirical models to obtain
estimates of software cost, effort, and duration. Empirical estimation models are used to achieve reliable
cost and effort prediction.
The effort estimate can also be derived by converting the size estimate using an estimation software.
Empirical Estimation Models
These models use empirically derived formula to predict efforts as a function of LOC and FP. Values for
LOC or FP are estimated using the approach discussed in the previous lesson (on software metrics), but
instead of using the tables, the resultant values for LOC and FP are plugged into the estimation model.
A typical estimation model is derived using regression analysis on data collected from past software
projects. The overall structure of the model takes the form [MAT94]:
E = A + B x (ev)c
Where A,B, and C are empirically derived constants, E is effort in person-months, and ev is the estimation
variable(either LOC or FP). The majority of estimation models have some form of project adjustment
component that enables E to be adjusted by other project characteristics (e.g. problem complexity, staff
experience, development environment).
LOC-oriented estimation models:
E = 5.2 x (KLOC)0.91 Walston-Felix Model
E = 5.5 + 0.73 x (KLOC)1.16 Bailey-Basili Model
E = 3.2 x (KLOC)1.05 Boehm Simple Model
E = 5.288 x (KLOC)1.047 Doty Model for KLOC > 9

FP-oriented estimation models:

E = 13.39 + 0.0545 FP Albrecht and Gafney Model
E = 60.62 x 7.728 x 10-8 FP3 Kemerer Model
E = 585.7 + 15.12 FP Matson, Barnett, Mellichamp

The models listed above will yield a different result for the same value of LOC or FP. Therefore, estimation
models must be calibrated for local needs. No estimation model is appropriate for all classes of software
and in all development environments. Hence, resulting values from these models must be used
judiciously.

These estimation models must also be tested by applying data collected from completed projects; plug
the data into the model; and compare actual to predicted results. An estimation model should also be
calibrated to reflect local conditions.
The Function Points (FP) metrics discussed earlier, rely on the requirements specifications so that
function points reflect the user’s view of the system being developed, and, therefore, they are as stable
as the requirements themselves. As a requirements-based estimation technique, estimations are
obtained once the software project scope is clearly defined in terms of the required functionalities (during
the requirements phase of software development). Computing the number of function points (fp count)
for the project is independent of the design choices taken, tools used, or the programming language
utilized to implement the system.

Use Case Points

The Use Case Points (UCP) is a software effort estimation technique that was introduced by Gustav
Kamer in 1993. It is an extension of the function point method based on the use cases existing in the use
case model of a software system. Like function point metrics, it is also a requirements-based specification
technique, so that estimations are obtained once the software project scope is clearly defined in terms of
the required functionalities (during the requirements phase of software development).
In UCP metrics, actors and use cases are classified under three categories: simple, average, and
complex. For example, an external system interacting with the system using defined application
programming interfaces is typically a simple actor. External systems interacting with the system using
some standard protocols and data stores are actors of average complexity. A user interacting with the
software using GUI components, such as forms and dialog boxes, is considered a complex actor.
The complexity assessment of a use case is based on the number of transactions or steps that are
included in the use case description. These steps are included in the normal and alternative flow of events
in the use case description. A use case is classified as simple if the number of transactions does not
exceed 3. Similarly, an average complexity use case includes 4 to 7 transactions and a complex use
case includes more than 7 transactions. Factors are assigned to the various complexities of both actors
and use cases. The factors for both actors and use cases are shown in the table below.
Table 1.0 Actor and use case complexity values

Actor Type Value Use Case Type Value

Simple 1 Simple: less than or equal to 3 transactions 1

Average 2 Average: between 4 to 7 transactions 2

Complex 3 Complex: > 7 transactions 3

The unadjusted actor weight (UAW) is the sum of the complexity values assigned to each actor. Similarly,
the unadjusted use case weight (UUCW) is the sum of the complexity values assigned to each use case.
The total unadjusted use case point (UUCP) is the sum of the UAW and UUCW. The number of adjusted
use case points (AUCP) is computed by multiplying the UUCP with the product of two adjustment factors:
the technical complexity factor (TCF) and the environmental factor (EF).
The TCF is obtained using the equation: TCF = 0.6 + (0.01 X TF)
where TF is the sum of all the weighted values computed for each of the 13 technical factors listed in the
table below.
Table 2.0 Technical and environmental complexity values

Technical Factor Weight Environmental Factor Weight

Distributed system 2 Familiarity with project 1.5

Performance requirements 1 Application experience 0.5

End user efficiency 1 Object-oriented experience 1

Internal processing 1 Lead analyst capabilities 0.5

Reusability of code 1 Motivation 1

Installation ease 0.5 Stability of requirements 2

Usability requirements 0.5 Part-time staff -1

Portability requirements 2 Programming language difficulty -1

Changeability requirements 1

Concurrency 1

Security requirements 1

Direct access to 3rd party 1

User training facility 1

Technical complexity factors are mainly related to the product and its complexity in terms of functional
and non-functional requirements (NFRs). Each factor has its own weight, and a value ranging from 0 to
5 is assigned to a factor, depending on the technical complexity of the corresponding factor. For example,
the technical factor related to the level of security requirements is given a weight of 1. If the security
requirements are complex, a high value of 5 is assigned to the factor yielding a weighted value of 5. The
smallest and largest possible values of TCF can be computed.
The EF is obtained using the equation: EF = 1.4 – (0.03 X ENVF)
Where ENVF is the sum of all the weighted values computed for each of the 8 environmental factors
listed in the table. Environmental factors are related to the people, process, and project aspects of the
software. Each factor has its own weight, and a value ranging from 0 to 5 is assigned to a factor,
depending on its relevance. For example, the stability of requirements is given the highest weight of 2
and if the requirements are felt to be volatile or not well-defined, a high value of 5 is assigned to it, making
the weighted value 10. The smallest and largest possible values of EF can be computed.

The equation to obtain the number of adjusted use case points (AUCP) is:
AUCP = (UAW + UUCW) X TCF X EF
To obtain the estimated effort in person-hours needed to develop the software according to the UCP
metrics, Kamer stated that 20 person-hours are needed or each use case point. However, other
refinements and empirical studies of the UCP technique suggested range between 15 and 30 person-
hours per UCP. Assuming we use p person-hours peer UCP and a work day of h hours, the number of
work days would then be: ((p X AUCP)/h) days.

The COCOMO Model

Image Source: slideshare.com

In 1981, Barry Boehm[BOE81] introduced a hierarchy of software estimation models bearing the name
COCOMO, for Constructive Cost Model. It takes the following form:
Model 1. The Basic COCOMO model computes software development effort (and cost) as a function of
program size expressed in estimated lines of code.
Model 2. The Intermediate COCOMO model computes software development effort as a function of
program size and a set of “cost drivers” that include subjective assessments of product, hardware,
personnel, and project attributes.
Model 3. The Advanced COCOMO model incorporates all characteristics of the intermediate version
with an assessment of the cost driver’s impact on each step (analysis, design, etc.) of the software
engineering process.
The COCOMO models are defined for three classes of software projects: (1) organic mode – relatively
small, simple software projects in which small teams with good application experience work to a set of
less than rigid requirements; (2) semi-detached mode – an intermediate (in size and complexity)
software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid
requirements (e.g. transaction processing system with fixed requirements for terminal hardware and
database software); (3) embedded mode – a software project that must be developed within a set of
tight hardware, software and operational constraints(e.g. flight control software for aircraft).
Table 3.0 Basic COCOMO model

Software Project Ab Bb Cb db
Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

The Basic COCOMO model takes the form:

E = abKLOC
D = cbEd exp b
Where:
E = effort applied in person-months
D = development time in chronological months
KLOC = estimated number of delivered lines of codes for the project (expressed in thousands)
Coefficients ab and Cb and the exponents Bb and db are given in the table.

The effort estimate is used to compute for the project duration, following the above formula. The value
for project duration enables the planner to determine a recommended number of people for the project.
N = E/D
Where:
N is the recommended number of people for the project;
E is the effort estimate computed;
D is the project duration computed.

The Basic model is extended to consider a set of “cost driver attributes” [BOE81] that can be grouped
into four major categories: product attributes, hardware attributes, personnel attributes, and project
attributes. Each of the fifteen (15) attributes in these categories is rated on a six-point scale that ranges
from “very low” to “extra high” (in importance or value). Based on the rating, an effort multiplier is
determined from tables published by Boehm, and the product of all effort multipliers results is an Effort
Adjustment Factor(EAF). Typical values for EAF range from 0.9 to 1.4.

Table 4.0 Intermediate COCOMO model

Software Project ai Bi

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20
The Intermediate COCOMO model takes the form:
E = aiKLOCb exp I x EAF
Where:
E = effort applied in person-months
KLOC = estimated number of delivered lines of codes for the project (expressed in thousands)
Coefficients ai and the exponent Bi are given in the table.

COCOMO represents a comprehensive empirical model for software estimation. However, “software cost
estimation model is doing well if it can estimate software development costs within 20% of actual costs,
70% of the time, and this is not as precise as we might like, but it is accurate enough to provide a good
deal of help in software engineering economic analysis and decision making”. [BOE81]
See https://www.geeksforgeeks.org/software-engineering-cocomo-model/.
See also http://athena.ecs.csus.edu/~buckley/CSc231_files/COCOMO.pdf.
COCOMO has evolved into a more comprehensive estimation model, called COCOMO II. Like its
predecessor, COCOMO II is actually a hierarchy of estimation models that address the following areas:

Application composition model. Used during the early stages of software engineering, when
prototyping of user interfaces, consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.

Early design stage model. Used once requirements have been stabilized and basic software
architecture has been established.
Post-architecture-stage model. Used during the construction of the software.

Like all estimation models for software, the COCOMO II models require sizing information. Three different
sizing options are available as part of the model hierarchy: object points, function points, and lines of
source code.

The COCOMO II application composition model uses object points . It should be noted that other, more
sophisticated estimation models (using FP and KLOC) are also available as part of COCOMO II.

Like function points , the object point is an indirect software measure that is computed using counts of
the number of (1) screens (at the user interface), (2) reports, and (3) components likely to be required to
build the application. Each object instance (e.g., a screen or report) is classified into one of three
complexity levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm . In essence,
complexity is a function of the number and source of the client and server data tables that are required
to generate the screen or report and the number of views or sections presented as part of the screen or
report.
Once complexity is determined, the number of screens, reports, and components
are weighted The object point count is then determined by multiplying the original number of object
instances by the weighting factor and summing to obtain a total object point count. When component-
based development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated
and the object point count is adjusted:

NOP = (object points) x [(100 %reuse)/100]

where NOP is defined as new object points.

To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be derived
for different levels of developer experience and development environment maturity.:

PROD = NOP/person-month

Once the productivity rate has been determined, an estimate of project effort can be derived as:
estimated effort = NOP/PROD

SUMMARY:
Although there are different estimation techniques, their common attributes are: Project scope must be
established in advance; software metrics (past measurements) is used as a basis from which estimates
are made; the project is broken into small pieces, which are estimated individually. Empirical estimation
techniques are used to provide reliable and accurate estimates of the software effort, schedule and cost.
However, it is recommended to use several estimation techniques and compare the results and apply
adjustments on the models used based on local conditions.

BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

ASSESSMENT:
1. Interview a software project manager who has completed a software project and collect software
metrics (LOC-oriented and FP-oriented) needed for the empirical estimation models discussed
above.
2. Using COCOMO, predict the project effort, cost and schedule requirements; and compare your
prediction with the actual project effort, schedule and cost. Discuss the difference.
3. Which do you think is more appropriate to use as metrics for effort, cost and schedule projection,
LOC-oriented or FP-oriented? Why?
 4.6 PROJECT RISK MANAGEMENT

LEARNING OBJECTIVES:
At the end of this chapter you should be able to:

➢ Enumerate software project risks

➢ Describe the process of software project risk management
➢ Perform risk analysis
➢ Develop a risk response plan

OVERVIEW:

One of the main reasons for the failures of software projects is the inability to deal adequately with both
anticipated and unanticipated problems occurring during the execution of the project. A software risk is a
problem occurring during the development of the software and the consequence of that problem.
Software project risk management encompasses activities that deal with the continuous identification,
classification, assessment, prioritization, avoidance, detection, and mitigation of software risks. The
ultimate goal of software risk management is to make timely and informed decisions and take appropriate
risk control actions when anticipated and unanticipated risks occur.

Image Source: Blogzilicus.net

READING MATERIALS:

Risk and Risk Management Process

Risk is a function of how likely and undesirable event will happen; how likely that event will cause loss;
and how serious is that loss. Risk management tackles these by reducing the likelihood of the event
happening; reducing the likelihood of an accident or loss occurring and/or reducing the amount of loss.
The risk management process includes the following activities:
➢ Risk identification
➢ Risk analysis
➢ Risk planning
➢ Risk tracking
➢ Risk control
➢ Risk communication

Image Source: PMISConsulting.com

Risk Identification
The first step in a risk management process involves the identification of risks, which require the expertise
of application domain experts in addition to general project management experience. The early
identification of risks reduces the costs that can be incurred should the risk materialize, and widens option
for available risk mitigation solutions that are less costly, more efficient, and more effective.
Risks can be either system-related or project-related. System-related risks are technical and non-
technical risks related to system elements, including information, people, hardware, and software. These
risks include the following:
➢ The product and its capabilities at various stages of the development process. Examples are (1)
requirement specified is unfeasible, (2) bad performance of a selected design solution, (3)
insecurity of an access control mechanism.
➢ The software development processes, the work environment, and the adopted process model.
Examples are: (1) unfamiliarity of the development team with the adopted process model, (2)
unsuitability of the adopted process model, (3) communication problem and lack of team
coherence.
➢ The development system and the technologies used. Examples are: (1) unfamiliarity of the
development team with the development system, (2) lack of knowledge of the team in regard to
the tools and techniques used.

Project risks are technical and non-technical risks related to project management style, project plan, effort
estimation, risk planning, and project dependencies and constraints. Examples of technical project risks
are: (1) underestimation of effort for scheduled project activities, (2) inadequacy or lack of project
progress monitoring methods, (3) unavailability of third-party software when needed. Examples of non-
technical people-related project risks are: (1) lack of synergy among team members, (2) lack of
communication among various project stakeholders.
Identified risks must be well-documented and maintained. Each risk is assigned to an owner. The owner
is a developer who is responsible for following up on the planning, tracking, and control of the risk.

Risk Analysis
After identifying the risks, they must be assessed and verified for appropriateness and applicability. The
likelihood of their occurrence and their impacts on the project schedule, cost, and quality must be
evaluated either qualitatively or quantitatively. For example, in a qualitatively assessment, the likelihood
ranges from very low, low, medium, high, to very high. The risk impact ranges from negligible, minor,
tolerable, significant, to major. In a quantitative assessment, risk likelihood and risk impact are
continuous, and are used to compute risk exposure as follows:
Risk exposure = risk likelihood * risk impact
For example, the likelihood of a risk is 0.25 (or 25 percent), and its impact is the loss of PhP 100,000,
then the risk exposure is PhP 25,000. Based on the risk exposure, identified risks can then be assigned
priorities. A risk priority can be very low, low, medium, high, or very high. High exposure risks should be
dealt with thoroughly since they will likely be assigned a high priority. Many techniques can be used to
assess the risks and analyze them, including interviews and meeting with internal experts or consultants
in the application domain. A project risks table summarizing all project risks, their likelihoods, impacts
and exposures, can be used to view and sort the risks in order to prioritize them. A typical template for a
risks table is shown in Table 1.0.
Table 1.0 Template for a project risks table

Risk Risk Name Risk Likelihood Risk Impact Risk exposure = RL * RI Risk Priority
ID (RL) (RI)

For more of quantitative risk analysis, see https://projectriskcoach.com/evaluating-risks-using-quantitative-risk-

analysis/.

Risk Planning
A risk response plan must be designed for every risk identified. A risk response plan aims at enhancing
the opportunities to counter the risk and to reduce the threats it poses to the project. The types of risk
actions are developed and prioritized. Risk actions include:
➢ Risk avoidance actions to prevent the risk from occurring. Examples are steps to improve
communications among team members and to increase by 20 percent the efforts estimated for
critical activities in the project schedule to deal with the risk of project delivery delays.
➢ Risk mitigation actions to reduce the risk impact should it occur. Timely and planned actions to
reduce the likelihood and impact of a risk are typically taken when the risk is unavoidable but its
impact could be costly. An example is the development of a disaster recovery plan to deal with
the risk of a natural or man-made disaster leading to the interruption of the project development
team.
➢ Risk acceptance, meaning no action is taken should the risk occur. Typically, very low-impact
and low-exposure risks are accepted and their costs are assumed without further actions.
➢ Risk transfer actions shift the responsibility of dealing with the risk and taking the appropriate
action to a third party should the risk occur. The third party could be an insurance company or a
financial institution. Risk transference is normally considered when dealing with non-technical
risks such as contracts, financing risks, and natural disasters.

The aim of a risk action is to reduce the risk exposure. The risk reduction leverage (RRL) can be
computed for every risk action as follows:
RRL= (Exposure before reduction – Exposure after reduction) / Risk action cost
For example, if a risk action costs PhP10,000 and reduces the risk exposure from PhP 500,000 to PhP
100,000, the RRL would be 40.

Below is an image of a Risk Response Matrix:

Image Source: slideteam.net

Risk Tracking
Risk tracking is an ongoing activity mainly based on the monitoring of the risks by continuously checking
the conditions for their occurrences. The proper implementation of risk actions is also monitored. Risk
tracking techniques include periodic risk status reports and the monitoring of key risk indicators. The early
detection of the imminence of a risk occurrence is desirable because it enhances the preparedness of
the team to initiate, implement, and control the risk actions planned earlier. Once a risk is realized, the
planned risk actions are activated to deal with that risk.

Risk Control
Risk control is part of the overall project control dealing with the proper implementation of the control
actions and risk plan. If corrections to the actions or to their implementations are needed, updates to the
risk management plan are made. Risk control involves risk reassessment, audits, and status meeting.
These risk control activities are normally needed when some identified risks are not being dealt with
according to plan or if the manager notices the occurrence of an unusual number of unanticipated risks.
Risk Communication
Risks are potential problems that have not been seen nor felt but may occur in the future. Risks in a
software development project that are identified, assessed, and planned for must be communicated to
the concerned stakeholders. To properly follow up and control risks, they must be communicated to
various units within the organization, to the appropriate levels of management, and to the client’s
organization. For example, the client must be aware of the risk related to changes to the requirements
and the consequences of such changes on the project schedule. A risk is typically identified by any project
stakeholder. The project manager will review the risk and check its validity. If it is found to be a relevant
risk, the risk is saved in the risk registry. The project review team would then review the risk and prescribe
the appropriate actions. The assigned risk owner (member of the project team) is then responsible for
implementing the risk actions.
A typical template for documenting a risk is shown in table 2.0.
Table 2.0. Template for a risk description

Project Name: Project manager:

Risk ID
Risk description:

Risk originator: Risk origin date:

Risk stakeholders:
Risk likelihood: Risk impact: Risk priority:

Description of risk impact:

Risk owner:

Key risk indicators:

Recommended avoidance actions:

Recommended mitigation actions:

Recommended control actions:

Last risk review date:

Table 2.0 provides a formal risk description for each identified risk earlier identified and analyzed, that
should be communicated to concerned stakeholders. The risk likelihood should indicate whether the
probability of occurrence is low, medium or high. The risk impact should show whether the negative effect
on the project when the risk happens is low, medium or high. The risk priority should indicate whether
the risk is of low, medium or high priority for the project resources. The specified risk owner shall
implement the recommended risk actions.
SUMMARY:
Risks are problems that may not have been felt nor seen but may occur in the future; and when they do
occur, the will have an impact on the project cost and schedule. Software project risks may be related to
system elements, including information, people, hardware, and software; and may also be related to the
project management style, project plan, effort estimation, risk planning, and project dependencies and
constraints. All these risks should be properly identified and analyzed early on during the project initiation
phase. They should be properly documented, communicated and monitored as the project progresses;
and proper risk actions be implemented should they occur.

BOOK REFERENCE/S:
Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

ASSESSMENT:
1. For a simple information system developed for academic requirements, identify the project risks.
The software project may be hypothetical or may be an actual software project.
2. Create a project risks table, where risk analysis is performed for each identified project risk.
3. Create a formal risk description for each identified risk following the template provided in the
lesson.
 5.1 PROBLEM ANALYSIS

LEARNING OBJECTIVES:
➢ Describe problem analysis as part of system analysis.
➢ Utilize problem analysis tools to correctly identify and analyze system problems
➢ Draw fishbone diagram to present analysis of an existing organizational or sectoral problem

OVERVIEW:
Every software development effort starts with analyzing a system problem that can be addressed by a
software solution. The software solution then becomes the computerized or automated system. This
process is called problem or root cause analysis. Hence, we can say that problem analysis is the first
step in systems analysis. It aims to dig the root causes or the ‘real’ problems that lead to the observed
symptoms or effects. The are available tools that can be used to analyze problem or root cause. One of
the widely used tools is the Fish Bone Diagram also called Ishikawa Diagram. The diagram illustrates the
observed effect (negative symptom) as a fish head and the factors that cause it as bone ribs.

Fishbone Diagram Structure (en.Wikipedia.org)

READING MATERIALS:

Fishbone Diagrams (FBD) also known as cause and effect diagrams, and Ishikawa diagrams, are used
in process improvement methods to identify all of the contributing root causes likely to be causing a
problem. It was developed by Developed by Dr. Kaoru Ishikawa at the University of Tokyo in 1943.
Completed Fishbone diagram includes a central spine and several branches reminiscent of a fish
skeleton. It can be used on any type of problem, and can be tailored by the user to fit the circumstances.
The following questions should be answered when analyzing the FBD.

How to Use the Fishbone Diagram for Problem/Root Cause Analysis

Root cause analysis is a structured team process that assists in identifying underlying factors or causes
of an adverse event or near-miss. Understanding the contributing factors or causes of a system failure
can help develop actions that sustain the correction. A cause and effect diagram, often called a “fishbone”
diagram, can help in brainstorming to identify possible causes of a problem and in sorting ideas into
useful categories. A fishbone diagram is a visual way to look at cause and effect. It is a more structured
approach than some other tools available for brainstorming causes of a problem (e.g., the Five Whys
tool, SWOT analysis, etc). The problem or effect is displayed at the head or mouth of the fish. Possible
contributing causes are listed on the smaller “bones” under various cause categories. A fishbone diagram
can be helpful in identifying possible causes for a problem that might not otherwise be considered by
directing the team to look at the categories and think of alternative causes. Include team members who
have personal knowledge of the processes and systems involved in the problem or event to be
investigated.

Directions:
The team using the fishbone diagram tool should carry out the steps listed below.
● Agree on the problem statement (also referred to as the effect). This is written at the mouth of the “fish.”
Be as clear and specific as you can about the problem. Beware of defining the problem in terms of a
solution (e.g., we need more of something).
● Agree on the major categories of causes of the problem (written as branches from the main arrow).
Major categories often include: equipment or supply factors, environmental factors,
rules/policy/procedure factors, and people/staff factors.
● Brainstorm all the possible causes of the problem. Ask “Why does this happen?” As each idea is given,
the facilitator writes the causal factor as a branch from the appropriate category (places it on the fishbone
diagram). Causes can be written in several places if they relate to several categories.
● Again ask “Why does this happen?” about each cause. Write sub-causes branching off the cause
branches.
● Continues to ask “Why?” and generate deeper levels of causes and continue organizing them under
related causes or categories. This will help you to identify and then address root causes to prevent future
problems.

Tips:
● Use the fishbone diagram tool to keep the team focused on the causes of the problem, rather than the
symptoms.
● Consider drawing your fish on a flip chart or large dry erase board.
● Make sure to leave enough space between the major categories on the diagram so that you can add
minor detailed causes later.
● When you are brainstorming causes, consider having team members write each cause on sticky notes,
going around the group asking each person for one cause. Continue going through the rounds, getting
more causes, until all ideas are exhausted.
● Encourage each person to participate in the brainstorming activity and to voice their own opinions.
● Note that the “five-whys” technique is often used in conjunction with the fishbone diagram – keep asking
why until you get to the root cause.
● To help identify the root causes from all the ideas generated, consider a multi-voting technique such
as having each team member identify the top three root causes. Ask each team member to place three
tally marks or colored sticky dots on the fishbone next to what they believe are the root causes that could
potentially be addressed.

The value of using the fishbone diagram is to dig deeper, to go beyond the initial incident report, to better
understand what in the organization’s systems and processes are causing the problem, so they can be
addressed. To create a Fishbone Diagram, you can use any of a variety of materials like a white board,
or a flip chart to get started. You may also want to use “Post It” notes to list possible causes but have the
ability to re-arrange the notes as the diagram develops. There are also several software packages that
can be useful in creating a Fishbone Diagram, including Microsoft Excel, EngineRoom for Excel and
EngineRoom software.

Source :Adapted from https://www.cms.gov/medicare/provider-enrollment-and-

certification/qapi/downloads/fishbonerevised.pdf. Click the link for detailed example on how to use FBD
to identify root causes.

Below are images of fishbone diagrams used in real-life in problem analysis:

Fishbone Diagram Example (https://www.edrawsoft.com/fishbone-examples.php)

Fishbone Diagram Example (https://www.moresteam.com/toolbox/fishbone-diagram.cfm)

Fishbone Diagram Example (https://www.slideshare.net/amreeksingh1977/fish-bone-examples-ppt)

ASSESSMENTS:

1. Analyze the given examples and extract the steps in drawing and using the FBD
2. Following the guidelines, draw your own FBD for an existing organizational (or unit) problem or a
problem of a societal sector (people group). Evaluate if the root cause/problem can be addressed
by a computerized system.
3. If the problem can be addressed by a computerized/software solution, create a formal problem
and solution statement describing what you analyzed and the proposed solution on how the root
causes can be addressed by the software.
 5.2 USER REQUIREMENTS ANALYSIS

LEARNING OBJECTIVES
➢ Create a product vision and project scope document
➢ Explain the difference between functional and non-functional requirements (NFRs)
➢ Explain the requirements engineering process steps
➢ Apply requirements elicitation techniques to identify functional and non-functional requirements
of a proposed software solution
➢ Develop a use case model of a proposed software solution
➢ Validate software requirements identified
➢ Write initial software requirements specifications (SRS) document using IEEE format

OVERVIEW:

The first phase of a typical software development process model is the software analysis phase which
focuses on the definition of what the software under development is supposed to do. Software analysis
involves defining the scope of the software project, capturing and documenting it’s users’ requirements,
knowing the various constraints that have to be met, and understanding the interfaces with external
systems, entities and users. The steps in software analysis involve the following: (1) project scope
definition; (2) user requirements analysis; (3) software requirements specification; (4) software
requirements review and validation.

READING MATERIALS:

Project Scope Definition

A product vision and project scope document defines clearly the project scope. To build an effective
analysis model, we should adopt and use a well-structured requirements engineering process, which
starts normally from the approved product vision and project scope document. This document facilitates
in establishing the business requirements and aligning them with the software requirements specification
(SRS). The product vision provides the business limits and focus to the project scope. A vision and scope
document template typically includes three main sections: (1) business requirements and context; (2)
product vision; and (3) project scope and limitations.
Business requirements and context section includes the following:
1. brief description of the product rationale and business opportunity for the product;
 2. main business objectives (financial or technical benefits to users) and some quantifiable success
criteria for the objectives;
3. business risks associated with the business requirements, and the risks management activities;
4. types of product users and other stakeholders;
5. context and environment in which the product will be operating, that will determine non-functional
requirements such as security, performance, availability, and business continuity requirements.

Product vision section includes the following:

1. clear statement of the product goals that capture the views of all stakeholders and users and that
clearly show the financial and non-financial business benefits over other existing systems;
2. main functionalities and features of the product in which the detailed functional requirements in
the SRS must be traced back;
3. all the assumptions that are made and the dependencies that exist which are the external
conditions that have to be met.

Project scope section includes the following:

1. scope of current release or the functionalities and features that will be included in the current
release;
2. scope of future releases or the functionalities and features that will be included in the future
releases or versions of the product;
3. limitations or the functionalities and features that will not be offered by the product in any of its
releases.

Table 1 Template for a software product vision and project scope document

Title Page

Change History

Preface

Table of contents

1. Business requirements and context

1.1 Product rationale and business opportunity
1.2 Business objectives
1.3 Business risks
1.4 Stakeholders
1.5 Context and environment
2. Product vision
2.1 Statement of product goals
2.2 Main features
2.3 Assumptions
3. Project scope
3.1 Scope of current release
3.2 Scope of future releases
3.3 Limitations

Annexes

Index
After the project scope has been clearly defined, the next step is to build the analysis model by specifying
and documenting user requirements.

Requirements and Requirements Engineering

What are requirements?

A requirement is a feature of a system or a description of something the system is capable of
doing in order to fulfill the system’s purpose. A requirement can be functional or non-functional.
A functional requirement describes an interaction between the system and its environment. It
includes functionalities and services that are needed by the users to meet their needs and to
achieve their business objectives. A non-functional requirement or constraint describes a
restriction on the system that limits our choices for constructing a solution to the problem, and
are mainly quality requirements related to the attributes of the offered functionalities, such as
software usability, reliability, performance, and supportability.
Types of Requirements can be the physical environment of the system, functionalities the system need
to provide, system’s interfaces, documentation required, data input and output for the system, resources
for system’s operation, security levels and features needed, quality assurance.

Meaning of Requirements Engineering

Along with a clear product vision and project scope document, a well-defined requirements engineering
process must be used to produce software requirements. Obtaining good software requirements is crucial
towards building reliable and usable software systems because requirement is the foundation upon which
a software architecture and design is developed. Accurate requirements save time and money later in
the software development and maintenance activities hence, there is a need for structured and well-
defined processes to develop and manage requirements. Requirements engineering is a subset of
software engineering that deals with the use of sound techniques for the development and management
of software requirements. Requirements development includes four main steps: (1) elicitation, (2)
analysis, (3) specification, and (4) maintenance. Requirements management deals with project
management issues and some technical issues supporting the proper management of requirements such
as:(1) prioritization, (2) maintenance and change management, (3) negotiation, and (4) quality assurance
of requirements.

Activities in Requirements Engineering

1. Requirements elicitation
2. Requirements analysis or modeling
3. Requirements specification
4. Requirements review and validation
5. Requirements approval
 6. Requirements management

How to Elicit Requirements?

Requirements elicitation involves the extraction, discovery or invention, acquisition or elaboration of
the stakeholder’s needs. The person performing the elicitation step is called system analyst, business
analyst, requirement engineer, or requirement facilitator. Requirements elicitation uses various proven
techniques for seeking, extracting, acquiring, and documenting software requirements.
Activities in requirements elicitation
1. understanding the application domain and the current environment or system
2. identifying sources of requirements and the stakeholders
3. selection of appropriate techniques to use for requirements elicitation
4. gather inputs from problem owner or client, stakeholders, documentation and standards from the
application domain or the interface information from other systems

Elicitation Techniques
1. Interviews or questionnaires
2. Task analysis and scenarios
3. Preliminary requirements domain analysis
4. Brainstorming
5. Workshops, meetings, and/or observations
6. Ethnographic assessment
7. Practicing
8. prototyping

Interviewing. An informal technique that engages various participants, and is used to establish the
mission statement and goals of the system being developed; it can either be structured, unstructured, or
hybrid. Structured interview requires a set of questions prepared ahead of time and can be distributed to
the participants before the interview; whereas in unstructured interview, questions are developed
dynamically as the interview progresses. Hybrid interviews are formatted with a fixed set of questions
and impromptu questions asked during the interview.
Questionnaire/Survey. Is an instrument used to poll the participants and stakeholders and to obtain
their thoughts on the issues related to the system. The questions have to be clear, concise, and relevant;
and can be multiple choice, true and false, or open-ended questions (must be limited). The answers to
the questions can be used by the requirements engineer to identify initial conflicting requirements that
need to be resolved later.
Task Analysis. Is a technique based on the identification of the uses of the system and the description
of the interactions between the users and the system (scenarios or flow of events) .Task analysis can be
performed in a top-down manner in which initially high-level system tasks are identified, and then refined
into lower level tasks and sub-tasks for which scenarios have to be elicited. Task analysis requires
domain knowledge expertise and an understanding of the tasks performed by similar systems.
Preliminary requirement and domain analysis techniques. Starts from an initial set of requirements
proposed by the expert requirements engineer, and are passed to the various stakeholders for
discussion. In this case, the engineer must be an authority in the application domain.
Brainstorming. Are informal meetings in which stakeholders meet and discuss the various desirable
functionalities and services to be offered by the system, but is not meant to make decisions. All ideas are
encouraged and inventive ideas that might or might not be feasible are generated. The merits of the ideas
are discussed by the requirements analysts and other participants later in more formal settings. The end
product of a brainstorming session is an initial set of software requirements.
Group meeting. Are informal meetings that include all participants and stakeholders to interact at the
start of the elicitation process. Cohesiveness, openness, and transparency are the key communications
features during group meetings.
Requirements workshop. Formal setting used to elicit software requirements participated by a
facilitator, a technical writer, the requirements engineer and representatives from the client and user
group. The aim of a requirements workshop is to reach an agreement on a working draft of the software
requirements. The workshop must be prepared thoroughly ahead of time; expectations from each
participant must be explicitly known; the best case and worst case scenarios must be elicited.
Ethnographic assessment. Is used by the requirements engineer to gain a greater understanding of
the problem domain by being an active or passive participant in the working of similar systems and their
user interfaces. The engineer can go through the various scenarios and business flows, or he can just
observe the users’ activities without interference .
Prototyping. Is an effective tool for eliciting and validating requirements because of the client and users’
active participation in developing the software requirements through their inputs. The requirements
engineer, with possible inputs from the users, can develop an initial prototype of the system showing the
main elements of the system functionalities. The prototype is then evaluated and modified interactively
with the users’ inputs. Prototype-based requirements are faster to elicit and include fewer errors than
requirements developed using other elicitation techniques. However non-technical managers have the
tendency to consider them overhead and they are tempted to use them as a basis for building actual
systems, or they might be misled to conclude that the project is nearly complete.
The exact combination of requirements elicitation techniques used depends on several factors, among
which are the type and size of system being developed, and the expertise of the requirements engineer.

Modeling the Elicited Functional Requirements

Functional requirements elicited are used to construct a use case-based requirements model. It is a
requirements model based on the use case modeling approach. This is termed as the analysis model.
The identification and documentation of the use case model is performed using the various elicitation
techniques earlier specified, by which the actors, scenarios, and use cases are elicited. Other approaches
to describe functional requirements include the specification of the services offered by the system
(functional specification); and the specification of the user-interfaces used to interact with the system.
This chapter concentrates on the use case-based approach. Use case diagrams (UCDs) are introduced
in the Unified Modeling Language (UML) as the primary diagram for building the use case model or
viewing the system being developed, in terms of the system’s functionalities and interactions with the
external environment.
Participants in the development of the use case model include customers paying for the system
development, users, managers, requirements engineers, designers, programmers, testers, and technical
writers. To elicit the actors, the analyst has to identify the following:
(1) user types or groups that are supported by the system and benefits from its services. The services
represent the main business functions provided by the system
(2) User types or groups that perform administrative, maintenance, and support services which
include among others, system administrators and security managers.
(3) external systems that are needed to interact with the system under development

An actor is a role that a user plays in the system. It is important to distinguish between a user and an
actor (better thought of as a role). A user of the system may play several different roles through the
course of his, her or its job (since an actor may be another system). Examples of actors are salesperson,
manager, support person, and web store system. It is possible that the same person may be a sales
person and also provide support. When creating a use case model, we are not concerned with the
individuals, only the roles that they play. An Actor is any external entity that makes use of the system
being modeled. This means that any person, device or external system that have access to, or make use
of the information and functions present in the system being modeled can be considered an actor.
A use case is a complete functional unit that is offered by the system being modeled. A use case must
primarily satisfy some functional requirements. The functional requirements are listed as the steps
followed in the use case; and typically, five to seven steps are included in a use case. In addition, a use
case might have to meet certain constraints or NFRs.
A use case is represented by an oval with the use case name inside it. A use case is normally described
using a verb and a noun. The verb identifies what is being done and the noun identifies to what entity the
verb applies to. An actor, interacting with the use case, is linked with that use case. An actor is
represented with a stickman with the unique actor name next to it. A line represents the fact that the
actor and use case communicates. An optional directed line with an arrow pointing at the use case
indicates that the actor initiates or triggers the communication with the use case, to request a service
through that use case. A plain line indicates a two-way communication between the actor and the use
case, whereby the actor initiates or triggers the communication with the use case to request a service
through that use case; and the use case communicates with the actor to prompt the actor for input or a
decision, or to inform the actor of events or decisions made by the system. An actor can communicate
with several use cases and many actors can communicate with a single use case.
Within use cases there are a number of relationships that can be modeled:

Association Relationship
On a use case diagram, associations are drawn between actors and use cases to show that an actor
carries out a use case. A use case can be carried out by many actors and an actor may carry out many
use cases.
In the diagram below, the actors are shown as the green stick figure shapes on the left, the use cases
are the blue ellipses, and the associations between them are represented by the connecting lines. The
interaction between the actors and the use cases is called association relationship. In the example
below, both the developer and the stakeholder are responsible for specifying the system roles, but only
the developer creates the model.

Figure 3.1 Association relationship

Use cases can also be related to each other with three different links that represent their relationships:
(1) includes, (2) extends, and (3) generalization links.
Generalization Relationship
When a use case describes a variation on another use case, use a generalization link. In the example
below, the use case limit exceeded describes a situation in which the usual scenario of online purchase
is not performed. Use cases that generalize another use case should only specify an alternative, even
exceptional scenario to the use case being generalized. The overall goal of the use cases should be the
same.

Figure 3.2 Generalization relationship

Includes Relationship
To reduce the complexity of a use case, the requirements analyst breaks down a complex use case into
smaller ones by factoring out some behavior from the original use case and then include that behavior in
a new use case. The original use case and the newly created one are then linked using the include
relationship. It is represented by a dashed arrow starting from the original use case and ending at the
new use case. The diagram below shows the use of the includes link. Both invoice purchase and online
purchase include the scenarios defined by purchase valuation. In general, the includes link is used to
avoid repetition of scenarios in multiple use cases.

Figure 3.3 Includes Relationship

Extends Relationship
Another way of reducing the complexity of a use case is by factoring out all the behaviors that deal with
either exceptional or abnormal conditions or optional behaviors. In this case, you would want to describe
a variation on behavior in a more controlled form. Exceptional or abnormal behaviors normally interrupt
the progress of the original use case; examples of which include timeout or failures occurring during the
progress of the original use case (also called base use case) or cancelling the use case execution.
Optional behaviors can be selected by one or more of the use case actors during the progress of the
original use case; an example of which is seeking help during the progress of the original use case. In
such instances you can define extension points in the extended use case. In the example below, search
by name is said to extend search at the name extension point. The extends link is more controlled than
the generalization link in that functionality can only be added at the extension points. The extends
relationship is represented by a dashed arrow starting from each newly created use case to the original
use case.

Figure 3.4 Extends Relationship

Another advantage of recognizing the common behaviors and using them in include and extend
relationships and including them in separate use cases is the possibility of reusing them in the same
requirements or in future requirements specifications. Hence, each use case in the use case model need
to be fully described and documented showing its detailed specifications. A typical way for describing
and documenting a use case is shown in Table 3.2.

Table 3.2 Place Order use case description

Identification UCx

Name Place Order

Created by J. Smith, January 5, 2006

Date created

Updated by

Date of update

Actors involved Triggering actor: Buyer

Secondary (affected) actors: Finance and Warehouse

Brief description This use case is started by the buyer to construct electronic basket
with books selected from the catalogue

Assumptions Catalogue includes available books

Preconditions Buyer could be a registered or unregistered individual user

Buyer could be a registered institutional user

Registered buyer has already logged on successfully

Postconditions Electronic basket is created and closed prior to placing the order

Priority High

Frequency of use High (one hundred orders per day during the first year)

Flow of events (or steps) 1. Browse book catalogue

2. Select books
2.1 Select a book and quantity
2.2 Confirm availability
2.3 Compute current total cost
2.4 Repeat 2.1 through 2.3 until desired books are
purchased
3. Confirm order
4. Provide payment information and get confirmation of
payment

Alternative flows Use case can be interrupted at any point by the use cases E1 to E7.
Use case is discontinued when interrupted by the use cases: E1 to
E4. However, the use case continues after being interrupted by use
cases E5 to E7.

Used use cases Add book to basket

 (Include) Remove book from basket

Modify order

Clear order

Save order

Send order

Provide payment information

Check credit information

Check book availability

Interrupting or extending use cases E1: Handle timeout

(Extend) E2: Handle communications failure

E3: Handle server failure

E4: Handle cancel

E5: Handle invalid payment information

E6: Handle book unavailability

E7: Help place order

Non-functional requirements Refer to Section 3.5

Remarks and issues

To illustrate use case modeling, consider the following business scenario in Example 3.1:
Example 3.1

A student has to compile a course schedule for a semester. In order to do this, the student has to register
for two primary courses and four secondary courses. The faculty wants all tasks to be automated within a
system in such a way that the students can compile their course schedules on their own by using only the
system. To this end they have tasked a business analyst to model the business scenario for them.

To compile a use case model the business analyst has to identify the actors and use cases involved in the
system. To start - the actors defined are the students who will register. This also leads to the obvious
functionality; that of being able to register for a course.

In order to register for the courses the students will need to reference a list of courses available. Such lists
are already available from an existing system: the course catalog system. As it does not form a part of our
current system, it can be considered an external entity and as such are modeled as an actor.

In digging through the requirement, the business analyst is informed that the processes for registering for
primary and secondary courses are subtly different. This necessitates the definition of two different
functions: Register primary course and Register secondary course. Once all courses are registered the
student has to be able print out the course schedule, although this requirement is an optional function.
 A meeting with the faculty reminds the business analyst that the system has to have the ability for students
to to log in with their different user identification codes to be able to create course schedules. This
immediately highlights the requirement for the students to be created as a user and some sort of
administrator to administer the user identifications. All use of functions in the system must also be logged
via the mechanism of an audit trail.

Building the use case diagram

Step one. With all of the information available identify the actors. From the above- mentioned the
following are applicable:
1. Student - primary actor to use the registration function
2. Course catalog system - provides information regarding the available courses
3. Administrator - Creates user ID's for the students in order to log in.

Step two. Identify the functions:

1. Register course - primary function to allow students to register for courses
2. Register primary course/Register secondary course - child functions of the above mentioned
function
3. Login - the function that allows the students to gain access to the register course functions.
4. Register user - a function whereby the users of the system can be defined.
5. Create audit trail - to log the individual interactions with the system
6. Print course schedule - to optionally print the course schedule

(Note. The Administrator must be able to log in as well in order to create the users of the system. We can
handle this in two ways: The administrator may have an association with the Login function, or a
generalized actor may be created: Registered user, who will have common characteristics to both
Student and Administrator, but each of the specialized actor will have behavior that is unique to them.)
Step three. Model the relationships where the users (actors) will use functionality (use cases) as follows:
Actor : Registered user
Use case : Login system
Relationship : Association - The registered user will make use of the functionality of this use case.
This implies that the Administrator role and the Student role will use this function via the Generalization
relationship with Registered user.

Actor : Student
Use case : Register course
Relationship : Association - The Student is associated with the use of this use case (Register
course).

Use case : Print course schedule

Relationship : There is no direct relationship visible, but the optional use of this use case is
implied through the extend relationship. The condition under which the use case is executed is
documented under the base use case: Register course

Use Case : Register primary course

Relationship : There is no direct relationship visible, but the use of this use case is implied through
the Generalization relationship. The use of this use case, follows from the concept that the behavior (and
the use of) is inherited from the parent use case: Register course.

Use Case : Register secondary course

See previous.

Use Case : Create audit trail

Relationship : There is no direct relationship visible, but the use of this use case is implied through
the Include relationship.

Actor : Course catalog system

Use case : Register course
Relationship : The Course catalog system provides information to the use case and as such is
associated to the use case: Register course. The Generalization relationship to Register primary course
and Register secondary course implies that the course catalog system is referenced by these uses cases.

Actor : Administrator
Use case : Register user
Relationship : Association - The Administrator is associated with the use of this use case
(Register user).

The resulting diagram will look something like this:

You can explode a use case into a new use case diagram. For example, the use case Register course
may require further specification as you move into the design. You can create a sub-diagram within any
use case to help clarify and understand the tasks involved. A use case represents a goal of a user, not
an atomic programming operation. The use case design should be simple and should help to clarify the
user's goals and expectations for the system.
After completing the use-case based requirements model, the use cases are reviewed during formal
review meetings attended by authors of the use cases, requirements engineers, customer’s, user’s, and
developer’s representatives. A recorder who is not technically involved in the discussions records the
decisions and modifications to be made to the requirements model. A review moderator ensures the
smooth progress of the discussions during the review. The customer or user will determine if the use
cases are understandable and reflect the desired behavior. However, a use case is clear and complete
if, when passed to a designer and a tester, it can be used clearly as a good starting point to begin the
design and to produce a test procedure that can determine if the use case implementation ca be
accepted.
Eliciting Non-Functional Requirements (NFRs)
Non-functional requirements (NFRs) are requirements that are related to the quality aspects of the
system being developed; and cover both technical and non-technical aspects of the system and its
functionalities. While eliciting and modeling the functional requirements using the use case modeling
approach, the analyst must also elicit the NFRs that are associated with each use case (use case-specific
NFRs). In addition, the analyst must also identify and elicit generic system-wide NFRs which are use
case independent and apply to the entire software system. For example, security requirements can be
either use case-specific or generic. However, cultural, political, and standards conformity requirements
are mainly generic requirements since they normally apply to the system as a whole. NFRs can be either
technical or non-technical. Technical NFRs are chiefly quantifiable and possibly automatically verifiable
requirements. Non-technical NFRs are mostly non-quantifiable and only verifiable using a non-
automated review process. The types of requirements affect the whole software architecture and can
impose or limit the possible design or architectural choices. The proper elicitation of NFRs is critical
because the types of requirements can conflict or affect each other; in addition, they can affect other
functional requirements. For example, a security requirement can affect the performance of the software
negatively, requiring, for example, the additional exchange of messages, and can also require additional
functional requirements. NFRs can also be a main concern either to the user or to the developer. For
example, testability is an NFR that affects the developer predominantly because it requires additional
effort for developers to make the system testable, which has a positive and indirect effect on the reliability
of the software, a technical NFR of particular interest to the user. On the other hand, performance is an
NFR that mainly affects the user because response time delays and lack of memory are noticed by the
user. However, the developer is also affected because meeting performance requirements must be dealt
with at various phases of the software development process. Table 3.3 shows the classification of NFRs.
Table 3.3 Classification of NFRs

Mainly a user concern Mainly a developer concern

Technical NFRs Interoperability Implementation

Performance Installation

Reliability Maintainability

Availability Operability

Robustness Portability

Security Reusability

Safety Scalability

Usability Testability

User friendliness Traceability

Non-technical NFRs Business integrity Legal

Cultural Conformity to standards

Political
Normally, non-technical NFRs are generic, such as standards conformity requirements that are system-
wide requirements. On the other hand, technical NFRs can be either system-specific or use-case specific.
For example, various performance requirements can be attached to multiple use cases. As evident in the
discussions in the beginning chapters, some of the NFRs can be considered software quality attributes
that are mainly of interest to the developer but can have a tangible impact on the users. NFRs are
essentially technology-independent and must not attempt to prescribe or impose a technical solution.

Technical NFRs
To elicit technical NFRs, the analyst, client, and user must work together to consider each type of
requirement thoroughly. One approach is to first consider the types of requirements that are mostly
system-wide requirements such as usability and maintainability requirements. Then, proceed to those
requirement types that can be partly use case dependent, such as security and performance. In this way,
the rework of the requirements from generic to specific ones is minimized.
Interoperability requirements impose constraints on the types of systems (hardware or software) with
which the software has to interface. An example of interoperability requirement statement: The system
must be able to interface with all printers manufactured by ABC Company. This imposes some
dependability on the proper specification and implementation of the interface with the printers. The
requirements are indicative of some potential external risks to the development process.
Maintainability requirements impose constraints related to the ease with which the software can be
fixed, adapted to new environments and technologies, or expanded. To meet the requirements, there can
be various technical and non-technical measures that need to be taken. Technical measures are related
to the development environment and tools used as well as the development methodologies and models
adopted. Non-technical measures include hiring decisions and appropriate developers training program.
Operational requirements impose constraints on both the physical and logical environments in which the
software under development will operate, such as: characteristics in which the servers are physically
located, minimum speed of the network connections, the operating systems that are compatible, and the
hardware devices with which the software interfaces.
Performance requirements impose some technical constraints on the response time delays, throughput
of the system, and memory requirements. Response time delays can be either system-wide, (for
example, putting an upper limit on the maximum response time delay for all system functions) or use
case-specific (requiring different upper limits, depending on the individual function or use case). Similarly,
throughput requirements can be either system-wide or use case-specific. A throughput-based use case-
specific performance requirement might be: The maximum memory needed to run the system shall not
exceed 2MB of RAM.
Portability requirements impose some conditions related to the future deployment of the software
system. An example would be: The system should be able to run under Android OS with the least
development effort. To meet this requirement, many constraints related to the development environment
and the implementation programming language used have to be imposed.
Reliability requirements impose some values related to the reliability of the software such as : mean
time between failures (MTBF) or the maximum time allowed for failures over a period of time. Imposing
an upper limit on the downtime of the software, indicating an acceptable level of failures can be
considered availability requirement which is part of security requirements discussed later.
Reusability requirements impose constraints on the development of the system related to the degree of
reuse. There are two types of reuse: development with reuse and development for reuse. Development
with reuse aims at developing software faster by using existing software components. Components that
are of good quality also help the reliability of the overall system. Development for reuse aims at producing
highly maintainable software that is typically made use of reusable components that can be reused in
future projects by the same team or other development teams. A development for reuse requirement help
the maintainability of the software system and can impose specific decisions related to the software
development methodologies used (i.e. object-oriented or component-based methods and development
tools only)
Robustness requirements impose constraints related to the way the software handles abnormal and
erroneous inputs and operational conditions. They address the software behavior with respect to error
recoverability and fault tolerance and can be system-wide or use case-specific. An example of a system-
wide robustness requirement is: The system must recover from power failures and continue operating
without any side effects on the currently executing transactions. An example of a use-case specific
requirement is: Completing the Create Supplier use case shall be guaranteed even in the case of a
database server failure. Robustness requirements should not state how to achieve software robustness
or suggest a particular technological solution to do it.
Safety requirements are needed when the software being developed deals with safety-critical issues
such as aviation software or power and chemical plants control software. The safety requirements must
address and require the enforcement of safety standards that are known in the particular application
domain. An example of safety requirements statement is: In the case of software failure, a safety
procedure XYZ must be activated immediately to ensure no chemical leakage takes place.
Scalability requirements impose constraints on how the software system should scale up to a high-input
load at all interfaces. An example scalability requirement might be: The system must be able to
accommodate a maximum of 150 users logged on and performing all types of transactions. This
requirement can force specific architectural design (implementation and deployment) choices on the
development team. Scalability requirements are quantifiable and are normally verified during load testing
(See chapter on Testing).
Security requirements are critical and need to be identified early in the software development process.
The four main security concerns are: (1) confidentiality, (2) integrity, (3) availability, and (4) accountability.
Confidentiality requirements are access-control related requirements that include identification,
authentication, authorization and physical protection; which can be either system-wide or use case-
specific. The client can require that certain functionalities (or physical elements) are only accessible by
identified, authenticated, and authorized users, and other functionalities (or physical elements) can be
publicly and unanimously accessible.
Integrity concerns are addressed using integrity, immunity, and privacy requirements. An
example of privacy requirement statement is: The software shall allow a registered user to have control
over its own private information. An immunity requirement might state that no files can be attached to a
customer profile without being disinfected with the software. An integrity requirement can be either
system-wide or use case-specific. An example of a system-wide integrity requirement might state that all
files saved by the software must be tamperproof so that any malicious and unauthorized modification of
a file shall be detected.
Availability issues are dealt with using the survivability and physical protection requirements. A
survivability requirement can be applicable system-wide, such as the system shall continue to provide its
own functions even if one node fails. It can also be a function-specific or use case-specific, for example:
the User Validation shall always be performed regardless of some network nodes failures. A physical
protection requirement that addresses availability concerns might state that the database servers shall
be protected in fireproof data centers.
Accountability concerns are dealt with using non-repudiation and standards conformity
requirements. An example of a non-repudiation requirement is: the software shall preserve a tamper-
proof record of every privileged access to the system. Accountability requirements can be either system-
wide or applicable to specific use functions or use cases. Standards conformity requirements are normally
system-wide. An example of a standards conformity requirement could be: the software and the
environment in which it operates shall conform to the ISO 17799 standard.

Although security requirements are considered to be NFRs, some of them must be implemented by first
identifying the appropriate security-related functional requirements. For example, identification,
authentication, and authorization requirements are considered by introducing a Logon use case as a
functional requirement. Other researchers have introduced the idea of a misuse case in which the
involved actors are called misusers. A misuse case represents the abnormal behavior of an attacker or
misuser and specifies the software reaction to the specified misuse.
Testability requirements impose constraints on the future testing of the developed software. Testability
is defined as the ease with which testing can be performed, leading to the ease of maintenance (applying
changes); these two are positively correlated. Ideally, this requirement is quantifiable. An example of
testability requirement is: testing the software must be completed in 36 hours. This requirement imposes
some constraints on the test automation and the tools used for testing, considering the testing time
constraint given.
Traceability requirements impose constraints on the ease with which the software is traceable. This
requirement has two types: (1) traceability of the different parts of the software development process
deliverable; (2) traceability of the software during its execution. The first type refers to the ability to link
every aspect of software deliverables forward and backward. For example, each module in the software
design can be traced backward to a requirement specifications document, or forward to a particular piece
of code or test cases, enhancing the software maintainability (maintainability requirement). An example
of statement for this type is : functional requirements must be traced forward in the design, code and
testing documents. In the second type, traces collected during the execution of the software, for testing
and debugging purposes, thus, enhancing the software testability and help meet the auditability and non-
repudiation aspects of security requirements. Example statement for this type is: all activities of an admin
user session must be recorded by the system.
Usability requirements address the constraints imposed by the client with regards to the user community,
the objective of which is to make the software easy to use by the various users interacting with it. These
requirements are normally elicited by first knowing the intended users and their backgrounds and
characteristics. Example of a system-wide usability requirement states that: the software must be easy
to use by 7- to -9 year-old children. A use case-specific quantifiable usability requirement could be: eighty
percent of students between ages 10 and 14 must be able to create a demo within thirty minutes.
User-friendliness requirements impose constraints on the user experiences when interacting with the
software; these requirements can have implications on the functional requirements and the graphical
user interface design decisions. The availability of context-sensitive help versus generic help, a forgiving
and courteous interface, and the ease of navigability are examples of user-friendliness requirements.
Usability and user-friendliness requirements complement each other and are often seen as equivalent
because ideally, a highly-usable system is normally a user-friendly system; although that is not always
the case.

Non-technical NFRs
These requirements are normally system-wide. However, it is possible to have a system with two types
of users, admin users and normal users, with cultural requirements imposed only on normal users.
Cultural and political requirements address the cultural and political constraints that have to be
considered when developing the software. The analyst and client must be aware of the cultural
sensitivities of the countries in which the software will be deployed and used; such as language use, use
of symbols, and politically offensive contents. Failure to properly elicit the requirements can affect its
acceptability and market penetration and thus, several other versions of the software might have to be
developed and deployed.
Legal and regulatory requirements address the legal and regulatory issues related to the software.
The software and the software process by which it is developed should adhere to local and international
laws. For example, for national security concerns, the development team must not include people that
have resided in certain countries. Other requirement might be that the software is in line with copyright
law and regulations. If overlooked, the requirements can lead to lawsuits and criminal investigations
affecting the economic feasibility and reputation of the development company.
Standards conformity requirements indicate the standards that must be followed while developing the
software. Internal standards that are developed by the software development company can include
coding, testing, and documentation standards and templates. The developer and client must be aware of
specific country standards that might have to be followed. If the military is one of the software
stakeholders, military standards exists and need to be followed. Industry-specific standards exist for
health, finance, construction, and education sectors, among others. Professional standards can also be
referred to such as the IEEE standard for developing Software Requirements Specifications (SRSs).
International standards, such as those developed by International Standard Organization (ISO) and
International Telecommunications Union (ITU) can also be used as part of the standard conformity
requirements. Non-adherence to known and relevant standards and the failure to meet them can lead to
unusable software or a delayed release of the software.
NFRs can be documented separately in the software requirement document if they are generic but if they
are specific to a particular use case, they can be attached to the use case description thru the constraints
section.

Requirements Validation
After specifying all requirements, they must be validated prior to refining them The requirements
validation process cannot be automated and so the most effective way of validating requirements is by
using good communication skills, both verbal and written, for eliciting and reviewing requirements. Ideally,
requirements, specially the NFRs, should be quantifiable. When writing requirements, the requirements
engineer must make sure that the produced requirements possess good qualities.

Below is the IEEE standard’s desirable properties of software requirements:

• Correctness • Modifiability and maintainability

• Completeness • Testability

• Clarity and comprehensibility • Traceability

• Non-ambiguity • Verifiability

• Consistency • Reusability

• Feasibility • Ranking for importance and criticality

Correctness. Requirements, when implemented, should reflect the behavior expected by its users.
Completeness. Requirements should consider all functional and non-functional aspects of all tasks
expected to be performed by all its users.
Clarity and comprehensibility. Requirements should allow all stakeholders to understand them and,
consequently, to pass an informed judgment on their correctness.
Non-ambiguity. Requirements should have a unique (single) interpretation by all its stakeholders.
Consistency. One requirement should not impose some restrictions that conflict with other requirements
and affect their validity as mostly in the case of NFRs. For example, a usability requirement can be in
conflict with performance requirement.
Feasibility. Requirements must be implemented using the available time and technology (technical
feasibility), and the requirements’ automation or inclusion within the system must be financially rewarding
(economic feasibility).
Modifiability and maintainability. Requirements must be documented in a structured and well-
presented manner.
Testability. Requirements must support testing in a given test context. Requirements, in order to be
testable, need to be consistent, complete, unambiguous, quantitative, and verifiable in practice (even
with limited resources).
Traceability. Requirements must be easily identified and referenced; and the origins must be known.
Verifiability. Once implemented in the system, checking whether the requirement is met, must be
feasibly verified either manually or automatically.
Reusability. Requirements must be written or documented in a way that helps its reuse in future software
projects.
Ranking for importance and criticality. A requirement must be ranked for its importance for the
success of the current version of the software under development. A requirement must also be ranked
for its criticality with respect to the levels of risks that can hinder its fulfillment.
Approaches in Requirements Validation
Requirements are validated using two approaches: (1) synthetically or constructively during their
development; and (2) analytically after having been developed. These two complement each other and
there is a need to use both of them to ensure good quality requirements. In the synthetic approach, the
process by which requirements have been obtained must be structured in a way to eliminate or minimize
requirements errors with the use of industry-proven guidelines, templates and standards, and elicitation,
formal specification, and prototyping techniques. It involves some degree of automation but still relies on
human interactions. Once the requirements are developed, analytic validation techniques must follow.
The analytical approach is based on requirements inspection and walkthrough processes. The
processes are used to ensure the various desirable properties of requirements, including correctness,
completeness, non-ambiguity, clarity, feasibility, modifiability, and verifiability. The efficiency and
effectiveness of the processes rely on the traceability of the requirements and the comprehensiveness
and thoroughness of the checklist used during the inspection and walkthrough process.

Requirements Maintenance
Requirements can be subject to varying types of maintenance activities. While in the specification and
design phases of software development, the developer might discover that the requirements are
incomplete, ambiguous or contradictory. The requirements errors must be dealt with before continuing
the development, by coordinating with the originator of the requirements document, who in turn has to
coordinate with the users’ or clients’ representative. If the errors have serious implications to the project
plan, the upper management and the project leader must intervene to avoid delays in the planned project
deadlines.
After the software is released, the user population might report many errors; and some might be caused
by requirements and specification errors that were not caught during development. At times, new
requirements can be requested by the client and users.
In addition to requirements change, sometimes the priority of requirements must be changed as a result
of changes to the project scope. This will have an implication to the software features and functionalities
that will be available in the current and future releases of the software.
Because changes to the requirements can have serious implication to project scope and the deliverable
deadlines, requests for requirement changes and their approvals should be made in a formal manner in
the form of a formal change request procedure, and must be considered an integral part of a change
management plan normally included in a comprehensive software project plan.

Software Requirements Specification (SRS) Document

The main deliverable of the software analysis phase is the SRS document, which contains the software
requirements captured using the techniques described earlier, as well as the refinements using the
techniques that will be discussed in the next chapter. The IEEE has recommended a standard practice
for writing SRS, with IEEE standards 830 which was first introduced in 1984 and was revised in 1993.
The recommended template for the SRS document contains three sections: (1) introduction, (2) overall
description of the software, and (3) specific requirements.
The introduction (Section 1) describes the purpose of the SRS, its intended audience, its scope in
terms of the overall use of the software produced, the definitions, acronyms, and abbreviations used in
the rest of the document, references used in the document, and an overview of the organization and
content of the rest of the document.
The overall description (Section 2) describes the context of the software that is being developed and
the various types of external interfaces, the user characteristics, the major functions that will be performed
by the software, the general development constraints, and the assumptions and dependencies for the
validity of the SRS.
The specific requirements (Section 3) contain the detailed description of the functional requirements,
which can be organized by system features, system modes, user classes, stimuli, responses, use cases,
or objects. In addition, this section provides a further refinement of the requirements, to complete the
software analysis phase. Data-, behavioral-, and object-oriented modeling techniques for describing data,
functionalities and their relationships are used and their outcomes are documented in this section. These
analysis and modeling techniques that are needed to complete Section 3 of the SRS document are
discussed in the next chapter (Chapter 4). Section 3 of the SRS document also includes the external
interfaces and the NFRs related to usability, user-friendliness, portability, and interoperability
requirements, which specify the communications interfaces with other external hardware and software
systems. Also included are other NFRs such as the performance, safety, security, standards
conformance, legal, regulatory, and cultural requirements that the software must meet. Table 3.4 shows
the template used in the IEEE recommended practice for SRSs.
Table 3.4 Template used in the IEEE recommended practice for software requirements specifications

Title Page

Change History

Preface

Table of Contents

1. Introduction
1.1 Purpose and intended audience
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview of the document
2. Overall description
2.1 Product perspectives and context
2.1.1 System interfaces
2.1.2 User interfaces
2.1.3 Hardware and software interfaces
2.1.4 Communications interfaces
2.1.5 Memory constraints
2.1.6 Operational context
2.2 Product functions
2.3 User characteristics
2.4 General development constraints
2.5 Project assumptions and dependencies
3. Specific requirements
3.1 external interfaces
 3.2 functional requirements
3.3 performance requirements
3.4 database requirements
3.5 design constraints and standards compliance
3.6 software system attributes (non-functional requirements)
4. Supporting information
4.1 Appendices
4.2 Index

The SRS document produced as a result of requirements phase are user-centered, and is normally used
as a legal contract between the developers and the client representing the users. It is also used to develop
the software acceptance criteria described in the acceptance test plan. Because of this, it is written by
the development team in simple technical terms that are understandable by the users.

SUMMARY
Software analysis is the first phase of a typical software development process model. It includes both the
software requirements stage (gathering and identification of user requirements), and the requirements
specification stage (modeling software requirements). This chapter discusses the software requirements
stage of the software analysis phase, while the specification stage is studied in detail in the next chapter.
Obtaining proper software requirements is an important and crucial task in a software development
project because requirements are the foundation upon which a software architecture and design is
developed. Along with a well-defined product vision and project scope document, a well-defined software
requirements engineering process must be used to produce software requirements. A typical requirement
engineering process starts with requirements elicitation. Requirements elicitation helps to capture, invent,
and discover the software requirements. Different elicitation techniques can be used depending on the
complexity of the target product to be developed. A requirements model based on the use case modeling
approach can be developed and documented.
There are two types of requirements, functional and non-functional. Functional requirements are related
to the visible, user-interface-driven functions to be provided by the software. NFRs are mainly quality
requirements related to the attributes of the offered functionalities, and can be product-wide or function-
specific.
Once developed, requirements must be reviewed and validated. Requirements prototyping is a useful
method to obtain an approval on software requirements. Requirements management is also an important
and often overlooked process that allows for the proper handling and maintenance of requirements. Once
software requirements are obtained, they can be explained further using software specification
techniques that will be discussed in the next chapter. The outcomes of the software analysis phase,
including both requirements and specifications, can be documented using a recommended IEEE
standard format for SRS.
ASSESSMENTS:

1. Create a Software Product Vision and Scope Document (IEEE format) for the software solution
you have identified from the previous activity.
2. Identify the functional and non-functional user requirements for the proposed software solution;
and using appropriate approaches in requirements validation, validate the requirements utilizing
IEEE’s standard desirable qualities of requirements.
3. Document the requirements using the IEEE SRS template.
4. Present your outputs and discuss your most significant learnings from the topics and activities.
 5.3 SOFTWARE SPECIFICATION

LEARNING OBJECTIVES:
➢ Describe the different process specification techniques
➢ Describe the different data specification techniques
➢ Describe the different behavior specification techniques
➢ Model software structural, architectural, and behavioral requirements using object-oriented
modeling tools
➢ Produce a detailed software requirements specification document using IEEE format.

OVERVIEW:

In the software analysis phase of the software development life cycle, software specification follows after
user requirements are elicited and analyzed. Software specification uses appropriate and relevant
analysis techniques to bridge the gap between the user-centered software requirements specification
(SRS) and the developer-centered software design. The deliverable of this stage is either a separate
software specification document or a more refined SRS document that shows more technical details. The
SRS document produced as a result of requirements phase are user-centered, and is normally used as
a legal contract between the developers and the client representing the users. It is also used to develop
the software acceptance criteria described in the acceptance test plan. It is written by the development
team in simple technical terms that are understandable by the users. Others call this user-oriented
document, software requirements definition. The deliverables of the software analysis phase are used by
software designers to produce an appropriate software design. Before we proceed to software design, it
is important to provide technical analysis of the software requirements that is more detailed and refined.
The software specification phase is mainly the process of refinement and elaboration on the user-
centered requirements specifications to produce more technical details, thus allowing designers a more
sound and formal idea about what the software under development is supposed to do. Consequently,
designers can make better design choices and, more importantly, correct design decisions. Ideally, the
software specification document allows for a better understanding of the software requirements by
modeling the (1) behavioral, (2) data, and (3) processing aspects needed to meet the requirements. The
behavioral and process aspects provide a dynamic view of the system. The behavioral aspect
concentrates on describing the changes in internal and external states of the software system as a result
of handling either internal or external inputs. The process aspect concentrates on the description of
what the software processes do to the incoming internal or external data. The data aspect provides a
static view of the system. It concentrates on the data requirements needed for the system to deliver its
intended functions. Requirements modeling techniques offer important tools for describing, visualizing,
analyzing, and verifying the requirements before proceeding with design.
READING MATERIALS:

Process Modeling

There are tools that can be used to model the software’s process as well as the data. When the
process model adapted is procedural approach (in contrast to object-oriented approach), a
proposed software solution’s process and data are modeled using structured tools.

The Dataflow Diagram

A Data Flow Diagram (DFD) is a network representation of a system showing the processes and data
interfaces between them. This diagram is used for structured analysis so we will not discuss it in detail
but will just mention the basic elements – the external entity represented by rectangle, the data flow
represented by arrow, the process represented by rounded rectangle and the data store represented by
a rectangle with open right side or a shadowed square.

Rules for drawing DFDs

1. Data Flows
• between processes, into and out of data stores, to/from destinations/sources
• must have arrow to indicate direction
• Unique, meaningful and consistent name must be given to the flow
2. Processes
• Represent transformations
• sometimes drawn as circles or ovals
• Name of process should be written - meaningful
• Normally data flows in and out of each process
• Each process must have a unique number
• description - active verb + object clause
3. Data Store
• Temporary depository of data
• Stores data between processes
• Identified by Dn where n is an integer
• Data Stores are connected to processes by data flows
• Duplicated stores represented by rectangle with open right side
4. Sources and Sinks
• show origin/receiver of data
• can be duplicated
• lie outside the DFD
• Name is written inside the symbol
• Sometime drawn as box with shadow

Guidelines for drawing DFD

1. Identify all external entities
2. Identify all inputs and outputs
3. Work your way through from Inputs to outputs
4. Label all data flows and data stores descriptively
5. Ignore initialisation/ termination trivia
6. Omit trivial error paths and control logic e.g conditions, loops
Levelling the DFD
High level DFD shows the major processes in a system. These must be broken down to show
the details. This task is called levelling
Levels are:
1. CONTEXT DFD - the top diagram
2. the bottom level - procedure which cannot be further decomposed (functional
primitives)
3. the middle levels -everything else

Guidelines for Levelling

1. Number each process in the context DFD
2. Identify those processes in the overview which need to be decomposed
3. Draw a lower level DFD (child diagram) for each high level DFD which can be
decomposed.
4. Number each child to associate it with its parent e.g. the children of process 3.0
may be called 3.1, 3.2 etc.
5. Check inputs and outputs match between parent and child diagrams
6. Repeat the procedure until system is sufficiently described (can be described on 1
A4 sheet)

Level Balancing
➢ Child diagram must have exactly the same data flows as the parent i.e. there is a balance
in data content
➢ 2 ways to balance data content
o If exactly the same data flows are present in the child then the levels are balanced
o If net data content is the same, there is balancing (Wu & Wu, Fig 9-18)
➢ Data stores need not balance - they may be concealed as “unnecessary detail” at a higher
level

Types of DFD Model

DFDs model the flow of data through a system and the model can be logical or physical
➢ Physical
o when any physical object or process is present; limited to the way things are done
➢ Logical
o when no physical components are present; concerned with what is done
➢ Example – a data store called ‘Sales Notebook’ is a physical data store but ‘Sales File’ is
logical.

Physical Process
➢ processes that use a physical object - e.g. “membership card” is physical, “member
details” is logical
➢ process that performs data entry - e.g. “key in payroll data”
➢ processes that only transmit data - e.g. “Send paycheque” is physical
➢ processes that rearrange data - e.g. sort paycheque
Modeling the Proposed System
➢ Model the existing system using DFDs - include physical features
➢ Remove physical aspects
➢ Modify the logical DFDs in 2, to show the new system
➢ Examine the logical DFDs and determine how each part can be implemented
➢ Produce a set of physical DFD’s

Data Modeling

Dataflow Diagram in Data Modeling

➢ DFDs show data flowing through processes
➢ Data Dictionary reveals the contents of the data
➢ This data needs to be converted to a format for files/dbms
➢ Data Model helps the analyst to understand and document the logical structure of the
data

Entity Relationship Model (Data Model)

➢ A graphical description of data entities and the relationship between them
➢ Important as the quality of the design affects the usability and maintainability of the
database
➢ ER Model gives an easy way to design a database
➢ Entity - something that exists
➢ Entities have attributes - properties
➢ Each entity has a key which is one or more attributes that can be used to uniquely identify
an entity
➢ e.g. Employee(Emp#,EmpName, EmpAddress...)
➢ e.g. Part(Part#,PartName,....)
➢ e.g. Contact(ContactName, ContactCo, Phone, Fax...)
➢ Relationships - exist between 2 (or more) entities - an association between entities Every
relationship has a multiplicity: 1 or N
➢ NB: SSADM uses for N (we prefer Chen’s notation)
➢ Membership of relationships may be
➢ optional - not all occurrences of the entity are members
➢ or mandatory - all occurrences of the entity are members

ER To Relational Database Design

➢ Every entity becomes a table with the same name and attributes. The entity key becomes
the table key
➢ Relationships must be represented either using foreign keys or creating a separate table
Relationships
➢ For 1:1 relationship, put the key of one as a foreign key in the other
➢ For 1:N, Place the key of the “1” side as an attribute in the “N” side
➢ For N:M, Always create a separate relationship
Behavior Modeling

The behavioral aspects of the software systems requirements can be modeled using different techniques
such as: (1) finite state machine (FSM) model and its extensions, (2) Petri net (PN) model and its
extensions, the (3) activity diagram of the UML, and (4) state chart diagram of the UML. Each of these
modeling techniques has its own expressive power and limitations. It is up to the software analyst to
choose the technique that seems relevant and appropriate to the software requirement to model. The
activity diagram and state chart diagram are behavioral models under the object-oriented analysis (OOA)
approach, whereas the Finite State Machine and Petri net are more traditional behavior modeling tools.

Finite State Machine(FSM) Model

The finite state machine (FSM) is a modeling technique that can be used to describe the state-based
behavior of a process within software systems; or it can be used to model the whole system as one
process, when the number of states the process can be in is small, and the next state of a process is
determined by its current state and the inputs to the process. The process behavior is described by the
next process state and by the output the process delivers after accepting an input.

Formally, an FSM modeling process is described by a 6-tuple M = (S, ∑1, ∑0, Ω, T, S0), where:

S = the set of states the process can be in

∑1 = the set of inputs to the process
∑0 = the set of outputs from the process
Ω = the partial output function (defined as : Ω: S X ∑1 → ∑0)
T = the partial state transition function (defined as : T: S X ∑1 → S)
S0 = the initial state of the process and S0 € S.

This machine is also known as Mealy machine in which the output is a partial function of the current
state and the input applied at that state.

Graphical, Algebraic, and Tabular Representations

There are three alternative and equivalent representations of an FSM: (1) graphical, (2) algebraic, and
(3) tabular. FSM can be represented graphically as follows: a circle represents a state. A directed edge
between two states S1 and S2, also called a transition, represents a transition from S1 and S2. A label on
the transition from S1 to S2 of the form i/o, indicates that when the input i € ∑1 arrives while at state S1, an
output o € ∑0 is generated and the process moves to state S2. It is also possible to have transitions
occurring spontaneously or triggered after the elapse of time or the occurrence of a timeout. In this case,
the input i is represented by ∑1 indicating that no input is needed for the transition to occur. Similarly, in
a transition that does not produce any output, the output o in the label is represented by ∑ 0 indicating
that no output is needed. Consider the example below:

Example 4.1 Representations of FSM M in three ways

 b/-
a/1
S S
0 2

a/0
a/1
c/1

S
1
Figure 4.2 Graphical representation of FSM M

The FSM M corresponds to the following algebraic representations

M = (S = {s0, s1,s2}, ∑ = ∑1 U ∑0 = {a, b, c} U {0, 1} , Ω = {s0 X a → 1, s2 X b → -, s2 X a → 1, s1 X c →

1, s1 X a → 0},
T = {s0 X a → s2, s2 X b → s2, s2 a → s1, s1 X c → s0, s1 - → s2}, s0)

Ω can be equivalently stated as:

{(s0,a, 1), (s2, b, 1), (s2, a, 1), (s1, c, 1), (s1, a, 0)}

Similarly, T can be stated as:

{(s0, a, s2), (s2, b, s2), (s2, a, s1), (s1, c, 1), (s1, a, 0)}

For simplicity, Ω and T can be merged together as follows:

{(s0, a/1, s2),(s2, b/1, s2), (s2, a/1, s1), (s1, c/1, s0), (s1, a/0, s2)}.

An FSM can also be represented in tabular form. A two-dimensional table will have n rows and n columns,
where n is the finite number of states in S, also called the cardinality of S. Each cell in the n X n table
represents a transition from Si to Sj denoted by (Si, Sj). A table cell includes the label i/o for that transition.
If no transition from Si to Sj exists, the corresponding cell will include -. The tabular representation of the
FSM M is shown in Table 4.1.

Table 4.1 Tabular representation of the FSM M shown in Figure 4.2

si/sj s0 s1 s2
s0 - - a/1
s1 c/1 - a/0
s2 - a/1 b/-

An alternative representation is to have an n x m table in which n is the number of states and m is the
number of possible inputs. In this case, a cell shows the next state reached and the output generated.
Table 4.2 illustrates the alternative table for the FSM representation in Example 4.1.
Table 4.2 Alternative tabular representation of the FSM M shown in Figure 4.2
S/Input A B C -
s0 s2, 1 - - -
s1 - - s0, 1 s2, 0
s2 s1, 1 s2, - /- -

Desirable Properties of FSM-Based Models

Completeness
The FSM should be completely specified, or in other words, the FSM should be able to react to every
input at every state. The FSM in Example 4.1 is not complete because at state S0 it is not specified what
to do if input arrives while at this state. In a tabular form, an FSM is incomplete if a cell includes – or Ф
exists in the table. A complete specifications allows the implementation of a robust process – a process
capable of dealing with both correct and incorrect inputs.

Determinism
The FSM is deterministic if, and only if, at any state, the reaction to the input is unique and unambiguously
determined; meaning for the same input, the FSM should move to the next state and should deliver the
same output anytime it executes. The FSM in Example 4.1 is deterministic because there are no distinct
transitions with the same input at any given state. A software implementation must be deterministic
because a user, at the same state, would like to obtain the same result any time the same request (input)
is present. (For the Extended FSM, a model is deterministic if at the same state, for the same input, and
the same predicate, the same transition (next state and output) must always occur).

Strong connectedness
An FSM is strongly connected if from any state we can reach any other state immediately by executing
one or more transitions. The FSM in Example 4.1 is strongly connected because any state is reachable
from any other state in the FSM. A state that is not reachable from any other state means that the process
is somehow disconnected or discontinued; therefore, the unreachable part of the process is useless.
Normally, in a user-driven interface any situation (state or screen) must be reached somehow at one
point, and we should be able to get out of that state or screen.

Minimality
An FSM is said to be minimal if there exists no other equivalent FSM with fewer numbers of states or
transitions. Implementing a non-minimal FSM for software and digital systems implies wasting
development efforts on a non reduced and somehow redundant specification (assuming that all
transitions are of equal complexity).

Extended Finite State Machine (EFSM) Model

The basic FSM model is unable to describe certain process behavior requirements such as timing and
timeout specifications, conditional transitions, variable or data manipulation, and concurrency
specifications.

Timing and timeout specification

Suppose that at a given state of the FSM we would like to specify that if no input is present within t time
units, a transition should take place and an output should be delivered. This would occur in many real-
time processes and in user-oriented interfaces and systems. We would like to have certain delayed
transitions in which a time delay is specified instead of an input symbol. The basic FSM model cannot
specify such timing and timeout constraints.

Conditional transitions
Suppose that at a given state of the FSM we would like to specify that in addition to the availability of an
input symbol, certain predicate(s) should evaluate to true for the transition to take place. A predicate is a
Boolean function P: X → {True, False},where X is an arbitrary set, and P is said to be a predicate on X.
We would like to have certain predicated or conditional transitions. In addition to the correct input at the
source state of a conditional transition ( for the basic FSM model), there has to be a predicate specified
for this transition which is evaluated; then the transition would take place only if the predicate evaluates
to true.

Variable condition
Suppose that a given state of the FSM, the reaction to the next input symbol, must change a certain
variable value, which is critically needed in future transitions (for example in a predicate evaluation). For
example, in a user-interface driven process, at the logon state, the reaction to a bad login input can
depend on the number of times a bad login input was performed earlier. Therefore, a variable holding a
counter of the number of bad logins is needed.

Concurrency specification
Due to its inherently sequential nature, a basic FSM cannot model concurrent behaviors that can be
needed to describe complex concurrent applications. The UML statechart diagram can be an extension
to this model with the specification of concurrent substates.

The extended finite state machine (EFSM) model can overcome the limitations of FSM on timing and
timeout constraints, conditional transitions, and variable condition with the introduction of the formal
definition of EFSM by an 8-tuple M = (S, ∑1, ∑0, Ω, V, T, S0, V0) where:

S = the set of states the process can be in

∑1 = the set of inputs to the process
∑0 = the set of outputs from the process
Ω = the partial output function (defined as : Ω: P X S X ∑1 → Ω)
V = the set of model variables
T = the partial state transition function (defined as : T: P X S X ∑1 → S X f(v))
S0 = the initial state of the process and S0 € S.
V0 = the initial values assignments

In the EFSM model, the transition function determines for each transition:
• Predicate, if any is needed, that must be evaluated to true
• Time delay, if any, that must elapse before the transition takes place
• Changes to the variable values that must be performed when the transition occurs

However, when a time delay is specified for a transition, no input symbol should exist in the corresponding
transition specification.

As a result of the modification to the basic FSM model, a cell in the tabular representation of the ESFM
can contain more than one entry. For example, from state Si to Sj, as shown in Figure 4.3, we can have
a delayed transition and one or more conditional or predicated transitions. Also, in an EFSM graphical
representation, the time delay, the predicate, and f(v) can be added to the label of the appropriate
transition.
 Sj
.
.
.

P1: a/0, f1(v)

P2: a/1, f2(v)
Si . . . . . . . P3: td = 10, -/1 Figure 4.3 A cell in a tabular EFSM representation
~P3: td = 10, -/0

The EFSM model is a powerful model for describing complex software systems such as a graphical user
interface, telephone systems interaction, programming language parser, communications protocols, and
many more types of software systems. Consider the GUI as a process with deterministic behavior. The
set of states typically correspond to the set of screens, inputs include all those possible input to the
screens; outputs correspond to the distinct outcomes from the system, including voice messages, control
signals, warning messages, error messages, help messages, and printed logs. In a communications
protocol specification, each protocol entity or participating machine can be described by an ESFM. A
global state of the distributed system is composed of the individual states of each FSM and the content
of the communications channels between the communicating FSMs. The initial global state is when each
FSM is at its initial state and all channels are empty.

Petri Net (PN) Model

Petri Nets were first introduced by Carl Petri in 1963. A PN provides a powerful modeling technique with
a strong mathematical foundation which facilitates the verification of the model properties. It can be
represented mathematically and graphically.

Mathematical Representation

A basic PN is represented by a quintuple PN (P, T, B, F, M0) where:

P =a non-empty set of places and the cardinality of P is P

T = a non-empty set of transitions and the cardinality of T is T
B = P X T →N, a backward incidence function that determines the number of arcs emanating from
transitions to places in the net
N = the set of natural numbers
F = P X T →N, a forward incidence function that determines the number of arcs emanating from places
to transitions in the net
M0 = the initial marking of the net that specifies the initial distribution of tokens inside the p places of the
net.

If we order the set P and T, then the functions of F and B can be represented by p X t matrices. n1 arcs
exists from transition ti to place pk, if and only if, B(pk, ti) = n1. Also, n2 arcs exist from place p1 to transition
tj if, and only if, F(p1, tj) = n2. Finally, M0 is a p X 1 vector, called initial marking of the PN, representing
the initial mapping of tokens where M0(p) = n is represented by n tokens in place p. A marking M can be
considered as one state of the net. Marking M0 denotes the initial state of the net. The definition of B
implies that if no arcs exist from ti to pj, B[pj, ti] will be 0. Similarly, if no arcs exist from pi to tj, F[pi, tj] will
be 0.
Graphical Representation

A PN is represented graphically as follows:

1. A place is represented by circle
2. A transition is represented by a horizontal bar
3. A forward (backward) transition is represented by an arc starting from a place (transition) and
terminating at a transition (place)
4. A token is represented by a bold dot and i token exist inside a place P if M0(P) = i.

The initial distribution of tokens, in M0, among the many places of the net is a choice that depends on the
initial state of the system we are modeling. In Figure 4.7, t1 and t2 are transitions and p1, p2, andp3 are
places. Arc a is a forward arc while arc b is a backward arc. The initial marking M0 is (1, 0, 1).

A transition is called a synchronization transition if it has two or more incoming arcs and one outgoing
arcs. A transition is called a forking transition if it has one incoming arc and more than one outgoing arc;
a forking transition specifies the enabling of concurrent executions. A transition can be both a
synchronizing and a forking transition.
p3 p1

t1 t2
a
p2

Figure 4.7 A Petri net example

Mathematical and equivalent graphical representation

Figure 4.8 shows the graphical representation of a net PN, where t1 is a forking transition and t3 is a
synchronizing transition. The mathematical representation of the net PN is: PN = (P = {p1, p2, p3, p4,
p5}, T = {t1, t2, t3, t4}, B, F, M0 = (2, 0, 0, 0)). Figure 4.9 shows the backward matrix (B) and forward
matrix (F).
Given a PN and a transition t € T, we define: (1) PRE (t) = {p € P/F(p, t) ≠ 0} to be the set of input
places of transition t, and (2) POST(t) = {p € P/B(p, t) ≠ 0} to be the set of output places of transition t.
The PN incidence matrix C is defined as: C(p, t) = B(p, t) – F(p, t).
 p1

t1
t2
p2 p3 p4

t3 t4

p5

Figure 4.8 Graphical representation of the Petri Net n

t1 t2 t3 t4 t1 t2 t3 t4
p1 0 0 0 2 p1 1 1 0 0
p2 1 0 0 0 p2 0 0 1 0
B= p3 1 0 0 0 F= p3 0 0 1 0
p4 0 1 0 0 p4 0 0 1 0
p5 0 0 1 0 p5 0 0 0 1

Figure 4.9 Backward and forward matrices for the Petri net n in Figure 4.8

The formula defining the incidence matrix C implies that the new marking is the net result of the tokens
that are gained minus the tokens that are lost as a result of the firings of certain fireable transitions.
Given a marking M, we say that a transition t of a PN is enabled or fireable if, and only if, for every p €
PRE(t), M(p) ≥ F(p, t). Firing of a transition t € T is defined by the transformation of the enabling marking
M into a new marking M’ such that: p € P, M’ (p) = M(p) + C(p, t) σ
The main advantage of the PN as a specification model lies in its verifiability, using some mathematical
manipulations from linear algebra.

Verifiable Properties of a PN Model

Two distinct types of PN properties that can be verified in a PN model of a system are safety and
liveliness. Safety properties are related to the semantics of the net and can be verified using static or
structural analysis techniques, which verify the existence of some predefined net invariants. Liveness
properties are related to the syntactic correctness of the net and can be verified using dynamic or
enumerative analysis techniques, which verify the freeness from deadlocks, livelocks, and the
identification of five loops and home states in the PN model.

Activity Diagram
The logical place to start analysis and design using UML diagrams is with the use of Activity Diagram. It
describes several related activities in time order as a group of jobs or a series of processes. The easiest
way to visualize an Activity Diagram is to think of a flowchart of a code. The flowchart is used to depict
the business logic flow and the events that cause decisions and actions in the code to take place. Activity
diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the
particular state. It is a flowchart that models the actions, the object will perform and in what order. It is
used to break out the activities that occur within a use case and is good for showing parallel threads.
From the software engineering perspective they are used to analyze requirements and use cases to the
process flow diagrams to give the broad picture of the overall process flow.
Uses of Activity Diagram
✓ It can be used early on in the analysis and design process to show business workflow.
✓ It can be used to show where each of the Use Cases might be in an activity to illustrate what Use
Case has to happen.
✓ It can be used to show how things flow between the Use Cases.
✓ It can be used at the design level to model very complicated set of algorithms for a particular
class.
✓ It can be used to show the flow between the methods of a class.

Basic parts of the activity diagram are : Activities or Action States: Related activities in time order are
represented as rounded rectangles. These activities are typically action states – states that transition
automatically to the next state after the action is complete; Initial State: The filled in circle (followed by
an arrow) represents the start of the activity diagram – where the flow of control starts; Final State: An
arrow pointing to a filled circle nested inside another circle represents the final action state; Transitions:
Transitions shown as arrows show how you move from activity to activity or the relationships among
action states; Synchronization bars: These bars show how activities happen in parallel. It can guard a
transition that says “Go to this activity only if this condition is true,” and it can show you where it stops;
Swimlanes: These swimlanes show ownership. They clearly illustrate to all parties what individual or
group is responsible for what activity. Here, related activities are grouped in one column. However there
are other elements that need to be considered when drawing an activity diagram. The table below lists
those elements and symbols.
Table 4.10 Elements and Symbols of Activity Diagram
Element & Symbol Description
Start State/ Initial Activity This shows the starting point or first activity of the flow.
Denoted by a solid circle.

Activity/ Action State Represent the non-interruptible actions of objects.

An action state represents an activity.
If necessary, you can use another activity diagram to
provide details about the activity; that is, you can use
activity
activity diagrams to decompose action states.
Represented using a rectangle with rounded corners.

Guard Is a condition that must be true in order to traverse a

transition.

Condition Defining a guard which must evaluate to true in order to

traverse the node.

Decision(s)/ Branching & Similar to flowcharts, a logic where a decision is to be made

Merge is depicted by a diamond, within box brackets.
With the options written on either side of the arrows
emerging from the diamond, within box brackets.
A diamond represents a decision with alternate paths. The
outgoing alternates should be labeled with a condition or
guard expression. You can also label one of the paths
“else.”
Decision A diamond with one flow entering and several leaving. The
flows leaving include conditions although some modelers
will not indicate the conditions if it is obvious.
A diamond with several flows entering and one leaving.
Merge The implication is that all incoming flows must reach this
point until processing continues.
Transition(s)/ Flow/ Edge Transitions (solid arrows) order the sequence of activities.
Completing an activity fires the outgoing transitions of the
action state representing the activity. An action state must
have at least one outgoing transition. If an action state has
more than one outgoing transition, each must have a guard
condition.

Signal When an activity sends or receives a message, that activity

is called a signal. Signals are of two types:
 Input Signal (Message receiving activity) shown by a
concave polygon. A signal receipt symbol shows a
transition receiving a signal. Do not label transitions
Input Signal connected to a signal receipt symbol. Optionally, use an
object flow to indicate the object that sends the signal.

Output Signal (Message sending activity) shown by a

convex polygon. A signal sending symbol shows a
transition sending a signal. Do not label transitions
Output Signal connected to a signal sending symbol. Optionally, use an
object flow to indicate the object that receives the signal.
Concurrent Activities Some activities occur simultaneously or in parallel. Such
activities are called concurrent activities. For example,
listening to the lecturer and looking at the blackboard is a
parallel activity. This is represented by a horizontal split
(thick dark line) and the two concurrent activities next to
each other, and the horizontal line again to show the end
of the parallel activity.

Object in State An object in state represents instances of a specified object

in a specified state. You must specify the object name. The
state name is optional; if specified, the UML suite
automatically encloses it in square brackets. Folding an
object hides its state name.
Object Flow You use object flows (dashed arrows) to show how objects
in state are used by action states and transitions. If an
action state generates an object in state that is used by the
subsequent action state, you can omit the transition (solid
arrow) between the two states.
Partition(s)/ Swimlanes You use partitions to group the states of an activity model.
Typically, each partition corresponds to an organizational
Applicant Register unit in a business model. You can use partitions to allocate
characteristics or resources among the states of an activity
model. Indicating who/
what is performing the activities. Divide activities
according to objects by arranging objects in a column
format and placing activities by that object within that
column. Objects are listed at the top of the column and
vertical bars separate the columns to form the swimlanes.
Swimlane Separator You use swimlane separators to divide a partition into
horizontal or vertical zones called swimlanes. A partition
with no swimlane separators contains one swimlane.
Swimlanes group related activities into one column.
Synchronization Bars Activities can be done in parallel. To split processing “fork”,
or to resume processing when multiple activities have been
 completed “join”, synchronization bars are used.
A black bar with one flow going into it and several leaving
it. This denotes the beginning of parallel activity. A
black bar with several flows entering it and one leaving it.
This denotes the end of parallel processing.
Fork

Join

Sub-activity Indicator Indicates that the activity is described by a more finely

detailed activity diagram.
Note(s) A standard UML note that usually use to indicate
something that may hard to understand.
Action State Is a state that represents the execution of an atomic action,
typically the invocation of an operation or transaction.
Text in the activity box should represent an activity.
Event Is triggered by an activity. It is specification of a significant
occurrence that has a location in time and space. These
are represented by direct straight lines emerging from
triggering activity and ending of the activity to be triggered.
Label text for events should represent event but not the
data involved.
Final State/ Final Activity The final state ends the sequence of activities and is shown
by a bull's eye symbol.
 Registrar Professor

Create

curriculum

Select courses

To teach

Create

catalog
[Registration time period expired]

Place Catalog Mail catalog

In bookstore To students

Open

registration

Close

registration

Figure 4.10 An Activity Diagram Example

 Figure 4.11 An Activity Diagram for Take Order Use Case

In this example, completing the Take Order activity, creates an Order in the [entered] state. The
Fill Order activity requires an Order in the [entered] state and creates an Order in the [filled] state.
 In this example, the transition from Take Order to Fill Order sends an enterOrder signal to the
Order object. The transition from Fill Order to Deliver Order receives an orderFilled signal from the Order
object.

Figure 4.12 Example Activity Diagram for Signal Sending and Receiving

Example of Swimlane

To create the two swimlanes, use a partition and a horizontal or vertical swimlane separator.

Figure 4.3 Example of Swimlane

 Consider the following example. The Activity Diagram begins with a call to Request Service, the
Initial State. Upon completion of this operation, a synchronization bar is used to indicate parallel
processing, where the customer pays, and the sales and stockroom staff take and fill the customer’s
order simultaneously. Another synchronization bar is used to indicate that when the customer has paid
and the order has been filled, then the order is ready for delivery. After the delivery of the order, the
customer can collect the order, and the process is complete. This is marked with the final state icon.

Customer Sales Stockroom

final state icon.

Request Service

Take Order

Pay

Fill Order

Deliver Order

Collect Order

Figure 4.4 Example of Swimlane with Synchronization Bars

Similarities and Difference with State chart Diagram
The Activity Diagram is similar to the Statechart Diagram in that they both model aspects
of system behavior. Unlike a Statechart Diagram, an Activity Diagram models an objects workflow during
program execution.
A Statechart Diagram shows the different states an object is in during the lifecycle of its
existence in the system, and the transitions in the states of the objects. These transitions depict the
activities causing these transitions, shown by arrows.
An Activity Diagram talks more about these transitions and activities causing the changes
in the object states.
Because an Activity Diagram is a special kind of Statechart Diagram it uses some of the
same modeling conventions.
Statechart and Activity Diagrams both describe state transitions and share many of the
same elements. A Statechart Diagram is useful for describing the behavior of a single object across
several use cases while an Activity Diagram is a dynamic diagram that shows the activity and the event
that causes the object to be in the particular state.

Advantages and Disadvantages

The Activity Diagram focuses on activities, in this sense it is like a flow chart supporting compound
decisions. However, it differs from a flow chart by explicitly supporting parallel activities and their
synchronization. Unlike EPC, the starting point eliminates need to traverse through the entire process
model for identifying the process start or triggering event that is of user interest. The back flows of
activities can be represented unlike the Event Trace Diagrams.

The biggest disadvantage of Activity Diagrams is that they do not make explicit which objects
execute which activities, and the way that the messaging works between them. Labeling of each activity
with the responsible object can be done. Often it is useful to draw an Activity Diagram early on in the
modeling of a process, to help you understand the overall process. Then interaction diagrams can be
used to help you allocate activities to classes.

Guidelines in Diagramming
A. General Guidelines
A.1 Place the Start Point in the Top-Left Corner
A start point is modeled with a filled in circle, using the same notation that UML State Chart
Diagrams use. Every UML Activity Diagram should have a starting point, and placing it in the top-left
corner reflects the way that people in Western cultures begin reading. Figure 1 which models the
business process of enrolling in a university, takes this approach.
Figure 4.5 Modeling a business process with a UML Activity Diagram.

A.2 Always Include an Ending Point

An ending point is modeled with a filled in circle with a border around it, using the same notation
that UML State Chart Diagrams use. Fowler and Scott's (1999) style is to make ending points optional,
some times an activity is simply a dead end, but if this is the case then there is no harm in indicating that
the only transition is to an ending point. That way when someone else reads your diagram they know
that you have considered how to exit these activities.

Figure 4.6 Is interesting because it does not include an end point because it describes a
continuous process – sometimes the guidelines don’t apply.

A.3 Flowcharting Operations Implies the Need to Simplify

A good rule of thumb is that if an operation is so complex you need to develop a UML Activity
Diagram to understand it that you should consider refractory it.

B. Activities

An activity, also known as an activity state, on a UML Activity Diagram typically represents the
invocation of an operation, a step in a business process, or an entire business process.

B.1 Question “Black Hole” Activities

A black hole activity is one that has transitions into it but none out, typically indicating that you
have either missed one or more transitions. As noted previously if an activity is in fact the final activity in
the process you are modeling you should consider adding a transition out of it to an end point.

B.2 Question “Miracle” Activities

A miracle activity is one that has transitions out of it but none into it, something that should be
true only of start points. Once again, this is an indication that you have missed one or more transitions.
C. Decision Points
C.1 Decision Points Should Reflect the Previous Activity
In Figure 4.5 you see that there is no label on the decision point, unlike traditional flowcharts
which would include text describing the actual decision being made, you need to imply that the decision
concerns whether the person was enrolled in the university based on the activity that the decision point
follows. The guards depicted using the format [description], on the transitions leaving the decision point
also help to describe the decision point.

C.2 Avoid Superfluous Decision Points

The Fill Out Enrollment Forms activity in Figure 4.5 includes an implied decision point, a check to
see that the forms are filled out properly, which simplified the diagram by avoiding an additional diamond.

D. Guards
D.1 Each Transition Leaving a Decision Point Must Have a Guard
This ensures that you have thought through all possibilities for that decision point.

D.2 Guards Should Not Overlap

The guards on the transitions leaving a decision point, or an activity, must be consistent with one
another. For example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such as x <=
0 and x >= 0 are not consistent because they overlap – it isn’t clear what should happen when x is 0.
You see that this is true in Figure 1 the guards on the exit transitions from the Fill Out Enrollment Forms
activity do not overlap, nor do the guards on the decision point.

D.3 Guards on Decision Points Must Form a Complete Set

Once you have reached a decision point it must always be possible to leave it, therefore the
guards on its exit transitions must be complete. For example, guards such as x < 0 and x >0 are not
complete because it isn’t clear what happens when x is 0.

D.4 Exit Transition Guards and Activity Invariants Must Form a Complete Set
An activity invariant is a condition that is always true when your system is processing an activity.
For example, in Figure 4.5 an invariant of the Enroll In University activity is that the person is not yet
officially a student. Clearly the conditions that are true while processing an activity must not overlap with
its exit conditions and the invariants and exit conditions must “add up” to a complete set.

D.5 Apply a [Otherwise] Guard for “Fall Through” Logic

In Figure 4.5 you see that one of the transitions on the decision point is labeled. Otherwise, a
catch-all condition for the situation when the problems with the forms are not trivial and help is not
available. This enabled me to avoid a very wordy guard, simplifying the diagram.

D.6 Guards Are Optional

It is very common for a transition to not include a guard, even when an activity includes several
exit transitions. When a UML Activity Diagram is used to model a software process or business process
the transitions often represent sharing or movement of information and objects between activities, a
situation where guards often make less sense. Follow Agile Modeling (AM)’s (Ambler 2002) principle of
Depict Models Simply and only indicate a guard on a transition if it adds value.
E. Parallel Activities

It is possible to show that activities can occur in parallel, as you see in Figure 4.5 depicted using
two parallel bars. The first bar is called a fork; it has one transition entering it and two or more transitions
leaving it. The second bar is a join, with two or more transitions entering it and only one leaving it.

E.1 A Fork Should Have a Corresponding Join

In Figure 4.5 you see that the business process forks into two parallel streams, one where the
person attends a presentation and another where they sign up and pay for courses. The process forks,
the person performs these activities, and once both streams are complete the process continues from
there (in this case it simply ends). In general, for every start (fork) there is an end (join).
E.2 Forks Have One Entry Transition
When you find that you want to have several transitions into the same fork you should first merge
them by having them enter a single diamond and then have a single transition from the diamond into the
fork. However, this situation is also a good indication that you’ve either missed an activity, likely where
the merge occurs, or that you really don’t have parallel activities at this point.
E.3 Joins Have One Exit Transition
The desire to have several exit transitions is a good indication that you still have parallel activities
occurring; therefore move your join further along in the overall process.
E.4 Avoid Superfluous Forks
Figure 4.6 depicts a simplified description of the software process of enterprise architectural
modeling, a part of the Infrastructure Management discipline of the Enterprise Unified Process (EUP).
There is significant opportunity for parallelism in this process, in fact all of these activities could happen
in parallel, but forks were not introduced because they would only have cluttered the diagram.

F. Swimlane Guidelines
A swimlane is a way to group activities performed by the same actor on an activity diagram or to
group activities in a single thread (Douglass 1999). Figure 4.6 includes three swimlanes, one for each
actor.

Figure 4.6. A UML activity diagram for the enterprise architectural modeling (simplified).
F.1 Order Swimlanes in a Logical Manner
Although there are no semantics behind the ordering of swimlanes there often is a natural ordering
for them. For example, in Figure 4.6 you see that the swimlanes are listed left-to-right in the relative
order that the activities would occur in a serial process (even though this one is iterative) – stakeholders
will start by identifying and prioritizing requirements, the analyst will model them, then the architects will
act on them.

F.2 Apply Swim Lanes to Linear Processes

A good rule of thumb is that swimlanes are best applied to linear processes, unlike the one
depicted in Figure 4.6 where the logic proceeds from one activity to another. For example, the steps that
customers take to check an order out of a grocery store are a perfect example of a relatively linear
process. This diagram would likely include three swimlanes, one for the customer, one for the checkout
clerk, and one for the person who bags the groceries.

F.3 Have Less Than Five Swimlanes

A disadvantage of swimlanes is that they reduce your freedom to arrange activities in a space-
effective manner, often increasing the size of your diagrams. When a diagram has a small number of
swimlanes there is less chance that this problem will occur.

F.4 Consider Swimareas for Complex Diagrams

When you need several swimlanes, for example if Figure 4.6 where to include all of the activities
of the Infrastructure Management discipline it would include swimlanes for roles such as Reuse Manager,
Programmed Manager, Software Process Manager, and Human Resource Manager, you would discover
that the swimlanes would force you to arrange the activities in a non-optimal way (the transitions between
some activities would cross the page). Another approach would be to use swimareas, sections of related
activities, instead of a formal swimlane. Fowler and Scott (1999) call these swimareas non-linear zones.

F.5 Swim areas Suggest the Need to Reorganize Into Smaller Activity Diagrams
When a swim area includes several activities you may instead decide to introduce a UML
package, or simply a higher-level activity, that is then described by a detailed UML Activity Diagram. For
example, Figure 4.6 may simply be the detailed description of a Model the Enterprise activity on a high-
level diagram for that EUP discipline.

F.6 Consider Horizontal Swimlanes for Business Processes

In Figure 4.7 you see that the swimlanes are drawn horizontally, going against common
convention of drawing them vertically. Because project stakeholders typically like to read from left-to-
right this helps to increase the understandability of your UML Activity Diagrams used to depict business
processes. Also notice how the outside borders of the swimlanes were dropped to simplify the diagram.
Figure 4.7. Activity Diagram for Submitting Expenses

G. Action Object Guidelines

Activities act on objects, in the strict object-oriented sense of the term an action object is a system
object, a software construct. In the looser, and much more useful for business application modeling,
sense of the term an action object is any sort of item. For example in Figure 4.7 the ExpenseForm action
object is likely a paper form.

G.1 Place Shared Action Objects on Swimlane Separators

In Figure 4.7 you see that the ExpenseForm action object is placed on the line separator between
the Consultant and Accountant swimlanes. This was done because the ExpenseForm is critical to both
swimlanes and because it is manipulated in both, very likely being a something the two people will work
together on (at least when there is a problem).

G.2 When an Object Appears Several Time Apply State Names

The ExpenseForm object appears twice on the diagram, an initial version of it and one with errors.
To distinguish between them their state names, in this case Initial and Error, are indicated using the same
notation for guards on transitions.

Note that this notation may be applied to any object on any UML diagram, including UML
Sequence diagrams and UML Collaboration diagrams.

G.3 State Names Should Reflect the Lifecycle Stage of an Action Object
You depict the same action object on a UML Activity Diagram in several places because it is
pertinent to what is being modeled and because itself object has changed (it has progressed through one
or more stages of its lifecycle).

G.4 Show Only Critical Inputs and Outputs

Although Figure 4.7 shows ExpenseForm as an output of the Fill Out Expense Form activity, you
know it’s an output because the transition is depicted using a dashed arrow, there isn’t a lot of value in
doing so because it’s clear that an expense form would be the output of that activity. Remember AM’s
practice Depict Models Simply and only model something if it adds value.

G.5 Depict Action Objects As Smaller Than Activities

The focus of a UML Activity Diagram is activities, not the actions implementing or being produced
by those activities, therefore you can show this focus by having larger activity bubbles.

To depict the fact that an activity is implemented by an action object you use a solid arrow.

State Chart (State Machine) Diagrams

State charts diagrams captures the life cycles of objects, sub-systems and systems. They indicate
what states an object can have and how different events affect those states over time.
State chart diagrams should be attached to classes that have clearly identifiable states and is governed
by complex behaviour.
A State is displayed as a rounded rectangle with optional compartments for attributes, events and
internal activities. State flows or transitions are drawn between States, usually with guard conditions and
rules governing how and when an object may transition from one state to another.
States are usually named according to their condition, for example 'Checking', 'Waiting' and
'Dispatching' are all active conditions an object can be in while waiting to transition to another state or
end the cycle completely.
Start and end nodes represented as solid and empty circles are used to represent the beginning
and end of all transitions. State charts can have a start point and several end points.
State transitions may be triggered by events. These events may have keywords (guards)
associated with it to clarify the event. It is not always necessary to show these events.
States can be nested. This implies that states (sub states) can exist in an overall state. Parallel
states can also be defined where an object may have several states at the same time. For example: A
person has at any time many parallel states. These may be: walking, thinking, young, etc.

Formerly called state chart diagrams in UML 1, state machine diagrams depict the dynamic behavior of
an entity based on its response to events, showing how the entity reacts to various events depending on
the current state that it is in. Create a UML state machine diagram to explore the nature of a:

• Explore the complex behavior of a class, actor, subsystem, or component.

• Modeling real-time systems.

Table 4.11 Elements of a State diagram

Element and its Description Symbol

Initial State: This shows the starting point or first activity of the flow. Denoted
by a solid circle. This is also called as a "pseudo state," where the state has no
variables describing it further and no activities.
State: Represents the state of object at an instant of time. In a state diagram,
there will be multiple of such symbols, one for each state of the Object we are
discussing. Denoted by a rectangle with rounded corners and compartments
(such as a class with rounded corners to denote an Object). We will describe
this symbol in detail a little later.

Transition: An arrow indicating the Object to transition from one state to the
other. The actual trigger event and action causing the transition are written
beside the arrow, separated by a slash. Transitions that occur because the state
completed an activity are called "triggerless" transitions. If an event has to
occur after the completion of some event or action, the event or action is called
the guard condition. The transition takes place after the guard condition occurs.
This guard condition/event/action is depicted by square brackets around the
description of the event/action (in other words, in the form of a Boolean
expression).

History States: A flow may require that the object go into a trance, or wait state,
and on the occurrence of a certain event, go back to the state it was in when it
went into a wait state—its last active state. This is shown in a State diagram
with the help of a letter H enclosed within a circle.

Event and Action: A trigger that causes a transition to occur is called as an

event or action. Every transition need not occur due to the occurrence of an
event or action directly related to the state that transitioned from one state to
another. As described above, an event/action is written above a transition that
it causes.

Signal: When an event causes a message/trigger to be sent to a state, that

causes the transition; then, that message sent by the event is called a signal.
Represented as a class with the <<Signal>> icon above the action/event.

Final State: The end of the state diagram is shown by a bull's eye symbol, also
called a final state. A final state is another example of a pseudo state because
it does not have any variable or action described.

1.1 Create A state machine When Behavior Differs Based on State

Agile Modeling (AM)’s (Ambler 2002) principle of Maximize Stakeholder Investment advises you
to create a model only when it provides positive value to your efforts. If an entity, such as a class or
component, exhibits the same sort of behavior regardless of its current state then drawing a UML state
machine diagram will be of little use. For example a SurfaceAddress class is fairly simple, representing
data that you will display and manipulate in your system, therefore a UML state machine for it would not
reveal anything of interest. On the other hand a Seminar object is fairly complex, reacting to events such
a enrolling a student differently depending on its current state, as you see depicted in Error! Reference
source not found..

Figure 4.8 A UML state machine Diagram for a seminar during enrollment.

1.2 Place The Initial State In The Top-Left Corner

An initial state is modeled with a filled in circle, as you see in Figure 4.8, placing an initial state in
the top-left corner reflects the way that people in Western cultures begin reading.

1.3 Place The Final State In The Bottom-Right Corner

A final state is modeled with a filled in circle with a border around it, as you see in Figure 4.8.
Placing the final state in the bottom-right corner reflects the left-to-right, top-to-bottom approach to
reading by Western cultures.

A state is a stage in the behaviour pattern of an entity. States are represented by the values of
the attributes of an entity. For example, in Figure 4.8 a seminar is in the Open For Enrollment state when
it has been flagged as open and there are seats available to be filled.

2.1 State Names Should be Simple but Descriptive

State names such as Open For Enrollment and Proposed are easy to understand, thus increasing
the communication value of Figure 4.8. Ideally state names should also be written in present tense
although names such as Proposed, past tense, are better than Is Proposed, present tense.

2.2 Question “Black Hole” States

A black hole state is one that has transitions into it but none out, something that should be true
only of final states, an indication that you have missed one or more transitions.
2.3 Question “Miracle” States
A miracle state is one that has transitions out of it but none into it, something that should be true
only of start points, an indication that you have missed one or more transitions.

3.1 Model Substates For Targeted Complexity

The UML state machine diagram presented in Figure 4.8 is not complete because it does not
model any post-enrollment states of a Seminar. Note that the labels on the transitions were not included
for the sake of simplicity, normally you would include them as they are currently modeled in Figure 4.8.
Modeling substates makes sense when an existing state also exhibits complex behavior, thereby
motivating you to explore its substates. Introducing a superstate makes sense when several existing
states share a common entry or exit condition (Douglass 1999), in Figure 4.8 you see that all of the states
share a common closed transition to the final state.

Figure 4.9. The complete lifecycle of a Seminar.

3.2 Aggregate Common Substate Transitions

In Figure 4.9 you see that the cancelled transition is depicted leaving the Enrollment superstate
and not every single substate as depicted in Figure 4.9, simplifying the diagram. Had the substates all
shared an entry transition the same approach would have been taken, or even another exit transition, the
same approach would have been taken. The guards and actions, if any, on the transitions being
aggregated should be identical.

3.3 Create a Hierarchy of state machines for Very Complex Entities

Although showing substates in this manner works well, the resulting diagrams can become quite
complex – just imagine what would happen to Figure 4.9 if the Being Taught state also had substates.
An alternative approach would be to create a hierarchy of UML state machine diagrams. For example,
Figure 4.10 represents the top-level view and Figure 4.9 depicts a more detailed view, the advantage of
this approach being that another detailed diagram could be developed to explore the Being Taught state
as required.
Figure 4.10. A top-level state machine for Seminar.

3.4 Top-Level state machines Always Have Initial and Final States
A top-level UML state machine, such as the one depicted in Figure 4.10, should represent the
entire lifecycle of an entity including its “birth” and eventual “death”. Lower-level diagrams may not always
include initial and final states, particularly those diagrams that model the “middle states” of an entity’s
lifecycle.

4. Transitions and Actions

A transition is a progression from one state to another and will be triggered by an event that is
either internal or external to the entity being modeled. For a class, transitions are typically the result of
the invocation of an operation that causes an important change in state, although it is important to
understand that not all method invocations will result in transitions. An action is something, in the case
of a class it is an operation, that is invoked by/on the entity being modeled.

4.1 Name Software Actions Using Implementation Language Naming Conventions

The actions in Figure 4.10 follow the Java naming convention for operations (Vermeulen et. al.
2000) because the intention is to implement this system using Java. Had another language been our
target we would have followed the appropriate naming conventions.

4.2 Name Actor Actions Using Prose

UML state machine diagrams can be used to model the lifecycle of non-software entities, in
particular actors on UML Use Case diagrams. For example the Student actor likely has states such as
Accepted, Full Time, Part Time, Graduated, Masters, Doctoral, and Post-Doctoral, exhibiting different
behaviors in each one. When you are modeling the real-world actor, as opposed to the software class
Student, the transitions between these states would be better worded using prose such as drop seminar
and pay fees instead of dropSeminar() and payFees() because people in the real world do things, they
don’t execute operations.

4.3 Indicate Entry Actions Only When Applicable For All Entry Transitions
 In Figure 4.10 you see that upon entry into the Closed To Enrollment state the operation
notifyInstructor() is invoked via the entry/ action label. The implication is that this operation will be invoked
every single time that this state is entered – if you don’t want this to occur then associate actions to
specific entry transitions. For example, the addStudent() action is taken on the student enrolled transition
to Open For Enrollment but not to the opened transition, this is because you don’t always add a student
each time you enter this state.

4.4 Indicate Exit Actions Only When Applicable For All Exit Transitions
Exit actions, indicated with the exit/ label, work in a similar manner to entry actions.

4.5 Model Recursive Transitions Only When You Want to Exit and Re-Enter the State
A recursive transition is one that has the same state for both of its end points. An important
implication is that the the entity is exiting and then re-entering the state, therefore any operations that
would be invoked due to entry/ or exit/ action labels would be automatically invoked. This would be the
case with the recursive transitions of the Open For Enrollment state of Figure 4.10 where the current
seminar size is logged on entry.

4.6 Name Transition Events in Past Tense

The transition events in Figure 4.8 , such as seminar split and cancelled, are written in past tense
reflecting the fact that transitions are the results of events – because the event occurs before the transition
it should be referred to in past tense.

4.7 Place Transition Labels Near The Source State

Although 4.8 is complex wherever possible the transition labels, such as seminar split and student
enrolled, where placed as close to the source as possible. Furthermore, the labels were justified (left
and right respectively) to help visually place them close to the source state.

4.8 Place Transitions Labels Based on Transition Direction

To make it easier to identify which label goes with a transition, place transition labels according
to the following heuristics:

• Above transition lines going left-to-right

• Below transition lines going right-to-left
• Right of transition lines going down
• Left of transition lines going up

5. Guards

5.1 Guards Should Not Overlap

The guards on similar transitions leaving a state must be consistent with one another. For
example guards such as x <0, x = 0, and x > 0 are consistent whereas guard such as x <= 0 and x >= 0
are not consistent because they overlap – it isn’t clear what should happen when x is 0. You see in
Error! Reference source not found.that the guards on the student dropped transitions from the Being
Taught state do not overlap.
5.3 Introduce Junctions to Visually Localize Guards
In Figure 4.9 you see that there are two transitions from Being Taught as the result of the student
dropped event, whereas there is only one in 4.10 – the transitions are combined into a single one that
leads to a junction point (the filled in circle). The advantage of this approach is that the two guards are
now depicted close to one another on the diagram, making it easier to determine that the guards don’t
overlap.

5.3 Guards Need Not Form a Complete Set

It is possible for the guards on the transitions from a state to not form a complete set. For example,
a bank account object might transition from the Open state to the Needs Authorization state when a large
deposit is made to it. However, a deposit transition with a “small deposit” guard may not be modeled –
you’re following the AM Depict Models Simply practice and only including pertinent information – although
it would be implied.

5.4 Name Guards Consistently

Figure 4.8 includes guards such as seat available and no seat available, two consistently worded
guards. However, had the various guards been worked seats left, no seat left, no seats left, no seats
available, seat unavailable, … they would not have been consistent and harder to understand.

As a summary, we should create state diagrams when the business logic for a particular flow is very
complex, or needs greater understanding by the developer to be coded perfectly. Arrange the states and
transitions to ensure that the lines that cross each other are minimal. Criss-crossing lines are potential
sources of confusion in conveying the diagram's meaning. Statechart Diagram is very much important in
designing a particular system. Through this diagram, we are able to know the life cycle of a system. We
are able to point out what part of the system occurs complexity. We are also able to analyze the stages
and behaviors of each object.

Object-Oriented Analysis

Most new client-server application development tools emphasize object-oriented features. The
introduction of the object-oriented approach in th 1970s marked a radical change in the methodology and
approach of large-scale application development. In contrast to the old paradigm where each module in
a system denotes a major step in some overall process, where applications relied heavily on testing and
debugging to meet required specifications, the object-oriented paradigm requires that applications are
decomposed by primary objects and major components are developed independently.

Suppose you're at the dinner table, you would like some salt, and the salt shaker is inconveniently located
at the other end of the table. You might say to your friend, "Please pass me the salt," and she would do
so. On the other hand, instead of saying just "Please pass me the salt," you could try, "Please remove
your right hand from your wine glass, move it to the left until it contacts the salt shaker, grasp it, lift it from
the table, move it in a natural arc in my direction, stop when it contacts my hand, wait until my hand has
closed around it, and then release it. The object-oriented way is to say "Pass the salt," and leave it up to
the object to carry out the request any way it chooses. The procedural way is to specify each and every
step of getting that shaker of salt into your hands.
Concepts Of Object-Orientation

Encapsulation
• An object is a "black box" (that contains code and data) which receives and sends messages.
• All communication is to be done via messages. Messages define the interface to the object.
• The action that a message carries out is called a method. It is the code that gets executed when
the message is sent to a particular object.
• An object can be used without knowing exactly what is inside of it, and it becomes unnecessary
to directly modify the object.
• Providing access to an object only through its messages, while keeping the details private is called
encapsulation"
• Encapsulation is important because parts of software must sometimes be changed or re-used.

Classes
An object is defined via its class which determines everything about an object. Objects are individual
instances of a class. "For example, you may create an object called Tagpi from class Dog. The Dog class
defines what it is to be a Dog object, and all the "dog-related" messages a Dog object can act upon". All
object-oriented languages have some means to create object instances from a class definition.

More than one object can be created for a class. In the above example, objects named Putot and Batik
might also be created in class Dog. In a class, messages are defined that objects in the class understand.
Using the above example, the Dog objects might understand messages such as Bark, Fetch, and Roll-
over.

Arguments are supplied as part of a message. "For example, the "fetch" message might contain an
argument that says what to fetch or the "roll-over" message could contain one argument to say how fast,
and a second argument to say how many times"

Inheritance
If there is already a class which can respond to many different messages, it is possible to make a new,
similar class which adds just a couple more messages without having to re-write the entire class by
creating a subclass. This new class inherits all the existing messages, and therefore, all the behavior of
the original class. The original class is called the superclass of the new class.

Inheritance also promotes reuse. It is not necessary to start from scratch when writing a new program if
the existing classes have similar behaviors to those needed in the new program. "For example, after
creating the class Dog, you might make a subclass called Wolf, which defines some wolf-specific
messages, such as hunt. Or it might make more sense to define a common class called Canine, of which
both Dog and Wolf are subclasses".

Object-oriented Analysis VS Other Analysis Methods

OOA differs the most from Structured analysis. "Structured analysis maintains a process-oriented view
of systems, providing a decomposition based on processes, whereas OOA decomposes the problem
domain based on classification entities".
Information engineering is closer to OOA because it provides a variety of tools for modeling of entities
(namely, entity-relationship diagramming). The differences between OOA and information
engineering lie in OOA's requirement for encapsulated operations. "Information engineering violates this
rule because operations may access numerous entities and are not subordinated to one entity".

Developers who are currently using structured analysis techniques usually discover that their experience
in modeling requirements using data flow diagrams is irrelevant or worthwhile only in the context of
modeling existing procedures. Those developers schooled in information engineering will find the road to
object-oriented analysis much easier to follow. However, developers still need to alter their views from
modeling disembodied processes to encapsulated services.

Domain modeling identifies real-world, problem space object or domain objects within a system. The
domain model serves as a glossary of terms for writers of use cases. Domain modeling allows writing
of use cases in the context of the object model or in terms of the domain objects. Effective domain
modeling encourages reuse of objects among applications. Domain objects are abstractions of the real
world i.e. the main conceptual objects that are going to participate in the system concerned. When you
design object-oriented software, you structure the software around objects. Domain objects are modeled
thru Class Diagrams.

Steps In Identifying Domain Objects

1. Gather and document high-level problem statement, lower-level requirements and expert
knowledge on the problem space. The Use-case document may be useful for this.
2. Identify nouns and noun phrases from relevant statements. (Noun Phrase Technique). List
these as potential classes.
3. Refine the list. Nouns and noun phrases become domain objects and attributes. (Verbs and
verb phrases become operations and associations). Discard all the irrelevant, redundant and
incorrect classes according to the following criteria:

Redundant classes: if two classes express the same information, the most descriptive name should
be kept;
Irrelevant classes: if a class has little or nothing to do with the problem, it should be eliminated;
Vague classes: non-specific classes with ill-defined boundaries should be eliminated;
Attributes: names that primarily describe individual objects should be restated as attributes
Operations: if a name describes an operation that is applied to objects and not manipulated in its
own right, then it is not a class.
Roles: the name of a class should reflect its intrinsic nature and not a role that it plays in an
association.
Implementation constructs: constructs extraneous to the real world should be eliminated from the
analysis model.
Or you may ask the following questions:
▪ Is the candidate a synonym of another domain object?
▪ Is the candidate outside the scope of the system?
▪ Is the candidate a role without unique behavior, or is it an external role?
 ▪ Is the candidate unclear or in need of focus?
▪ Is the candidate an action or an attribute?
Any candidate that qualifies to these questions should be discarded.

Steps In Modeling Domain Objects

1. Identify object classes using the Noun Phrase Technique.
2. Identify attributes for each potential class. Attributes are properties of individual objects, such as
name, weight, velocity, or color. Attributes should not be objects; they usually correspond to nouns
followed by possessive phrases, such as "the color of the car", or adjectives. Attributes are not
likely to be fully described in the problem statement, so you must draw on your knowledge of the
application domain and the real world to find them. Get the most important attributes first. Fine
details can be added later. Avoid attributes that are solely for implementation. Be sure to give
each attribute a meaningful name. Derived attributes (e.g. "age") should be omitted or clearly
labeled.
3. Prepare a data dictionary or a paragraph precisely describing each object class. Describe the
purpose and scope of the class within the current problem including any assumptions or
restrictions on its membership or use. Also, describe the class attributes, associations and
operations.
2. Make adjustments in response to findings in later stages. After identifying the candidate attributes,
eliminate unnecessary and incorrect attributes with the following criteria:
▪ If the independent existence of an entity is important, rather than just its value, then it is
an object;
▪ If the value of an attribute depends on a particular context, then consider restating the
attribute as a qualifier;
▪ Identifiers must exist in the problem-domain, implementation-identifiers should not be
listed as attributes.
▪ If a property depends on the presence of a link, then the property is an attribute of the link
and not of a related object
▪ If an attribute describes the internal state of an object that is invisible outside the object,
then eliminate it
▪ Omit minor attributes which are unlikely to affect most operations.
An attribute that seems completely different from and unrelated to all other attributes may
indicate a class that should be split into two distinct classes
4. Identify associations. Any dependency between two or more classes is an association. A
reference from one class to another is an association. Associations often correspond to stative
verbs or verb phrases. These include physical location, directed actions, communication,
ownership, or satisfaction of some condition.
5. Draw the Class Diagram. In the initial Class Diagram, operations need not be included but never
show classes with just two compartments.
6. Refine the class diagram. Operations should be included already in the final analysis class
diagram. Evaluate the attributes, associations, and operations and apply the necessary changes
to the diagram. Discard unnecessary and incorrect associations, using the following criteria:
a. If one of the classes in the association has been eliminated, then the association must be
eliminated or restated in terms of other classes.
b. Eliminate any associations that are outside the problem domain or deal with
implementation constructs.
c. An association should describe a structural property of the application domain. Eliminate
associations that describe a transient event.
 d. Try to decompose associations between three or more classes in binary associations, or
phrase them as qualified associations. If a term in a ternary association is purely
descriptive and has no features of its own, then the term is a link attribute on a binary
association. Omit associations that can be defined in terms of other associations because
they are redundant. Also omit associations defined by conditions on object attributes.
7. Organize and simplify object classes using inheritance. Inheritance can be added in two different
ways:
a. Bottom up: by generalizing common aspects of existing classes into a superclass.
You can discover inheritance from the bottom up by searching for classes with similar attributes,
associations, or operations. For each generalization, define a superclass to share common
features. Some attributes or even classes may have to be redefined slightly to fit in properly (this
is acceptable, but don't push too hard if it doesn't fit, you may have the wrong generalization).
Some generalizations will suggest themselves based on an existing taxonomy in the real world;
use existing concepts whenever possible.
b. Top down: by refining existing classes into specialized subclasses. Top-down specializations
are often apparent from the application domain. Look for noun phrases composed of various
adjectives on the class name (e.g. fixed menu, pop-up menu, sliding-menu). Avoid excessive
refinement. If proposed specializations are incompatible with an existing class, the existing class
may be improperly formulated.

Modeling software structure, behavior and architecture

In object-oriented approach, the system structure, architecture and behavior should be analyzed using
appropriate modeling tools. The static and dynamic behaviors of a system are communicated using
diagrams that may emphasize either the behavioral aspects, the structural aspects, or the architectural
aspects of a software system. The behavioral aspects involve the functionalities provided by the system
(static behavioral aspects) and their associated interactions, timings, and orderings (dynamic behavioral
aspects). Structural aspects involve the class structures of the software and the interrelationships
among the classes (static structural aspects), and the algorithmic details of object life cycles and their
interactions (dynamic structural aspects). Architectural aspects are related to the deployment and
distribution of software and hardware across the various distributed system components.

Object-oriented Modeling Tools

The Class Diagram
The class diagram shows a collection of classes and how they are related to one another. It is
used to express a class structure(ex. a hierarchical relation or relationships between classes) and to view
the problem domain logically and statically. A class diagram is similar to a family tree. A class diagram
consists of a group of classes and interfaces reflecting important entities of the business domain of the
system being modeled, and the relationships between these classes and interfaces. The classes and
interfaces in the diagram represent the members of a family tree and the relationships between the
classes are analogous to relationships between members in a family tree. Interestingly, classes in a class
diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or
matriarch of the family, as the case may be) and related child classes under the parent classes.
In a class diagram, classes are represented by a box with three(3) sections:
1. top section – contains the name of the class
2. middle section – contains the attributes (properties/behaviors) of the class
3. lower section – contains the operations (methods/functions) of the class

Example of a class representation:

Asset

Title:

Acquisition Date:

Check out

Calculate due date

Relationships (Associations) Between Classes

1. Normal Association
• Is a temporary relationship between classes. Classes do not always have relationships with
each other.
• Represented with a line
2. Inheritance (Generalization ) Relationship – “IS A”
• Exists when one class object is a specialized version of another class
• Represented by a line with a triangle at the end of the line
• Triangle points to the generalized class
3. Aggregation Relationship – “HAS A”
• Exists when one class is “part-of” another class
• Represented with a line (association) with a diamond at the end of it

Parts of an Association Relationship:

1. Association Name
For an association name, an arbitrary name(in active voice) is indicated at the center of the
association. Add a small blank triangle to specify the direction for reading names.
2. Role Name
Role name indicates the purpose, position and role of a class in association with another class. This
is described as a character string near the end of a line segment. A role name is optional but cannot
be hidden. Indicate role names when multiple associations between two classes exist and indicate
role names on recursive associations.
3. Multiplicity
Multiplicity indicates the range of the number of instances that associated classes may have.
This can be hidden. An integral range, including zero, is specified in the format. See Table 1.
4. Visibility
For visibility, an indicator (+, #, -) or explicit keyword like [public] is added before a role name
to indicate how the object having the role looks like from the client of the other object. See
Table 2.
5. Ordering
Ordering is specified if the multiplicity is greater than 1. The element order is determined only
when ordering is specified.
6. Inductive Visibility
Inductive visibility indicates that the class can send a message to or reference information at
the other related class. An arrow is attached to the end of an association to indicate that
inductive visibility is supported for the class to which the arrow points.

Types of Aggregation (“HAS-A”) Relationship:

1. Composite aggregation(Composition):
• A relationship between two classes where one class cannot exist without the other class.
When you destroy the host(aggregate) class, the other class is destroyed
• For example, Order Detail class requires the Orders (Order Header) class. An Order Detail
cannot exist without an Order, but an Order can probably exist without an Order Detail
• Represented by a filled diamond in the line connecting the classes represents a composite
aggregation

2. Simple Aggregation:
• A relationship between two classes where one class is dependent on another class but it still
can exist without the other class
• For example, Customer Master List class includes the Customer class. The Customer class
can still exist without the Customer Master List class.
• Represented by a diamond that is not filled on the line connecting the classes
Figure 4.11. Example of regular association, aggregation and composition.

Guidelines In Domain Modeling And Analysis Using Class Diagram

1. Class, attribute and operation names should be in simple English using common terminology.
Class names should be complete singular noun; attributes should be domain-based nouns; name
operations with a strong verb.
2. Focus on identifying class responsibilities instead of attributes and operations. For example, the
Invoice class is responsible for providing its total, but whether it maintains this as an attribute or
simply calculates it at request time is a design decision that you’ll make later.
3. It is not necessary to show visibility since default visibility of attributes and operations is public.
4. Do not include attribute type(except required), parameters, and return values
5. Always model association classes (associations that have methods and attributes) via a dashed
line attached to the center of the association. Do not name associations with association classes
already. The name of the association class should adequately describe the association. See
Figure 1. Note that association classes are typically modeled during analysis and then refactored
during design (Ambler 2001) because mainstream programming languages such as C++ and
Java do not (yet) have native support for this concept.
6. Do not model attributes and operations required to implement basic functionality within your
classes, such as the code required to implement relationships with other classes, and the SETters
and GETters.
7. Always show multiplicity but avoid multiplicity of “*”because your reader can never be sure if you
really meant "0..*" or "1..*". See Figure 2.

Table 4.12 Types of analysis (domain) classes

Class Behavior
Boundary In an ideal multi tier system, the user interacts only with the boundary
classes. For example, JSPs in a typical MVC architecture form the
boundary classes.
 Control These classes typically don't contain any business functionality.
However, their main task is to transfer control to the appropriate business
logic class, depending on a few inputs received from the boundary
classes.

Entity These classes are those that contain the business functionality. Any
interactions with back-end systems are generally done through these
classes.

• Interface: An interface is a variation of a class. As we saw from the previous point, a class provides
an encapsulated implementation of certain business functionality of a system. An interface on the
other hand provides only a definition of business functionality of a system. A separate class
implements the actual business functionality.

So, why would a class not suffice? You can define an abstract class that declares business
functionality as abstract methods. A child class can provide the actual implementation of the
business functionality. The problem with such an approach is that your design elements get tied
together in a hierarchy of classes. So, even though you may not have intended to connect your
design elements representing drastically different business entities, that is what might result.
Hence, the use of the interface design construct in class diagrams. Different classes belonging to
different and discrete hierarchies can maintain their distinct hierarchies and still realize the
functionality defined in the methods of the interface.

An interface shares the same features as a class; in other words, it contains attributes and
methods. The only difference is that that the methods are only declared in the interface and will
be implemented by the class implementing the interface.

In addition to the above, there is one more element used in class diagrams:

• Package: A package provides the ability to group together classes and/or interfaces that are either
similar in nature or related. Grouping these design elements in a package element provides for
better readability of class diagrams, especially complex class diagrams.

Figure 4.12—a package

From Figure 4.12, you can see a package is represented as a tabbed folder. A package can also
have relationships with other packages similar to relationships between classes and interfaces.
Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship
between them. The following table shows the kinds of relationships between classes, their notation, and
what they mean.

Table 4.14 Class Relationships Symbols

Relation Symbol Description

Association When two classes are connected to each
other in any way, an association relation is
established. For example: A "student studies
in a college" association

Multiplicity An example of this kind of association is

many students belonging to the same
college. Hence, the relation shows a star
sign near the student class (one to many,
many to many, and so forth kind of
relations).
Directed Association between classes is bi-
Association directional by default. You can define the
flow of the association by using a directed
association. The arrowhead identifies the
container-contained relationship.

Reflexive No separate symbol. However, An example of this kind of relation is when a

Association the relation will point back at class has a variety of responsibilities. For
the same class. example, an employee of a college can be a
professor, a housekeeper, or an
administrative assistant.
Aggregation When a class is formed as a collection of
other classes, it is called an aggregation
relationship between these classes. It is also
called a "has a" relationship.

Table 4.14 UML Multiplicity indicators.

0…1 Zero or one

1 One only
0…* Zero or more
1..* One or more
N Only n (where n > 1)
* Many
0…n Zero to n (where n > 1)
 1…n One to n (where n > 1)
n…m Where n & m both > 1 more when n>1
n…* N or more where n > 1

Table 4.15. Visibility options on UML class diagrams.

Visibility Symbol Accessible To

Public + All objects within your system.
Protected # Instances of the implementing class and
its subclasses.
Private - Instances of the implementing class.
Package ~ Instances of classes within the same
package.

Figure 4.13. Modeling association classes.

Figure 4.14. Modeling an order

NOTE: Item appears on Order but was not modeled because association is implied through OrderItem
UML Interaction Diagrams

An interaction is a behavioral specification that comprises a sequence of message exchanges

among a set of objects within a context to accomplish a specific purpose, such as the implementation of
an operation. To specify an interaction, it is first necessary to specify a context, that is, to establish the
objects that interact and their relationships. Then the possible interaction sequences are specified. These
can be specified in a single description containing conditionals (branches or conditional signals), or they
can be specified by supplying multiple descriptions, each describing a particular path through the possible
execution paths.

Interaction diagrams are models that describe how a group of objects collaborate in some
behavior - typically a single use-case. The diagrams show a number of example objects and the
messages that are passed between these objects within the use-case.

Interactions are shown as sequence diagrams or as collaboration diagrams both present in UML.
Both diagram formats show the execution of collaborations.

Sequence diagrams were found in a variety of OO methods under a variety of names and date to
pre-OO days. Collaboration diagrams were adapted from Booch (object diagram), Fusion (object
interaction graph), and a number of other sources. Collaborations are now first-class modeling entities,
and often form the basis of patterns.

1. Sequence Diagram - A sequence diagram shows the interactions among a set of objects in temporal
order, which is good for understanding timing issues. In this form, objects are shown as vertical lines with
the messages as horizontal lines between them. This form was first popularized by Jacobson.
2. Collaboration diagram - A collaboration diagram is a scenario diagram that shows the sequence of
messages that implement an operation or a transaction. Whereas Sequence diagrams emphasize the
temporal flow of behavior,

Collaboration diagrams emphasize relationships. They define a context, that is, a graph of objects and
links with message flows attached to its links. The context of the diagram shows the objects relevant to
the performance of an operation, including objects indirectly affected or accessed during the operation.

Scenario: the order entry window sends a prepare message to an order. The order then sends prepare
to each order line on the order. The order line first checks the stock item, and if the check returns true it
removes stock from the stock item. If stock item falls below the reorder level it requests a new delivery.

Sequence Diagrams

A sequence diagram has two dimensions: the vertical dimension represents time; the horizontal
dimension represents different objects. Normally time proceeds down the page. (The dimensions may be
reversed if desired). Usually only time sequences are important but in real-time applications, the time
axis could be an actual metric. There is no significance to the horizontal ordering of the objects. Objects
can be grouped into "swim lanes" on a diagram.

Within a sequence diagram an object is shown as a box at the top of a dashed vertical line (See
Fig 1). This vertical line is called the object's lifeline. The lifeline represents the object's life during the
interaction.
 Each message is represented by an arrow between the lifelines of two objects. The order in which
these messages occur is shown top to bottom on the page. Each message is labeled at minimum with
the message name; you can also include the arguments and some control information, and you can show
self-delegation, a message that an object send to itself, by sending the message arrow back to the same
lifeline.

Figure 4.15 A Sequence Diagram

Two bits of control information are valuable. First, there is a condition, which indicates when a
message is sent (for example, [remove()=“true”). The message is only sent if the condition is true. The
second useful control marker is the iteration marker, which shows that a message is sent many times to
multiple receiver objects, as would happen when you are iterating over a collection (such as *prepare).

Collaboration Diagrams

The second form of the interaction diagram is the collaboration diagram. Here the example objects
are shown as icons. Again arrows indicate the messages sent in the use case. This time the sequence
is indicated by a numbering scheme. Simple collaboration diagrams simply number the messages in
sequence. More complex schemes use a decimal numbering approach to indicate if messages are sent
as part of the implementation of another message. In addition a letter can be used to show concurrent
threads.
 Figure 4.16 A collaboration Diagram

In the past, people used the simple numbering scheme. The UML uses the decimal scheme
because it makes it clear which operation is calling which other operation, although it is harder to see the
overall sequence. Regardless of what numbering scheme you use, you can add the same kind of control
information you might show on a sequence diagram.

Different people have different preferences when it comes to choosing the form of interaction
diagram to use. Some prefer the sequence diagram because it puts emphasis on sequence; it is easy to
see the order in which things occur. Others prefer the collaboration diagram because they can use the
layout to indicate how objects are statically connected.

One of the great strengths of an interaction diagram is its simplicity. You can easily see the
messages by looking at the diagram. They do, however, have weaknesses, the principal one is that
although they are good at describing behavior: they do not define it. If you try to represent something
other than a single sequential process without much conditional or looping behavior, the technique begins
to break down.

They typically do not show all the iteration and control that is needed to give a computationally
complete description. Various things have been done to try and remedy this. Jacobson uses pseudo-
code in conjunction with sequence charts to provide a more executable model. Others have added
various diagrammatic notations to increase the model's executability. Many of these are included in the
UML.

However, the beauty of interaction diagrams is their simplicity, and much of these additional
notations lose this in their drive to computational completeness. Thus it might be a good idea not to rush
to the more complex forms of interaction diagrams; you may find that the simpler ones give you the best
value.

Interaction diagrams should be used when you want to look at the behavior of several objects
within a single use case. They are good at showing the collaborations between the objects; they are not
so good at precise definition of the behavior.
 If you want to look at the behavior of a single object across many use-cases, use a state transition
diagram. If you want to look at behavior across many use cases or many threads, consider an activity
diagram.

One of the great strengths of an interaction diagram is its simplicity. It is difficult to write much
about interaction diagrams because they are so simple. They do, however, have weaknesses, the
principal one is that although they are good at describing behavior: they do not define it. They typically
do not show all the iteration and control that is needed to give a computationally complete description.

REFERENCES:

Software Engineering: A Practitioner’s Approach 7/e by Roger S. Pressman

https://www.visual-paradigm.com

https://www.uml-diagrams.org/

https://www.youtube.com/watch?v=sB2iQSvrcG0

ASSESSMENTS:

1. Following your adapted approach ins systems analysis (procedural vs object-oriented), identify
the different tools that you will use to model and specify your proposed software solution.
2. Use appropriate software available online to draw the diagrams that will specify the different
objects, the structure, the behavior and architecture of your proposed solution.
3. Specify your proposed software specifications following the IEEE standard for detailed Software
Requirements Specification document/template.
4. Present your outputs and discuss your most significant learnings from the topic and the activities.
5. *Watch the video clip https://www.youtube.com/watch?v=sB2iQSvrcG0. Relate your
learnings from the video with the topic you read from this material. Discuss.

Note: * for OL mode

 6. SOFTWARE DESIGN

LEARNING OBJECTIVES:
• Apply various design principles, techniques and patterns in the development of a software
project.
• Construct an architectural diagram based on the analyzed system requirements.
• Design the software data, program/class structure, and static behavior based on specified
requirements
• Design a preliminary system prototype or working model/version of the software.
• Apply patterns in the design of a software solution effectively
• Validate each design component for each subsystem of the project.

OVERVIEW:

Developing software involves many important steps and phases, just as any product does. The product’s
efficacy, the customer’s satisfaction, and the cost-effectiveness are all as important as they are for any
developed hardware product, and are likewise reliant on a multi-stepped and sometimes complicated
process. The actual design, which can be thought of as a blue print, cannot begin until the requirements
are determined. Software requirements documents such as the SRS, help determine what the software
must accomplish. Once software requirements have been specified, these specifications are translated
into software design specifications. After this step, the actual design is done, and then the coding can
take place, after which testing, debugging, and maintenance occur (“Software design”, n.d., para 1).

READING MATERIALS:

Understanding Software Design

Software design is a process of defining the architecture, components, interfaces, and other
characteristics of a system or component and planning for a software solution. After the purpose and
specifications of software is determined, software developers will design or employ designers to develop
a plan for a solution (archive.cnx.org, n.d). It is the process by which an agent creates a specification of
a software artifact intended to accomplish goals, using a set of primitive components and subject
to constraints (Ralph & Wand, 2009). Software design may refer to either "all the activity involved in
conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or
"the activity following requirements specification and before programming, as a stylized software
engineering process" (Freeman & Hart, 2004). Software design usually involves problem-solving and
planning a software solution. This includes both a low-level component and algorithm design, and a high-
level architecture design.

We can see software design in three main levels:

• Architectural Design – The architectural design is the highest abstract version of the system. It
identifies the software as a system with many components interacting with each other (Tutorialspoint,
n.d.).
• High-level Design- Focuses on how the system along with all of its components can be implemented
in forms of modules. It recognizes modular structure of each sub-system and their relation and
interaction among each other(Tutorialspoint, n.d.)..
• Detailed Design- It is more detailed towards modules and their implementations. It defines logical
structure of each module and their interfaces to communicate with other modules(Tutorialspoint, n.d.).

Software Design Document

Design specifications are found in Software design documentation (SDD). SDD may be reviewed or
presented to allow constraints, specifications and even requirements to be adjusted prior to computer
programming. Redesign may occur after review of a programmed simulation or prototype. The SDD
usually contains the following information:
1. The data design describes structures that reside within the software. Attributes and relationships
between data objects dictate the choice of data structures.
2. The architecture design uses information flowing characteristics, and maps them into the program
structure. The transformation mapping method is applied to exhibit distinct boundaries between
incoming and outgoing data. The data flow diagrams allocate control input, processing and output
along three separate modules.
3. The interface design describes internal and external program interfaces, as well as the design of
the human interface. Internal and external interface designs are based on the information
obtained from the analysis model.
4. The procedural design describes structured programming concepts using graphical, tabular and
textual notations.

Design Principles
Basic design principles enable the software engineer to navigate the design process. Davis (Davis, 1995)
suggests a set of principles for software design, which have been adapted and extended in the following
list:
• The design process should not suffer from "tunnel vision." A good designer should consider
alternative approaches, judging each based on the requirements of the problem, the resources
available to do the job.
• The design should be traceable to the analysis model. Because a single element of the design
model can often be traced back to multiple requirements, it is necessary to have a means for tracking
how requirements have been satisfied by the design model.
• The design should not reinvent the wheel. Systems are constructed using a set of design patterns,
many of which have likely been encountered before. These patterns should always be chosen as an
alternative to reinvention. Time is short and resources are limited; design time should be invested in
representing (truly new) ideas by integrating patterns that already exist (when applicable).
• The design should "minimize the intellectual distance" between the software and the problem
as it exists in the real world. That is, the structure of the software design should, whenever possible,
mimic the structure of the problem domain.
• The design should exhibit uniformity and integration. A design is uniform if it appears fully
coherent. In order to achieve this outcome, rules of style and format should be defined for a design
team before design work begins. A design is integrated if care is taken in defining interfaces between
design components.
• The design should be structured to accommodate change. The design concepts discussed in
the next section enable a design to achieve this principle.
• The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. Well-designed software should never "bomb"; it should be
designed to accommodate unusual circumstances, and if it must terminate processing, it should do
so in a graceful manner.
• Design is not coding, coding is not design. Even when detailed procedural designs are created
for program components, the level of abstraction of the design model is higher than the source code.
The only design decisions made at the coding level should address the small implementation details
that enable the procedural design to be coded.
• The design should be assessed for quality as it is being created, not after the fact. A variety of
design concepts and design measures are available to assist the designer in assessing quality
throughout the development process.
• The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes
a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A
design team should ensure that major conceptual elements of the design (omissions, ambiguity,
inconsistency) have been addressed before worrying about the syntax of the design model.

Fundamental Design Concepts

The design concepts provide the software designer with a foundation from which more sophisticated
methods can be applied. A set of fundamental design concepts has evolved:

1. Abstraction - Abstraction is the process or result of generalization by reducing the information

content of a concept or an observable phenomenon, typically in order to retain only information
which is relevant for a particular purpose. It is an act of Representing essential features without
including the background details or explanations.
2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a
macroscopic statement of function in a step-wise fashion until programming language statements
are reached. In each step, one or several instructions of a given program are decomposed into
more detailed instructions. Abstraction and Refinement are complementary concepts.
3. Modularity - Software architecture is divided into components called modules.
4. Software Architecture - It refers to the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system. Good software architecture will yield a good
return on investment with respect to the desired outcome of the project, e.g. in terms of
performance, quality, schedule and cost.
5. Control Hierarchy - A program structure that represents the organization of a program component
and implies a hierarchy of control.
6. Structural Partitioning - The program structure can be divided into both horizontally and vertically.
Horizontal partitions define separate branches of modular hierarchy for each major program
function. Vertical partitioning suggests that control and work should be distributed top down in
the program structure.
7. Data Structure - It is a representation of the logical relationship among individual elements of data.
8. Software Procedure - It focuses on the processing of each module individually.
9. Information Hiding - Modules should be specified and designed so that information contained
within a module is inaccessible to other modules that have no need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularisation, and Hierarchy
as fundamental software design principles (Booch et al, 2004) . The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularization, and Encapsulation) is sometimes used to refer to these four
fundamental principles (Suryanarayana, 2014).

Design Concepts: Module Partitioning Techniques

1. Data-Oriented Technique. Also called data flow-oriented technique, it depends on identifying the
flows of data through the intended software, together with the transformations on the flows of data. There
are several methods under this technique:

STS Method
The acronym STS stand for Source, Transform, and Sink. In the STS partitioning method, the program
processing is divided into three functions: Source (input section), Transform (processing section), and
Sink (output section). STS partitioning has partitioning criterion boundary points called the maximum
abstraction input point and the maximum abstraction output point, ad modules are partitioned using these
points. A point immediately before the input transformed losing its original form as it is, is called the
maximum abstraction input point. The point where the output data begins to be created, as process
steps are traced in the reverse order from the final output is called the maximum abstraction output
point. The section from data input to the maximum abstraction input point is defined as S (Source), the
section from the maximum abstraction input point to the maximum abstraction output point is defined as
T (Transform), and the section from the maximum abstraction point to output is defined as S (Sink). This
method is illustrated below:

STS partitioning is suited for partitioning based on data flow without branches. Basically, the same
processing is performed for all input data. it is difficult to implement compared to transaction method.
Procedures of STS Partitioning:
1. Clarify and extract the problem structure.
2. Determine the main flow of input data and output data in the problem structure.
3. Find the logical final point of the input data flow and the logical first point of the output data flow.
4. Use these points as partitioning points, and describe each section as a single function.

Transaction Partitioning Method. Transaction means a unit of processing for which a request is issued
to the computer to perform a specific process. A structured design where/that:
1. Modules are partitioned with focus on transaction
This method is used when input data can be classified into different types of processing.
2. Is suitable for branched data flow
Transaction is suited for data flow with branches because 2 or more types of data exist, and
processing suited to each type is performed while in STS method same processing is performed to all
input data.

Function

Function

Input Function Function Output

Function

Common Function Partitioning Method. This method separates a module having a commonly used
function from those that have been identified as a result of either the STS method or the Transaction
method. Generally, it has a main module that handles 3 types of processing, INIT (initialization), PROC
(procedure), and END. The main module thus consists mostly of instructions calling these 3 processing
functions.
Steps: Partitioning the PROC function
1. Find the Maximum Control Function in PROC processing
2. Determine the Process Function, which is dependent on the control function.
3.
<<PROC>>

Terminates Matching Process (Control Function)

Matching the master and the

transaction file (Processing Function)

4. Control Function and the Processing Function are examined.

The Matching the master and the transaction file has a control function and has three processing
function as you can see in the picture below
 <<Matching the master and the transaction file>>

Compare key items (Control Function)

Processing Processing when Processing

when the key item in the when the
key item is master matched key item is
found only with the key not found in (Process Function)
in the item in the the master
master file transaction file file

5. Find the Control Function in each Processing Function and its subordinate processing functions.
Repeat this procedure and partition until no control function can be found.
• Processing function when key item is found only in the master file
The function does not include any control function and it means no further partitioning. This
processing function can be changed to “copy master file” to represent the function more
accurately.
• Processing function when key item in the master matched with the key item in the
transaction file

Control function within this processing function is the Correction category

Correction category Subordinate processing function

1 Indicate new setting Error processing(duplicate)

2 Indicate changed Change processing

3 indicate cancellation Cancellation Processing

Each subordinate processing function do not contain a control function, thus stops the partitioning.
Change the name of the processing that is carried out when the master file matches with the
transaction files the “update master file”.

• Processing function when key item is not found

The same as the previous processing function, it also has correction category as the
control function but different subordinate processing function.

Correction category Subordinate processing function

1 Indicate new setting New setting processing

2 Indicate changed Error processing(unmatched)

3 indicate cancellation Error processing(unmatched)

In this case partition ends here. Again, change the name of the process when the key item is not
found as “creation of new master file”
6. When no more control function is found, focus on the processing function to partition major
processing function into single functions.

Single function Write a Read a Read a Write a

new master file transaction maintenance
master listing
file

Major functions

Copy a master file • •

Update a master file •

Create new master file •

Change processing •

Cancellation processing •

Error proc.(duplicate) •

New Setting •

Error proc.(unmatched) •

Error proc.(unmatched) •

The objective of this partitioning is to obtain information about common internal modules in a program
thus if the same function is found in several places, it can be handled as a common internal module
in the program. In this example, the previous four functions that appeared as single function
separately are considered as module.
7. Combine the functions into unit of module so that it is easier to exist as such. While consolidate
modules that can be shared, name each module in such manner that represents the function and
its function can be easily understood from the name. In this example, error processing for
“unmatched state of change indication” and the error processing for “unmatched state of
cancellation indication” can be combined into one module. Use the same steps for INIT
processing and END processing to refine and evaluate the whole module structure. Summing up
the above descriptions, here is the hierarchical structure of the program.
 Master maintenance

INIT PROC END

Read a Read a
master file transaction

Copy a Update Create new

master file master file master file

Read a Write new Read a New Error Processing

master file master file transaction creation (unmatched)

Read a Change Cancellation Error Processing Write Write

transaction Processing Processing (duplicate) maintenance maintenance
listing listing

Write Write Write

maintenance maintenance maintenance
listing listing listing

2. Structure-Oriented Technique. Data Structure-Oriented methods represent software requirements

by focusing on data structure rather than data flow. Data structure oriented analysis methods lay the
foundation for software design that the data structure be represented using the sequence, selection and
repetition constructs for composite data. There are several methods under this technique:

Jackson Method
A method designed by Michael A. Jackson and John Cameron. The program structure is based on the
corresponding relationship between the input data structure and the output data. The concept of this
method implies that when the corresponding relationship between the data is revealed, the structure of
the program can be clarified as well. It is best suitable for handling input- output of clear data structure
(i.e. job processing system). The steps in partitioning a program are:
1. Define the structure of input data and output data.
2. Check for a one-to- one relationship between the components of input data and output data. If no
relationship found, define an intermediate data structure.
3. Create the program structure based on the corresponding relationship of the components.
4. Assign basic instructions according to the program structure.
There are four structures of data, namely: basic, consecutive, repetition and selection.

➢ Basic
The lowest part of the structure, it cannot be decomposed further.

A B
 ***Data A, Data B
**Indicates a data item
➢ Consecutive
Sequence components consist of elementary component parts that occur in a specific
order, left to right. The leftmost component part occurs first and the rightmost part occurs
last.

D consists of D andEE, and a sequence of D to E is represented

***C is
**Indicates a selection record
➢ Repetition
Iteration components include one component that may occur once, many times, or not at
all.

***F is a repetition of B by times or more

**Indicates a repetition record
➢ Selection
Selection components consist of two or more component parts; however, only one part
occurs for each component.

I J

***H is either B or C
**Indicates a selection record
The structure of data is then represented with a chart called a JSP Tree (Jackson Structured
Programming).
Warnier/ Orr Method
A hierarchical flowchart designed by Jean Dominique Warnier (France) and Kenneth Orr (US). It is a
method designed mainly on the structure of the input data. The Warnier method analyzes the input data
with regards to the Hierarchy, Sequence, Selection, Repetition, Concurrency and Recursion. In
comparison with the Jackson Method, This method places more importance on how many times the data
appears during processing. It makes use of brackets to denote the sub process of a process or a sub
element of an element.

Different Constructs Considered in Warnier Method

➢ Hierarchy
Hierarchy is the most fundamental of all of the Warnier/Orr constructs. It is simply a nested
group of sets and subsets shown as a set of nested brackets.

First Name

Customer Middle Name

Name Last Name

Customer Street Address

➢ Sequence
It is the simplest structure of this method. Within one level of hierarchy, the features are
shown in the order in which they occur.

Step 1

Step 2

Process Step 3

➢ Repetition
It is the representation of classical “loop” in programming terms. It occurs whenever the
same set of data occurs over and over again or whenever the same group of actions is to occur
over and over again. Repetition is indicated by placing a set of numbers inside parentheses
beneath the repeating set.

Month Day etc..

(28, 31)
 ➢ Alternation/Selection
The traditional “selection” process whereby a determination is made to execute one process or
another. It indicates a relationship between two subsets of a set. The exclusive OR symbol
indicates that the sets immediately above and below it are mutually exclusive (if one is present
the other is not). It is also permissible to use a “negation bar” above an alternative in a manner
similar to engineering notation.

Management ..etc.

(0,1)

Employee

➢ Concurrency
One of the advanced constructs in the methodology. It is used whenever sequence is
unimportant.
➢ Recursion
Recursion is the least used of the constructs. It is use to indicate that a set contains an
earlier or less ordered version of itself.
Warnier Method performs processing based on the contents of input data, the processing
structure is determined according to how often the data appears during processing. It may look
simple yet it is a powerful tool to partition a data structure.

Data-Oriented Technique Vs Structure-Oriented Technique

Data-Oriented depends on identifying the flows of data through the intended software, together with the
transformations on the flows of data. The data-oriented design approach extended the procedural
techniques by explicitly integrating information flow into the design process. A data flow-oriented
approach to design is particularly useful when information is processed sequentially and no formal
hierarchical data structure exists.
On the other hand, Data Structure-Oriented methods represent software requirements by focusing on
data structure rather than data flow. Although each data structure-oriented method has a distinct
approach and notation, all have some characteristics in common: (1) each assists the analysis in
identifying key information objects (also called entities or items) and operations (also called actions or
processes); (2) each assumes that the structure of information is hierarchical; (3) each requires their flow-
oriented counterparts like data structure oriented analysis methods lay the foundation for software design
that the data structure be represented using the sequence, selection and repetition constructs for
composite data; and (4) each provides a set of or mapping a hierarchical steps of data structure into a
program structure.

Measuring a Module
1. Coupling and Cohesion
The ideas of coupling and cohesion are a terminology and a classification scheme for describing the
interactions between modules and within modules. Ideally, a piece of software should be constructed
from modules in such a way that there is a minimum of interactions between modules (low coupling) and,
conversely, a high degree of interaction within a module (high cohesion). If this can be achieved, then an
individual module can be designed, coded, tested, or amended without the undue complications of having
to deal with other modules. Another beneficial effe4ct is that when an error occurs in a module, the spread
of damage to other modules may be limited. Coupling and cohesion are opposite sides of the same coin,
in that strong cohesion will tend to create weak coupling, and vice versa.
Coupling is the degree of interaction between modules.
Types of Coupling:
Bad
(a) Content Coupling
(b) Common Coupling
(c) Control Coupling
(d) Stamp Coupling
(e) Data Coupling Good
Content Coupling Content Coupling exists if one module refers to the inside of another. In other words,
it branches into or changes data in or alters a statement in, the other module. Clearly, for this to happen,
the invoking module must know a great deal about the called module.
A

B C

D E

Common Coupling Modules are common coupled if they refer to the same global variable. This is
undesirable because, in the format of the global data needs to be changed, then many modules may be
affected. Unless an up-to-date cross-reference list is maintained, which relates data items to the
modules where they are used, and then it may be necessary to check every module.
 Global

A1

A2

A3

_______________ ________________ ________________

_______________ ________________ ________________
Increment V1 V1 = V2 + A1
Change V1 to Zero
________________ ________________
_________________ ________________ ________________
_________________ ________________ ________________
** It can be difficult to determine which module is responsible for having set a particular value.
Control Coupling. Two modules are control coupled if one passes a parameter to the other, with the
intention of controlling its behavior; in other words, the parameter is a flag. In general, downward –
traveling flags imply that the receiving module is less than a black box. They are thus, undesirable.

EXEC
COMMAND

Parse Flag Command (parsed or unparsed)

GETCOMM

(a)

EXEC
COMMAND

Parsed Command

GETPCOMM

Command
GETCOMM

Command (b)
** The figure above shows that a module, EXEC COMMAND, is able to call another module GETCOMM.
When called, GETCOMM is expected to provide the parameter Command. However, EXEC COMMAND
may require the parameter in parsed or unparsed form. The super ordinate module indicates the version
required by the downward-traveling parameter Parse flag.
An alternative structure, which eliminates parse flag and the consequent control coupling, is shown in
figure b. if parsed command is required, then GETPCOMM calls GETCOMM to obtain the unparsed
version, parses it, and returns it to EXEC COMMAND.
Stamp Coupling. Two modules are stamp coupled if they accept the same record type as a parameter.
This type of coupling may manufacture independency between otherwise interrelated modules. A further
disadvantage of this type of coupling is that it may prevent a basically simple and useful module from
being used elsewhere.

PRODINVOICE

Customer Customer
Record Basic Mile Record
Charge Charge
CALC CALC
BASECHARGE MILECHARGE
Stamp
Coupling
** A module PRODINVOICE is intended to generate invoices for car hire. The invoice value comprises
two components: the basic rental charge (calculated in CALC BASECHARGE) and the mileage charge
(calculated in CALC MILECHARGE) the parameter to both is customer record. Now it may be that the
two subordinate modules need different data items in Customer Record. For instance, CAC
BASECHARGE may need Customer Address and Rental Period. CALC MILECHARGE may require
miles traveled only. Thus, a change to the format or structure of Customer Address for the benefit of
CALC BASECHARGE may enforce changes to CALC MILECHARGE.
Data Coupling. If modules communicate by parameter, each one being either a single data item or a
homogeneous set of data items which do not incorporate any control element, then the modules are data
coupled. This is the necessary communication between modules and is unavoidable.
Cohesion is the interaction within a module.
Types of Cohesion: Bad
(a) Coincidental Cohesion
(b) Logical Cohesion
(c) Temporal Cohesion
(d) Procedural Cohesion
(e) Communicational Cohesion
(f) Sequential Cohesion
(g) Functional Cohesion Good

Coincidental Cohesion. This occurs when there is little or no functional relationship among the elements
of a module.
Logical Cohesion. The elements of a module are logically associated if they appear to fall into the same
logical class of activities. For example, we could combine into a single module all processing elements
that fall into the class of printing output. E.g., output text to screen, output line to printer, output record to
file. The potential disadvantage though is that different types of input may be required at different times
so that the calling module must know something about the inside of the called module and employ a
downward-traveling flag into the bargain.
Temporal Cohesion. The elements of a module are temporally associated if they are logically associated
and related in time. An example might be an initialization module which includes such elements as: read
a control message from the terminal; open disk files; reset counters; set accumulators to zero. Although
temporal is regarded as stronger than logical, experience has shown that it still may lead to complications
at the maintenance stage.
Procedural Cohesion. Often, functions must be performed in certain order. When these functions are
grouped together in a module just to insure its order, then it is procedurally cohesive.
Communicational Cohesion. This type of cohesion occurs when the elements of the module use the
same input data or contribute to the same output data. On the whole, such modules are acceptable
although experience has shown that they may on occasion cause maintenance problems.
Sequential Cohesion. With this type, the output data from one element serves as input to another. As
such a partitioning approach may result in the inclusion of part-functions into a single module, rather than
one complete function, it is not regarded as the ultimate, cohesion-wise.
Functional Cohesion. In a completely functional module, every element is an integral part of, and is
essential to, the performance of a single function. A good operational definition is the following: ‘If it is
not sequential, communicational, procedural, temporal, logical or coincidental...then it is functional!’
 FUNCTION A COINCIDENTAL COMMUNICATIONAL -
Parts Access same data
FUNCTION unrelated
FUNCTION
FUNCTION B C
FUNCTION A
FUNCTION
FUNCTION D E
B
FUNCTION

FUNCTION A’
LOGICAL-
FUNCTION SEQUENTIAL-
similar functions Output of one is
LOGIC FUNCTION A’’ A input to
FUNCTION next

FUNCTION A’’’ B
FUNCTION

Time T0 FUNCTION A- part1 FUNCTIONAL –

TEMPORAL- Sequential
Related by time FUNCTION A- part2
Time T0 + Δ with complete
FUNCTION A- part3 and related
functions
Time T0 + 2Δ

PROCEDURAL-
FUNCTION A Related by order of
functions
FUNCTION B
FUNCTION C

Fan-in and Fan-out

The issue control of one module by another is an important one for functionally decomposed designs.
Suppose our design is composed of modules that are functionally cohesive (to guarantee internal
functional consistency), and we connect the modules in such a way that we have a low degree of coupling
(so that the module are independent of one another). What else we examine to tell us about the quality
of the design?

Fan-in indicates how many modules directly control a given module. It represents the elimination of
replicated code and thus is highly desirable from the maintenance point of view. Fan-in should be
maximized but not in any cost.
Fan-out is a measure of the numbers of modules that are directly controlled by another module. If this
number is excessive the module is deemed as likely to be too complex for comfort and correspondingly
difficult to maintain. The Fan-out of a module should be less than 8. The origin of the upper limit of eight
is obscure. It is at least partially based on Miler’s magical number seven, plus or minus two. This is all
about the limits of human capacity for processing information. It is often quoted as evidence of the number
of subordinates that a human manager can cope with efficiently. It is interesting, therefore, that a heuristic
that won its spurs in the field of human organization design is now quoted in the context of software
design.
Depth & Width provide an indication of the number of levels of control and overall span of control,
respectively. A module that controls another module is said to be super ordinate to it, and conversely, a
module controlled by another is said to be super ordinate to the controller.
Example1:

System 1 A

B C D

E F G

System 2

C B D F G

E
Module A has a fan-out of 3 in system 1 but a fan-out of 5 in system 2. Similarly, the fan-out for module
C in either system is 1. Which is the better design? In general, we want to minimize the number of
modules with a high fan-out. A module controlling many other modules usually indicates that the
controlling module is doing too much; the controlling module probably performing more than one function.
Thus, system 1 may be a better design than system 2 since its modules have low fan-out. On the other
hand, as we increase the number of levels in the design, sometimes we want to use a particular module
more than once.
For instance, in many cases we may need to search a string for particular character. If we design one
general-purpose module to do that task, and then invoke that module from many others, the resulting
design is more efficient and easier to test and modify than one in which there is a proliferation of similar
string-searching functions. Thus, for a design with a large number of levels, will create a set of utility
modules: tools or building bocks that are used by other modules to perform often-needed tasks. A typical
utility module has a high fan-in because it is invoked by many other modules. One of our goals in
designing system is creating modules with high fan-in and low fan-out.
Example2:
Z

A B C

D E K L M

F G H N O P Q

I J R

Module M is super ordinate to modules A, B and C. Module H is super ordinate to module E and is
ultimately super ordinate to module M. Width-oriented relationships (e.g. between module D and E),
although possible to express and practice, need not to be defined with explicit terminology.
Scope of Control and Effect. Finally, we want to be sure that the modules in our design do not affect
other modules over which they have no control. An example will show us why this consideration is
important. Look again at system 1 in the first example. The structure chart leads you to believe that what
happens in C affects only F and G. thus, a change to the design of C should only affect F and G. suppose,
however, that module C resets a pointer in A that then affects the processing module E. in the structure
chart, an arrow connects one module to another only if the first module can invoke the other. For a given
module, the set of modules to which arrows are drawn from it is called the scope of control of the module.
The modules controlled by the given module are collectively referred to as the scope of effect. No module
should be in the scope of effect if it is not in the scope of control. If the scope of the effect of a module is
wider than the scope of its control, it is almost impossible to guarantee that change to the module will not
destroy the entire design.
Conventional VS Object-Oriented Design (OOD)
All design methods strive for software that exhibits abstraction, information hiding, functional
independence and modularity, but only OOD provides a mechanism that enables the designer to achieve
all four important software design concepts with less complexity and compromise.
Like conventional software design, OOD applies data design (when attributes represented), interface
design (when messaging model is developed), and procedural design(in the design of operations).
However, unlike the architectural designs derived using conventional software engineering methods, an
OO design does not exhibit a hierarchical control structure. The “architecture” of an OO design has more
to do with the collaborations among objects with the flow of control.
Because many conventional and OOD approaches are available, it is difficult to develop a generalized
comparison between the two methods. However, the table shows which design components(suggested
by Fichman and and Kemerer) supported by OOD are not supported using structured design or its
derivatives.

Table 6.1 Design Modeling Components (Fichman and Kemerer)

Component OOD Support Conventional
Support
1. representation of hierarchy of modules Yes yes
2. specification of data definitions Yes yes
3. specification of procedural logic Yes yes
4. indication of end-to-end processing sequences Yes yes
5. representation of object states and transitions Yes no
6. definition of classes and hierarchies Yes no
7. assignment of operations and classes Yes no
8. detailed definition of operations Yes no
9. specification of message connections Yes no
10. identification of exclusive services Yes no

Problems with Structured Design Technique

1. The changes to specifications of a function, which is a focused unit in the structured design
techniques can easily happen.
2. In the structured design technique, low-level functions are created to implement a high-level
function. If the high-level function is altered, it may affect the low-level and other functions.
3. In the structured design technique, low-level functions are created to satisfy a high-level function.
Therefore, it is difficult to reuse existing functions.
 4. Since the structured design technique is function-oriented, what should be done to implement a
specific function, tend to be considered in the first place. As a result, data for which functions can
be easily implemented are considered, and it becomes difficult to maintain data consistency.
5. Because of the existence of the same information in different locations, changing the data
structure may affect multiple programs in a system.

Merits of Object-oriented Design

1. Since the visualization of programs is possible, the development efficiency increases. The
visualization of programs means that the characteristics and methods which objects have are
easy to understand.
2. Since a program is separated into objects as units which are independent of each other, it can be
modified easily.
3. Since each object has attributes and methods, which are encapsulated, a program can be
handled as a component and easily ported to another application. Encapsulation means to create
a structure that puts together attributes and methods.

The Object-oriented Design Process

A. Architecture Definition
In the Architecture Definition, the system configuration and job restructuring are defined based on outputs
from the analysis phase. In object-oriented system development, objects are extracted from the system
requirements. Components that can be reuse are created wherever possible, by making extracted objects
more independent through encapsulation.

B. Component Design
In the component design, components contained in subsystems are designed in more detail based on
the outputs of the architecture definition, and also classes contained in each component are designed.
The following are the steps:
1. Class Diagram Refinement
2. Design of an interface between classes in the component

C. Detailed Design
In the detailed design, design is carried out in more detail so that classes contained in the component
can be implemented based on the output of the component design.

Class Diagram in Design

Class diagrams are the basic building block used to define the design of a system. Class diagrams can
be modeled by using any UML tool that supports class diagrams. The Unified Modeling Language (UML)
is a general modeling language to describe software both structurally and behaviorally. It has a graphical
notation and allows for extension.
Classes in a class diagram should be descriptive and must be named after business entities. Using
business entities as names ensures greater readability of class diagrams.

Designing is an incremental process and class diagrams are updated as the system gets built. Hence,
do not try to capture and freeze the class diagrams of a system in the first pass.

Relationships between classes may not be apparent in the first iteration. Revise and refine your class
diagrams to determine possible relationships during each iteration.

Mapping Specificaton to Design

The Design Model

The Analysis Model

Figure 6.1 Translating the Analysis Model into a Software Design

The data object and relationship defined in the entity relationship diagram and the detailed data content depicted in the data
dictionary provide the basis for the data design.

The design-representation – the modular framework of a computer program can be derived from the analysis model and the
interaction of subsystems defined within the analysis model serves as the basis for architectural design.

An interface implies a flow of information (e.g. data and or control). Therefore, the data and control flow diagrams provide the
information required for interface design.
The information obtained from Process specification (PSPEC), Control Specification (CSPEC) and State-Transition Diagram
serve as the basis for procedural design.

Domain Model to Design Model

To understand how a class diagram is translated into a design model, consider the following example:

Figure 6.2 Analysis and design versions of a class.

After a thorough inspection of the two versions of class diagram, the following rules can be extracted:

1. For domain modeling and analysis

- focus on identifying class responsibilities instead of attributes & operations
- attribute and operation name is simple english
- visibility not necessary
- no attribute type (except required), parameter, return value
- Additional note: model association classes via a dashed line attached to the association
class (association classes have no more association name)
2. For detailed design modeling
- attribute name only one word; operation name only one word
- sometimes attribute name with “( )”
- indicate visibility of attributes and operations (+, -, #)
- Additional note: do not model scaffolding codes (attributes and operations required to
implement basic functionality within your classes, such as the code required to
implement relationships with other classes, and the SETters and GETters

For a detailed discussion on the class diagram from a domain model into a design model, take note of
the following:

Model Association Classes On Analysis Diagrams

Association classes, also called link classes, are used to model associations that have methods and
attributes. Figure 6.3 shows that association classes are depicted as class attached via a dashed line to
an association – the association line, the class, and the dashed line are considered one symbol in the
UML. Association classes are typically modeled during analysis and then refactored during design
(Ambler 2001) because mainstream programming languages such as C++ and Java do not (yet) have
native support for this concept.

Figure 6.3. Modeling association classes.

Do Not Name Associations That Have Association Classes

The name of the association class should adequately describe the association, therefore as you see in
Figure 6.3 the association does not need an additional adornment indicating its name.

Center The Dashed Line of an Association Class

The dashed line connecting the class to the association path should clearly be connected to the path and
not to either class or to any adornments of the association so it is clear what you mean. As you see in
Figure 6.3 the easiest way to accomplish this is to center the dashed line on the association path.

Use Common Terminology for Names

A class is effectively a template from which objects are created (instantiated). Although in the real world
Doug, Wayne, John, and Bill are all student objects we would model the class Student instead. Classes
define attributes, information that is pertinent to their instances, and operations, functionality that the
objects support. Classes will also realize interfaces (more on this later). Note that you may need to soften
some of the naming guidelines to reflect your implementation language or software purchased from a
third-party vendor. Class names should be based on commonly accepted terminology to make them
easier to understand by others. For business classes this would include names based on domain
terminology such as Customer, OrderItem, and Shipment and for technical classes names based on
technical terminology such as MessageQueue, ErrorLogger, and PersistenceBroker.

Prefer Complete Singular Nouns for Class Names

Names such as Customer and PersistenceBroker are preferable to Cust and PBroker respectively
because they are more descriptive and thus easier to understand. Furthermore, it is common practice to
name classes as singular nouns such as Customer instead of Customers. Even if you have a class that
does in fact represent several objects, such as an iterator (Gamma et. al. 1995) over a collection of
customer objects, then a name such as CustomerIterator would be appropriate.

Name Operations with a Strong Verb

Operations implement the functionality of an object, therefore they should be named in a manner that
effectively communicates that functionality. Table 2 lists operation names for analysis class diagrams as
well as for design class diagrams – the assumption is that your implementation language follows Java
naming conventions (Vermeulen et. al. 2000) – indicating how the operation name has been improved in
each case.

Table 6.2. Example names for operations.

Initial Name Good Analysis Good Design Name Issue

Name
Open Acc Open Account openAccount() An abbreviation was replaced
with the full word to make it clear
what is meant.
Mailing Label Print Print Mailing printMailingLabel() The verb was moved to the
Label beginning of the name to make it
active.
purchaseparkingpass() Purchase purchaseParkingPass() Mixed case was applied to
Parking Pass increase the readability of the
design-level name.
Save the Object Save save() The name was shortened
because the term “TheObject”
did not add any value.

Name Attributes With a Domain-Based Noun

Like classes and operations you should use full descriptions to name your attributes so that it is obvious
what the attribute represents. Table 3 suggests a Java-based naming convention for analysis names
that in the format Attribute Name, although attribute name and Attribute name formats are also fine if
applied consistently. Table 3 also suggests design names that take an attributeName format, although
the attribute_name format is just as popular depending on your implementation language.

Table 6.3. Example names for attributes.

Initial Name Good Analysis Good Design Issue

Name Name
fName First Name firstName Do not use abbreviations in attribute
names.
firstname First Name firstName Capitalizing the second word of the
design name makes the attribute
name easier to read.
personFirstName First Name firstName This depends on the context of the
attribute, but if this is an attribute of
 the “Person” class then including
“person” merely lengthens the
name without providing any value.
nameLast Last Name lastName The name “nameLast” was not
consistent with “firstName” (and it
sounded strange anyway).
hTTPConnection HTTP httpConnection The abbreviation for the design
Connection name should be all in lower case.
firstNameString First Name firstName Indicating the type of the attribute,
in this case “string,” couples the
attribute name to its type. If the type
changes, perhaps you decide to
reimplement this attribute as an
instance of the class “NameString”
then you would need to rename the
attribute.
orderItemCollection Order Items orderItems The second version of the design
name is shorter and easier to
understand.

Do Not Model Scaffolding Code

Scaffolding code refers to the attributes and operations required to implement basic functionality within
your classes, such as the code required to implement relationships with other classes. Scaffolding code
also includes getters and setters, also known as accessors and mutators, such as getItem() and setItem()
in Figure 6.4 that get and set the value of attributes. Most modelers choose to simplify their class
diagrams by assuming that scaffolding code will be created, many CASE tools can generate it for you
automatically, and therefore will not model it. Figure 6.4 depicts the difference between the OrderItem
class without scaffolding code and with it – including the constructor, the common static operation
findAllInstances() that all business classes implement (in this system), and the attributes item and order
and their corresponding getters and setters to maintain its relationships with the Order class and Item
class respectively.
Figure 6.4 The OrderItem class with and without scaffolding code.

Never Show Classes With Just Two Compartments

It is allowable within the UML to have a class with one or more compartments. Although compartments
may appear in any order, traditionally the top-most compartment indicates the name of the class and any
information pertinent to the class as a whole (such as a stereotype), the second optional compartment
typically lists the attributes, and the third optional compartment typically lists the operations. Other “non-
standard” compartments may be added to the class to provide information such as lists of exceptions
thrown or notes pertaining to the class. Because naming conventions for attributes and operations are
similar, see below, and because people new to object development may confuse the two concepts, it isn’t
advisable to have classes with just two compartments (one for the class name and one listing either
attributes or operations) because it can become confusing for your readers. If you need to, include a
blank compartment as a placeholder as you see with the Student class in Figure 6.3.

Label Uncommon Class Compartments

If you do intend to include a class compartment that isn’t one of the standard three – class name, attribute
list, operations list – then include a descriptive label such as “Exceptions” or “Constraints” centered at
the top of the compartment as you see with the Student class in Figure 6.3.

Include an Ellipsis ( … ) At The End of Incomplete Lists

You know that the list of attributes of the Student Class of Figure 6.3 is incomplete because the modeler
included an ellipsis at the end of the list – without this ellipsis there would be no indication that there is
more to the class than what is currently shown.

List Static Operations/Attributes Before Instance Operations/Attributes

In most classes static operations and attributes will be outnumbered by instance operations and
attributes. Furthermore, static operations and attributes typically deal with early aspects of a class’s
lifecycle, such as the creation of objects or finding existing instances of the classes. In other words, when
you are working with a class you often start with statics, therefore it makes sense to list them first in their
appropriate compartments as you see in Figure 6.4 (statics are underlined).
List Operations/Attributes in Decreasing Visibility
The greater the visibility of an operation or attribute the greater the chance that someone else will be
interested in it. For example, because public operations are accessible to a greater audience than
protected operations, there is a greater likelihood that greater interest exists in public
operations. Therefore, list your attributes and operations in order of decreasing visibility so they appear
in order of importance. As you can see in Figure 6.4 the operations and attributes of the OrderItem class
are then listed alphabetically for each level of visibility.

For Parameters That Are Objects, Only List Their Type

As you see in Figure 6.4 operation signatures can become quite long, extending the size of the class
symbol. To save space you can forgo listing the types of objects that are passed as parameters to
operations. For example, you see that Figure 6.4 lists calculateTaxes(Country, State) instead of
calculateTaxes(country: Country, state: State), saving a little bit of room.

Develop Consistent Method Signatures

The greater the consistency within your designs the easier they are to learn and to understand. First,
operations names should be consistent with one another – for example in Figure 6.4 all finder operations
start with the text find. Second, parameter names should also be consistent with one another. For
example, parameter names such as theFirstName, firstName, and firstNm are not consistent with one
another nor are firstName, aPhoneNumber, and theStudentNumber. Pick one naming style for your
parameters and stick to it. Third, the order of parameters should also be consistent. For example, the
methods doSomething(securityToken, startDate) and doSomethingElse(studentNumber, securityToken)
could be made more consistent by always passing securityToken as either the first or the last parameter.

Avoid Stereotypes Implied By Language Naming Conventions

The Unified Modeling Language (Rumbaugh, Jacobson, and Booch, 1999) allows for stereotypes to be
applied to operations. In Figure 6.4 I applied the stereotype <<constructor>> to the operation
OrderItem(Order) but that information is redundant because the name of the operation implies that it’s a
constructor, at least if the implementation language is Java or C++. Furthermore, you should avoid
stereotypes such as <<getter>> and <<setter>> for similar reasons – the names getAttributeName() and
setAttributeName() indicate the type of operations you’re dealing with.

Indicate Exceptions In An Operation’s Property String

Some languages, such as Java, allow operations to throw exceptions to indicate that an error condition
has occurred. Exceptions can be indicated with a UML property string, an example of which is shown
below:

+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}

Interface Definitions Must Reflect Implementation Language Constraints

An interface is a collection of operation signature and/or attribute definitions that ideally defines a
cohesive set of behaviors. Interfaces are implemented, “realized” in UML parlance, by classes and
components – to realize an interface a class or component must implement the operations and attributes
defined by the interface. Any given class or component may implement zero or more interfaces and one
or more classes or components can implement the same interface.. In Figure 6.5 you see that a standard
class box has been used to define the interface PersistentObject (note the use of the <<interface>>
stereotype). This interface includes a public attribute named OID and several public operations.

Figure 5. Interfaces on UML class diagrams.

Name Interfaces According To Language Naming Conventions

Interfaces are named in the same manner as classes: they have fully described names in the format
InterfaceName. In Java it is common to have interface names such as Serializable that end in able or
ible or just descriptive nouns such as EJBObject. In Microsoft environments it is common practice to
prefix interface names with a capital I, resulting in names such as IComponent.

Apply “Lollipop” Notation To Indicate That A Class Realizes an Interface

As you see in Figure 6.5 there are two ways to indicate that a class or component implements an
interface: the lollipop notation used with the Serializable interface and the realization line (the dashed line
with a closed arrowhead) used to show with the PersistentObject interface. The lollipop notation is
preferred because it is visually compact – the class box and realization line approach tend to clutter your
diagrams.

Define Interfaces Separately From Your Classes

To reduce clutter you should define interfaces separately from classes, either in another diagram
specifically for interface definitions or simply on one edge of your class diagram.

Do Not Model the Operations and Attributes of an Interface in Your Classes

In Figure 6.5 you’ll notice that the Shipment class does not include the attributes or operations defined
by the two interfaces that it realizes – that information would be redundant because it is already contained
within the interface definitions.

Consider an Interface to Be a Contract

When you model that classifier realizes an interface you are effectively committing to implementing that
interface in the classifier, in other words the interface acts as a contract that the classifier fulfills. Because
many classifiers may implement a single interface you should think seriously before modifying the
definition of an interface. AM’s Formalize Contract Models (Ambler 2002) suggests that you negotiate
any changes to a contract model, in this case the interface specification, with the users of that interface
before making any changes.

Model Relationships Horizontally

With the exception of inheritance the common convention is to depict relationships horizontally, the more
consistent you are in the manner that you render your diagrams the easier it will be to read them. In
Figure 6.6 you see that the dependencies are modeled horizontally although the fulfilled via association
is not – this sometimes happens.

Figure 6.6 Shipping an order.

Collaboration Indicates Need for a Relationship

You need to have some sort of relationship between two model elements to enable them to
collaborate. Furthermore, if two model elements do not collaborate with one another then there is no
need for a relationship between them. If the classes never take advantage of the relationship, why
maintain it?

Model a Dependency When The Relationship is Transitory

Transitory relationships, relationships that are not persistent, occur when one or more of the items
involved in a relationship is either transitory itself or a class. In Figure 6.6 you see that there is a
dependency between DeliveryScheduler and Order – DeliveryScheduler is a transitory class, one that
you do not persist to your database, and therefore there is no need to persist any relationship between
the scheduler and the order objects that it interacts with. The relationship between DeliveryScheduler
and Delivery is also a dependency, even though DeliveryScheduler creates Delivery objects, for the same
reason.

In Figure 6.6 instances of Delivery interact with OIDGenerator to obtain a new integer value to act as an
object identifier (OID) to be used as a primary key value in a relational database (Ambler, 2001). You
know that Delivery objects are interacting with OIDGenerator and not an instance of it because the
operation is static. Therefore, because there is no permanent relationship to be recorded and therefore
a dependency is sufficient.

Depict Similar Relationships Involving A Common Class As A Tree

In Figure 6.6 you see that both Delivery and Order have a dependency on OIDGenerator. Note how the
two dependencies are drawn in combination in “tree configuration”, instead of as two separate lines, to
reduce clutter in the diagram. You can take this approach with any type of relationship, it is quite common
with inheritance hierarchies as long as the relationship ends that you are combining are identical. For
example, in Figure 6.7 you see that OrderItem is involved with two separate relationships. Unfortunately
the multiplicities are different for each, one is 1..* and the other 0..* so you can’t combine the two into a
tree structure – had they been the same you could have, even though one relationship is aggregation
and the other association.

Note that there is a danger that you may be motivated not to change a relationship when you really should
in order to preserve the tree arrangement.

Always Indicate the Multiplicity (Design Model)

For each class involved in a relationship there will always be a multiplicity for it. When the multiplicity is
one and one only, for example with aggregation and composition it is often common for the part to be
involved only with one whole, many modelers will not model the “1" beside the diamond. I believe that
this is a mistake, and as you see in Figure 6.7 I will indicate the multiplicity in this case. If the multiplicity
is "1" then indicate it as such so your readers know that you’ve considered the multiplicity. Table 6.4
summarizes the multiplicity indicators that you will see on UML class diagrams.

Figure 7. Modeling an order.

Table 6.4. UML multiplicity indicators.

Indicator Meaning
0..1 Zero or one
1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
* Many
0..n Zero to n (where n > 1)
1..n One to n (where n > 1)
n..m Where n & m both > 1
n..* n or more, where n > 1
Avoid a Multiplicity of “*”
You should avoid the use of "*" to indicate multiplicity on a UML Class diagram because your reader can
never be sure if you really meant "0..*" or "1..*".

Replace Relationships By Indicating Attribute Types

In Figure 6.7 you see that Customer has a shippingAddress attribute of type Address – part of the
scaffolding code to maintain the association between customer objects and address objects. This
simplifies the diagram because it visually replaces a class box and association.

Note that this partially contradicts the Do Not Model Scaffolding Code guideline. You will need to judge
which guideline to follow, the critical issue being which one will improve your diagram the most given your
situation.

Do Not Model Implied Relationships

In Figure 6.7 there is an implied association between Item and Order, items appear on orders, but it was
not modeled. A mistake? No, the association is implied through OrderItem, orders are made up of order
items which in turn are described by items. These two relationships, when taken together, implement
the implied association that students take (enroll in) seminars. If you model this implied association not
only do you clutter your diagram you also run the risk that somebody will develop the additional code to
maintain it. If you don’t intend to maintain the actual relationship, e.g you aren’t going to write the
scaffolding code, then don’t model it.

Do Not Model Every Single Dependency

A common mistake made on detailed design diagram is to model every single dependency between
classes, quickly cluttering your diagrams with additional lines. A better approach is to model a
dependency between classes only if doing so adds to the communication value of your diagram – as
always you should strive to follow Agile Modeling (AM)’s practice Depict Models Simply (Ambler, 2002).

Center Names on Associations

It is common convention to center the name of an association above an association path, as you see in
Figure 6.7 with the describes association between Order and Item, or beside the path as with the fulfilled
via association between Order and Delivery.

Write Concise Association Names In Active Voice

The name of an association, which is optional although highly recommended, is typically one or two
descriptive words. If you find that an association name is wordy think about it from the other direction –
for example, the places name of Figure 6.7 is concise when read from right-to-left but would be wordy if
written from the left-to-right perspective (e.g. “is placed by”). Furthermore, places is written in active
voice instead of passive voice, making it clearer to the reader .

Indicate Directionality To Clarify An Association Name

When it isn’t clear in which direction the name of an association should be read you can indicate the
direction with a filled triangle as you see in Figure 6.7 between OrderItem and Item. This marker indicates
that the association should be read as "an item describes an order item" instead of "an order item
describes an item." It is also quite common to indicate the directionality on recursive associations, where
the association starts and ends on the same class, such as mentors in Figure 6.8.
Better yet, when an association name isn’t clear then you should consider rewording it or potentially even
renaming the classes.

Figure 6.8. Professors and seminars.

Name Unidirectional Associations In The Same Direction

The reading direction of an association name should be the same as that of the unidirectional association
– this is basically a consistency issue.

Word Association Names Left-To-Right

Because people in Western societies read from left-to-right it is common practice to word association
names so that they make sense when read from left-to-right. Had I followed this guidelines with the
describes association of Figure 6.7 I likely would not have needed to include the direction marker.

Indicate Role Names When Multiple Associations Between Two Classes Exist
Role names are optionally indicated on association ends to indicate how a class is involved in the
association. Although the name of an association should make the roles of the two classes clear, it isn’t
always obvious when several associations exist between two classes. For example, in Figure 6.8 there
are two associations between Professor and Seminar, delivers and teaches. These to association names
reflect common terminology at the university and cannot be changed, therefore we opt to indicate the
roles that professors play in each association to clarify them.

Note that the use of the term role is different between UML Class diagrams and UML Use Case
diagrams. Roles on UML class diagrams pertain to the class/objects they are associated with, helping
to indicate the context for the behavior of the participating objects. On UML Use Case diagrams actors
represent roles that people, systems, or organizations take with respect to your system.

Indicate Role Names on Recursive Associations

Role names can be used to clarify recursive associations, ones that involve the same class on both ends,
as you see with the mentors association in Figure 6.8. The diagram clearly depicts the concept that an
advisor mentors zero or more associate professors.

Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions

The lives at association of Figure 6.9 is uni-directional – a person object knows its address but an address
object does not know who lives at it. Within this domain there is no requirement to traverse the
association from Address to Person, therefore the association does not need to be bi-directional (two
way). This reduces the code that needs to be written and tested within the address class because the
scaffolding to maintain the association to Person isn’t required.

Figure 6.9. Modeling people at a university.

Redraw Inherited Associations Only When Something Changes

An interesting aspect of Figure 6.9 is the association between Person and Address. First, this association
was pushed up to Person because Professor, Student, and Alumnus all had a lives at association with
Address. Because associations are implemented by the combination of attributes and operations, both
of which are inherited, the implication is that associations are inherited by implication. If the nature of the
association doesn’t change, for example both students and professors live at only one address, then we
don’t have any reason to redraw the association. However, because we track multiple addresses for
Alumnus the relationship did need to be redrawn between Alumnus and Address.

Question Multiplicities Involving Minimums And Maximums

The problem with minimums and maximums is that they change over time. For example today you may
have a business rule that states that an Alumnus has either one or two addresses that the university
tracks, motivating you to model the multiplicity as 1..2 as depicted in Figure 6.9 . However, if you build
your system to reflect this rule when the rule changes you may find that you have significant rework to
perform. In most object languages it is easier to implement a 1..* multiplicity, or better yet a 0..*
multiplicity, because you don’t have to check the size of the collection maintaining the
association. Providing greater flexibility with less code seems good to me.

Apply the Sentence Rule For Inheritance

Inheritance models “is a” and “is like” relationships, enabling you to easily reuse existing data and code.
When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of
“A.” Furthermore, we say that we have “pure inheritance” when “A” inherits all of the attributes and
methods of “B.” The UML modeling notation for inheritance is a line with a closed arrowhead pointing
from the subclass to the superclass. One of the following sentences should make sense: “A subclass IS
A superclass” or “A subclass IS LIKE A superclass.” For example, it makes sense to say that a student
is a person and a dragon is like a bird. It does not make sense to say a student is an address or is like
an address, so the class Student likely should not inherit from Address – association is likely a better
option, as you see in Figure 6.9. If it does not make sense to say that "the subclass is a superclass" or
at least "the subclass is like the superclass" then you are likely misapplying inheritance.
Implementation inheritance, often called convenience inheritance, often occurs when the sentence fails
yet inheritance is used anyway. This is particularly common when developers want to take short cuts
and have business classes inherit system or persistence behaviors, instead of accessing these services
through collaboration.

Place Subclasses Below Superclasses

It is common convention to place a subclass, such as Student in Figure 6.9 , below its superclass –
Person in this case.

Beware of Data-Based Inheritance

If the only reason why two classes inherit from each other is because they share common data attributes
it indicates one of two things: you have either missed some common behavior (this is likely if the sentence
rule applies) or you should have applied association instead.

Subclass Should Inherit Everything

A subclass should inherit all of the attributes and methods of its superclass, and therefore all of its
relationships as well – a concept called pure inheritance. The advantage of pure inheritance is that you
only have to understand what a subclass inherits, and not what it does not inherit. While this sounds
trivial, in a deep class hierarchy it makes it a lot easier if you only need to understand what each class
adds, and not what it takes away. Note that this contradicts the Redraw Inherited Associations Only
When Something Changes guideline so you’ll need to decide accordingly.

Apply the Sentence Rule for Aggregation

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage,
wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or more packages. A
team consists of two or more employees. These are all examples of the concept of aggregation, which
represents “is part of” relationships. An engine is part of a plane, a package is part of a shipment, and
an employee is part of a team. Aggregation is a specialization of association, specifying a whole-part
relationship between two objects. Composition is a stronger form of aggregation where the whole and
parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its
parts. From a stylistic point of view, because aggregation and composition are both specializations of
association the guidelines for associations apply. It should make sense to say “the part IS PART OF the
whole.” For example, in Figure 6.10 it makes sense to say that a course is part of a program or that a
component is part of an airplane. However, it does not make sense to say that a team is part of an
airplane or an airplane is part of a team – it does make sense to say that a team builds airplanes, an
indication that association is applicable.
Figure 6.10. Examples of aggregation and composition.

You Should Be Interested In Both The Whole And The Part

For aggregation and composition you should be interested in both the whole and the part separately –
both the whole and the part should exhibit behavior that is of value to your system. For example, you
could model the fact that my watch has hands on it but if this fact isn't pertinent to your system (perhaps
you sell watches but not watch parts) then there is no value in modeling watch hands.

Depict the Whole to the Left of the Part

It is common convention to draw the whole, such as Team and Airplane, to the left of the part, Employee
and Component as you see in Figure 6.10 respectively.

Apply Composition to Aggregates of Physical Items

A good rule of thumb is that composition is applicable whenever aggregation is AND both classes
represent physical items. For example, in Figure 6.10 you see that composition is used between Airplane
and Component whereas aggregation is used between Team and Employee – airplanes and components
are both physical items whereas teams are not.

Apply Composition When the Parts Share The Persistence Lifecycle With the Whole
A good rule of thumb is that if the lifecycle of the parts is the same as the whole, if they’re read in at the
same time, if they’re saved at the same time, if they’re deleted at the same time, then composition is
likely applicable.

Don’t Worry About Getting the Diamonds Right

When deciding whether to use aggregation or composition over association, Craig Larman (2001) says
it best: If in doubt, leave it out. The reality is that many modelers will agonize over when to use
aggregation when the reality is that there is very little difference between association, aggregation, and
composition at the coding level.

Case study—Courseware Management System

The class diagram of our Courseware Management System case study can be built after a careful
analysis of the requirements. In the previous article, we identified the primary actors and use cases in
the use case model of the case study. Because we did much of the groundwork of our analysis while
building the use case model, we will use those analysis steps as the basis for identifying the classes and
interfaces of this system.

Let us recap our analysis that we had performed when we designed the use case model. The following
terms and entities specific to the system were identified from the problem statement:
• Courses and Topics that make up a course
• Tutors who teach courses
• Course administrators who manage the assignment of the courses to tutors
• Calendar or Course Schedule is generated as a result of the
• Students who refer to the Course schedule or Calendar to decide which courses for which they
wish to sign up

The potential actors of the system were:

• Tutors
• Course administrators
• Students

And the use cases of the system were:

• View courses
• Manage topics for a course
• Manage course information
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors

Identifying classes of the Courseware Management System

We will identify the classes and interfaces using an incremental approach.

1. Identify the "active" entities in the system

The basic rule that we learned until now for identifying classes and interfaces is that classes and
interfaces reflect important entities of the business domain of the system being modeled. We will
apply this rule to determine classes and interfaces of the case study system. At first glance, the
actors identified in the use case appear to be prime candidates for being listed as potential
classes. Even though we had excluded Students and Tutors from our final list of actors, we will
still include them in our list as potential classes. So, our first list of classes in the system appears
to be:
o Course administrators
o Tutors
o Students
2. Identify business domain ("passive") entities in the system

But these are the "active" entities of the system. We had also identified "passive" elements in the
system as well in the analysis for our use case model. These entities reflect the business domain
and hence are potential classes for our system.
 o Courses
o Topics that make up a course
o Course calendar generated

Entities that reflect the business terms are also called business domain classes or just "domain
classes." Some of the business domain classes hold transient data and some hold persistent
data for the application. Normally, such business domain classes map to either one or many
database tables.

For example, in our case study, the Course class can be modeled as a database table
cms_course. The data in this table for a particular course will be represented by an instance of
the Course class and made available to the rest of the application.

Our two-step process has definitely yielded promising results! We have covered all the relevant
items in our analysis. So, let us list the list of classes and interfaces that we have identified in the
Courseware Management System.

o CourseAdministrator
o Tutor
o Student
o Course
o Topic
o CourseCalendar

3. Categorize and map the use cases and any relevant business functionality to either the passive
or active entities. These will become the business methods of the classes in the system.

Classes encapsulate functionality. The classes that we have identified for the Courseware
Management System also provide business functionality related to the application. The
functionality encapsulated by these classes is distinct in nature and differs from each class. Recall
from our use case model, that, along with actors, we had identified a set of use cases that the
actors interacted with. Let us try to associate them with our classes. Because our primary actor
is the course administrator and the use cases were related to this actor, we can directly map the
use cases to the CourseAdministrator class as methods.

ClassName Methods
CourseAdministrator viewCourses()
manageCourse()
manageTopic()
viewCourseCalendar()
viewTutors()
manageTutorInformation()
assignTutorToCourse()

In addition to this, we also can determine some implicit functionality of classes that reflect business
entities. For example, what functionality should the Course class provide? Intuitively, we would define
the Course class to provide functionality to view all courses in the system, ability to create new courses
or modify information of existing courses, view the details of a particular course, or even remove a course
from the system. We expect the Course class to provide such business functionality because the Course
class reflects a business entity in the system. Hence, these become the methods exposed by the Course
class. So, we can now refine the class diagram and add methods to each of these classes.

To cut a long story short, each of the classes that reflect business entities will provide similar implicit
business functionality. Let us list all such "implicit" functionality for each of these classes.

Table 6.6 Class and Methods

ClassName Methods
Course viewAllCourses()
viewCourseInformation()
createCourse()
modifyCourse()
removeCourse()
Topic viewAllTopics()
viewTopicInformation()
createTopic()
modifyTopic()
removeTopic()
Tutor viewTutorInformation()
createTutor()
modifyTutor()
removeTutor()

CourseCalendar viewCourseCalendar()
Student viewAllStudents()
viewStudentInformation()

Refine and revise the list of classes and interfaces

Revisit the class diagram and revise it by identifying shared features and/or common functionality
between classes or interfaces. These will translate into reusable pieces of code for your system. To some
extent, we can say that CourseAdministrator, Tutor, and Student are essentially users of the system.
Hence, we can define a shared parent class named User and define basic functionality like for example,
authentication, in the User class that can be inherited by the CourseAdministrator, Tutor, and Student
classes. It is left to the design expertise to identify reusable classes/functionality.

This completes our analysis of the problem statement to define the classes for the Courseware
Management System.

Identifying relationships between the classes of the Courseware Management System

The next step after defining the classes of the Courseware Management System is to define the
relationships and dependencies between these classes and interfaces. To define the relationships
between the classes, we need to analyze the interconnections between the classes—whether implicit or
explicit. Relationship analysis can be broken up into three steps:

1. Identify relationships between "active" entities

Active entities normally share generalization relationships ("is-a"). Essentially, the common
attributes and functionality between classes are defined in a common parent class. All the related
child classes inherit functionality from the parent class. Apart from generalization, a few active
entities can also be interconnected by a realization relationship. Recall that elements in a
realization relationship implement declared functionality as a "contract." For example, a set of
classes may implement functionality declared as methods in an interface, and this can be
modeled as a realization relationship between the interface and the classes implementing the
interface.

In our case study, we do not find an example of inheritance relationship between the active entities
such as Student, Tutor, and CourseAdministrator or any realization relationships.

2. Identify relationships between "passive" business entities

Passive business entities frequently share plain association or aggregation relationships ("has-
a"). This is especially true because these business entities are non-transactional in nature and
reflect data more than behavior. It is by far quite intuitive to identify aggregation as well as its
variations—composition relationships for passive business entities.

Some of the classes in our case study do exhibit aggregation relationships. Because a set of
topics makes up a course, we can define an aggregation relationship between the Course and
Topic classes. Moreover, we can define this as a directed aggregation, meaning that you can
check for the topics of a course but not vice versa. Similarly, we can define a plain association
relationship between the Course and Tutor classes and Course and Student classes.

Identify relationships between "active" and "passive" entities

Relationships between active and passive entities can easily be represented using directed association.
The directed association, a variation of the "vanilla" association relationship, provides easy identification
of which is the container class and which is the contained class. The CourseAdministrator class can be
modeled to have a directed association with the Course class. This association can be named as
"manages" because the course administrator manages courses as a business activity. In addition to this,
because the course administrator also manages the tutor information and topic information, we can model
a directed relationship named as "manages" between the CourseAdministrator and the Course and Topic
classes, respectively. We can enhance the readability of the association between CourseAdministrator
and the Course, Tutor, and Topic classes by defining the multiplicity for the association—one to many,
one to one, many to many, and so forth.
Figure 6.11 – shows the class diagram for the Courseware Management System

We have completed identifying the classes for the Courseware Management System and established the
relationships among the classes. Take a look at the class diagram in Figure 4.2.1. The class diagram of
the Courseware Management System includes all the classes and their relationships that we identified
during our analysis of the problem statement.

Model View Controller Design

The class diagram that we designed for the Courseware Management System defined the basic classes
necessary for representing the basic structure of the system. But this is by no means a complete design
if the architecture of your system is to be based on the Model View Controller (MVC) architecture.
Because an MVC model defines clear separation of classes among the three layers—business,
presentation, and flow control—you need to define additional classes and revise your design to include
them. In case your UML tool does not support explicit partitioning of classes, you can mark classes in
each of the layers using stereotypes such as <<entity>>, <<boundary>>, <<control>>, and so forth.

For example, in our case study application, we can revise the class diagram to define a new
CMSController class that manages the flow of the application. The model layer primarily consists of
classes relevant to the business domain. Next, the classes that we had defined can be categorized as
transactional and persistent classes. The CourseAdministrator class performs most of the activities in
the system. Hence, this class can be designated as a transaction class of the model layer. Similarly,
the Course, Topic, Tutor, CourseCalendar, and Student classes represent persistent business data.
Hence, these can be categorized as persistent classes of the model layer. Finally, you can define a set
of classes that represent the presentation layer; in other words, the user interface of the system.
Forward Engineering from Class Diagrams

Forward engineering is the process of generating source code (in a specific language) from a class
diagram model. The extent to which a UML class diagram can be used to generate source code depends
upon the limitations of the source code language. Because UML is pictorial, and can depict a lot of details,
these details could be lost in the code. Hence, before creating a complete class model, it is a good idea
to be aware of the language that is going to be used, to limit the class model accordingly. Typically, the
association relationships between classes are generated as member variables between the related
classes in the source code. Generalization relationships are generated as inheritance relationships in the
source code.

The above screenshot shows the source code file generated for the CourseAdministrator Java source
code file as a result of forward engineering the class diagram of the Courseware Management System
case study. You need to check how forward engineering works in the tool that you use.

Reverse Engineering of Class Diagrams

Obtaining a class model from existing source code is called reverse engineering. This is generally done
when it is required to understand the architecture of an existing system, either for re-engineering, or for
maintenance. Reverse engineering is of great use especially when trying to figure out the static structure
and organization of a complex system. Typically, classes defined as member variables in the source
code are modeled as association relationships between the classes. Inheritance relationships in the
source code are generated as generalization relationships between the classes.

The above screenshot shows a class diagram generated as a result of reverse engineering a sample
source code file. You need to check how reverse engineering works in the tool that you use.

Uses of a class diagram

• Class diagrams can be used to document a Business Object Model and are widely used in both
high-level and low-level design documents.
• From a Java perspective, it may not be effective to include each and every operation and attribute
of a class in a class diagram because this leads to maintenance issues (e.g., if a method or
attribute changes in the code then the model needs to be updated); rather, javadoc can be used
to document an implementation.
• To maintain consistency with Java coding style, class names should begin with an uppercase
letter while operations and attributes should begin with a lowercase letter.
• Generalization relationships can be mapped to the Java extends relationship while the realizes
relationship can be mapped to the Java implements relationship.

Object Diagram

Although we design and define classes, in a live application classes are not directly used, but instances
or objects of these classes are used for executing the business logic. A pictorial representation of the
relationships between these instantiated classes at any point of time (called objects) is called an "Object
diagram." It looks very similar to a class diagram, and uses the similar notations to denote relationships.

If an object diagram and a class diagram look so similar, what is an object diagram actually used for?
Well, if you looked at a class diagram, you would not get the picture of how these classes interact with
each other at runtime, and in the actual system, how the objects created at runtime are related to the
classes. An object diagram shows this relation between the instantiated classes and the defined class,
and the relation between these objects, in the logical view of the system. These are very useful to explain
smaller portions of your system, when your system class diagram is very complex, and also sometimes
recursive.

Let us now see what the components of an object diagram are. After this, we will build an object diagram
for our case study—Courseware Management system.

Elements of an Object Diagram

Because an object diagram shows how specific instances of a class are linked to each other at runtime,
at any moment in time it consists of the same elements as a class diagram; in other words, it contains
classes and links showing the relationships. However, there is one minor difference. The class diagram
shows a class with attributes and methods declared. However, in an object diagram, these attributes and
method parameters are allocated values.

As an example, in the last article, a class diagram for a multiplicity relation between college and students
was shown, as you cam see in Figure 4:

Figure 6.12—an example College-Student class diagram

This class diagram shows that many students can study in a single college. Now, if we were to add
attributes to the classes "College" and "Student," we would have a diagram as shown in Figure 5:

Figure 6.13—the class diagram with attributes

Now, when an application with the class diagram as shown above is run, instances of College and
Student class will be created, with values of the attributes initialized. The object diagram for such a
scenario will be represented as shown in Figure 5.6:

Figure 6.14—the object diagram for the College-Student class diagram

As can be seen from Figure 6.14, the object diagram shows how objects are instantiated in the running
system represented by the College-Student class diagram. The class diagram shows that a single college
has many students, and defines the variables. The object diagram for the same system shows
instantiated classes of Student (Student #1 and Student #2) enrolled in College (Graduate School of
Business).

The object diagram shows the name of the instantiated object, separated from the class name by a ":",
and underlined, to show an instantiation. Eg. Graduate School of Business: College

In the diagram, values are assigned to variables and represented using the notation variable
name=variable value.

This example was the representation of the relation of only two classes with each other. However, in a
real application system, there will be multiple classes. An object diagram then shows the relation between
the instantiations of these classes. We shall see this in our case study.

A class that defines the flow of the system is called as an active class. This class instance in the object
diagram is represented by thick border. In an MVC application architecture, the controller servlet is the
action class, and is denoted by a thicker border. Also, multiple instances of the same class, as in a factory
pattern, if the attributes of the individual objects are not important, or are not different, these can be
represented by a single symbol of overlapping rectangles (see Figure 5.7):

Figure 6.15—the object diagram for a Factory class

A class that performs more than one role, and is self-linked, is represented by a curve starting and ending
on itself, as illustrated in Figure 8:

Figure 6.16—the object diagram for a self-linked class

Dos

1. Use the object diagram as a means of debugging the functionality of your system.
2. Object diagrams can also be used to check whether the system has been designed as per the
requirements, and behaves how the business functionality needs the system to respond.
3. Show associations of any kind between objects as linkages (for example, a single segment joining
two objects, without arrows), and not as a dependency or any other specific type of association.
An object diagram only shows the linkages, but not the type of association.

Don'ts

1. Avoid representing all the objects of your system in an object diagram. Because an object diagram
represents the state of objects, it can become quite complex if you try to represent all the objects.
Hence, it is always better to represent the state of objects in certain important/critical flows in your
application using an object diagram. This will keep your object diagram readable, yet useful
enough to capture the state of objects that are important.
2. Because object diagrams represent the state of objects, forward engineering of object diagrams
does not make sense.

Case Study: Courseware Management System

Now, we shall create an object diagram for the courseware system. To do this, we will first build up on
our class diagram, and include the possible attributes and define the parameters of to the classes defined
earlier.

We will follow the following convention for the variable names:

Names starting with "s_" are of the String data type

Names starting with "i_" are of the int data type
Names starting with "v_" are of the Vector data type

The following table outlines the attributes, methods, and their return types for each of the classes:

Table 6.7 Class, Attributes and Methods

Class Name
Attributes Methods
 CourseAdministrator s_adminId Vector viewCourses()
v_courses Vector manageCourse(s_courseId)
s_courseId Vector manageTopic(s_topicId)
v_tutors Vector
v_tutorInfo viewCourseCalendar(s_courseId)
s_tutorId Vector viewTutors()
v_topics Vector
s_topicId manageTutorInformation(s_tutorId)
Boolean
assignCourseToTutor(s_courseId,
s_tutorId)

Student s_studentId Vector viewAllStudents()

v_studentInfo Vector
v_studentList viewStudentInformation(s_studentId)
Tutor s_tutorId Vector
v_tutorInfo viewTutorInformation(s_tutorId)
v_tutorList String createTutor(v_tutorInfo)
Boolean
modifyTutor(v_newTutorInfo)
Boolean removeTutor(s_tutorId)

Course s_courseId Vector viewAllCourses()

v_courseList Vector viewCourseInfo(s_courseId)
v_courseInfo Boolean
createCourse(v_courseInfo)
Boolean
modifyCourse(v_newCourseInfo)
Boolean removeCourse(s_courseId)

Topic s_topicId Vector viewAllTopics()

v_topicList Vector
v_topicInfo viewTopicInformation(s_topicId)
Boolean createTopic(v_topicInfo)
Boolean
modifyTopic(v_newTopicInfo)
Boolean removeTopic(s_topicId)

CourseCalender v_courseCalendar Vector

viewCourseCalendar(s_courseId)

To follow a logical sequence now, let us consider that the course administrator, courses, tutors, and
topics already exist. Let us now make an object diagram for the case where the administrator with user
id "admin" wishes to access the course calendar of a course with course id "Math_Course_001."

Hence, the following will be the attribute values, and method calls:
CourseAdministrator
Attributes: s_adminId = admin
s_courseId = Math_Course_001
Methods: viewCourseCalendar("Math_Course_001")

This method will call the method viewCourseInfo of class Course, which returns a Vector object populated
with all the details of the course "MathCourse_001" (see Figure 9)

Course
Methods: viewCourseInfo("Math_Course_001")

Figure 6.15—the object diagram for the courseware management system, for a simple scenario
of the course administrator managing a math course.

In Figure 5.9, for the single case where the flow is from Course Administrator to Course, when the
CourseAdministrator is requesting the course information for a particular course.

Design Patterns
A software designer or architect may identify a design problem which has been visited and perhaps even
solved by others in the past. A template or pattern describing a solution to a common problem is known
as a design pattern. The reuse of such patterns can help speed up the software development process
(Bishop, 2012).
A software design pattern is a general, reusable solution to a commonly occurring problem within a given
context in software design. It is not a finished design that can be transformed directly into source or machine
code. Rather, it is a description or template for how to solve a problem that can be used in many different
situations. Design patterns are formalized best practices that the programmer can use to solve common
problems when designing an application or system.
Object-oriented design patterns typically show relationships and interactions between classes or objects,
without specifying the final application classes or objects that are involved. Patterns that imply mutable state
may be unsuited for functional programming languages, some patterns can be rendered unnecessary in
languages that have built-in support for solving the problem they are trying to solve, and object-oriented
patterns are not necessarily suitable for non-object-oriented languages.
Patterns originated as an architectural concept by Christopher Alexander as early as 1966 (c.f. "The Pattern
of Streets," JOURNAL OF THE AIP, September, 1966, Vol. 32, No. 3, pp. 273-278). In 1987, Kent
Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming –
specifically pattern languages – and presented their results at the OOPSLA conference that year.[2][3] In the
following years, Beck, Cunningham and others followed up on this work.
Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable
Object-Oriented Software was published in 1994 by the so-called "Gang of Four" (Gamma et al.), which is
frequently abbreviated as "GoF". That same year, the first Pattern Languages of Programming Conference
was held, and the following year the Portland Pattern Repository was set up for documentation of design
patterns. The scope of the term remains a matter of dispute.
Design patterns can speed up the development process by providing tested, proven development paradigms
(Bishop, 2012). Effective software design requires considering issues that may not become visible until later
in the implementation. Freshly written code can often have hidden subtle issues that take time to be detected,
issues that sometimes can cause major problems down the road. Reusing design patterns helps to prevent
such subtle issues, and it also improves code readability for coders and architects who are familiar with the
patterns.
By definition, a pattern must be programmed anew into each application that uses it. Since some authors see
this as a step backward from software reuse as provided by components, researchers have worked to turn
patterns into components. Meyer and Arnout were able to provide full or partial componentization of two-thirds
of the patterns they attempted (Meyer & Aurnout, 2006).
Software design techniques are difficult to apply to a broader range of problems. Design patterns provide
general solutions, documented in a format that does not require specifics tied to a particular problem.
Design patterns are composed of several sections. Of particular interest are the Structure, Participants, and
Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that
developers copy and adapt to their particular designs to solve the recurrent problem described by the design
pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships.
Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which
means that micro-architectures in their designs will have structure and organization similar to the chosen
design motif.
Efforts have also been made to codify design patterns in particular domains, including use of existing design
patterns as well as domain specific design patterns. Examples include user interface design patterns (Laakso,
2003) secure design (Heer & Agrawala, 2006), "secure usability" (Dougherty et al, 2009), Web design
(Garfinkel, 2005) and business model design
The annual Pattern Languages of Programming Conference proceedings include many examples of domain-
specific patterns.

Classification and list

Design patterns had originally been categorized into 3 sub-classifications based on kind of problem they
solve. Creational patterns provide the capability to create objects based on a required criterion and in a
controlled way. Structural patterns are about organizing different classes and objects to form larger structures
and provide new functionality. Finally, behavioral patterns are about identifying common communication
patterns between objects and realize these patterns.
Creational patterns are ones that create objects, rather than having to instantiate objects directly. This
gives the program more flexibility in deciding which objects need to be created for a given case.
• Abstract factory groups object factories that have a common theme.
• Builder constructs complex objects by separating construction and representation.
• Factory method creates objects without specifying the exact class to create.
• Prototype creates objects by cloning an existing object.
• Singleton restricts object creation for a class to only one instance.
Structural patterns concern class and object composition. They use inheritance to compose interfaces and
define ways to compose objects to obtain new functionality.
• Adapter allows classes with incompatible interfaces to work together by wrapping its own interface
around that of an already existing class.
• Bridge decouples an abstraction from its implementation so that the two can vary independently.
• Composite composes zero-or-more similar objects so that they can be manipulated as one object.
• Decorator dynamically adds/overrides behaviour in an existing method of an object.
• Facade provides a simplified interface to a large body of code.
• Flyweight reduces the cost of creating and manipulating a large number of similar objects.
• Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral patterns are specifically concerned with communication between objects.

• Chain of responsibility delegates commands to a chain of processing objects.
• Command creates objects which encapsulate actions and parameters.
• Interpreter implements a specialized language.
• Iterator accesses the elements of an object sequentially without exposing its underlying representation.
• Mediator allows loose coupling between classes by being the only class that has detailed knowledge of
their methods.
• Memento provides the ability to restore an object to its previous state (undo).
• Observer is a publish/subscribe pattern which allows a number of observer objects to see an event.
• State allows an object to alter its behavior when its internal state changes.
• Strategy allows one of a family of algorithms to be selected on-the-fly at runtime.
• Template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to
provide concrete behavior.
• Visitor separates an algorithm from an object structure by moving the hierarchy of methods into one
object.

Table 6.8 Design Patterns

Image source: scientificprogrammer.net

Documentation
The documentation for a design pattern describes the context in which the pattern is used, the forces
within the context that the pattern seeks to resolve, and the suggested solution (Gabriel, 2007). There is no
single, standard format for documenting design patterns. Rather, a variety of different formats have been used
by different pattern authors. However, according to Martin Fowler, certain pattern forms have become more
well-known than others, and consequently become common starting points for new pattern-writing efforts
(Fowler, 2006). One example of a commonly used documentation format is the one used by Erich
Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their book Design Patterns. It contains the
following sections:
• Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring
to the pattern.
• Intent: A description of the goal behind the pattern and the reason for using it.
• Also Known As: Other names for the pattern.
• Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be
used.
• Applicability: Situations in which this pattern is usable; the context for the pattern.
• Structure: A graphical representation of the pattern. Class diagrams and Interaction diagrams may be
used for this purpose.
• Participants: A listing of the classes and objects used in the pattern and their roles in the design.
• Collaboration: A description of how classes and objects used in the pattern interact with each other.
• Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
• Implementation: A description of an implementation of the pattern; the solution part of the pattern.
• Sample Code: An illustration of how the pattern can be used in a programming language.
• Known Uses: Examples of real usages of the pattern.
• Related Patterns: Other patterns that have some relationship with the pattern; discussion of the
differences between the pattern and similar patterns.

Design Verification and Validation

Verification and validation (V&V) is the process of checking that a software system meets specifications
and that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally
the responsibility of software testers as part of the software development lifecycle. In simple terms,
software verification is: "Assuming we should build X, does our software achieve its goals without any
bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X
meet the high level requirements?"

The software design should undergo verification and validation. What's the difference between validation
and verification? Put simply, design validation determines if you are building the right product. Does
the device work as intended for the end users? Design verification determines if you’re building the
product right. Are design outputs matching design inputs?

According to the Capability Maturity Model (CMMI-SW v1.1),

• Software Validation: The process of evaluating software during or at the end of the development
process to determine whether it satisfies specified requirements. [IEEE-STD-610]
• Software Verification: The process of evaluating software to determine whether the products of a
given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]
Design Verification
• Design adequacy and conformance to Software Requirements and Interfaces
• Internal and External Consistency
• Verification of Feasibility and Maintenance

Design Validation
• Identification of unstable components/functionalities
• Validation focused on Error-Handling: complementary (not concurrent!) validation regarding the one
performed by the Development team (More for the Money, More for the Time)
• Compliance with Software and System Requirements
• Black box testing and White box testing techniques
• Experience based techniques

SUMMARY

The Class Diagram is the building block of object-oriented analysis and design. The initial class diagram
that models domain objects should be refined during latter iterations and transformed into a more detailed
version that describes the attributes, characteristics and relationships between classes and between
objects in the system. There are guidelines that need to be followed to successfully map the requirements
specifications during the analysis phase into the design specifications using class diagram. The final
class diagram can then be mapped into source codes for implementation. A design problem which has
been visited and solved in the past may be addressed with the use of a template or pattern describing a
solution to a common problem; this is known as a design pattern. The reuse of such patterns can help
speed up the software development process. The software design should undergo both verification and
validation to make sure components adequate, consistent, stable, maintainable and compliant with
specifications.

REFERENCES

Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K.,
Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–
136. Springer-Verlag, p. 109 doi:10.1007/978-3-540-92966-6_6.

Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the
ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.10120547. S2CID 14331332.

Booch, Grady; et al. (2004). Object-Oriented Analysis and Design with Applications(3rd ed.). MA, USA: Addison
Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.

Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann.
p. 258. ISBN 978-0128013977

Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from
O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're
ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.

Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.

archive.cnx.org. (n.d.) Software Design. archive.cnx.org. Retrieved from: http://archive.cnx.org/contents/ac67c233-

feb5-45fa-a49d-078899b6408b@3/software-design
“Software design”. (n.d.) What Do Software Designers Do? & How Does One Enter This Field? Software Engineer
Insider: Syracuse University. Retrieved from: http://www.softwareengineerinsider.com/careers/software-
designer.html#.WBTS8eHhDBI

Tutorialspoint. (n.d.) Software Design Basics. Retrieved

from: https://www.tutorialspoint.com/software_engineering/software_design_basics.htm

Udacity. (23 feb 2015). Software Architecture & Design. Retrieved

from: https://www.youtube.com/playlist?list=PLAwxTw4SYaPkMTetlG7xKWaI5ZAZFX8fL

Gabriel, Dick. "A Pattern Definition". Archived from the original on 2007-02-09. Retrieved 2007-03-06.

Fowler, Martin (2006-08-01). "Writing Software Patterns". Retrieved 2007-03-06.

Martin Fowler, Kendall Scott: UML Distilled Addison-Wesley 2000

Bishop, Judith. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from
O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're
ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.

Meyer, Bertrand; Arnout, Karine (July 2006). "Componentization: The Visitor Example"(PDF). IEEE
Computer. 39 (7): 23–30. CiteSeerX 10.1.1.62.6082. doi:10.1109/MC.2006.227. S2CID 15328522.

Laakso, Sari A. (2003-09-16). "Collection of User Interface Design Patterns". University of Helsinki, Dept. of
Computer Science. Retrieved 2008-01-31.

Heer, J.; Agrawala, M. (2006). "Software Design Patterns for Information Visualization". IEEE Transactions on
Visualization and Computer Graphics. 12 (5): 853–
60. CiteSeerX 10.1.1.121.4534. doi:10.1109/TVCG.2006.178. PMID 17080809. S2CID 11634997.

Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009). Secure Design Patterns (PDF). Software
Engineering Institute.

Davies. , Software Engineering. Pp. 61-69, 88-91.

Pfleeger, Shari Lawrence, Software Engineering. 2nd ed.1992, pp. 280-286.

Pressman, Roger S., Software Engineering (A Practioners Approach).3rd Edition, P. 270-283.

Garfinkel, Simson L. (2005). Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable (Ph.D.
thesis).

"Yahoo! Design Pattern Library". Archived from the original on 2008-02-29. Retrieved 2008-01-31.

"How to design your Business Model as a Lean Startup?". 2010-01-06. Retrieved 2010-01-06.

http://www.gdpro.com/what_is_uml.html

http://coursehero.com

http://www.developer.com/design/article.php

http://www.agilemodeling.com/artifacts/classDiagrms.htm
http://www.dotnetcoders.com/web/learning/dagrams/classdiagrams.aspx

http://www.agilemodeling.com/artifacts/objecctDiagrms.htm

http://www.dotnetcoders.com/web/learning/dagrams/objectdiagrams.aspx

ASSESSMENTS:
1. Construct an architectural diagram based on your previously specified software requirements
(Refer to UML architectural diagrams).
2. Construct structural diagrams to model the software data structure, class structures, and static
behaviors based on previously specified requirements (Refer to UML structural and behavioral
diagrams).
3. Document these diagrams in a Software Design Document IEEE format.
4. Perform design component validation for each subsystem of the software project.
5. Design a preliminary system prototype or working model/version of the software following the
design principles and guidelines you have studied.
6. Discuss what is your most significant learning on software design and why.
7. *Watch the video clip https://www.youtube.com/watch?v=sB2iQSvrcG0. Relate your
learnings from the video with the topic you read from this material. Discuss.

Note: * for OL mode

 7. SOFTWARE DESIGN IMPLEMENTATION

LEARNING OBJECTIVES:
• Translate design specifications into actual programmable lines of code using appropriate
programming language;
• Apply appropriate coding standards in the creation of source codes;
• Apply appropriate techniques in fault tolerance, exception handling, and security in the creation
of source codes;
• Generate a suitable application program interface (API) document relative to the software
component being developed;
• Apply the necessary code review technique for each of the software components created;
• Produce internal and external source code documents using appropriate modeling and
documentation tools;

OVERVIEW:
Coding is the process of transforming the design of a system into a computer language format. This
coding phase of software development is concerned with software translating design specification into
the source code. It is necessary to write internal and external source code documentation so that
conformance of the code to its specification can be easily verified. Coding is done by the coder or
programmers who are independent people than the designer. The goal is not to reduce the effort and
cost of the coding phase, but to cut to the cost of a later stage. The cost of testing and maintenance can
be significantly reduced with efficient coding. Programmers should follow coding standards, concepts,
principles and guidelines, and employ appropriate techniques and programming style to achieve effective
and efficient codes.

READING MATERIALS:

Mapping Design Into Codes

Each class in design is implemented by coding it in a programming language or by using a pre-
existing component. Exactly what a class in design corresponds to depends on the programming
language. For example, in object-oriented languages such as C++ and Java, a design class
corresponds to one or several classes. In Visual Basic, a design class corresponds to one
component of a specific type; for example, class module, form, or control. In Ada, a design class
corresponds to one or several tagged types defined in an Ada-package.

The design model can be more or less close to the implementation model depending on how you
map its classes to classes or similar constructs in the implementation language. For example, you
may give each design class a 1:1 relation to an implementation class. This will lead to a design
model with a seamless traceability to the implementation model, which is appropriate in round-trip-
engineering environments.

Another alternative is to let a design class be an abstraction of several implementation classes.

When using this approach, we recommend that you map each design class to one "head" class that,
in turn, can use several "help" classes to perform its behavior. You can use "help" classes to
implement a complex attribute or to build a data structure that you need for the implementation of
an operation. In design, you need not model the "help" classes and you need to model only some of
the attributes, relationships, and operations defined by the head class, as long as the model fulfills
its purpose and is a good abstraction of the source code. You should decide before the design starts
how classes in the design model should relate to implementation classes and capture that in
the Design Guidelines.

In many programming languages it is possible to separate the class interface from its implementation
and eventually place them in separate files. For example, the common style in C++ is to place the
interface of a class in a header (.h) file and the implementation of the class in a .cpp file. Ada has
the concept of package specification and package body, and of subprogram specification and
subprogram body.

Each programming language may offer a number of features that are difficult to "fit" in a general
process framework. For example, in C++ concepts such as virtual base classes, "const" attributes
and methods, abstract methods, friends, and so on have no direct equivalent in other languages.
Conversely, the programming language might have some limitations as to what can be easily
represented. The implementation discipline aims at this general framework for all object-oriented
languages. However, you need to specialize the implementation discipline to really use all
the possibilities and to handle the limitations of each programming language.

Adapted from : Source: Rational Unified Process

Retrieved :
https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/process/workflow/implemen/co_mdesc.htm

In mapping design to code, the UML artifacts created during the design work, the interaction diagrams
and Design Class Diagrams (DCDs) will be used as input to the code generation process. The
Implementation Model are all the implementation artifacts, such as the source code, database definitions,
JSP/XML/HTML pages, and etc. The creation of code in an OO language such as Java or C# is not part
of OOA/D. It is an end goal. Implementation in an object-oriented language requires writing source code
for: 1) Class and interface definitions 2) Method definitions 3) Collection Classes in Code.

Class Definitions are created from Design Class Diagrams (DCD). DCDs describe the class or interface
name, superclasses, operation signatures, and attributes of a class. This is sufficient to create a basic
class definition in an OO language.
Methods are created from Interaction Diagrams The sequence of the messages in an interaction
diagram translates to a series of statements in the method definitions.
The enterItem message is sent to a Register instance; therefore, the enterItem method is defined in class
Register.

public void enterItem(ItemID itemID, int qty)

Message 1: A getProductDescription message is sent to the ProductCatalog to retrieve a
ProductDescription. ProductDescription desc = catalog.getProductDescription(itemID);
Message 2: The makeLineItem message is sent to the Sale.
currentSale.makeLineItem(desc, qty);

Collection Classes in Code One-to-many relationships are common. For example, a Sale must maintain
visibility to a group of many SalesLineItem instances, as shown in Figure In OO programming
languages, these relationships are usually implemented with collection of object.

For example, the Java libraries contain collection classes such as ArrayList. Using ArrayList, the Sale
class can define an attribute that maintains an ordered list of SalesLineItem instances.

Source: Adapted from https://slideplayer.com/slide/11389023/

Goals of Coding
1. To translate the design of system into a computer language format: The coding is the
process of transforming the design of a system into a computer language format, which can be
 executed by a computer and that perform tasks as specified by the design of operation during the
design phase.
2. To reduce the cost of later phases: The cost of testing and maintenance can be significantly
reduced with efficient coding.
3. Making the program more readable: Program should be easy to read and understand. It
increases code understanding having readability and understandability as a clear objective of the
coding activity can itself help in producing more maintainable software.

For implementing our design into code, we require a high-level functional language. A programming
language should have the following characteristics:

• Readability: A good high-level language will allow programs to be written in some methods that
resemble a quite-English description of the underlying functions. The coding may be done in an
essentially self-documenting way.
• Portability: High-level languages, being virtually machine-independent, should be easy to
develop portable software.
• Generality: Most high-level languages allow the writing of a vast collection of programs, thus
relieving the programmer of the need to develop into an expert in many diverse languages.
• Brevity: Language should have the ability to implement the algorithm with less amount of code.
Programs mean in high-level languages are often significantly shorter than their low-level
equivalents.
• Error checking: A programmer is likely to make many errors in the development of a computer
program. Many high-level languages invoke a lot of bugs checking both at compile-time and run-
time.
• Cost: The ultimate cost of a programming language is a task of many of its characteristics.
• Quick translation: It should permit quick translation.
• Efficiency: It should authorize the creation of an efficient object code.
 • Modularity: It is desirable that programs can be developed in the language as several separately
compiled modules, with the appropriate structure for ensuring self-consistency among these
modules.
• Widely available: Language should be widely available, and it should be feasible to provide
translators for all the major machines and all the primary operating systems.

Coding Standards
A coding standard lists several rules to be followed during coding, such as the way variables are to be
named, the way the code is to be laid out, error return conventions, etc. General coding standards refers
to how the developer writes code, so here we will discuss some essential standards regardless of the
programming language being used. The following are some example or representative coding
standards:
• Indentation: Proper and consistent indentation is essential in producing easy to read and
maintainable programs. Indentation should be used to:
o Emphasize the body of a control structure such as a loop or a select statement.
o Emphasize the body of a conditional statement
o Emphasize a new scope block
• Inline comments: Inline comments analyze the functioning of the subroutine, or key aspects of
the algorithm shall be frequently used.
• Limiting the use of global: These rules file what types of data can be declared global and what
cannot.
• Structured Programming: For Structured (or Modular) Programming methods, "GOTO"
statements shall not be used as they lead to "spaghetti" code, which is hard to read and maintain..
• Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always begin with a capital letter,
local variable names are made of small letters, and constant names are always capital letters.
• Error return conventions and exception handling system: Different functions in a program
report the way error conditions are handled should be standard within an organization. For
example, different tasks while encountering an error condition should either return a 0 or 1
consistently.

Coding Guidelines
General coding guidelines provide the programmer with a set of the best methods which can be used to
make programs more comfortable to read and maintain. Most of the examples use the C language syntax,
but the guidelines can be tested to all languages. The following are some representative coding
guidelines recommended by many software development organizations.
Line Length: It is considered a good practice to keep the length of source code lines at or below 80
characters. Lines longer than this may not be visible properly on some terminals and tools. Some printers
will truncate lines longer than 80 columns.

Spacing: The appropriate use of spaces within a line of code can improve readability.
Example:
Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);
Better: cost = price + ( price * sales_tax )
fprintf (stdout,"The total cost is %5.2f\n",cost);

The code should be well-documented: As a rule of thumb, there must be at least one comment line on
the average for every three-source line.

The length of any function should not exceed 10 source lines: A very lengthy function is generally
very difficult to understand as it possibly carries out many various functions. For the same reason, lengthy
functions are possible to have a disproportionately larger number of bugs.

Do not use goto statements: Use of goto statements makes a program unstructured and very tough to
understand.

Inline Comments: Inline comments promote readability.

Error Messages: Error handling is an essential aspect of computer programming. This does not only
include adding the necessary logic to test for and handle errors but also involves making error messages
meaningful.

Programming Style
Programming style refers to the technique used in writing the source code for a computer program. Most
programming styles are designed to help programmers quickly read and understands the program as
well as avoid making errors. (Older programming styles also focused on conserving screen space.) A
good coding style can overcome the many deficiencies of a first programming language, while poor style
can defeat the intent of an excellent language.
The goal of good programming style is to provide understandable, straightforward, elegant code. The
programming style used in a various program may be derived from the coding standards or code
conventions of a company or other computing organization, as well as the preferences of the actual
programmer. Some general rules or guidelines in respect of programming style:

• Clarity and simplicity of Expression: The programs should be designed in such a manner so
that the objectives of the program is clear.
• Naming: In a program, you are required to name the module, processes, and variable, and so
on. Care should be taken that the naming style should not be cryptic and non-representative.
For Example: a = 3.14 * r * r
area of circle = 3.14 * radius * radius;
• Control Constructs: It is desirable that as much as a possible single entry and single exit
constructs used.
• Information hiding: The information secure in the data structures should be hidden from the rest
of the system where possible. Information hiding can decrease the coupling between modules
and make the system more maintainable.
• Nesting: Deep nesting of loops and conditions greatly harm the static and dynamic behavior of a
program. It also becomes difficult to understand the program logic, so it is desirable to avoid deep
nesting.
• User-defined types: Make heavy use of user-defined data types like enum, class, structure, and
union. These data types make your program code easy to write and easy to understand.
• Module size: The module size should be uniform. The size of the module should not be too big
or too small. If the module size is too large, it is not generally functionally cohesive. If the module
size is too small, it leads to unnecessary overheads.
• Module Interface: A module with a complex interface should be carefully examined.
• Side-effects: When a module is invoked, it sometimes has a side effect of modifying the program
state. Such side-effect should be avoided where as possible.
Source Adapted from : https://www.javatpoint.com/software-engineering-coding

Software Fault Tolerance

Software fault tolerance is the ability of computer software to continue its normal operation despite the
presence of system or hardware faults. Fault-tolerant software has the ability to satisfy requirements
despite failures. not all software change in the same way so software fault tolerance methods are
designed to overcome execution errors by modifying variable values to create an acceptable program
state.[4] The need to control software fault is one of the most rising challenges facing software industries
today. Fault tolerance must be a key consideration in the early stage of software development.
There exist different mechanisms or techniques for software fault tolerance, among which:
• Recovery blocks
• N-version software
• Self-checking software

Recovery Blocks
The recovery block method is a simple method developed by Randell from what was observed as
somewhat current practice at the time. [Lyu95] The recovery block operates with an adjudicator which
confirms the results of various implementations of the same algorithm. In a system with recovery blocks,
the system view is broken down into fault recoverable blocks. The entire system is constructed of these
fault tolerant blocks. Each block contains at least a primary, secondary, and exceptional case code along
with an adjudicator. (It is important to note that this definition can be recursive, and that any component
may be composed of another fault tolerant block composed of primary, secondary, exceptional case, and
adjudicator components.) The adjudicator is the component which determines the correctness of the
various blocks to try. The adjudicator should be kept somewhat simple in order to maintain execution
speed and aide in correctness. Upon first entering a unit, the adjudicator first executes the primary
alternate. (There may be N alternates in a unit which the adjudicator may try.) If the adjudicator
determines that the primary block failed, it then tries to roll back the state of the system and tries the
secondary alternate. If the adjudicator does not accept the results of any of the alternates, it then invokes
the exception handler, which then indicates the fact that the software could not perform the requested
operation.

Recovery block operation still has the same dependency which most software fault tolerance systems
have: design diversity. The recovery block method increases the pressure on the specification to be
specific enough to create different multiple alternatives that are functionally the same. This issue is further
discussed in the context of the N-version method.

The recovery block system is also complicated by the fact that it requires the ability to roll back the state
of the system from trying an alternate. This may be accomplished in a variety of ways, including hardware
support for these operations. This try and rollback ability has the effect of making the software to appear
extremely transactional, in which only after a transaction is accepted is it committed to the system. There
are advantages to a system built with a transactional nature, the largest of which is the difficult nature of
getting such a system into an incorrect or unstable state. This property, in combination with checkpointing
and recovery may aide in constructing a distributed hardware fault tolerant system.

N-version Software
The N-version software concept attempts to parallel the traditional hardware fault tolerance concept of
N-way redundant hardware. In an N-version software system, each module is made with up to N different
implementations. Each variant accomplishes the same task, but hopefully in a different way. Each version
then submits its answer to voter or decider which determines the correct answer, (hopefully, all versions
were the same and correct,) and returns that as the result of the module. This system can hopefully
overcome the design faults present in most software by relying upon the design diversity concept. An
important distinction in N-version software is the fact that the system could include multiple types of
hardware using multiple versions of software. The goal is to increase the diversity in order to avoid
common mode failures. Using N-version software, it is encouraged that each different version be
implemented in as diverse a manner as possible, including different tool sets, different programming
languages, and possibly different environments. The various development groups must have as little
interaction related to the programming between them as possible. [Avizienis85] N-version software can
only be successful and successfully tolerate faults if the required design diversity is met.

The dependence on appropriate specifications in N-version software, (and recovery blocks,) can not be
stressed enough. The delicate balance required by the N-version software method requires that a
specification be specific enough so that the various versions are completely inter-operable, so that a
software decider may choose equally between them, but cannot be so limiting that the software
programmers do not have enough freedom to create diverse designs. The flexibility in the specification
to encourage design diversity, yet maintain the compatibility between versions is a difficult task, however,
most current software fault tolerance methods rely on this delicate balance in the specification.

The N-version method presents the possibility of various faults being generated, but successfully masked
and ignored within the system. It is important, however, to detect and correct these faults before they
become errors. First, the classification of faults applied to N-version software method: if only a single
version in an N-version system, the error is classified as a simplex fault. If M versions within an N-version
system have faults, the the fault is declared to be an M-plex fault. M-plex faults are further classified into
two classes of faults of related and independent types. Detecting, classifying, and correcting faults is an
important task in any fault tolerant system for long term correct operation.

The differences between the recovery block method and the N-version method are not too numerous,
but they are important. In traditional recovery blocks, each alternative would be executed serially until an
acceptable solution is found as determined by the adjudicator. The recovery block method has been
extended to include concurrent execution of the various alternatives. The N-version method has always
been designed to be implemented using N-way hardware concurrently. In a serial retry system, the cost
in time of trying multiple alternatives may be too expensive, especially for a real-time system. Conversely,
concurrent systems require the expense of N-way hardware and a communications network to connect
them. Another important difference in the two methods is the difference between an adjudicator and the
decider. The recovery block method requires that each module build a specific adjudicator; in the N-
version method, a single decider may be used. The recovery block method, assuming that the
programmer can create a sufficiently simple adjudicator, will create a system which is difficult to enter
into an incorrect state. The engineering tradeoffs, especially monetary costs, involved with developing
either type of system have their advantages and disadvantages, and it is important for the engineer to
explore the space to decide on what the best solution for his project is.

Self-Checking Software
Self checking software is not a rigorously described method in the literature, but rather a more ad hoc
method used in some important systems. [Lyu95] Self-checking software has been implemented in some
extremely reliable and safety-critical systems already deployed in our society, including the Lucent ESS-
5 phone switch and the Airbus A-340 airplanes. [Lyu95]

Self-checking software are the extra checks, often including some amount checkpointing and rollback
recovery methods added into fault-tolerant or safety critical systems. Other methods including separate
tasks that "walk" the heap finding and correcting data defects and the options of using degraded
performance algorithms. While self-checking may not be a rigorous methodology, it has shown to be
surprisingly effective. The obvious problem with self-checking software is its lack of rigor. Code coverage
for a fault tolerant system is unknown. Furthermore, just how reliable a system made with self-checking
software? Without the proper rigor and experiments comparing and improving self-checking software
cannot effectively be done.
Fault tolerance is defined as how to provide, by redundancy, service complying with the specification in
spite of faults having occurred or occurring. (Laprie 1996). There are some important concepts buried
within the text of this definition that should be examined. Primarily, Laprie argues that fault tolerance is
accomplished using redundancy. This argument is good for errors which are not caused by design faults,
however, replicating a design fault in multiple places will not aide in complying with a specification. It is
also important to note the emphasis placed on the specification as the final arbiter of what is an error and
what is not. Design diversity increases pressure on the specification creators to make multiple variants
of the same specification which are equivalent in order to aide the programmer in creating variations in
algorithms for the necessary redundancy. The definition itself may no longer be appropriate for the type
of problems that current fault tolerance is trying to solve, both hardware and software. Randell argues
that the difference between fault tolerance versus exception handling is that exception handling deviates
from the specification and fault tolerance attempts to provide services compliant with the specification
after detecting a fault [Lyu95], This is an important difference to realize between trying to construct robust
software versus trying to construct reliable software. Reliable software will accomplish its task under
adverse conditions while robust software will be able to indicate a failure correctly, (hopefully without the
entire system failing.)
Source: Adapted from
https://users.ece.cmu.edu/~koopman/des_s99/sw_fault_tolerance/#:~:text=Software%20fault%20tolerance%20is
%20the,in%20accordance%20with%20the%20specification.

Exception handling
Exception handling is the process of responding to the occurrence of exceptions – anomalous or
exceptional conditions requiring special processing - during the execution of a program. In general, an
exception breaks the normal flow of execution and executes a pre-registered exception handler; the
details of how this is done depend on whether it is a hardware or software exception and how the
software exception is implemented. It is provided by specialized programming language constructs,
hardware mechanisms like interrupts, or operating system (OS) inter-process communication (IPC)
facilities like signals. Some exceptions, especially hardware ones, may be handled so gracefully that
execution can resume where it was interrupted.
An alternative approach to exception handling in software is error checking, which maintains normal
program flow with later explicit checks for contingencies reported using special return values, an
auxiliary global variable such as C's errno, or floating point status flags. Input validation, which
preemptively filters exceptional cases, is also an approach.
Software exception handling and the support provided by software tools differs somewhat from what is
understood by exception handling in hardware, but similar concepts are involved. In programming language
mechanisms for exception handling, the term exception is typically used in a specific sense to denote a data
structure storing information about an exceptional condition. One mechanism to transfer control, or raise an
exception, is known as a throw. The exception is said to be thrown. Execution is transferred to a "catch".
From the point of view of the author of a routine, raising an exception is a useful way to signal that a
routine could not execute normally - for example, when an input argument is invalid (e.g. value is outside
of the domain of a function) or when a resource it relies on is unavailable (like a missing file, a hard disk
error, or out-of-memory errors), or that the routine has detected a normal condition that requires special
handling, e.g., attention, end of file. In systems without exceptions, routines would need to return some
special error code. However, this is sometimes complicated by the semipredicate problem, in which users
of the routine need to write extra code to distinguish normal return values from erroneous ones.
Programming languages differ substantially in their notion of what an exception is. Contemporary
languages can roughly be divided into two groups:
• Languages where exceptions are designed to be used as flow control structures: Ada, Java, Modula-
3, ML, OCaml, PL/I, Python, and Ruby fall in this category.
• Languages where exceptions are only used to handle abnormal, unpredictable, erroneous situations:
C++,[8] C#, Common Lisp, Eiffel, and Modula-2.
Kiniry also notes that "Language design only partially influences the use of exceptions, and consequently,
the manner in which one handles partial and total failures during system execution. The other major
influence is examples of use, typically in core libraries and code examples in technical books, magazine
articles, and online discussion forums, and in an organization’s code standards" (Kiniry, 2006).
Contemporary applications face many design challenges when considering exception handling strategies.
Particularly in modern enterprise level applications, exceptions must often cross process boundaries and
machine boundaries. Part of designing a solid exception handling strategy is recognizing when a process
has failed to the point where it cannot be economically handled by the software portion of the process.[9]
Excluding minor syntactic differences, there are only a couple of exception handling styles in use. In the
most popular style, an exception is initiated by a special statement ( throw or raise ) with an exception
object (e.g. with Java or Object Pascal) or a value of a special extendable enumerated type (e.g. with Ada or
SML). The scope for exception handlers starts with a marker clause ( try or the language's block starter
such as begin ) and ends in the start of the first handler clause ( catch , except , rescue ). Several
handler clauses can follow, and each can specify which exception types it handles and what name it uses
for the exception object.
A few languages also permit a clause ( else ) that is used in case no exception occurred before the end of
the handler's scope was reached.
More common is a related clause ( finally or ensure ) that is executed whether an exception occurred or
not, typically to release resources acquired within the body of the exception-handling block. Notably, C++
does not provide this construct, since it encourages the Resource Acquisition Is Initialization (RAII)
technique which frees resources using destructors.
In its whole, exception handling code might look like this (in Java-like pseudocode):

try {
line = console.readLine();

if (line.length() == 0) {
throw new EmptyLineException("The line read from console was empty!");
}

console.printLine("Hello %s!" % line);

console.printLine("The program ran successfully.");
}
catch (EmptyLineException e) {
console.printLine("Hello!");
}
catch (Exception e) {
console.printLine("Error: " + e.message());
}
finally {
console.printLine("The program is now terminating.");
}

As a minor variation, some languages use a single handler clause, which deals with the class of the
exception internally.
The implementation of exception handling in programming languages typically involves a fair amount of
support from both a code generator and the runtime system accompanying a compiler. (It was the
addition of exception handling to C++ that ended the useful lifetime of the original C++ compiler, Cfront.)
Two schemes are most common. The first, dynamic registration, generates code that continually updates
structures about the program state in terms of exception handling. Typically, this adds a new element to
the stack frame layout that knows what handlers are available for the function or method associated with
that frame; if an exception is thrown, a pointer in the layout directs the runtime to the appropriate handler
code. This approach is compact in terms of space, but adds execution overhead on frame entry and exit.
It was commonly used in many Ada implementations, for example, where complex generation and
runtime support was already needed for many other language features. Dynamic registration, being fairly
straightforward to define, is amenable to proof of correctness.
The second scheme, and the one implemented in many production-quality C++ compilers, is a table-
driven approach. This creates static tables at compile time and link time that relate ranges of the program
counter to the program state with respect to exception handling. Then, if an exception is thrown, the
runtime system looks up the current instruction location in the tables and determines what handlers are
in play and what needs to be done. This approach minimizes executive overhead for the case where an
exception is not thrown. This happens at the cost of some space, but this space can be allocated into
read-only, special-purpose data sections that are not loaded or relocated until an exception is actually
thrown. This second approach is also superior in terms of achieving thread safety[
Other definitional and implementation schemes have been proposed as well.[For languages that
support metaprogramming, approaches that involve no overhead at all (beyond the already present
support for reflection) have been advanced (Hof et al, 2016).

Program Documentation
Many corporate or organizational standards and procedures focus on the descriptions accompanying a
collection of programs. We consider program documentation to be the set of written descriptions that
accompany programs in order to explain to a reader what the programs do and how they do it. Internal
documentation is descriptive material written directly within the programs; all other documentation is
external documentation.

Internal Documentation
The internal documentation contains information directed at someone who will be reading the source
code of our program. Thus, summary information is provided to a reader to identify the program and
describe its data structures, algorithms, and control flow. This summary information is placed at the
beginning of the program module in a set of comments called the header comment block.

Header Comment Block. Just as a good newspaper reporter must include the who, what, where, when,
why, and how in a story, you must include the following information in the header comment block:
1. What your program is
2. Who wrote the program
3. Where the program fits in the general system designs
4. When the program was written and revised
5. Why the program exists
6. How your program uses its data structures, algorithms, and control

Although the order in which the elements of the header comment block are listed can vary, it is usually
subject to any formal standards that apply to the project. No matter what the standard for your particular
project is, it is important to include all of the above information in your header comment block. Here is
how a typical header comment block for a comment block for a text processing module might look:
PROGRAM SCAN – Program to scan a line for a given character
PROGRAMMER: Beatrice Clarman (718)345-6789
CALLING SEQUENCE: CALL SCAN(LENGTH,CHAR)
where ‘LENGTH’ is the length of the line to be scanned, ‘CHAR’ is the character to be sought,
line of text passed as array ‘NTEXT’.
VERSION 1: written 1-12-89
REVISION 1.1: 2-3-90 improve searching algorithm.
PURPOSE: General-purpose scanning module to be used for each new line of text, no
matter the length.
DATE STRUCTURES: Variable LENGTH – INTEGER
Variable CHAR – CHARACTER
ARRAY NTEXT – CHARACTER array of length ‘LENGTH’
ALGORITHM: Reads array NTEXT one character at a time; if CHAR is found, posi-
tion in NTEXT returned in variable ‘LENGTH’; else variable ‘LENGTH’ set 0

Other Program Comments. The header comment block acts as an introduction to your program, much
as an introduction to a book explains its purpose. Additional comments enlighten readers as they move
through your program. If the organization of the code reflects a well-structured design, of the statements
are formatted clearly, and if the labels, variable, and data names are descriptive and easy to distinguish,
then the necessary number of additional comments is small. By following the guidelines in this chapter
for code format and structure, the code acts as a source of information about itself.
Comments have a place even in clearly structured and well-written code. Although clarity of code and
structure minimize the need for other comments, additional comments are needed wherever useful
information can be added to a program module. Comments can play other roles besides providing a line-
by-line explanation of what the program is doing. For example, comments can break a program into
phases that represents major activities. The code for an activity is usually no more than one age in length.
Then, an individual activity may be separated by comments into smaller steps, each only several lines of
code in length. Pseudocode from your program design can serve this purpose and remind you of the
functions involved.
When code is revised, programmers sometimes forget to update the comments to reflect the change. It
is essential that your comments agree with what the code is actually doing. In addition, be sure that every
comment adds new information. For example, it is of no use to write
13 – 13 + 1 ; INCREMENT 13
when you can add substantially more information by writing
13 – 13 + 1 ; SET COUNTER TO READ NEXT CASE
Ideally, the parameter names should help to explain the activity being performs:
CASE_COUNTER – CASE COUNTER + 1
Your comments should be written as you write the code itself, not afterward. By beginning with the design
and moving to the final code in stages, the design evolves to pseudocode, which in turn acts as a
framework for your final code and a basis for your comments. As you write in-line comments and explain
what the code is doing, beware of a code that is difficult to comments. If you are having problems writing
understandable comments about complex code, you may need to redesign your code in some way.
Meaningful Variable Names and Statement Labels. Choose names for your variables and statements
that reflect use or meaning. Writing
WEEKWAGE – (HRRATE * * HOURS) + (.5) * (HRRATE) * (HOURS - 40.)
Makes much more sense to the reader than
Z – (A * B) + (.5) * (A) * (B – 40.)

In fact, the first example is likely not to need in any additional comments. Also, you are less likely to
introduce errors into your program when the statements labels and variable names are meaningful.
Similarly, alphabetic statement labels should tell readers something about what the labeled section of
your program does. If the labels are numeric or incorporate numbers, they should be in ascending order
and clustered by related purpose.
Formatted to Enhance Understanding. The format of your comments can help a reader understand what
the code is doing and how. Indentation and spacing of statements can reflect the basic control structures.
Notice how unintended code like this
IF XCOORD < YCOORD
THEN RESULT – -1;
ELSE IF XCOORD – YCOORD
THEN IF SLOPE1 > SLOPE2
THEN RESULT – 0;
ELSE RESULT – 1 ;
ELSE IF SLOPE1 > SLOPE2
THEN RESULT – 2;
ELSE IF SLOPE1 < SLOPE2
THEN RESULT – 2;
ELSE RESULT – 4;

Can be clarified by using indentation and rearranging the space:

IF XCOORD < YCOORD THEN RESULT – -1;
ELSE IF XCOORD – YCOORD THEN
IF SLOPE1 > SLOPE2 THEN RESULT – 0;
ELSE RESULT – 1 ;
ELSE IF SLOPE1 > SLOPE2 THEN RESULT – 2;
ELSE IF SLOPE1 < SLOPE2 THEN RESULT – 3;
ELSE RESULT – 4;

Documenting Data. One of the most difficult things for readers of a program to understand is the way in
which data are structured and used. A “map” of the data is very useful in interpreting the actions of lines
of code, especially when a system handles many files of varying types and purposes, coupled with flags
and passed parameters. Thus, internal documentation should include descriptions of the data structures
and uses. Be sure to list major variables in the header control block and any default values for each
variable. A data entry in the header control block may look like this one:
{ DATA STRUCTURES: }
{ DAMLOC contains }
( dam locations and height )
{ DEFAULT VALUES: read from tape )
{ WATERQUAL to store }
{ water quality data from sensors }
( DEFAULT WALUES: initialized to 0 }

External Documentation
Whereas internal documentation is concise and written at a level appropriate for a programmer, external
documentation is intended to be read also by those who may never look at the actual code. For instance,
system or program designers may review the external documentation when considering modifications or
enhancements to the system. In addition, in the external documentation you have a chance to explain
things more broadly than might be reasonable within your program’s comments. Of you consider the
header comment block to be an overview or summary of your program, then the external documentation
can be considered the full-blown report. It answers the same questions—who, what, why, when, where,
and how—using a system rather than a module, perspective.
Because a software system is built from interrelated modules, the external documentation often includes
an overview of the mosules comprising the system or of several groupings of system modules. Diagrams,
accompanied by narrative describing each module, show how data structures are shared and used by
one or more modules; in general, the overview describes how information is passed from one module to
another. Object classes and their inheritance hierarchy are explained here as are reasons for defining
special types or categories of data.
External program documentation is part of the overall system documentation. At the time the program is
written, much of the rationale for the program structure and flow have already been detailed in the system
and program design documents. In a sense, the program design is the skeleton of the external
documentation; the flesh is supplied by narrative discussing the particulars of the program.
Describing the Problem. In the first section of the external documentation, you explain what problem is
being addressed by the program. This section sets the stage for describing what options were considered
for solutions and why a particular solution was chosen. The problem description is not a repeat of the
requirements description that resulted from the requirements analysis. Rather, it is a general discussion
of the setting: when this program is called and why it is needed.
Describing the Algorithm. Once you make clear why the program exists, you should address the choice
of algorithms. Each algorithm used by the program is discussed in detail in a narrative form. All formulae
are included, and boundary or special conditions are discussed. When appropriate, include the derivation
of the algorithm or a reference to it in some other source (such as the program design, a journal article,
or a textbook).
If an algorithm deals with special cases, be sure to discuss the cases and explain how each special case
is derived and handled. Of certain cases are not handled because they will never be encountered, the
documentation should explain why they will not be encountered. For example, an algorithm may involve
a formula where one variable expression is derived by another. The documentation should discuss the
possibility that the denominator is zero, an explanation of how the program handles the formula and
subsequent calculations should be included; if it is impossible for the denominator to be zero, then your
document addresses why this case will never occur.
Describing the Data. In the external documentation, users or programmers can see the data flow through
the system at a program module level. Thus, data flow diagrams accompany any description of a program
design; the external documentation can refer to the design but should also describe the layout in a
narrative form. For a set of object-oriented programs, an overview of objects and classes should explain
the general interaction of objects.

What is an API? (Application Programming Interface)

API is the acronym for Application Programming Interface, which is a software intermediary that allows
two applications to talk to each other. Each time you use an app like Facebook, send an instant message,
or check the weather on your phone, you’re using an API.

What Is an Example of an API?

When you use an application on your mobile phone, the application connects to the Internet and sends
data to a server. The server then retrieves that data, interprets it, performs the necessary actions and
sends it back to your phone. The application then interprets that data and presents you with the
information you wanted in a readable way. This is what an API is - all of this happens via API. To explain
this better, let us take a familiar example. Imagine you’re sitting at a table in a restaurant with a menu of
choices to order from. The kitchen is the part of the “system” that will prepare your order. What is missing
is the critical link to communicate your order to the kitchen and deliver your food back to your table. That’s
where the waiter or API comes in. The waiter is the messenger – or API – that takes your request or
order and tells the kitchen – the system – what to do. Then the waiter delivers the response back to you;
in this case, it is the food.

Here is a real-life API example. You may be familiar with the process of searching flights online. Just like
the restaurant, you have a variety of options to choose from, including different cities, departure and
return dates, and more. Let us imagine that you’re booking you are flight on an airline website. You
choose a departure city and date, a return city and date, cabin class, as well as other variables. In order
to book your flight, you interact with the airline’s website to access their database and see if any seats
are available on those dates and what the costs might be. However, what if you are not using the airline’s
website––a channel that has direct access to the information? What if you are using an online travel
service, such as Kayak or Expedia, which aggregates information from a number of airline databases?
The travel service, in this case, interacts with the airline’s API. The API is the interface that, like your
helpful waiter, can be asked by that online travel service to get information from the airline’s database to
book seats, baggage options, etc. The API then takes the airline’s response to your request and delivers
it right back to the online travel service, which then shows you the most updated, relevant information.

What an API Also Provides Is a Layer of Security

Your phone’s data is never fully exposed to the server, and likewise the server is never fully exposed to
your phone. Instead, each communicates with small packets of data, sharing only that which is
necessary—like ordering takeout. You tell the restaurant what you would like to eat, they tell you what
they need in return and then, in the end, you get your meal. APIs have become so valuable that they
comprise a large part of many business’ revenue. Major companies like Google, eBay, Salesforce.com,
Amazon, and Expedia are just a few of the companies that make money from their APIs. What the “API
economy” refers to is this marketplace of APIs.

The Modern API

Over the years, what an “API” is has often described any sort of generic connectivity interface to an
application. More recently, however, the modern API has taken on some characteristics that make them
extraordinarily valuable and useful:
• Modern APIs adhere to standards (typically HTTP and REST), that are developer-friendly, easily
accessible and understood broadly
 • They are treated more like products than code. They are designed for consumption for specific
audiences (e.g., mobile developers), they are documented, and they are versioned in a way that
users can have certain expectations of its maintenance and lifecycle.
• Because they are much more standardized, they have a much stronger discipline for security and
governance, as well as monitored and managed for performance and scale
• As any other piece of productized software, the modern API has its own software development
lifecycle (SDLC) of designing, testing, building, managing, and versioning. Also, modern APIs
are well documented for consumption and versioning.

Source: Adapted from https://www.mulesoft.com/resources/api/what-is-an-api

What is API Documentation?

API documentation is a technical content deliverable, containing instructions about how to effectively use
and integrate with an API. It’s a concise reference manual containing all the information required to work
with the API, with details about the functions, classes, return types, arguments and more, supported by
tutorials and examples. API Documentation has traditionally been done using regular content creation
and maintenance tools and text editors.

API description formats like the OpenAPI/Swagger Specification have automated the documentation
process, making it easier for teams to generate and maintain them.

The third-party developer, who is your API’s main consumer, is busy solving complex programming
challenges. Your API is a means to an end for the technical user, and they want to integrate as quickly
as possible to move forward in their software development, meaning they should immediately understand
the value and usage of your API. The aggregate experience of the developer when discovering, learning
to use, and finally integrating with an API is termed as Developer Experience (DX). API documentation
is the key to a great DX.

Why Document APIs?

Among all the phases in the API lifecycle, documentation is probably the area showing the most growth.
This is especially true with the tooling ecosystem around documentation. It’s interesting to note this
trends, since documentation is traditionally something that developers paid little attention to when
launching code.

In fact, it’s much easier to implement code, than is it to write good documentation. But this is because of
its direct impact on adoption and usage. You can have the best, functional product, but no one will use it
if they don’t know how to. Documentation is the foundation for good Developer Experience.
Improved User Adoption. Adoption patterns are already shifting towards developers in the technology
sphere. One big reason for having good API documentation is that it improves the experience for
developers using your API, which has a direct correlation on API adoption. People adopt products they
enjoy using, and the same holds true with your API. If you get your documentation right, more people will
find value in your services easily, leading to better growth and adoption.

Increased Awareness. Users beget users. The network effect is the phenomenon when a service or
product becomes more valuable when more people use it. Your satisfied consumers will be the API’s
biggest advocates. As more users adopt your APIs and reach critical mass, there will be a probable
increase in evangelism and word-of-mouth publicity by your satisfied consumers, leading to the network
effect.

Saves Support Time and Costs. In addition to driving increased awareness and adoption for your API,
good documentation also decreases the amount of time spent onboarding new users, be it internal
developers or external partners. Poor or no documentation means more frustrated users relying on your
team to understand how to work with your API. On the contrast, when you give users the ability to try out
the API before implementing it, and arm them with detailed documentation to get started, you’ll save your
team countless hours responding to support emails and calls.

Easier Maintenance. And finally, documentation leads to good product maintenance. It helps your
internal teams know the details of your resources, methods, and their associated requests and
responses, making maintenance and updates quicker.

How to Document Your APIs

There are a number of ways to get started with documenting your APIs. It just really depends on which
method of API design you've settled on. Like we said before, if you're building your API from scratch,
OpenAPI and Swagger Tools have helped automate the documentation process, which makes it easier
for you, or your team, to maintain and update your documentation. If you are following the "Code First"
approach to API design, creating API documentation is a breeze with Swagger Inspector.
This tool is a free, cloud based API testing and documentation generation tool. Swagger Inspector allows
you to take any API and generate OpenAPI documentation automatically. This is especially useful for
individuals looking to standardize with the OpenAPI specification.

Documentation is the key to a great experience when consuming your API. It not only enables consumer
satisfaction, but also allows your API adoption to increase. Popular open source description formats like
OpenAPI Specification and commercial platforms like SwaggerHub allow teams to automate the
documentation process and work on a great overall experience consuming APIs.

Source: Adapted from https://swagger.io/blog/api-documentation/what-is-api-documentation-and-why-it-matters/

Code Review
Code Review is a systematic examination, which can find and remove the vulnerabilities in the code
such as memory leaks and buffer overflows.
• Also called technical reviews, these are well documented and use a well-defined defect detection
process that includes peers and technical experts.
• It is ideally led by a trained moderator, who is NOT the author.
• This kind of review is usually performed as a peer review without management participation.
• Reviewers prepare for the review meeting and prepare a review report with a list of findings.
• Reviews may be quite informal or very formal and can have a number of purposes but not limited
to discussion, decision making, evaluation of alternatives, finding defects and solving technical
problems.

Code Review, or Peer Code Review, is the act of consciously and systematically convening with one’s
fellow programmers to check each other’s code for mistakes, and has been repeatedly shown to
accelerate and streamline the process of software development like few other practices can. There
are peer code review tools and software, but the concept itself is important to understand. Software is
written by human beings. Software is therefore often riddled with mistakes.

When done correctly, peer reviews save time, streamlining the development process upfront and
drastically reducing the amount of work required later of Quality Assurance teams. Reviews can also
save money, particularly by catching the types of bugs that might slip undetected through testing, through
production, and into the end-users’ laptops.

Work environments that encourage programmers to talk with each other about their code tend to foster
greater communication and camaraderie, distribute the sense of "ownership" for any piece of code, and
provide an invaluable educational context for junior developers—as senior colleagues demonstrate,
through real instances, better ways to write clean code, solve common problems with useful shortcuts,
and visually identify any number of potential troublespots, such as memory leaks, buffer overflows, or
scalability issues.

Understanding Code Review

Recent work by Tom Gilb, one of the more prominent authors dealing with software inspections, and his
colleagues continues to support earlier findings that a human being inspecting code is the most effective
way to find and eliminate complex problems that originate in requirements, design, and other noncode
deliverables. Indeed, to identify deeper problems in source code, formal code inspection outranks testing
in terms of defect-removal efficiency levels.

Common Code Review Approaches

The Email Thread
As soon as a given piece of code is ready for review, the file is sent around to the appropriate colleagues
via email for each of them to review as soon as their workflow permits. While this approach can certainly
be more flexible and adaptive than more traditional techniques, such as getting five people together in a
room for a code-inspection meeting, an email thread of suggestions and differing opinions tends to get
complicated fast, leaving the original coder on her own to sort through it all.

Pair Programming
As one of the hallmarks of Extreme Programming (XP), this approach to writing software puts developers
side by side (at least figuratively), working on the same code together and thereby checking each other’s
work as they go. It’s a good way for senior developers to mentor junior colleagues, and seems to bake
code review directly into the programming process. Yet because authors and even co-authors tend to be
too close to their own work, other methods of code review may provide more objectivity. Pair
programming can also use more resources, in terms of time and personnel, than other methods.

Over-the-Shoulder
More comfortable for most developers than XP’s pair programming, the old over-the-shoulder technique
is the easiest and most intuitive way to engage in peer code review. Once your code is ready, just find a
qualified colleague to site down at your workstation (or go to theirs) and review your code for you, as you
explain to them why you wrote it the way you did. This informal approach is certainly "lightweight," but it
can be a little too light if it lacks methods of tracking or documentation. (Hint: bring a notepad.)

Tool-Assisted
There is arguably no simpler and more efficient way to review code than through software-based code
review tools, some of which are browser-based or seamlessly integrate within a variety of standard IDE
and SCM development frameworks. Software tools solve many of the limitations of the preceding
approaches above, tracking colleagues’ comments and proposed solutions to defects in a clear and
coherent sequence (similar to tracking changes in MS Word), enabling reviews to happen
asynchronously and non-locally, issuing notifications to the original coder when new reviews come in,
and keeping the whole process moving efficiently, with no meetings and no one having to leave their
desks to contribute. Some tools also allow requirements documents to be reviewed and revised and,
significantly, can also generate key usage statistics, providing the audit trials and review metrics needed
for process improvement and compliance reporting.

Tracking Your Progress

Whichever method of peer review one prefers, it goes without saying that metrics matter in the arena of
code review, especially with so many dev teams out there still waiting to be convinced about its ultimate
efficacy as a regular practice. Yet there is no better way than tracking actual metrics to justify, and most
intelligently utilize, the time and brainpower required—and that’s why some existing studies are so
edifying, such as a 2005-2006 analysis of Cisco’s peer-code review process conducted by SmartBear
Software, which surveyed no less than 2,500 reviews of 3,200,000 lines of code written by 50 developers
(the full study is presented in SmartBear’s in-depth eBook Best-Kept Secrets of Peer Code Review).

Not only was it determined that Cisco’s code review process detected far more bugs, or defects, than
regular testing alone could have uncovered, but the metrics (derived from such a large sample set)
allowed the researchers to glean the following crucial insights about code review in general:
• Lines of code (LOC) under review should be less than 200, not exceeding 400, as anything larger
overwhelms reviewers and they stop uncovering defects.
• Inspection rates of less than 300 LOC/hour result in the best defect detection, and rates under 500
are still good, but expect to miss a significant percentage of defects if LOC are reviewed faster than
that.
• Authors who prepare the review with annotations and explanations have far fewer defects than those
that do not. The cause, presumably, is due to authors being forced to self-review their code.
• The total review time should be less than 60 minutes, not to exceed 90. Defect detection rates
plummet after 90 minutes of reviewing.
• Expect defect rates at around 15 per hour. This rate can only be higher with less than 175 LOC under
review.
In another case study, recorded in the same ebook, the SmartBear team reported that one customer
wanted to reduce the high cost of fielding customer support calls each year, which they determined cost
them $33 per call. Starting at 50,000 calls a year, within a few years after systematic code review
procedures were implemented to both remove software defects (because computer glitches would initiate
random calls to the customer support department) and to improve usability (to reduce the number of
bewildered customers calling tech support), the frequency of support calls had dropped down to just
20,000 per year (despite even a 200% increase in product sales)—equaling a cool $2.6 million in savings.

Source: Adapted from https://smartbear.com/learn/code-review/what-is-code-review/

BOOK REFEERENCES:
• Kiniry, J. R. (2006). "Exceptions in Java and Eiffel: Two Extremes in Exception Design and
Application". Advanced Topics in Exception Handling Techniques. Lecture Notes in Computer
Science. 4119. pp. 288–300. doi:10.1007/11818502_16. ISBN 978-3-540-37443-5.
• Graham Hutton, Joel Wright, "Compiling Exceptions Correctly Archived 2014-09-11 at
the Wayback Machine". Proceedings of the 7th International Conference on Mathematics of
Program Construction, 2004.
• Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN
Notices. 33 (8): 40–47. doi:10.1145/286385.286390. S2CID 1522664.
• M. Hof, H. Mössenböck, P. Pirkelbauer, "Zero-Overhead Exception Handling Using
Metaprogramming Archived 2016-03-03 at the Wayback Machine", Proceedings SOFSEM'97,
November 1997, Lecture Notes in Computer Science 1338, pp. 423-431.

ASSESSMENTS:

1. Translate your software design specifications into actual programmable lines of code using
appropriate programming language, appropriate coding standards, coding style/principles and
internal header/documentation. Generate a suitable application program interface (API)
document when necessary.
2. Perform code review applying appropriate technique for each of the software components
created.
3. Produce internal and external source code documents using appropriate modeling and
documentation tools.
4. Discuss what is your most significant learning in software design implementation topics and why.
 8. SOFTWARE TESTING

LEARNING OBJECTIVES:
• Explain various software testing activities needed in the evaluation of a software;
• Design test cases needed for internal and external tests;
• Construct test plan and test cases for proper implementation of software testing.
• Describe other software quality assurance activities

OVERVIEW:
Testing is significant to delivering defect free-software. It is one of the software quality assurance activities
that should be performed in any software project. The testing phase focuses on identifying all defects
that may be present in the program code. Every piece of code written needs to be tested. Careful testing
can help expose most of the errors/defects existing in a program, and therefore provides a practical way
of reducing defects in a system. Testing a code involves forming test cases (set of test inputs) and
providing it to the program and then verify if the system behaves as expected for these set of inputs. At
first each module is tested in isolation and errors or defects, are removed. Next required modules are
integrated and tested again to check for any defect or failure after modules were integrated. For any type
of test, test cases are designed and executed These test cases are documented in the Test Plan.
READING MATERIALS:

A software product is normally tested at three levels:

1. Unit testing
2. Integration testing
3. System testing

Unit Testing.
Once the module is coded and reviewed, unit testing of the module in isolation is performed.
Every individual module needs to undergo unit testing procedure before they are integrated to one
another. This helps in detecting errors or bugs in the code that may result in failure of the software
product. Unit testing is referred to as testing in small.
To proceed with unit testing:
1. unit test case has to be designed.
2. test environment for the unit that would be tested needs to be developed

Driver and Stub modules. The complete environment is required to unit test an individual module. This
complete environment simply means:
• The methods of other modules that would get called by the module under unit testing.
• Non local data structure that the module under test access.
• A procedure with proper parameter to call the methods of the module under test.
All the above modules and their methods will not be available until they are ready and unit tested. So
there are two options, either wait for the other modules to get ready or provide the dummy methods and
modules to proceed with unit testing of the ready module. For this, driver and stub are designed which
provides the dummy environment to carry out the unit testing.

A stub is a dummy procedure that contains the same input output parameters that as the given procedure
in the module under unit test. Stub procedures has a very simplified behavior. For instance, stub may
use a simple table look up to produce the expected result.

A driver module contains the non-local data structures that is referred by the module under the test.
Moreover, it should also have the code to call the different functions of the module under test with
appropriate parameter value for testing.
integration Testing.
Once all the modules or at least the required modules are unit tested successfully, integration testing is
carried out. After unit testing is completed, to a large extent, it ensures that unit as a whole works
satisfactorily. In this context, the objective of integration testing is to detect the errors at the module
interfaces (call parameters). For instance, when a module invokes the functionality of the other modules,
then parameter mismatch may occur. Integration testing helps detect that no parameter mismatch occurs
in such cases. The main aim of the integration testing in software engineering is to test, check and ensure
that different modules of the program interface with each other properly. Integration is done based on
planned manner. The integration plan defines the steps and order in which the modules are combined to
create a system. After two modules are integrated, then it is tested for any error or fault. Module
dependency graph is the important factor that guides the integration plan.

The test plan for integration testing can be carried out using any of the following approaches or types of
integration testing:
1. Big bang integration approach
2. Top-down integration approach
3. Bottom-up approach
4. Mixed or sandwiched approach

Big-bang integration testing works on the logic that all the individual modules that makes up the
complete system are integrated together in a single step. This means that all the individual modules or
units are linked together in one go and then tested for any fault or errors.

Advantages of big bang approach

• Big bang integration testing approach is mostly suitable for the small system comprising of less
modules. As error in less modules can be traced and debugging errors is not that difficult following
this approach.

Disadvantages of big bang approach

• Big bang integration testing is difficult to use in large systems or systems having large programs.
• In the large system comprising of numerous modules it becomes difficult to trace the fault or error,
if it occurs as the error may be present in any of the modules that we linked together in a single
step. So, if there are 20 modules then the error appearing may possibly be in any of the modules.
Thus, debugging error in big-bang testing approach is difficult and expensive to fix.

Top-down integration testing begins with the top most module also called the root module. After the
top-level module is tested then the modules present at the immediate lower layer are picked up,
integrated and unit tested. Top-down integration testing approach requires the use of program stubs. A
pure top-down approach does not require any driver routine.

Advantages of top-down integration testing

• Top-down approach requires writing only stubs which are simpler to write as compared to drivers.

Disadvantages of top-down integration testing

• Several times, in the absence of the lower level routines it may become problematic to exercise
the top-level routines in the desired manner since the lower level routines perform several low
level function likes the input/output operations.
Bottom-up integration testing is another important approach used in integration testing of the system.
First the modules of each sub-system (in a big software product) are integrated and thoroughly tested.
This simply means that the modules present at the bottom hierarchy are tested first and then the higher
modules that are dependent on them are tested. Each subsystem may consist of many several module
that work on a particular task while frequently communicating with each other. The main purpose behind
bottom-up integration testing to test the subsystems is to make sure whether the interfaces among
various modules making up the sub-system works as per requirement or not. The test cases must be
chosen carefully to demonstrate each possible scenario. After each lower-level subsystems are tested
they are integrated together to form higher level subsystem. In pure bottom-up integration testing
approach only test-drivers are required. It doesn't require stubs.

Advantages of bottom-up approach

• Using bottom-up integration testing approach several disjoint subsystems can be tested
simultaneously.
• In this approach low-level modules are tested thoroughly. Since low level modules mostly perform
input-output operations and other critical operations as well so testing them nicely increases
comprehensibility of the system.

Disadvantages of bottom-up approach

• When large number of subsystems exists at the same level then following bottom-up approach
turns out to be very complex. In extreme level it becomes quite similar to big-bang approach.

Mixed integration testing is also referred to as sandwiched integration. Mixed integration follows the
combination of bottom-up testing approach and top-down integration testing approach.

Mixed integration testing approach requires to create both:

• the stubs, and
• the drivers.

Advantages of mixed integration testing

Both top-down approach and bottom-up approach has few drawbacks which is attempted to be
eliminated by adopting mixed testing approach. In top-down integration, integration testing can start only
once the top-level modules are coded and unit tested while in bottom-up approach integration testing can
be started only when bottom level modules are coded and unit tested. Mixed integration testing approach
overcomes those limitations by making sure that integration testing of the modules can be started as and
when they are available after unit testing.

Source: Adapted from https://tutorialsinhand.com/tutorials/software-engineering-tutorial/software-testing/software-

testing-basics.aspx

System Testing
It is a level of software testing where a complete and integrated software is tested. The purpose of this
test is to evaluate the system’s compliance with the specified requirements. System testing of the
software product is started once the entire modules contributing to completion of system is integrated
and thoroughly tested while integrating each module.

System test cases are designed with intention to cover entire functionalities as mentioned and agreed
upon in SRS document designed during requirement gathering and analysis phase.
Thus, we can say that system test cases are designed to validate the software product upon completion.
Reason for this is that test cases are solely designed based on SRS documented requirements thus
approach of development is not significant while designing system test cases.

The procedure adopted for system testing is same for both the OOP (Object Oriented Programming) and
POP (Procedure Oriented Programming) systems.

Types of system testing in software engineering:

1. α-testing → It is performed by development team responsible to test the system, mostly testing
team. It is responsibility of the development team to make sure that point to point functionality as
mentioned in SRS document is working properly and anything isn't missed. If anything is breaking
then it must be fixed and properly tested.
2. ß-testing → It is performed by a friendly set of customers to make sure that everything is all fine
before finally submitting product for client evaluation.
3. Acceptance testing → It is performed by customer to confirm whether the product is as per their
requirement or not. Customer and their team intended to use software work with it for few days
and see if things are actually working without any glitch. On satisfactory evaluation of the system
it is accepted else rejected (or asked to make certain changes before acceptance)

System test cases can be classified as:

Functionality based test cases are designed with intention to test the functional aspect of the product.
These test cases can be designed using black box (code free) testing or white box (structural/dynamic)
testing.

Performance based test cases are designed to check if the system meets non-functional requirement
for the software product that is developed. Some example for designing performance based test cases
using black box testing approach are:
• volume testing
• security testing
• stress testing
• regression testing
• usability testing
• configuration testing
• compatibility testing

Source: Adapted from https://tutorialsinhand.com/tutorials/software-engineering-tutorial/software-testing/system-

testing-in-software-engineering.aspx
Code-based testing corresponds to the testing that is carried out on code development, code inspection,
unit testing in software development process.
The Code-based testing consists of following testing:
• Dynamic Testing - Statement coverage, Branch coverage, Path coverage
• Checking for Complexity of Code using techniques like Cyclomatic Complexity
• Static/Code-free Testing - Code Inspection, Code Walkthrough, Code Review, Code Audit

Code Based Testing Techniques:

Structural testing is the type of testing carried out to test the structure of code. It is also known as White
Box testing or Glass Box testing. This type of testing requires knowledge of the code, so, it is mostly done
by the developers. It is more concerned with how system does it rather than the functionality of the
system. It provides more coverage to the testing. For example, to test certain error message in an
application, we need to test the trigger condition for it, but there must be many triggers for it. It is possible
to miss out one while testing the requirements drafted in SRS. But using this testing, the trigger is most
likely to be covered since structural testing aims to cover all the nodes and paths in the structure of code.
It is complementary to Functional Testing. Using this technique, the test cases drafted according to
system requirements can be first analyzed and then more test cases can be added to increase the
coverage. It can be used on different levels such as unit testing, component testing, integration testing,
functional testing etc. Its helps in performing a thorough testing on software. The structural testing is
mostly automated. There are different criteria that are used to perform such testing. Before moving on to
those, it is important to understand some terms.
Control Flow Graph: It is a graphical representation of the program depicting all the paths that may be
transverse during the execution. It contains
• Basic Block or Node: It is a sequence of statements such that control can only have one entry
point and can exit the block only when all the statements have been executed.
• Edge:It shows the control flow.
For example following is a control flow graph:

N1, N2, N3, N4 and N5 represents Basic Blocks or Nodes and E1, E2, E3, E4 and E5 represents Edges.
We can also observe that N2, N3, N4 and N5 together represent an IF loop.

Adequacy Criterion: This term refers to the coverage provided by a test suite.

Structural Testing Techniques:

Statement Coverage: It aims to test all the statements present in the program
Adequacy Criterion should be equal to 1 to ensure 100% coverage. It is a good measure of testing each
part in terms of statements but it is not a good technique for testing the control flow. For ex: one node
can be reached from multiple other nodes, but since the aim is to cover just the statements, those
conditions are not covered. It can be understood from the help of following example:
Here all the statements in the program can be covered using two flow
1. E1->E2->E5
2. E1->E3
But using these two statements the flow from N3 to N4 is not tested i.e. E4. It does not provide branch
coverage. N3 has 2 exit points depending upon the decision statement in N3 i.e. True and False, but
since N4 has already been covered, the testing for a decision statement is missed out.

Branch Coverage: It is also known as Decision coverage testing. It aims to test all the branches or edges
at least once in the test suite or to test each branch from a decision point at least once. It provides solution
for the problem faced in Statement coverage. Branch E4 will be covered here as we saw in previous
example. Branch Testing provides a better coverage than Statement testing but it too has its
shortcomings. It doesn’t provide a good coverage from different conditions that lead from node 1 to node
2 as it covers that branch only once. Let’s try to understand it better with the help of following example.

In this case, the 100% branch coverage can be provided as following

• E1->E2
• E3
But as we can see edge E1 can be tested for multiple conditions, but under branch testing the aim is to
just test the edge for one condition and not for multiple conditions associated to it. The different conditions
can be:
• A>2 and B>8 (A True and B False)
• A<2 and B<8 (A False and B True) etc.

Condition Coverage: It aims to test individual conditions with possible different combination of Boolean
input for the expression. It is modification of Decision coverage but it provides better coverage and the
problem discussed under Branch coverage can be resolved here. Notice the different combination of
inputs in the following table
S.No. A B A or B

1 0 0 0

2 0 1 1

3 1 0 1

4 1 1 1

However, when compound conditions are involved the no. of test cases may increase exponentially,
which is not desired.

Modified Condition/Decision coverage: It is a modification of condition coverage. Its adequacy criterion

can be defined as N+1 test cases for N variables. The test cases are derived such that that each variable
independently affects the final output.So it provides coverage for different conditions without increasing
the size of test case suit.

Path Coverage: It aims to test the different path from entry to the exit of the program, which is a
combination of different decisions taken in the sequence. The paths can be too many to be considered
for testing, for ex, a loop can go on and on. It can be avoided using cyclomatic complexity, which help in
finding out the redundant test cases. Cyclomatic Complexity is quantitative measure of no. of linearly
independent paths through a program and is used to indicate complexity of a program. So, cyclomatic
complexity helps aiming to test all linearly independent paths in a program at least once.

Advantages of Structural Testing:

• Provides a more thorough testing of the software.
• Helps finding out defects at an early stage.
• Helps in eliminating dead code.
• Not time consuming as it is mostly automated.
Disadvantages of Structural Testing:
• Requires knowledge of the code.
• Requires training in the tool used for testing
• It is expensive.

Tools Required:
Some of the test tools that are used for White box or Structural Testing are as follow:
1. JBehave
2. Cucumber
3. Junit
4. Cfix

Source: Adapted from https://www.softwaretestingclass.com/what-is-structural-

testing/#:~:text=Structural%20testing%20is%20the%20type,mostly%20done%20by%20the%20developers.

Cyclomatic Complexity is a source code complexity measurement that is being correlated to a number
of coding errors. It is calculated by developing a Control Flow Graph of the code that measures the
number of linearly-independent paths through a program module. Lower the Program's cyclomatic
complexity, lower the risk to modify and easier to understand. It can be represented using the below
formula:
Cyclomatic complexity = E - N + 2*P
where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

Example :
IF A = 10 THEN
IF B > C THEN
A=B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C
FlowGraph:

The Cyclomatic complexity is calculated using the above control flow diagram that shows seven
nodes(shapes) and eight edges (lines), hence the cyclomatic complexity is 8 - 7 + 2 = 3.

Static Testing or Code Free Testing is a type of software testing in which software application is tested
without code execution. Manual or automated reviews of code, requirement documents and document
design are done in order to find the errors. The main objective of static testing is to improve the quality of
software applications by finding errors in early stages of software development process.

Static testing involves manual or automated reviews of the documents. This review is done during an
initial phase of testing to catch defect early. It examines work documents and provides review comments.
It is also called Non-execution testing or verification testing. Examples of Work documents-
• Requirement specifications
• Design document
• *Source Code (for code-based test)
• Test Plans
• Test Cases
• Test Scripts
• Help or User document
• Web Page content

For code-based testing, the code free or static testing is a technique performed without the execution of
code. The static testing techniques such as code walkthrough, inspection, review and static analysis are
part of code free testing.
• Review - Typically used to find and eliminate errors or ambiguities in documents
• Walkthrough - a type of review where a programmer leads the review process and the other team
members ask questions and spot possible errors against development standards
• Code inspection – examines the code for the presence of common programming errors
• Static analysis - The code written by developers are analyzed (usually by tools) for structural
defects that may lead to defects.
Code Review is a systematic examination, which can find and remove the vulnerabilities in the code
such as memory leaks and buffer overflows.
• Also called technical reviews, these are well documented and use a well-defined defect detection
process that includes peers and technical experts.
• It is ideally led by a trained moderator, who is NOT the author.
• This kind of review is usually performed as a peer review without management participation.
• Reviewers prepare for the review meeting and prepare a review report with a list of findings.
• Reviews may be quite informal or very formal and can have a number of purposes but not limited
to discussion, decision making, evaluation of alternatives, finding defects and solving technical
problems.

What is Code Walkthrough?

Code Walkthrough is a form of peer review in which a programmer leads the review process and the
other team members ask questions and spot possible errors against development standards and other
issues.
• The meeting is usually led by the author of the document under review and attended by other
members of the team.
• Review sessions may be formal or informal.
• Before the walkthrough meeting, the preparation by reviewers and then a review report with a list
of findings.
• The scribe, who is not the author, marks the minutes of meeting and note down all the
defects/issues so that it can be tracked to closure.
• The main purpose of walkthrough is to enable learning about the content of the document under
review to help team members gain an understanding of the content of the document and also to
find defects.

Code Inspection aims at examining the code for the presence of common programming error. It checks
for:
• error that creep into the code due to programmar oversight
• whether coding standard is followed while coding

Software organizations generally keeps record of the different types of error that is committed by their
programmers. They also identify the errors that are commonly committed. This kind of records serves as
checklist during code inspection to look out for common error.

Given below is the sample of some common errors that can be checked for during code inspection:
• Array indices out of bound
• Arithmetic exceptions
• Use of uninitialized variables
• Non terminating loops
• Mismatch between actual and formal parameters
• Comparison of equality of floating point values
• Jump into loops

While doing code inspection it is likely that these errors can be discovered by specifically looking for this
kind of mistakes in the code. Apart from looking and correcting for coding error this process also makes
sure that code adheres to coding standards and guidelines.
Source: https://tutorialsinhand.com/tutorials/software-engineering-tutorial/software-coding/code-inspection.aspx
Static Analysis - By Tools. Static analysis tools are generally used by developers as part of the
development and component testing process. The key aspect is that the code (or other artefact) is not
executed or run but the tool itself is executed, and the source code we are interested in is the input data
to the tool. These tools are mostly used by developers. Static analysis tools are an extension of compiler
technology – in fact some compilers do offer static analysis features. It is worth checking what is available
from existing compilers or development environments before looking at purchasing a more sophisticated
static analysis tool. Other than software code, static analysis can also be carried out on things like, static
analysis of requirements or static analysis of websites (for example, to assess for proper use of
accessibility tags or the following of HTML standards). Static analysis tools for code can help the
developers to understand the structure of the code, and can also be used to enforce coding standards.

Features or characteristics of static analysis tools are:

• To calculate metrics such as cyclomatic complexity or nesting levels (which can help to
identify where more testing may be needed due to increased risk).
• To enforce coding standards.
• To analyze structures and dependencies.
• Help in code understanding.
• To identify anomalies or defects in the code.
Source: http://tryqa.com/what-is-static-analysis-tools-in-software-
testing/#:~:text=Static%20analysis%20tools%20are%20generally,input%20data%20to%20the%20tool.

Following are the types of defects found by the tools during static analysis:
• A variable with an undefined value
• Inconsistent interface between modules and components
• Variables that are declared but never used
• Unreachable code (or) Dead Code
• Programming standards violations
• Security vulnerabilities
• Syntax violations

Summary on Static Versus Dynamic Testing

• Static testing was done without executing the program whereas Dynamic testing is done by
executing the program.
• Static testing checks the code, requirement documents, and design documents to find errors
whereas Dynamic testing checks the functional behavior of software system, memory/CPU
usage and overall performance of the system.
• Static testing is about the prevention of defects whereas Dynamic testing is about finding and
fixing the defects.
• Static testing does the verification process while Dynamic testing does the validation process.
• Static testing is performed before compilation whereas Dynamic testing is performed after
compilation.
• Static testing techniques are structural and statement coverage while Dynamic testing
techniques are Boundary Value Analysis & Equivalence Partitioning.
https://www.guru99.com/static-dynamic-
testing.html#:~:text=What%20is%20Static%20Testing%3F,order%20to%20find%20the%20errors.
Software Testing Life Cycle (STLC)
Software Testing Life Cycle is a sequence of different activities performed by the testing team to ensure
the quality of the software or the product. It defines a series of activities conducted to perform Software
Testing. The different phases of Software testing life cycle are:

• Requirement Analysis — Requirement Analysis is the first step involved in Software testing life
cycle. In this step, Quality Assurance (QA) team understands the requirement in terms of what we
will testing & figure out the testable requirements.
• Test Planning — Test Planning is the most important phase of Software testing life cycle where all
testing strategy is defined. This phase is also called as Test Strategy phase. In this phase, Test
Manager is involved to determine the effort and cost estimates for the entire project. It defines the
objective & scope of the project.
• Test Case Development — The Test case development begins once the test planning phase is
completed. This is the phase of STLC where testing team notes the detailed test cases. Along with
test cases, a testing team also prepares the test data for testing. Once the test cases are ready then
these test ases are reviewed by peer members or QA lead.
• Test Environment Setup — Setting up the test environment is a vital part of the Software Testing
Life Cycle. A testing environment is a setup of software and hardware for the testing teams to execute
test cases. It supports test execution with hardware, software and network configured.
• Test Execution — The next phase in the Software Testing Life Cycle is Test Execution. Test
execution is the process of executing the code and comparing the expected and actual results. When
test execution begins, the test analysts start executing the test scripts based on test strategy allowed
in the project.
• Test Cycle Closure — The final phase of the Software Testing Life Cycle is Test Cycle Closure. It
involves calling out the testing team member meeting & evaluating cycle completion criteria based on
Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software.
Source: Adapted from https://medium.com/edureka/types-of-software-testing-d7aa29090b5b
Test Plan
A test plan is a document describing software testing scope and activities. It is the basis for formally
testing any software / product in a project. A test plan describes the scope, approach, resources and
schedule of intended test activities. It identifies amongst others test items, the features to be tested, the
testing tasks, who will do each task, degree of tester independence, the test environment, the test design
techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring
contingency planning. It is a record of the test planning process.

Test Plan is influenced by the following factors:

• Organizational test policy and test strategy
• Software development life cycle model
• Scope of testing
• Availability of resources.

At the beginning of the project, the test plan can be a draft or with very little details. But, as the project
progresses and more information becomes available, the test plan needs to be fleshed out. Test planning
is a continuous activity and is performed throughout the product’s life cycle.
Types of Test Plans:
1. Master Test Plan: A single high-level test plan for a project / product that unifies all other test
plans.
2. Test Level Specific Plan: Test plans for each level of testing:
Unit Test Plan
Integration Test Plan
System Test Plan
Acceptance Test Plan
3. Testing Type Specific: Test plans for specific types of testing like Performance Test Plan
and Security Test Plan.

Test Plan Template. The format and content of a software test plan vary depending on the processes,
standards, and test management tools being implemented. Nevertheless, the following format, which is
based on IEEE standard for software test documentation, provides a summary of what a test plan can /
should contain.
• Test Plan Identifier: Provide a unique identifier for the document. (Adhere to the Configuration
Management System if you have one.)
• Introduction: Provide an overview of the test plan. Specify the goals / objectives. Specify any
constraints.
• References: List the related documents, with links to them if available, including the Project Plan
and Configuration Management Plan
• Test Items: List the test items (software / products) and their versions.
• Features to be Tested: List the features of the software / product to be tested. Provide references
to the requirements and/or Design specifications of the features to be tested.
• Features Not to Be Tested: List the features of the software / product which will not be tested.
Specify the reasons these features won’t be tested.
• Approach: Mention the overall approach to testing. Specify the following:
o Testing levels [if it’s a Master Test Plan],
o Testing types
o Testing methods
• Item Pass / Fail Criteria: Specify the criteria that will be used to determine whether each test
item has passed or failed testing.
 • Suspension Criteria and Resumption Requirements: Specify criteria to be used to suspend
the testing activity. Specify what is required before testing can resume.
• Test Deliverables: List test deliverables, and links to them if available, including the following:
Test Plan (this document itself), Test Cases, Test Scripts, Test Data, Defect Reports, Test
Reports
• Test Environment: Specify the properties of test environment: hardware, software, network, etc.
List any testing or related tools.
• Estimate: Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed
estimation.
• Schedule: Provide a summary of the schedule, specifying key test milestones, and/or provide a
link to the detailed schedule.
• Staffing and Training Needs: Specify staffing needs by role and required skills. Identify training
that is necessary to provide those skills, if not already acquired.
• Responsibilities: List the responsibilities of each team / role / individual.
• Risks: List the risks that have been identified. Specify the mitigation plan and the contingency
plan for each risk.
• Assumptions and Dependencies: List the assumptions that have been made during the
preparation of this plan. List the dependencies.
• Approvals: Specify the names and roles of all persons who must approve the plan. Provide space
for signatures and dates. (If the document is to be printed.)

Test Plan Guidelines

Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section
that has been mentioned in the template above, go ahead and delete that section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test
environment, mention the OS Edition / Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to baselining it or sending it for approval.
The quality of your test plan speaks volumes about the quality of the testing you or your team is
going to perform.
• Update the plan as and when necessary. An out-dated and unused document stinks and is
worse than not having the document in the first place.
Source: Adapted from https://softwaretestingfundamentals.com/test-
plan/#:~:text=A%20TEST%20PLAN%20is%20a,schedule%20of%20intended%20test%20activities.

Test Design: Specifying Test Cases

Basically, test design is the act of creating and writing test suites for testing a software. Test analysis and
identifying test conditions gives us a generic idea for testing which covers quite a large range of
possibilities. But when we come to make a test case we need to be very specific. In fact now we need
the exact and detailed specific input. But just having some values to input to the system is not a test, if
you don’t know what the system is supposed to do with the inputs, you will not be able to tell that whether
your test has passed or failed. Test cases can be documented as described in the IEEE 829 Standard
for Test Documentation.

One of the most important aspects of a test is that it checks that the system does what it is supposed to
do. Copeland says ‘At its core, testing is the process of comparing “what is” with “what ought to be” ‘.
[Copeland, 2003]. If we simply put in some inputs and think that was fun, I guess the system is probably
OK because it didn’t crash, but are we actually testing it? We don’t think so. You have observed that the
system does what the system does but this is not a test. Boris Beizer refers to this as ‘kiddie
testing’ [Beizer, 1990]. We may not know what the right answer is in detail every time, and we can still
get some benefit from this approach at times, but it isn’t really testing. In order to know what the
system should do, we need to have a source of information about the correct behavior of the system –
this is called an ‘oracle’ or a test oracle.

Once a given input value has been chosen, the tester needs to determine what the expected result of
entering that input would be and document it as part of the test case. Expected results include information
displayed on a screen in response to an input. If we don’t decide on the expected results before we run
a test then there might be a chance that we will notice that there is something wildly wrong. However,
we would probably not notice small differences in calculations, or results that seemed to look OK. So we
would conclude that the test had passed, when in fact the software has not given the correct result. Small
differences in one calculation can add up to something very major later on, for example if results are
multiplied by a large factor. Hence, ideally expected results should be predicted before the test is run.

For a comprehensive material on software testing, see http://tryqa.com/ and

https://tutorialsinhand.com/tutorials/software-engineering-tutorial/

Code Driven VS Data Driven Testing

What is Code Driven Testing?

The Code driven testing also known as test driven development's first step is to add a test, which is
enough for code to fail. Next, we execute out tests usually a complete test suite or a subset of tests to
accelerate testing to ensure that the new test fails. Then, the code is updated to make it pass the new
tests. Then, the fourth step is to execute the tests again. If they fail, we need to update the code and
retest. Once the test passes, the next step is to go through the same process again for the next
development item.
The Code driven testing WorkFlow:
What is Data Driven Testing?
Data-driven testing is creation of test scripts where test data and/or output values are read from data
files instead of using the same hard-coded values each time the test runs. This way, testers can test
how the application handles various inputs effectively. It can be any of the below data files.
• Datapools
• Excel files
• ADO objects
• CSV files
• ODBC sources

Flow Diagram:
Data Driven Testing can be best understood by the following diagram:

Source: Adapted from https://www.tutorialspoint.com/software_testing_dictionary/

ASSESSMENTS:

1. Explain various software testing activities needed in the evaluation of the software.
2. Discuss the difference between structural tests and static tests.
3. Prepare a Unit Test Plan and Integration Test Plan following the IEEE standard.
4. Design test cases needed for internal and external tests.
5. Discuss what is your most significant learning in software testing topics why.
 9. SOFTWARE MAINTENANCE AND CONFIGURATION MANAGEMENT

LEARNING OBJECTIVES:
• Discuss various maintenance processes applied on software development;
• Differentiate the three categories of software maintenance;
• Discuss software maintenance techniques and principles based on best practices.
• Construct a software configuration management plan for proper conduct of software
maintenance.

OVERVIEW:

Software maintenance in software engineering is the modification of a software product after delivery to
correct faults, to improve performance or other attributes. Software maintenance is a very broad activity
that includes error correction, enhancements of capabilities, deletion of obsolete capabilities, and
optimization. Any work done to change the software after it is in operation is considered to be
maintenance work. The purpose is to preserve the value of software over time. The value can be
enhanced by expanding the customer base, meeting additional requirements, becoming easier to use,
more efficient and employing newer technology. Because change is inevitable, mechanisms must be
developed for evaluation, controlling and making modifications. The essential part of software
maintenance requires preparation of an accurate plan during the development cycle.

READING MATERIALS:

Software maintenance planning

An integral part of software is the maintenance, which requires an accurate maintenance plan to be
prepared during the software development. It should specify how users will request modifications or
report problems. The budget should include resource and cost estimates. A new decision should be
addressed for the developing of every new system feature and its quality objectives. The software
maintenance, which can last for 5–6 years (or even decades) after the development process, calls for an
effective plan which can address the scope of software maintenance, the tailoring of the post-
delivery/deployment process, the designation of who will provide maintenance, and an estimate of the
life-cycle costs. The selection of proper enforcement of standards is the challenging task right from early
stage of software engineering which has not got definite importance by the concerned stakeholders.

6 Software Maintenance Processes:

1. The implementation process contains software preparation and transition activities, such as the
conception and creation of the maintenance plan; the preparation for handling problems identified
during development; and the follow-up on product configuration management.
2. The problem and modification analysis process, which is executed once the application has
become the responsibility of the maintenance group. The maintenance programmer must analyze
each request, confirm it (by reproducing the situation) and check its validity, investigate it and
 propose a solution, document the request and the solution proposal, and finally, obtain all the
required authorizations to apply the modifications.
3. The process considering the implementation of the modification itself.
4. The acceptance of the modification process, by confirming the modified work with the individual
who submitted the request in order to make sure the modification provided a solution.
5. The migration process (platform migration, for example) is exceptional, and is not part of daily
maintenance tasks. If the software must be ported to another platform without any change in
functionality, this process will be used and a maintenance project team is likely to be assigned to
this task.
6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the
retirement of a piece of software.

There are a number of processes, activities and practices that are unique to maintainers, for example:
• Transition: a controlled and coordinated sequence of activities during which a system is transferred
progressively from the developer to the maintainer;
• Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts
negotiated by maintainers;
• Modification Request and Problem Report Help Desk: a problem-handling process used by
maintainers to prioritize, documents and route the requests they receive;

Categories of software maintenance

E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective.
The IEEE 1219 standard was superseded in June 2010 by P14764. These have since been updated and
ISO/IEC 14764 presents:
• Corrective maintenance: Reactive modification of a software product performed after delivery to
correct discovered problems. Corrective maintenance can be automated with automatic bug fixing.
• Adaptive maintenance: Modification of a software product performed after delivery to keep a software
product usable in a changed or changing environment.
• Perfective maintenance: Modification of a software product after delivery to improve performance
or maintainability.
• Preventive maintenance: Modification of a software product after delivery to detect and correct latent
faults in the software product before they become effective faults.

History of Software Maintenance

The history of software configuration management (SCM) in computing can be traced back as early as
the 1950s, when CM (for Configuration Management), originally for hardware development and
production control, was being applied to software development. Early software had a physical footprint,
such as cards, tapes, and other media. The first software configuration management was a manual
operation. With the advances in language and complexity, software engineering, involving configuration
management and other methods, became a major concern due to issues like schedule, budget, and
quality. Practical lessons, over the years, had led to the definition, and establishment, of procedures and
tools. Eventually, the tools became systems to manage software changes. Industry-wide practices were
offered as solutions, either in an open or proprietary manner (such as Revision Control System). With
the growing use of computers, systems emerged that handled a broader scope, including requirements
management, design alternatives, quality control, and more; later tools followed the guidelines of
organizations, such as the Capability Maturity Model of the Software Engineering Institute.
Software Maintenance Best Practices
Schedule
Ensure that you schedule maintenance windows regularly with the user base. Setting an expectation for
maintenance windows ahead of time is crucial to users so they can plan ahead for any critical work that
must be delivered. This is similar to construction notifications you may see on the streets of your daily
routine. When you know that maintenance is upcoming, you can plan ahead to take an alternative route
or travel at a different time. Knowing when maintenance is scheduled to happen can significantly improve
the user experience. I recommend that these windows be regular and predictable for the foreseeable
future and, most importantly, published to all users. For example, every Sunday between 12:00 AM –
2:00 AM for a production environment and everyday between 12:00 PM – 2:00 PM for a non-production
environment. Note that not every eligible window will maintenance time be taken, but it is regularly
available to administrators if required.

Think Holistically
The next best practice for system administrators is to think holistically about the software stack.
Specifically, subscribe to receive notifications for newly available maintenance releases for the entire
software stack, not just a single application. Let’s consider a typical Datameer installation as an example.
Most commonly, Datameer installations include the following dependencies: operating system, Hadoop,
Java and MySQL. Each of these software elements are maintained on a different schedule and are
distributed as separate software binaries. Correcting or preventing an issue in any one of these elements
will have a positive impact on your users and deems equal attention from the system administrators.
Lastly, when monitoring for new maintenance releases, it’s also important to pay attention to any end-of-
maintenance dates for versions installed in your software stack. Versions that are no longer receiving
maintenance updates at all should trigger an upgrade project to keep your users current.

Review Urgency
As you receive notifications about the availability of new maintenance releases, make it a priority to
review the list of fixes thoroughly. Reviewing this list helps you understand the urgency for when patches
should be applied, especially if multiple system elements have maintenance patches released around
the same time. When reviewing this list, administrators should do their best to review from a user’s
perspective. Specifically, ask yourself the following two questions: what is the benefit of applying this fix?
What is the risk of not applying this fix? Fixes for issues that your users have actually reported are
commonly the most urgent to resolve. At times, there will be several maintenance fixes that are required
for the full software stack. When multiple changes are desired, it is important to rank them from a user’s
perspective so that they can be applied in this order — more on this in the next section.

Test Updates
The next best practice may seem obvious, but so many try to skip it: test the maintenance updates!
Specifically, test the maintenance updates in a non-production replica environment first. When applying
the maintenance updates, I recommend a scientific approach. By scientific, I specifically mean that we
should perform a “control” test without any maintenance updates applied. After that, apply a single
maintenance update and re-run the test suite. The tests are intended to verify two things: (1) that
behaviors that changed matched expectations; and (2) that no unintended changes were observed.
To summarize, the testing process should have three steps: (1) perform a “control” test, (2) apply one
maintenance update and (3) perform a validation test. These three steps should all be performed during
the non-production maintenance window — this allows administrators to measure the duration required
to apply the update can successfully complete during the expected time. For the most conservative
system administrators, it’s also a good practice to test reverting a maintenance update in case production
produces different results than non-production.
Replicate in Production
The final best practice that I want to share is to repeat the steps in production. Emphasis is intended on
the repetition of the steps. This step again takes a scientific approach. Specifically, we’re expecting that
if we perform the same steps in production that we did in non-production that we should get the same
results. No matter how similar the non-production and production environments are to each other, there
will always be some difference in the environment. Since there are differences, it is still recommended to
perform the following three steps: (1) perform a “control” test, (2) apply one maintenance update and (3)
perform a validation test before concluding the maintenance window.
By using these best practices, system administrators can keep users satisfied and productive with regular
maintenance updates.

Software Configuration Management

In software engineering, software configuration management (SCM or S/W CM) or software change
management, is the task of tracking and controlling changes in the software, part of the larger cross-
disciplinary field of configuration management (Pressman, 2009). SCM practices include
revision control and the establishment of baselines. If something goes wrong, SCM can determine what
was changed and who changed it. If a configuration is working well, SCM can determine how to replicate
it across many hosts.

According to Gartner and Forrester Research, the acronym "SCM" is also expanded as source
configuration management process and software change and configuration management. However,
"configuration" is generally understood to cover changes typically made by a system administrator.

The goals of SCM are generally:

• Configuration identification - Identifying configurations, configuration items and baselines. This is
also a major activity in SCM.
• Configuration control - Implementing a controlled change process. This is usually achieved by setting
up a change control board whose primary function is to approve or reject all change requests that
are sent against any baseline. This is also a major activity in SCM.
• Configuration status accounting - Recording and reporting all the necessary information on the status
of the development process. This is also a major activity in SCM.
• Configuration auditing - Ensuring that configurations contain all their intended parts and are sound
with respect to their specifying documents, including requirements, architectural specifications and
user manuals. This is also a major activity in SCM.
• Build management - Managing the process and tools used for builds.
• Process management - Ensuring adherence to the organization's development process.
• Environment management - Managing the software and hardware that host the system.
• Teamwork - Facilitate team interactions related to the process.
• Defect tracking - Making sure every defect has traceability back to the source.

Source: Adapted from https://www.datameer.com/blog/five-best-practices-for-software-maintenance/

SCM And Software Maintenance
Software configuration management (SCM) is one of the primary concerns during system implementation
and maintenance. However, SCM as part of the software quality assurance (SQA) is different from
software maintenance. Software maintenance is required after the software is delivered to the client and
is put into operations. As opposed to this, SCM is a set of tracking and controlling activities that begins
when a software project begins and ends only when the software is taken out of operation.

SCM Tools
There are many available tools, beginning with systems such as Revision Control System (RCS) and
Concurrent Versions System (CVS), which have been followed by newer tools such as Subversion (SVN),
Mercurial (Hg) and Git. The basic approach is to create a software repository, usually on a network drive
or online, and then to keep a working copy of the software on your local hard drive. Software changes
are made in the working copy and then checked in to the repository. Conversely, software can
be checked out from the repository to the working copy. This basic approach supports multiple
developers, assuming that they all have access to the repository, but is useful even for a single developer
because the repository maintains a history of all software that was checked in. For example, if your latest
change introduced an error, it is easy to revert back to the previous version or to compare the current
version of the software to the previously working version. Generally, it is also possible to label, or tag, a
particular version of the software, for example, to indicate a particular release.
Another common concept is branches, which enable parallel development of different versions or
features of the software. For example, two programmers can each work on a separate branch, implement
different features, and then later merge their branches back into the main branch (sometimes
called trunk or master).

One of the most popular software configuration management packages is Git, initially released in 2005.
One reason for its popularity is the widespread use of GitHub (www.github.com), which is a code hosting
platform that is based on Git. GitHub provides users with free public repositories and many popular open-
source packages are hosted there. GitHub offers unlimited free hosting of private repositories for
research groups and, for a fee, GitHub also provides private repositories for corporate customers. Many
researchers create and use free GitHub repositories, even in cases where there is only a single
developer.
For collaborative development in large software projects, it is advantageous to have a well-defined
workflow. One popular workflow, that is based on Git and GitHub, is illustrated in Fig. 35.1. This figure
shows the scenario where an organization, org, maintains a public repository, sw_repo, on GitHub. Any
researcher can clone the repository (Step 1), thereby creating a repository (and working copy) on their
computer. For researchers who just wish to use the software, and do not plan to contribute back, this is
sufficient. However, researchers who wish to contribute to sw_repo must do so indirectly, since write
access to the primary repository is generally limited to a few trusted developers. Other researchers can
instead create a forked copy of the repository on their GitHub account and push their changes to that
repository, before issuing a pull request to the maintainers of the original repository. This mechanism
gives the maintainers a convenient way to review the proposed changes and possibly request
modifications, before merging the changes to the original repository. Some steps shown in the figure
below can be done in a different order (e.g., the repository can be forked before being cloned) and other
variations may be necessary. Note that in this workflow, the local repository has two remotes: the original
repository and the forked repository. The reason for keeping a remote to the original repository is to
enable merges from the original repository to incorporate changes that were done in parallel by other
developers.
Source:
Adapted from https://www.sciencedirect.com/topics/computer-science/software-configuration-management

BOOK/JOURNAL REFERENCES
• E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international
conference on Software engineering, San Francisco, 1976, pp 492 — 497".
Portal.acm.org. doi:10.1145/359511.359522. S2CID 14950091. Retrieved 2013-12-02.
• Status of 1219-1998 by IEEE Standards
• Roger S. Pressman (2009). Software Engineering: A Practitioner's Approach (7th
International ed.). New York: McGraw-Hill.

ASSESSMENTS:

1. Discuss various maintenance processes applied on software development.

2. Differentiate the three categories of software maintenance;
3. Discuss software maintenance techniques and principles based on best practices.
4. Construct a software configuration management plan for your software project.