FOREWORD

The world today has witnessed the use of different applications and systems to
transform processes and procedures into a more effective and efficient one. Information
Technology plays a vital role in producing relevant applications for different
organizations, groups and individuals, and communities. This course will cover the
discussion on the relevant fundamental concepts of application development and
software engineering. In this course, basic concepts on emerging technologies will also
be given emphasis in order for students to be able to have an idea on how they can
integrate such technologies in application development. While this course focuses on
application development, integration of recent advancements and technologies will also
be covered to give students essential information and update about them.
Contents of this learning module conforms to the minimum requirements of
CHED Memorandum Order No. 25 Series of 2015 or the Policies, Standards, and
Guidelines of BSCS, BSIS, and BSIT Programs. Author and contributors seek to
continuously refine the contents of this learning module together with a laboratory guide
for application development using JavaFX.
Students are expected to engage in Synchronous and Asynchronous Learning
Modalities to have a better experience in learning the course. Have fun learning on how
to develop your first application project.

Cris Norman P. Olipas

Angelito I. Cunanan Jr.
Ronaldin V. Bauat
Vanessa C. Pascual
 TABLE OF CONTENTS

LESSON 1: OVERVIEW ON SOFTWARE AND HARDWARE APPLICATIONS 4

LESSON 2: INTRODUCTION TO SOFTWARE ENGINEERING AND APPLICATION

DEVELOPMENT 14

LESSON 3: REQUIREMENTS ANALYSIS AND MODELLING 19

LESSON 4: PROCESS MODELLING 26

LESSON 5: SOFTWARE DESIGN 32

LESSON 6: APPLICATION AND SOFTWARE PROTOTYPING 40

LESSON 7: SOFTWARE QUALITY ASSURANCE 45

LESSON 8: SOFTWARE TESTING 55

LESSON 9: SOFTWARE MAINTENANCE 51

3
 LESSON 1
OVERVIEW ON SOFTWARE AND HARDWARE APPLICATIONS

Introduction

Today’s modern era has observed significant changes in the way how people
work, communicate, and perform different tasks and activities. Relative to this,
applications and different software plays a vital role in transforming different processes
into a more effective and efficient one. This lesson will cover an overview of software
and hardware applications essential for you to start in this journey of learning more
about applications development and emerging technologies.

Learning Objectives
At the end of the lesson, you must be able to:
1. define what is software and operating systems:
2. discuss the importance of software and operating systems;
3. compare and contrast the different types of operating systems;
4. identify the different software-related problems; and
5. construct insights on the different software applications

Discussion

Software is computer instructions that, when executed, provides desired

functions and performance. It is a data structure that enables the programs to
manipulate information adequately. The evolution of software starts in the early years,
including batch orientation, with limited distribution and custom software. In the second
era, software became multi-users, real-time, integrates database, and is more on
product software.
During the third era, distributed systems emerged and embedded intelligence;
hardware cost became low; and consumer impact was prioritized. In the fourth era,
robust desktop systems are observed; and object-oriented technologies are produced,
as well as expert systems, artificial neural networks, and parallel computing.

Software-Related Problems
1. Hardware advances continue to outpace our ability to build software to tap
hardware’s potential
2. Our ability to build new programs cannot keep pace with the demand for new
programs, nor can we build programs rapidly enough to meet business and
market needs

4
 3. The widespread use of computers has made society more and more dependent
on the software’s reliable use.
4. We struggle to build high-quality and reliable computer software.
5. Poor design and inadequate resources threaten our ability to support and
enhance existing programs.

Characteristics of Software
1. Software is constructed according to the needs of the client, and it is not
produced in a usual sense that conforms to “one size, fits all” principle. This
means that software is custom engineered.
2. The software does not wear out.

5
 The collection of data or computer instructions that tells the computer how to
perform different operations is commonly known as software. In computing disciplines,
software pertains to all the information processed by computer systems, programs, and
data. It includes computer programs, libraries, and related non-executable data like
documentation and digital media. The system software is designed to provide a platform
for other software. Examples of system software include Linux, macOS, Android, and
Microsoft Windows.

Figure 1: Types of Operating Systems

Types of Operating Systems

Operating systems are vital for performing the essential tasks of a computer,
including managing files, processes, and memory. Operating systems behave like a
manager on a computer that manages the various functions. Operating systems also
act as crossing point between the machine and the user. The following are the types of
operating systems widely used.

1. Batch Operating System

Batch Operating Systems do not directly interact with the computer. There
is an operator that performs the job. The operator takes similar jobs with the
same requirements, then group them as a batch. The operator’s primary
responsibility is to sort similar jobs with similar needs. Examples of batch
systems include a payroll system and banking statements.

6
 Figure 2: Batch Operating System

Advantages of Batch Operating System

a. The time required to complete any job can be a challenging task and
challenging to know. However, the processors of batch systems are
capable of identifying how long the job would take when it is in the
queue.
b. Multiple types of users can share the batch systems.
c. There is a lesser amount of idle time in Batch OS.
d. Managing a large amount of work when performed repeated is very
much more comfortable in batch systems.

Disadvantages of Batch Operating System

a. Computer operators should be well-oriented with batch systems.
b. Debugging a batch system is a challenging task.
c. The cost of batch systems can be high.
d. In case a job fails, other jobs in the queue will have to wait.

2. Time-Sharing Operating Systems

In time-sharing operating systems, tasks are given enough time to
execute. This means that to execute each task smoothly, each user gets the
CPU time, for they only use a single system. These systems are commonly
known as Multi-tasking Systems. Single users or multiple users can generate
tasks. Quantum Time is the term used to describe the time each task gets to

7
 execute. After the allotted time for a task, the OS switches over to the next.
Examples of Time-Sharing Operating System include Multics and Unix.

A
dvant
ages
of
Time-

Shari Figure 3: Time-Sharing Operating System

ng
Operating System
a. Equal opportunity for each task is given
b. The chances of having duplication are lesser than the other types
c. The idle time of the CPU can be reduced

Disadvantages of Time-Sharing Operating System

a. Reliability is one of the challenges of Time-Sharing Operating System
b. Security needs to be taken care to increase integrity.
c. There is a problem that can arise in terms of data communication

3. Distributed Operating System

Distributed Operating System is widely-accepted worldwide with a great
pace for it enables autonomous, interconnected computers to communicate with
each other through shared communication networks. Each autonomous,
independent computer has its memory unit and CPU. Distributed Operating
Systems are commonly known as Loosely Coupled Systems. Since computers
are interconnected, it is possible to share files or software with other computers
through remote access. Locus is one of the examples of a Distributed Operating
System.

8
 Figure 4: Distributed Operating System

Advantages of Distributed Operating System

a. Since systems have their memory and CPU, failures do not affect the
network communication of others.
b. The data exchange speed of electronic mail increases
c. Computation is highly fast and durable because of the shared
resources
d. Reduction of load on host computers
e. Scalability is possible since systems can be easily added to the
network
f. Reduction of delay in the data processing

Disadvantages of Distributed Operating System

a. Since there is a central network responsible for the entire
communication procedure, connections of systems can be stopped
when the main network fails
b. The language used to establish distributed systems are not very well
defined yet.
c. Distributed Operating systems are expensive because of their
complexity.

4. Network Operating System

Network Operating Systems run on a server and provides the capacity to
manage data, users, groups, security, applications, and other types of networking

9
functions. It enables sharing files, printers, security, applications, and other
essential networking functions over a small private network. This type of
Operating System is also known as a tightly coupled systems. This means that
the network members know the configuration and the other users connected
within the same network. Examples of Network Operating Systems include
Microsoft Windows Server 2003, Microsoft Windows Server 2008, UNIX, Linux,
Mac OS X, Novell Network, and BSD.

Figure 5: Network Operating System:

Advantages of Network Operating System

a. Centralized Servers are highly stable
b. The server handles security concerns
c. Integration to the system of new technologies and hardware upgrades
can be quickly done
d. Access to servers can be done remotely from different locations and
types of systems.

Disadvantages of Network Operating System

a. The cost of servers is high.
b. Since there is a server, users have to depend on it for most operations
c. It is required to maintain and update the system regularly.

5. Real-Time Operating Systems

When time is part of the requirements, Real-Time Operating Systems are
very efficient. Applications such as air traffic control systems, robotics, and

10
missile systems are some of the few examples of real-time operating systems.
There are two categories of Real-Time Operating Systems: Hard Real-Time
Systems and Soft Real-Time Systems. Hard Real-Time Systems are those that
require an application to be very strict with time requirements. Meaning, possible
delays in terms of response are not acceptable. This type of system is built to live
life like an automatic parachute or airbags. Also, virtual memory is almost never
found in this type of system. On the other hand, Soft Real-Time Systems are
those that have less strict time-constraints.

Figure 6: Real-Time Software

Advantages of Real-Time Software

a. Maximum Consumption
b. Task Shifting
c. Focus on Application
d. Real Time operating systems in embedded systems
e. Error Free
f. Memory Allocation

Disadvantages of Real-Time Software

a. Limited Tasks
b. Use heavy system resources
c. Complex Algorithm
d. Device driver and interrupt signals
e. Thread Priority

11
ACTIVITY 1.1 (Suggested Mode of Submission of Output: Email/Learning
Management System)

1. Construct a 500-word essay about your understanding on the different types

of operating systems. Your answer will be graded based on the following:
Content, 30 points; Organization, 10 points; and Clarity, 10 points.

12
Software Applications

Software applications include system software, real-time software, engineering,

scientific software, embedded software, personal computer software, and artificial
intelligence software. The system software is a collection of programs written to service
other programs. Examples include compilers, editors, file management utilities,
operating systems, and drivers. Real-time software is a program that monitors,
analyzes, and controls real-world events as they occur. On the other hand, business
software is an application that is used in the business environment and that supports
business operations. Engineering and scientific software are applications in fields such
as astronomy, volcanology, and the space shuttle.

Meanwhile, embedded software resides in read-only memory and controls

products and systems for the consumer and industrial markets. Examples include
keypad control for microwave oven and braking systems. Personal computer software is
an application that supports individual needs such as word processing, spreadsheets,
multimedia applications, and entertainment. Lastly, artificial intelligence software uses a
non-numerical algorithm to solve complex problems that are not amenable to
computation or straightforward analysis. Examples include pattern recognition and
game playing.

Cutting Edge Hardware and Software Technologies

1. Artificial and Augmented Intelligence
2. Real-Time Supply Chain Visibility
3. Data Standards and Advanced Analytics
4. Warehouse Robotics
5. Driverless Deliveries
6. Wearable Devices
7. More Space for Technology

13
ACTIVITY 1.2 (Suggested Mode of Submission of Output: Uploading of Video
Recording in the Learning Group/Learning Management System)

1. In a group of five (5) members, look on the internet of one example for each
cutting-edge hardware and software technologies. Your team must be able to
present it in a video recording, allowing your classmates to know more about
these technologies. Provide brief description and explanation for each cutting-
edge technologies. Presentation should not be more than 10 minutes.

ASSESSMENT – QUIZ NO. 1 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

14
 LESSON 2
INTRODUCTION TO SOFTWARE ENGINEERING AND APPLICATION
DEVELOPMENT

Introduction

Applications Development and Software Engineering are two growing trends in

the field of Information Technology. Today, different companies and organizations seek
to employ application developers and software engineers to cater the needs of
organization and the demands of the community as well. In this lesson, you will be able
to understand the fundamental concepts of application development and software
engineering. These are essential for you to start in the journey of developing your own
applications which can then be used to transform communities through Information
Technology.

Learning Objectives
At the end of the lesson, you must be able to:
1. explain what is software engineering and its difference to application
development;
2. identify the layers of software engineering and its similarities to application
development;
3. recognize the different software engineering and application development
paradigms; and
4. construct an understanding and insights about the use of different software and
application development paradigms and models.

Discussion

Software engineering is the establishment and use of sound engineering

principles to obtain economic software that is reliable and works efficiently on real
machines. Software engineering layers include tools, methods, process, and focus on
quality.

15
1. Process. It is the glue that holds the technology layers together and enables
rational and timely development of computer software.
2. Methods. These provide technical “how to’s” for building software.
3. Tools. These provide automated or semi-automated support for the process and
the methods.

Software Engineering and Application Development Paradigms

1. Prototyping Model. It is a method in which a prototype is built, tested and then
reworked as necessary until an acceptable outcome is achieved, from which the
complete system or product can be developed..

Figure 7: Prototyping Model

Prototyping can be problematic for the following reasons:

a. In prototyping, the customer thought that the working version of the software
satisfies the required expected quality. Unaware that it is a “prototype”, the
customer will not consider some problems. Thus, the quality is compromised.
b. Oftentimes, developers quickly deploy the prototype resulting to more
software or application-related problems.

2. Spiral Model. The spiral model is similar to incremental development for a

system, with more emphasis placed on risk analysis.

16
 Figure 8: Spiral Model

Six task regions:

a. Customer communication. At this region of the spiral model, it important that
the application developer or software engineer establish an effective
communication with the customer to gather all the essential requirements for the
project. One of the major causes of application or software failure is the lack of
communication between stakeholders. Project leaders and other key technology-
drivers of a project must seek to it
that proper and effective
communication medium and
relationship is well established.
b. Planning. Planning is vital to
provide important insights about
the project at hand. At this region
of the spiral model, key players
must be able to identify the
needed resources; define its
relevance to the project; draw
timeline; and gather all the project
related data which contributes to
the overall success of the
undertaking.
c. Risk analysis – This region of the
spiral model highlights the core
essence of the model. Tasks essential in this section require assessment of the

17 Figure 9: Spiral Model

 technical tools needed, and the risk management capacities of the players and
the project at hand. Successful analysis of the possible risks reduces greater
challenges and failures as the project progress.
d. Engineering. In this region of the model, application and software developers
are required to develop representations of the application. It is relevant to
perform such tasks to have an idea of how the system would work and how it
captures all the needed requirements from the customers. Also, engineering
phase allows further analysis to perform immediate changes and adjustments.
e. Construction and release. After the successful completion of the project, this
phase of the model requires construction of user support manual and
documentation, testing and initial deployment, as well as providing user support
and training.
f. Customer evaluation. When the actual project is deployed, it is relevant to
gather the customer's feedback and evaluation of the application to continuously
refine the project and to provide additional necessary changes and adjustments.
In this phase, the plan is reviewed and counterchecked if it conforms to what the
customer needs and requires.

3. Fourth Generation Technique. The source code is automatically generated

according to the specifications made by the developers. Fourth generation
technique utilizes mechanisms that is close to natural language or specific
notation to achieve significant functions. It includes some or all of the following
tools: nonprocedural languages for database query, report generation, data
manipulation, screen interaction and definition and code generation.

Figure 10: 4GL Technique

18
Summary of the current state of 4GT approaches:
a. Over the years, the use of 4GT has made possible the development of
different applications in different areas. It has been a practical approach in
conducting software and application projects.
b. Immense amount of time, effort, and resources has been reduced based from
the data collected from different organizations, entities, or groups that have
employed and utilized 4GT approach.
c. To achieve a better quality of output, for large application projects, 4GT
focused more on the analysis of essential requirements to save substantial
time, effort, and resources while trying to produce a more quality output.

19
ACTIVITY 2.1 (Suggested Mode of Submission of Output: Google Drive/Learning
Management System)
1. Form a team of five (5) members and look for studies that have applied
prototyping, spiral, incremental, agile and waterfall models in international
journals. Your team should be able to make an analysis for each article on how
they have applied each model. The analysis must not be less than 300-words
and not more than 500-words.

ASSESSMENT - QUIZ NO. 2 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

20
 LESSON 3
REQUIREMENTS ANALYSIS AND MODELLING

Introduction

Requirements play a vital role in the overall success and complete delivery of
software applications. When requirements are not properly identified, analyzed, and
collected, failure of delivery might happen. In this lesson, you will learn more about
requirements analysis, the different steps involved in conducting the process, and the
ways on how to convert these into meaningful models that will be significant and helpful
in developing applications.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. explain the importance of requirements and the requirements analysis process;
2. differentiate feasibility study, requirements gathering, software requirement
specifications, and software requirements validation;
3. demonstrate understanding on the different types of requirements gathering
techniques; and
4. compare and contrast functional and non-functional requirements

Discussion

Requirement Analysis is a software engineering and application development

task that bridges the gap between system-level software allocation and software design.
It enables the system engineer or application developer to specify software function and
performance, indicate software’s interface with other system elements, and establish
constraints that software must meet. Requirements analysis allows developers to
allocate software in a more refined manner and to build relevant data models including
functional and behavioral domains which will be treated by software. Different designs
may be produced using requirements analysis which include data, architectural,
interface, and procedural design.

21
 Figure 11: Requirements Analysis as Bridge between
Systems Engineering and Design

Five Areas of Efforts

1. Problem recognition
2. Evaluation and synthesis
3. Modeling
4. Specification
5. Review

Figure 12: Configuration Management Diagram

22
 Configuration Management is a set of procedures that track the requirements
that define the system, the design modules that are generated from the requirements,
the program code that implements the design, the tests that verify the functionality of
the system, and the documents that describe the system.

Software Requirements
Software Requirements include the description of features and functionalities of
the target system. Requirements are essential for it convey the expectations of the
users from the software product or application. It can be obvious or hidden, known or
unknown, expected or unexpected from the client’s point of view. It covers the process
of requirements engineering. Requirements engineering is the process of gathering the
requirements from the client, analyzing it, and documenting them. Steps in requirements
engineering includes feasibility study, requirements gathering, software requirement
specifications, and software requirements validation.

a. Feasibility Study. It is the process of studying in details whether the desired

system and its functionality are feasible to be developed. Typically, feasibility
studies focus on the goals of the organization. Developers must take time to
analyze every detail to see if the desired system is possible to be implemented
and will contribute to the organization success. In addition, identifying cost
constraints is essential in conducting feasibility studies to see if the desired
system is practical and achievable. The technical aspects are also analyzed in
terms of usability, maintainability, productivity, and integration ability. The output
of this process is a feasibility study report which contains comprehensive and
adequate comments and recommendations for the management to decide
whether to pursue or not a software project.

ACTIVITY 3.1 (Suggested Mode of Submission of Output: Video Presentation via

Google Form/Learning Group/Learning Management System)
1. Think of a possible application development project for a community in the
new normal. Make a three (3) to five (5)- minute video explaining about the
concept and other features. Upload the video presentation in the Facebook
Community Learning Group.

b. Requirements Gathering – In requirements gathering, analysts and software

developers communicate with the client and end-users to know their ideas on
what the application or system should provide including the intended features
they desired.

23
 c. Software Requirements Specifications (SRS) – The SRS is a document
created by system analysts after the requirements gathering is conducted and
essential requirements are collected from the different types of stakeholders.
SRS defines how the intended application or system will interact with hardware,
external interfaces, speed of operation, response time of the system, portability
across different platforms, maintainability, and speed of recovery after crashing,
security, quality, limitations, and the likes. Since the requirements collected are
written in the natural language, it is the responsibility of the analyst to translate
them in technical languages to be understood by the members of the
development team. The following are the vital features of the SRS document.
i. User requirements are expressed in natural language
ii. Technical requirements are expressed in structured language,
which is used inside the organization
iii. Design description should be written in pseudo code
iv. Format of Forms and GUI screen prints
v. Conditional and mathematical notations for DFDs, etc.

d. Software Requirements Validation – When software requirement specification

document has been developed, the contents are validated. Users might ask for
any illegal, impractical solutions, or experts may interpret the requirements
inaccurately. If not nipped in the bud, this may result in increase in cost. The
following conditions may be considered when checking requirements.
i. If they can be practically implemented
ii. If they are valid and as per functionality and domain of software
iii. If there are any ambiguities
iv. If they are complete
v. If they can be demonstrated

Software Requirements Elicitation Process

Requirements elicitation process includes requirements gathering, requirement
organization, negotiation and discussion, and requirements specification.

Figure 13: The Software Requirements Elicitation Process

24
 a. Requirements Gathering. The developers discuss with the client and end-users
and know their expectations from the software
b. Organizing Requirements. The developers prioritize and arrange the
requirements in order of importance, urgency, and convenience.
c. Negotiation and Discussion. If the requirements are ambiguous or there are
some conflicts in requirements of various stakeholders, it is then negotiated and
discussed with the stakeholders. Requirements may be then prioritized and
reasonably compromised. The requirements come from various stakeholders. To
remove ambiguity and conflicts, they are discussed for clarity and correctness.
Unrealistic requirements are compromised reasonably.
d. Documentation. All formal and informal, functional and non-functional
requirements are documented and made available for next phase processing.

Requirements Elicitation Techniques

This process includes activities to find out the requirements for an intended
software system by communicating with client, system users, and others who have a
stake in the software system development. The following are the commonly used
techniques in requirements elicitation process.
a. Interviews. Interviews are strong medium to collect requirements. Organizations
may conduct several types of interviews such as structured (closed) interviews
where the information to be gathered is already identified. A pattern is followed in
conducting structured interview. On the other hand, unstructured or open
interviews are more flexible, less biased, and information to be gathered is not
yet identified before the conduct of interview. Oral interviews and written
interviews can also be done. In terms of dynamics, one-to-one interview or group
interviews may be done.
b. Survey. Organizations may conduct surveys among various stakeholders by
querying about their expectations and requirements from the upcoming system.
c. Questionnaire. It is a document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to answer, which are
collected and compiled. A disadvantage of this technique is, if an option for some
issue is not mentioned in the questionnaire, the issue might be left unattended.
d. Task Analysis. Members of the development team may analyze the operation
for which the new system is required. If the client already has some software to
perform certain operation, it is studied and requirements of proposed system are
collected.
e. Domain Analysis. Every software falls into some domain category. The expert
people in the domain can be a great help to analyze general and specific
requirements

25
 f. Brainstorming. It is an informal debate held among several stakeholders and all
their inputs are recorded for further requirements analysis
g. Prototyping. It is the process of building user interface without adding
functionality for user to interpret the features of intended software product. It
helps giving better idea of requirements.
h. Observation. Development team visits the client’s organization to observe the
actual working of the existing installed system. They also observe the workflow
and how execution problems are dealt. In this process, the team draws
conclusions which aid to form requirements from the software.

Software Requirements Characteristics

1. Clear
2. Correct
3. Consistent
4. Coherent
5. Comprehensive
6. Modifiable
7. Verifiable
8. Prioritized
9. Unambiguous
10. Traceable
11. Credible source

Categories of Software Requirements

1. Functional Requirements. These requirements are related to the functional
aspect of the software. They define functions and functionality within and from
the software system.
Examples:
a. Search option given to user to search from various invoices
b. User should be able to main any report to management
c. Users can be divided into groups and groups can be given
separate rights
d. Should comply business rules and administrative functions
e. Software is developed keeping downward compatibility intact
2. Non-Functional Requirements. Non-Functional Requirements are not related to
the functional aspect of the system. They are the implicit or expected
characteristics of software, which users make assumption of.
Examples:
a. Security
b. Logging

26
 c. Storage
d. Configuration
e. Performance
f. Cost
g. Interoperability
h. Flexibility
i. Disaster Recovery
j. Accessibility

Requirements are categorized logically as:

1. Must Have
2. Should Have
3. Could Have
4. Wish List

User Interface Requirements

User interface (UI) are important aspects of systems. A software is widely
accepted if it is easy to operate, quick in response, effectively handle operational errors,
and provide simple yet consistent UI. Since UI is the only way users perceive the
system, it is important that the system is equipped with attractive, clear, consistent, and
responsive user interface. Otherwise, the functionalities cannot be used effectively. A
system is said to be good if it provides the users means to effectively use it. The
following are the UI requirements:
1. Content presentation
2. Easy Navigation
3. Simple interface
4. Responsive
5. Consistent UI elements
6. Feedback mechanisms
7. Default settings
8. Purposeful layout
9. Strategical use of color and texture
10. Provide help information
11. User centric approach
12. Group based view settings

ASSESSMENT - QUIZ NO. 3 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

27
 LESSON 4
PROCESS MODELLING

INTRODUCTION
In the previous lesson, you learned about the relevance of requirements and the
ways on how to effectively collect and analyze them. In this lesson, you will learn more
about process modelling. Process modeling in application development helps the team
in deepening their understanding about the project at hand. It is important that you will
be able to construct your own process model like data flow diagram to convert the
requirements into meaningful model representation of the project.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. determine the importance of modelling in application development;
2. recognize what are process models;
3. identify the different essential components of data flow diagram; and
4. create a data flow diagram based on given specifications and requirements.

DISCUSSION

Modelling incorporates text and graphics and is used to develop information

systems. Examples include data models, dynamic models, object models, process
models, solution-based models, and workflow models. Modelling provides a common
set of graphic symbols, provides examples for imitation or comparison, provides a
blueprint about the solution to be developed, use to clarify concepts, identifies areas of
interest, decreases ambiguity or redundancy, decreases details or complexity, manages
complexity, and minimizes development cost.
Data models, process models, and dynamic models' goal is to explain a portion
of the customer’s problem or solution domain. When models are created, the focus is on
collecting the information that has the largest impact to the solution.

Process Models
Process models was formalized in the late 1970s. Process models specify the
essential processing requirements, that is, state what must be accomplish without
specifying the technology to accomplish it. It identifies the information needed for each
business event. Process models manage complexity by limiting the amount of detail at
each level. It enforces the business rules defined in the data model. Also, process
models minimize development cost by clearly defining customer processes and provide
necessary input to determine development cost.

28
 Process models define the functional behavior of a customer’s business.
Components include customer involvement wherein customer provide the business
knowledge, data, and data associations. Then, analyst capture the information using a
specific development approach to quickly convey important aspects of the customer’s
business to help understand the problems.

Data Flow Diagram

Data flow diagram depicts a set of processes and each process represents a
particular task or set of tasks that needs to be accomplished. Each component in the
DFD includes textual documentation that further explains its purpose. DFD is use to limit
and manage the complexity of the customer’s business.

Purpose of DFD
1. Defines the scope of the customer’s business processes.
2. Divides each process into less complex activities.
3. Facilitates a more detailed analysis of the processing requirement.
4. Specifies how the data is manipulated within the customer’s business functions.
5. Serves as an input for preparing the system’s behaviour.

Components of DFD

a. Process – also called as process bubble. It is illustrated as a circle on a data

flow diagram. It manipulates information and remains dormant until it receives

29
 data from a data flow or is triggered by a control flow. Process identifiers are
used on DFD to depict the relationship between the parent process and the child
process. It may be either complex or simple. Complex process performs more
than one function while simple process performs only one function.
b. Agent – illustrated as a square or rectangle and acts as a source, a sink or both.
It can be a person, group, organization, or other systems. It can be classified as
external agent and internal agent. Agent acting as a source provides information
to the application while agent acting as a sink receives information from the
application. Internal agents can only act as a source and send a control flow
c. Data flow – Illustrated as a directed continuous arc, comprises a set of
attributes. It describes the movement of information from one part of the
application to another. Data flow enters data stores, processes, and agents
acting as sources. These are used to carry data from an origin object to a
destination object. Also, data flow has descriptive label, usually a noun that
identifies the type and purpose of the information carried.
d. Control flow – Control flow is illustrated as a directed dashed arc which triggers
a process by notifying it that a certain condition has been met. It contains no
data. It is given a descriptive name that helps identify the purpose or the
business policy governing the trigger. Also, control flow triggers a process to take
action.
e. Junction – Junctions are illustrated as a solid dot, representing a process that
provides data to another process. It is depicted as a solid dot on one end of the
flow and must be used whenever both of the following conditions exists
1. A process provides input (data or control) to another process
2. The process that provides input to another process is a parent
process, or the process that receives input from a process in a parent
process
f. Data store – It is illustrated as two parallel lines that represents a group of like
information at rest. Data store represents a logical table from the data model.
The table can represent either an entity or a regular relationship that did not
create an associative entity. Data store cannot interact with a parent process.

ACTIVITY 4.1 (Suggested Mode of Delivery of Output: Google Form/Learning

Group/Learning Management System)
1. Based on the video presentation of yours containing the possible application
development project, construct the context diagram and the level 1 diagram of
your proposed project.

30
Process Specification

Process specification provides the details of how processes perform their

functions and describe specific steps performed by a process to achieve its expected
output. It is a description of specific steps performed by a process. It is a prescription for
solving a particular problem or achieving an expected response without regard to any
arbitrary sequencing requirements or to the details of how the problem or response is
solved. Also, it is written using a non-procedural language built on a set of structured
keywords.

Purposes of Process Specification

1. Verify understanding of a process with the customer.
2. Describe the data input, the junction performed and the data output for each
simple process.
3. Provide a basis for estimating the amount of development or maintenance work
in the project definition and project plan.
4. Serve as an input for preparing module specification.
5. Validate any previously developed data flow diagrams or processes.
6. Uncover additional functions that must be incorporated into the data flow
diagrams.
7. Serve as a checklist to record the tables accessed by the process.
8. Validate the data model in terms of logical table structure.
9. Define what must be done to achieve the expected process response.

Structured Nonprocedural Language

Process specifications are termed nonprocedural, meaning the solution should
be specified in terms of structures that are relevant to the problem, rather than the
operations or control structures that are specific to a particular physical target
environment. The structure of a process specifications may change slightly from one
method to another because of the vocabulary. This vocabulary enables other engineers
to easily and quickly understand the customer’s business.

31
Data Conservation
Every process should receive only the information that the process needs to
perform its function. If data passes through a process without contributing to the
operation of the process, the data should be removed from the data flows. To ensure
that the process adheres to data conservation, you must understand the purpose of the
process. It is important to make the data flow diagram more understandable by limiting
the data carried on its data flows to only the data needed by each process. Also,
provide the necessary information for the analyst to create the process specification.

Context Diagram
A context diagram is a data flow diagram that depicts the highest level of a
process model. It has only one process, and one or more external agents that either
provide information to or receive information from the process as indicated by the data
flows. Context Diagram is at the highest level of abstraction within the process model.
Context Diagram provides only a small understanding of the overall behavior of the
application’s functions.
Context diagram defines the boundary of focus, identify the information needed
to provide the information requested, and identify where the information is coming from
and where it is going to outside the boundary.

Rules in Context Diagram

1. It must have only one process illustrated to represent the logical grouping of the
business processes being analyzed.

32
 2. It must have at least one external agent, acting as a source, a sink or both. Also,
it may have more agents acting as a source, a sink or both.
3. It must have a data flow connecting each of the agents to the process. The
directions of the data flow indicate the role of the agent has with the process
(either as a source or as a sink) .

High Level Process Diagram (HLP)

HLP illustrates a process one level below the context diagram. It is a child
diagram of the context diagram. It corresponds directly to one event on the event
response list. HLP illustrates somewhat more detail than the context diagram, but for
only one event.
The high-level process diagram breaks the context diagram into manageable
pieces. It focuses on a particular event of the event-response list.

Rule in High Level Process Diagram

1. It must have one and only one process.
2. It must have one agent (internal and external), acting as source. Also, it may
have external agents acting as sinks.
3. It must have a flow (data or control) connecting each of the agents to the
process. The direction of the flow indicates the role the agents has with the
process (either as a source or as sink) .

Composite Event
A composite event is composed of two or more interrelated events. It identifies
when an additional process and input attributes are needed to direct which processes to
trigger or one of the incoming data flows is not expected to contain any data on the
initial triggering of the high-level process. When an additional process and input
attributes are needed to direct which tasks (process) to trigger, this attribute is a design
technique.

Intermediate Level Process

It represents a child process that is not simple process and that consists of two or
more child processes. Intermediate level process manages the detail of a data flow
diagram by reducing the number of processes illustrated on a level, increase the
readability of its parent process diagram, and decrease the complexity of its parent
process’ diagram. In constructing intermediate level process, it must be a child of a
parent process and it must have at least two child processes.

ASSESSMENT - QUIZ NO. 4 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

33
 LESSON 5
SOFTWARE DESIGN

INTRODUCTION
In this chapter, you will learn more about software design and the different
techniques and procedures use to perform the activities. Software design is more than
what the eyes can see, but also how the users can use and make it more relevant. It is
expected that in this lesson, you will be able to apply the learned concepts and
techniques to successfully construct the design of your own application.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. state the importance of software design in application development;
2. identify the different design steps; and
3. recognize the different design concepts and explain their importance.

DISCUSSION

Software design sits at the technical kernel of the software engineering process
and is applied regardless of the software process model that is used. The first of three
technical activities – design, code generation, testing – is required to build and verify the
software. It includes an iterative process through which requirements are translated into
a “blueprint” for constructing the software.

Figure 14: Application Design

34
ACTIVITY 5.1 (Suggested Model of Submission of Output: Email/Learning
Management System)
1. Thinking about your proposed application as the reference:
a. Construct the proposed entity-relationship diagram
b. Construct the proposed data flow diagram (Context Diagram and Level 1)
c. Construct the state-transition diagram

Design Steps
a. Data Design transforms the information domain model created during analysis
into the data structures that will be required to implement the software.
b. Architectural Design defines the relationship among major structural elements
of the program.
c. Interface Design describes how the software communicates within itself, to
systems that interoperate with it, and with humans who use it.
d. Procedural Design transforms structural elements of the program architecture
into procedural description of software components.

Design Concepts
1. Abstraction
2. Refinement
3. Modularity
4. Software architecture
5. Control hierarchy
6. Structural partitioning
7. Data structure
8. Software procedure
9. Information hiding

Levels of Abstraction
a. Procedural Abstraction is a named sequence of instructions that has a specific
and limited function.
b. Data Abstraction is a named collection of data that describes a data object.
c. Control Abstraction implies a program control mechanism without specifying
internal details.

Refinement
Stepwise refinement is a top-down design strategy originally proposed by Niklaus
Wirth. It is a process of elaboration. It causes the designer to elaborate on the original
statement, providing more and more detail as each successive refinement occurs.
Refinement helps the designer to reveal low-level details as design progress. It helps
the designer to reveal low-level details.

35
Modularity
It includes the division of software into separately named and addressable
components (modules) integrated to satisfy problem requirements. Modularity is the
single attribute of software that allows a program to be intellectually manageable.

Criteria to define an effective modular system

1. Modular decomposability
2. Modular composability
3. Modular understandability
4. Modular continuity
5. Modular protection

Software Architecture
Alludes to “the overall structure of the software and the ways in which that
structure provides conceptual integrity of the system”. The hierarchical structure of
program components (modules), the manner in which these components interact, and
the structure of the data that are used by the components.
Different models in architectural design
1. Structural model
2. Framework model
3. Dynamic model
4. Process model
5. Functional model

Control Hierarchy

It is also called program structure. Control hierarchy represents the organization

(often hierarchical) of program components (modules) and implies a hierarchy of
control. It does not represent procedural aspects of software such as sequence of
processes, occurrence/order of decisions or repetition of operations. It also represents
two subtly different characteristics of the software architecture: visibility and
connectivity.

36
Structural Partitioning
Horizontal partitioning defines separate branches of the modular hierarchy for
each major program functions while vertical partitioning, often called "factoring",
suggests that control (decision making) and work should be distributed top-down in the
program architectural. Benefits of horizontal partitioning includes: results in software
that is easier to test, leads to software that is easier to maintain, results in propagation
of fewer side effects, and results in software that is easier to extend.

37
Data Structure
Data structure is a representation of the logical relationship among individual
elements of data. It is as important as program structure to the representation of
software architecture. Data structures dictates the organization, methods of access,
degree of associativity, and processing alternatives for information. Its organization and
complexity are limited only be the ingenuity of the designer. A scalar item, the simplest
of all data structures, represents a single element of information that may be addressed
by an identifier. Vectors are the most common of all data structures and open the door
to variable indexing of information. When the sequential vector is extended to two, three
and ultimately, an arbitrary number of dimensions, an n-dimensional space (also called
"array") is created. A linked list is a data structure that organizes non-contiguous scalar
items, vectors or spaces in manner (called nodes) that enables them to be processed
as a list. For example, a hierarchical data structure is implemented using multi-linked
lists that contain scalar items, vectors and possibly n-dimensional spaces. Like program

38
structures, data structures can be represented at different levels of abstraction. For
example, a stack is a conceptual model of a data structure that can be implemented as
a vector or a linked list.

Software Procedure
Software procedure focuses on the processing details of each module
individually. It must provide a precise specification of processing including sequence o
of events, exact decision points, repetitive operations, and even data
organization/structure.

Information Hiding
In information hiding, modules should be specified and designed so that
information (procedure and data) contained within a module is inaccessible to other
modules that have no need for such information. It implies that effective modularity can
be achieved by defining a set of independent modules that communicate with one
another only, and that information is necessary to achieve software function. It defines
and enforces access constraints to both procedural detail within a module and any local
data structure used by the module.

Cohesion
Cohesion is a natural extension of the information hiding concept. A
cohesive module performs a single task within a software procedure, requiring
little interaction with procedures being performed in other parts of a program. It
may be represented as a “spectrum”. A module that performs a set of tasks that
relate to each other loosely, if at all, is termed coincidentally cohesive. A module
that performs tasks that are related logically is logically cohesive. When a module
contains tasks that are related by the fact that all must be executed within the
same span of time, the module exhibits temporal cohesion.

Figure 15: Cohesion

39
 Coupling
Coupling is a measure of interconnection among modules in a program
structure. It may also be represented on a spectrum. Coupling depends on the
interface complexity between modules, the points at which entry or reference is
made to a module, and what data pass across the interface. At moderate levels,
coupling is characterized by passage of control between modules.

Figure 16: Coupling

Data Design
Data design is the first of four design activities that are conducted during
software engineering and application development. The impact of data structure on
program structure and procedural complexity causes it to have a profound influence on
software quality. Its primary activity is to select logical representations of data objects
(data structures) identified during the requirements definition and specification phase.
The important related activity is to identify those program modules that must operate
directly upon the logical data structure.

Principles for data specification

a. The systematic analysis principles applied to function and behavior should
also be applied to data.
b. All data structures and the operations to be performed on each should be
identified.
c. A data dictionary should be established and used to define both data and
program design.
d. Low level data design decisions should be deferred until late in the design
process.
e. The representation of data structure should be known only to those modules
that must make direct use of data contained within the structure.
f. A library of useful data structures and the operations that may be applied to
them should be developed.
g. A software design and programming language should support the
specification and realization of abstract data types.

40
Architectural Design
Architectural Design is the initial design process of identifying these subsystems
and establishing a framework for subsystem control and communication. Its objective is
to develop a modular program structure and represent the control relationships between
modules. It melds program structure and data structure, defining interfaces that enables
data to flow throughout the program. Architectural design maybe based on a particular
architectural model or style.

Five step process to accomplish the transition from information flow to

structure:
1. The type of information flow is established.
2. The boundaries are indicated.
3. The DFD is mapped into program structure.
4. Control hierarchy is defined by factoring.
5. The resultant structure is refined using design measures and heuristics.

Interface Design
It focuses on three areas of concern: the design of interfaces between software
modules; the design of interfaces between the software and other nonhuman producers
and consumer’s information; and the design of the interface between a human (the
user) and the computer.
The design of internal program interfaces, sometimes called intermodular
interface design, is driven by the data that must flow between modules and the
characteristics of the programming language in which the software is to be
implemented.

Procedural Design
Occurs after data, architectural and interface designs have been established. It
must specify procedural detail unambiguously. Its foundation was formed in the early
1960s and was solidified with the work of Edsgar Dijktra and his colleagues. They
proposed the use of a set of existing logical constructs from which any program could
be formed. Constructs of procedural design are the following: sequence – implements
processing steps that are essential in the specification of any algorithm; condition –
provides the facility for selected processing based on some logical occurrence; and
repetition – provides for looping.

ASSESSMENT - QUIZ NO. 5 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

41
 LESSON 6
APPLICATION AND SOFTWARE PROTOTYPING

INTRODUCTION
In this lesson, you will be able to learn about prototyping and its relevance in
software and application development. Prototyping has different forms and types and
these will be discussed in this lesson. After this lesson, you will be making your own
prototype based on the models and requirements you have from the previous lesson of
this learning module.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. identify what is a prototype, the benefits of prototyping, and the advantages of
prototyping;
2. compare and contrast the different types of prototyping;
3. construct prototype of the proposed application project.

DISCUSSION

A prototype is an early sample, model, or release of a product built to test a

concept or process. It is a term used in a variety of contexts, including semantics,
design, electronics, and application development and software programming. A
prototype is generally used to evaluate a new design to enhance precision by system
analysts and users. A prototype is a draft version of a product that allows you to explore
your ideas and show the intention behind a feature or the overall design concept to
users before investing time and money into development. A prototype is a simple
experimental model of a proposed solution used to test or validate ideas, design
assumptions, and other aspects. It is a partial implementation of a product expressed
either logically or physically with all external interfaces presented. Also, a prototype
typically simulates only a few aspects of, and may be completely different from, the final
product.

SOFTWARE AND APPLICATION PROTOTYPE

A software or application prototype is an executable model of the proposed
software system or application. It must be producible with significantly less effort than
the planned product. Software prototyping is the activity of creating prototypes of
software applications i.e. incomplete versions of the software program being developed.
It is an activity that can occur in software and application development and is
comparable to prototyping as known from other fields, such as mechanical engineering

42
or manufacturing. The degree of completeness and the techniques used in prototyping
have been in development and debate since its proposal in the early 1970s.
Benefits of Prototyping
1. The software designer and implementer can get valuable feedback from the
users early in the project.
2. The client and the contractor can compare if the software made matches the
software specification according to which the software program is built.
3. It also allows the software or application engineer some insight into the accuracy
of initial project estimates and whether the deadlines and milestones proposed
can be successfully met.

Advantages of Prototyping
1. Collect feedback from users/ stakeholders about the functionality of the product
before the public release.
2. Reveal areas for improvement and help identify faults and usability issues before
the public release. Help reduce unnecessary costs.
3. Improve team efficiency and collaboration.
4. Allow the user to interact with a working model of their product.
5. Help convert an abstract idea into a tangible product in a cost-effective way.
6. Identify if your product idea is a weak one and cost you heavily before actually
moving forward with it.

Types of Prototyping
1. Low Fidelity Prototypes
 Wireframes are used to
represent the basic structure of
a website/ web page/ app. It
serves as a blueprint,
highlighting the layout of key
elements on a page and its
functionality.

43

Figure 17: Wireframes

 Storyboards are another low-fidelity prototyping method that helps
visualize the user’s experience in using your product or how the user would
interact with your product.

Figure 18: Storyboards

 Diagrams are multiple diagram types that can help you visualize different
aspects of a product, which can in turn help you optimize your prototype
such as mind maps, customer journey maps, and flowcharts.

Figure 19: Diagrams

44
  Animation can be used to visualize how your product works. For example,
if it is a mobile app, you can animate how a user would navigate from one
screen to the other. This will help the stakeholders or users get an idea
about the functionality of the product.

2. High Fidelity Prototypes

 Interactive UI Mockups. A UI mockup is a more fleshed-out version of
the wireframe. It represents the color schemes, typography and other
visual elements that you have chosen for the final product.

Figure 20: Interactive UI Mock-ups

 P
hysical Models. If the final product is a physical one, you can use different
materials to create a model that represents the final look, shape and feel of
the product. You can use materials such as cupboards, rubber, clay etc.

 Wizard of OZ Prototyping. This is a type of prototype with faked

functions. This means when a user interacts with the product, the system
responses are generated by a human behind the scene rather than by a
software or code. This prototyping technique allows you to study the
reaction of the user at a lesser cost.

45
The Prototyping Process
1. Identify Obstacles.
2. Select the Features.
3. Sketch Your Design.
4. Share Your Design.
5. Continue to Develop.

ACTIVITY 7.1 (Suggested Mode of Submission of Requirements: Email/Learning

Management System)
Choose among the presented types of prototyping techniques and develop the
prototype of your proposed project. The prototype must showcase your creativity in
designing the UI of your proposed project.

ASSESSMENT - QUIZ NO. 7 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

46
 LESSON 7
SOFTWARE QUALITY ASSURANCE

INTRODUCTION
Quality is what software development team always look at. Teams must be able
to produce quality output to provide significant impact in an organization, business
entities, and individuals. In this lesson, you will learn more about the importance of
quality, and software quality in particular. Output of this lesson is a continuation of the
output produced from the previous lesson.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. recognize what is software quality assurance and its importance;
2. differentiate quality control and quality assurance;
3. explain the different factors affecting software quality; and
4. demonstrate understanding on the different software quality metrics

DISCUSSION

Software Quality Assurance (SQA) is an umbrella activity that is applied

throughout the software engineering process. It is an error-prevention technique that
focuses on the process of systems and software development. It is a planned and
systematic pattern of actions that are required to ensure quality in software. SQA
encompasses:
1. analysis, design, coding and testing methods and tools
2. formal technical reviews that are applied during each software engineering step
3. a multi-tiered testing strategy
4. control of software documentation and the changes made to it
5. a procedure to assure compliance with software development standards
6. measurement and reporting mechanism

SQA is often thought of as a software testing activity – WRONG

If quality is not part of a product prior to testing, it will not be part of the product
after testing is completed. SQA must be part of Software Engineering from the
beginning

The goals of SQA

1. To improve software quality by monitoring both the process and the product.
2. To ensure compliance with all local standards for SE.
3. To ensure that any product defect, process variance, or standards non-

47
 compliance is noted and fixed.

Quality Control Vs. Quality Assurance

 Quality control is about work product; quality assurance is about work process.
 Quality control activities are work-product oriented. They measure the product,
identify deficiencies, and suggest improvements. The direct result of these
activities are changes to the product. These can range from single-line code
changes to completely reworking a product. It is an error-removal technique.
Quality assurance activities are work-process oriented. They measure the
process, identify deficiencies, and suggest improvements. The direct result of
these activities are changes to the process. These changes can range from
better compliance with the process to entirely new processes. The output of
quality control activities is often the input to quality assurance activities.

Software Quality
Conformance to explicitly stated functional and performance requirements,
explicitly documented development standards and implicit characteristics are
expected of all professionally develop software.

An alternative definition by W. Edwards Deming

Striving for excellence in reliability and functions by continuous (process)
improvement, supported by statistical analysis of the causes of failure

Three (3) important points to remember on software quality

1. Software requirements are the foundation from which quality is measured. Lack
of conformance to requirements is lack of quality.
2. Specified standards define a set of development criteria that guide the manner in
which software is engineered. If the criteria are not followed, lack of quality will
almost surely result.
3. There is a set of implicit requirements that often goes unmentioned (e.g., the
desire for good maintainability) if software conforms to its explicit requirements,
but fails to meet implicit requirements.

Quality Characteristics
These refer to any property or element that can be used to define the nature of a
product. Each characteristic can be physical or chemical properties such as size,
weight, volume, color or composition.

Software Quality
1. It is achieved through a disciplined approach - called software engineering

48
 SE.
2. It can be defined, described, and measured.
3. It can be assessed before any code has been written.
4. It cannot be tested into a product.

Software quality challenges

1. Defining it.
2. Describing it (qualitatively).
3. Measuring it (quantitatively).
4. Achieving it (technically).

Designing software is a creative task, and like most such tasks, success is more
likely if the designer follows what might be termed a set of rules of form. The rules of
form also provide some way of assessing the quality of the eventual product, and
possibly of the processes that led to it.

Quality example

Music provides a good analogy: we could

write music by scattering notes around at
random, but we would get a better result if we
considered melody and harmony

Awful Bearable Good Extremely good

My music Beethoven’s music

How do we scale this?

Figure 21: Quality Example

In his book Quality Is Free, Philip Crosby suggests an analogy between quality and sex:
1. Everyone is for it, except in certain situations.
2. Everyone believes they understand it, but they don’t want to explain it.

49
 3. Most people believe the execution is merely a matter of following natural
inclinations.
4. Everyone believes that problems with it are always someone else’s fault.

REALISING QUALITY

A set of abstract quality factors (‘the ilities’) has been defined. These cannot be
measured directly but do relate to the ultimate goal.

Mapped Realized Measured

On to Through By

Quality factors Quality Measurable Counts

(ilities) Quantity from
criteria
designs
Figure 22: Model of Realizing Quality

Software Quality Factors (by McCall)

1) Product Revision (changing it)
 Flexibility (can I change it?)
The effort required to modify an operational program. Change and
enhancement of the system should be easily implementable.
 Maintainability (can I fix it?)
The effort required to locate and fix an error in a program. The system
should be easy to keep up for its intended use. Changes for improving
operational efficiency should be easy to implement. Failed operations should
be easy to restore to satisfactory condition.
 Testability (can I test it?)
The effort required to test a program to ensure that it performs its intended
function. The ability of the system to produce quality product units should be
easily testable. Useful messages should be generated for testing and
debugging purposes.

2) Product Transition (modifying it to work in a different environment)

 Interoperability (Will I be able to interface it with another system?)
The effort required to couple one system to another.
 Portability (Will I be able to use it on another machine?)
The effort required to transfer the program from one hardware and/or
software system environment to another. The system should be portable
among people and among machines. Attainment of the other quality
characteristics greatly facilitates portability.
 Reusability (Will I be able to reuse some of the software?)

50
 The extent to which a program (or part of a program) can be reused in
other applications-related to the packaging and scope of the functions that the
program performs.

3) Product Operations (using it)

 Correctness (Does it do what I want?)
The extent to which a program satisfies its specification and fulfills the
customer’s mission objectives. The extent to which software is free from
design defects and from coding defects; that is fault-free.
 Reliability (Does it do it accurately all of the time?)
The extent to which a program can be expected to perform its intended
function with required precisions under stated conditions for a stated period of
time.
 Efficiency (Will it run on my hardware as well as it can?)
The extent to which a software performs its function with a minimum
consumption of computing resources. It should not use any hardware
components or peripheral equipment unnecessarily.
 Integrity (Is it secure?)
The extent to which access to software or data by unauthorized persons
can be controlled.
 Usability (Is it designed for the use?)
The effort required to learn, operate, prepare input, and interpret output of
a program.

Quality Metrics
Provides an indication of how closely software conforms to implicit (essential)
and explicit (specific) requirements.
 Auditability refers to the ease with which conformance to standards can be
checked.
 Accuracy is the precision of computations and control. A qualitative
assessment of freedom from error. A quantitative measure of the magnitude
of error. The correct data values are recorded.
 Communication commonality is the degree to which standards interfaces,
protocols, and bandwidths are used.
 Completeness is the degree to which full implementation of required function
has been achieved. All data items are captured and stored for use. Data
items are properly identified with time periods.
 Conciseness is the compactness of the program in terms of lines code.
 Consistency is the use of uniform design and documentation techniques
throughout the software development project.

51
  Data commonality is the use of standard data structures and types throughout
the program.
 Error tolerance is the damage that occurs when the programs encounters an
error. Suitable error prevention and detection procedures are in place. There
are procedures for reporting and correcting errors. Various audit procedures
are applied.
 Execution efficiency refers to the run-time performance of a program.
 Expandability is the degree to which architectural, data, or procedural design
can be extended.
 Generality refers to the breadth of potential application of program
components.
 Hardware independence is the degree to which the software is decoupled
from the hardware on which it operates.
 Instrumentality is the degree to which the program monitors its own operation
and identifies errors that do occur.
 Modularity refers to the functional independence of program components.
 Operability refers to the ease of operation of a program.
 Robustness is the extent to which software can continue to operate correctly
despite the introduction of invalid inputs
 Security is the availability of mechanism that control or protect programs and
data. The system and its operations are protected from various environmental
and operation risks. There are provisions for recovery in the event of failure or
destruction of part or all system
 Self-documentation is the degree to which the source code provides
meaningful documentation.
 Simplicity is the degree to which a program can be understood without
difficulty.
 Software system independence refers to the degree to which the program is
independent of nonstandard programming language features, operating
system characteristics, and other environmental constraints.
 Traceability refers to the ability to trace a design representation or actual
program component back to requirements.
 Training is the degree to which the software in enabling new users to apply
the system.

Laws of software evolution dynamics (by Belady and Lehman):

1. Law of continuing Change (self-evident). It is a large program that is being
used undergoes continuing change until it is judged more cost-effective to rewrite
it. Software over time must be changed not only to repair errors that are

52
 discovered, but also to incorporate enhancements to adapt to new hardware
systems and changing environment.
2. Law of Increasing Entropy (intuitive). The entropy (disarray) of a system
increases with time unless specific work is done to maintain it or to reduce it.
Continuous changes made to a system tend to destroy the integrity of the system
thus increasing entropy.
3. Law of Statistically-Smooth Change (controversial). Measures of a global
system attributes and project attributes may appear quite irregular for a particular
system, but are cynically self-regulating, with statistically identifiable invariance
and well-defined long-range trends. Work input or the effort expended per unit
time, remained constant over the lifetime of the system.

SQA ACTIVITIES
1. Application of technical methods
The use of technical tools and methods helps analyst to achieve high quality
specification and the designer to develop a high-quality design

2. Conduct of formal technical reviews (FTR)

Reviews are another quality control activity. Again, reviews are held to find
defects in a work product. The result is changes to the work product. Over time, the
collection of these changes may induce process changes, but that is not necessary.
a. To uncover errors in function, logic or implementation for any representation of the
software
b. To verify if software meets requirements
c. To ensure that software has been presented according to pre-defined standards.
d. To achieve software that is developed in a uniform manner
e. Make projects more manageable.

It is not the task of team to correct faults, but merely to record them
for later correction.

Defect found early in the software life cycle can be repaired at much less
expense than later in the life cycle.

Types of Reviews
1) Walk through is an interactive process to evoke questions and discussions

Time limit - 2 hours SQA , participants : 4 - 6, senior tech. staff

Ways to conduct walk through:

53
 a) Participant - driven
 Each participant goes through his or her list of unclear items which
may appear incorrect.

b) document-driven
 A person responsible for the document walks the participants
through that document, with the reviewers in everything either with
their prepared comments or comments triggered by the
presentation

2) Inspection (goes far beyond walk through)

Formal steps of inspection

a) An overview of document is given to participants.
b) Participants prepare for inspection, aided with lists of fault types
previously found.
c) Inspection - every piece of logic is covered at least once, and every
branch is taken at least once. Written report of inspection is produced.
d) Rework - resolves all faults and problems noted in written report.
e) Follow-up ensures that every single issue raised has been
satisfactorily resolved.

Review Guidelines
1. Review the product, not the producer.
2. Set an agenda and maintain it.
3. Limit debate and rebuttal.
4. Enunciate problem areas, but do not attempt to solve every problem noted.
5. Take written notes.
6. Limit the number of participants and insist upon advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8. Allocate resources and time schedule for FTRs.
9. Conduct meaningful training for all reviewers.
10. Review your early reviews.

3. Software testing
Software testing is the activity or running software to find errors in the
software. The direct output of testing results in product changes. A study of these
changes may result in process changes, but this is not necessary. Thus, testing
is a quality control activity. It combines a multi-step strategy with a series of test

54
 case design methods that help ensure effective error detection. Program testing
can be very effective way to show the presence of bugs but it is hopelessly
inadequate for showing their absence

4. Enforcement of standards
SQA must be established to ensure that standards are being followed. An
assessment of compliance to standards must be conducted

5. Control of change
Every change to software has the potential for introducing error or creating
side effects that propagate errors. Request for change must be formalized-
evaluate the nature of change, and control the impact of change.

6. Measurement
To track software quality and assess impact of changes to software
quality.

7. Record keeping and reporting

Provide procedures for the collection and dissemination of SQA
information.

Software Quality and Productivity: What Top Management Must Do

A. Create constancy of purpose to increase software quality and productivity

with a plan to become competitive and to stay in business. Top management is
responsible to the general public, especially the software users whose
satisfaction is the supreme justification for the existence of a software business.

B. Adopt the new philosophy of quality and cost-effective software with the
understanding that we can no longer live with delays, mistakes, poor quality and
costly software.

C. Cease dependence on conventional software methods, requiring, instead of

statistical evidence that software quality is built in the eliminate need for
inspection and correction on the job where the software is used. Top
management of every computer and software developer and User Company has
a new job and must learn it. Every user company can now demand meaningful
software warranty using statistical quality control. Every developer company
must now show credibility by delivering software warranty.

55
D. End the practice of awarding software business on a lowest cost basis,
demanding, instead, that meaningful measures of quality along with price.
Software developers who cannot qualify with statistical evidence of quality must
be eliminated.

E. Find problems. Management must work continually on improving software

practices: training, supervision, retraining, and improvement of software
development methodologies using statistical methods.

F. Institute modern methods and rigorous programs of training in software

engineering and quality assurance with statistical quality control.

G. Institute modern methods of supervision of software personnel. The

responsibility of software personnel must change from sheer numbers to both
numbers and quality. Achievement of quality will automatically increase
productivity.

H. Drive out fear so that everyone in a software company will work effectively.

I. Break down barriers among departments. Personnel in research, design,

development, sales, and production must work as a team to foresee problems of
software development.

J. Create a structure in top management that will direct and control every day
on the above nine points.

ACTIVITY 8.1 (Suggested Mode of Submission of Output: Email/Google

Form/Learning Management System)
1. Write at least 500-word insight on the importance of software quality
assurance, its impact to application development, and the need to further
improve the quality of applications and software in the new normal. Your
insight paper will be assessed based on content and relevance to the topic
(30 points), organization of thoughts and clarity (20 points).

ASSESSMENT - QUIZ NO. 8 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

56
 LESSON 8
SOFTWARE TESTING

INTRODUCTION
In the previous lesson, you learned about software quality assurance and its
fundament concepts. In this lesson, you will learn more about software testing and the
different software testing techniques and activities you may conduct in developing your
application project. At the end of the lesson, you are expected to conduct software
testing activities in your proposed project application.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to:
1. identify what is software testing and its importance in software and application
development;
2. compare and contrast different software testing techniques; and
3. construct understanding on how to evaluate and apply proper and appropriate
testing techniques.

DISCUSSION

Software testing is a critical element of software quality assurance that

represents the ultimate review of specification, design and coding. It is a series of tests
cases that are intended to “demolish” the software that has been built are created.
Software testing is one step in the software engineering processes that could be viewed
as destructive rather than constructive. It requires that the developer discard
preconceived notions of the “correctness” of software just developed and overcome a
conflict of interest that occurs when errors uncovered.

Testing is a process of executing a program with the intent of finding an error. A

good test is one that has a high probability of finding an as-yet undiscovered error. A
successful test is one that uncovers an as-yet undiscovered error.

Testing Principles
a. All tests should be traceable to customer requirements.
b. Tests should be planned long before testing begins.
c. The Pareto Principle applies to software testing.
d. Testing should begin “in the small” and progress toward testing “in the large”.
e. Exhausting testing is not possible.
f. To be most effective, testing should be conducted by an independent third party.

57
Testability
Testability is simply how easily a computer program can be tested. It is important
to consider that it pays to know what can be done to streamline it. Testability is
sometimes used to mean how adequately a particular set of tests will cover the product.

Set of characteristics that lead to testable software

a. Operability
b. Observability
c. Controllability
d. Decomposability
e. Simplicity
f. Stability
g. Understandability

Software Testing Strategies

It provides a road map for the software developer, the quality assurance
organization, and the customers. It incorporates test planning, test case design, test
execution and resultant data collection and evaluation. Strategies should be flexible
enough to promote the creativity and customization that are necessary to adequately
test all large software-based systems. It must be rigid enough to promote reasonable
planning and management tracking as the project progresses.

Characteristics of Testing Strategies

a. Testing begins at the module level and works “outward” toward the integration
of the entire computer-based system.
b. Different testing techniques are appropriate at different points in time.
c. Testing is conducted by the developer of the software and an independent
test group.
d. Testing and debugging are different activities, but debugging must be
accommodated in any testing strategy.

Testing Techniques
Softwaretestinghelp.com presents the different testing techniques as follows:
1. Functional Testing
b. Unit Testing
Testing of an individual software component or module is referred to as
Unit Testing. Typically, this is done by the programmer and not by the tester,
as it requires detailed knowledge of the internal program design and code. It
may also require test driver modules or test harnesses to be developed.

58
c. Integration Testing
Testing of all integrated modules to verify the combined functionality after
integration is referred to as integration testing. Modules are typically code
modules, individual applications, network client and server applications, etc.
This type of testing is particularly relevant for the client/server and distributed
systems.

d. System Testing
The entire system is tested according to the requirements of the System
Testing technique. It is a Black-Box type of testing that is based on the over-
all requirements and covers all the combined parts of the system.

e. Sanity Testing
Sanity Testing is done to determine whether or not a new software version
is performing well enough to accept it for a major test effort. If the application
crashes for initial use, the system is not stable enough for further testing. As a
result, a build or application is assigned to fix it.

f. Smoke Testing
Whenever a new build is provided by the development team, the Software
Testing team validates the build and ensures that there is no major issue. The
testing team ensures that the design is stable and that further detailed testing
is carried out. Smoke Testing checks that there is no show stopper defect in
the build that prevents the testing team from testing the application in detail.
If testers find that the major critical functionality is broken down at the initial
stage itself, then testing team can reject the build and inform accordingly to
the development team. Smoke Testing is carried out to a detailed level of any
Functional or Regression Testing.

g. Interface Testing
The objective of this GUI Testing is to validate the GUI as per the
business requirement. The expected GUI of the application is mentioned in
the Detailed Design Document and GUI mockup screens. The GUI Testing
includes the size of the buttons and input field present on the screen,
alignment of all text, tables, and content in the tables. It also validates the
menu of the application, after selecting different menu and menu items. It
validates that the page does not fluctuate and the alignment remains same
after hovering the mouse on the menu or sub-menu.

59
 h. Regression Testing
Testing an application as a whole for the modification in any module or
functionality is termed as Regression Testing. It is difficult to cover all the
system in Regression Testing, so typically Automation Testing Tools are used
for these types of testing.

i. Beta/Acceptance Testing
Beta Testing is a formal type of Software Testing which is carried out by
the customer. It is performed in the Real Environment before releasing the
product to the market for the actual end-users. Beta Testing is carried out to
ensure that there are no major failures in the software or product and that it
satisfies the business requirements from an end-user perspective. Beta
Testing is successful when the customer accepts the software. Usually, this
testing is typically done by end-users or others. It is the final testing done
before releasing an application for commercial purpose. Usually, the Beta
version of the software or product released is limited to a certain number of
users in a specific area. So, end-user actually uses the software and shares
the feedback to the company. Company then takes necessary action before
releasing the software to the worldwide.

2. Non-Functional Testing
a. Performance Testing
This term is often used interchangeably with ‘stress’ and ‘load’
testing. Performance Testing is done to check whether the system meets the
performance requirements. Different performance and load tools are used to
do this testing.

b. Load Testing
Load Testing is a type of Non-Functional Testing whose objective is to
check how much load or maximum workload a system can handle without any
performance degradation. Load Testing helps to find the maximum capacity
of the system under specific load and any issue that causes software
performance degradation. Load testing is performed using tools like JMeter,
LoadRunner, WebLoad, Silk performer, etc.

c. Stress Testing
This testing is done when a system is stressed beyond its specifications in
order to check how and when it fails. This is performed under heavy load like
putting large number beyond storage capacity, complex database queries,
and continuous input to the system or database load.

60
d. Volume Testing
Volume Testing is a type of Non-Functional Testing performed by the
Performance Testing team. The software or application undergoes a huge
amount of data and Volume Testing checks the system behavior and
response time of the application when the system came across such a high
volume of data. This high volume of data may impact the system’s
performance and speed of the processing time.

e. Security Testing
It is a type of testing performed by a special team of testers. A system can
be penetrated by any hacking way. Security Testing is done to check how the
software or application or website is secured from internal and external
threats. This testing includes how much software is secured from the
malicious program, viruses and how secured and strong the authorization and
authentication processes are. It also checks how software behaves for any
hacker's attack and malicious programs and how software is maintained for
data security after such a hacker attack.

f. Compatibility Testing
It is a testing type in which it validates how software behaves and runs in a
different environment, web servers, hardware, and network environment.
Compatibility testing ensures that software can run on a different
configuration, different database, different browsers, and their versions.
Compatibility testing is performed by the testing team.

g. Install Testing
Installation and Uninstallation Testing is done on full, partial, or upgrade
install/uninstall processes on different operating systems under different
hardware or software environment.

h. Recovery Testing
It is a type of testing which validates how well the application or system
recovers from crashes or disasters. Recovery Testing determines if the
system is able to continue the operation after a disaster. Assume that
application is receiving data through the network cable and suddenly that
network cable has been unplugged. Sometime later, plug the network cable;
then the system should start receiving data from where it lost the connection
due to network cable unplugged.

61
 i. Usability Testing
Under Usability Testing, User-friendliness check is done. The application
flow is tested to know if a new user can understand the application easily or
not, Proper help documented if a user gets stuck at any point. Basically,
system navigation is checked in this testing.

Verification and Validation

Verification refers to the set of activities that ensures that software correctly
implements a specific function. Validation refers to a different set of activities that
ensures that the software that has been built is traceable to customer requirements
Verification: “Are we building the product right”
Validation: “Are we building the right product”

ACTIVITY 9.1 (Suggested Mode of Submission of Output: Google Form/Learning

Management System)
1. Based on your own understanding, which two functional and two non-
functional type of testing techniques are the most effective? Justify your answers.
Support your answers with articles. Limit your answer in not more than 500-words.

ASSESSMENT - QUIZ NO. 9 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

62
 LESSON 9
SOFTWARE MAINTENANCE

INTRODUCTION
In the delivery of software applications, software maintenance plays an important
role to continuously enhance and improve the implemented and deployed application. In
this lesson, you will learn the important concepts about software maintenance and will
guide you on how to conduct the processes required to maintain an application.

LEARNING OBJECTIVES
At the end of the lesson, you must be able to
1. define what is software maintenance and recognize the different types of
software maintenance activities;
2. identify the different quantities measures of software maintenance; and
3. propose software maintenance activities for a project.

DISCUSSION

Software Maintenance was characterized as an “iceberg”. It is a process of

changing a system after it has been delivered and is in use. There are four different
types. This includes corrective maintenance, adaptive maintenance, perfective
maintenance, and preventive maintenance.
 Corrective Maintenance
o Diagnosis and correction of one or more errors
 Adaptive Maintenance
o Modifies software to properly interface with a changing environment
 Perfective Maintenance
o Performed to satisfy requests from users (e.g., recommendations for new
capabilities, modifications to existing functions and general enhancement)
o Accounts for majority of all effort expended on software maintenance
 Preventive Maintenance
o Occurs when software is changed to improve future maintainability or
reliability or to provide a better basis for a future enhancement
o Characterized by reverse engineering and re-engineering techniques

Maintainability is the ease in which software can be understood, corrected,

adapted and/or enhanced. Controlling factors of maintainability includes the following:
1. Availability of qualified software staff.
2. Understandable system structure.
3. Ease of system handling.

63
 4. Used of standardized programming language.
5. Used of standardized operating systems.
6. Standardized structure of documentation.
7. Availability of test cases.
8. Built in debugging facilities.
9. Availability of proper computer to conduct maintenance.

Quantitative Measures:
1. Problem recognition time
2. Administrative delay time
3. Maintenance tools collection time
4. Problem analysis time
5. Change specification time
6. Active correction (or modification time)
7. Local testing time
8. Global testing time
9. Maintenance review time
10. Total recovery time

Maintenance Tasks
1. Establish a maintenance organization (de facto or formal).
2. Describe reporting and evaluation procedures.
3. Define sequence of events for each maintenance request.
4. Establish a record-keeping procedure for maintenance activities.
5. Define review and evaluation criteria.

64
Reverse Engineering
Reverse Engineering is the process of analyzing a program in an effort to create
a representation of the program at a higher level of abstraction than source code. It is a
process of design recovery. These are the tools used to extract data, architectural and
procedural design information from an existing program. Reverse engineering can
extract design information from source code, but the abstraction level, the completeness
of the documentation, the degree to which tools and a human analyst work together and
the directionality of the process are highly variable.

Figure 23: Reverse Engineering

Reengineering
Reengineering is also called "renovation" or "reclamation." Reengineering takes
time and it costs significant amounts of money, and absorbs resources that might be
otherwise occupied on immediate concerns. It is an activity that will absorb information
technology resources for many years. Typically, it is considered as a rebuilding activity.

65
 This activity not only recovers design information from existing software but uses
this information to alter or reconstitute the existing system in an effort to improve overall
function of the existing system (the software developer also adds new functions and/or
improves overall performance).

Figure 24: Reengineering Cycle

ACTIVITY 9.1 1 (Suggested Mode of Submission of Output: Google Form/Learning

Management System)
1. Construct a 500-word essay on how you plan to implement maintenance
activities for your proposed project. Brainstorm with your teammates but
construct and draw insights individually based on the outcomes of your
meeting.

ASSESSMENT – QUIZ 10 (Suggested Mode of Delivery of Assessment: Google

Form/Quizziz/Learning Management System)

66
REFERENCES

Pressman, R. (2005). Software Engineering: A Practitioner’s Approach. McGraw-Hill

Higher Education. 007301933X, 9780073019338

Software Testing Help (2020). Types of Software Testing: Different Testing Types with
Details. Retrieved at https://www.softwaretestinghelp.com/types-of-software-
testing/

RenierBrotha (2019). Techniques. Retrieved at https://renierbotha.com/tag/techniques/

TutorialsPoint (n.d). Software Engineering – Quick Guide. Retrieved at

https://www.tutorialspoint.com/software_engineering/software_engineering_quick
_guide.htm

67