1

PROG 301
Application Development and
Emerging Technologies
 2

STUDENT
Name:
Student Number:
Program:
Section:
Home Address:
Email Address:
Contact Number:

PROFESSOR
Name:
Academic Department:
Consultation Schedule:
Email Address:
Contact Number:
 3

LEARNING MODULE GUIDELINES

At CCC-DCE you learn through self-instructional modules, otherwise known as DCE Self-
Learning modules of DCEModL such as the one that you are now reading. It is significant that
you observe the following instructions:
1. Every student or course has a total of three (3) modules, each one might contain two or
more lessons. You must complete and satisfy the work prescribed by each module before
you can sit for the written examination that will determine if you pass or fail the course.
2. Make an effort to do some extra reading on any reference book on the subject (online or
offline) will do.
3. Test your own progress by performing the enrichment activities/application provided by
each lesson. Read the instructions very carefully and understand them well.
4. Consultation will be entertained by your professors through Facebook Messenger from
Monday to Friday (8-3pm) or as advised by your professors. Strictly follow the schedule
of consultations.
5. At the end of each module, perform and accomplish the Assessment Test.
6. Enrichment Activities/Application and Assessment Test with answers will be collected
periodically (sealed in long brown envelope signed across the flap and properly label it
with your name and year & section) and submit to the Office of the Director of the
Department of Computer Education (DCE), Baretto St., Brgy VII, Calamba City, Laguna,
for correction and grading. Corrected tests will be returned to you with the corresponding
grade or further instruction, if needed. While waiting, go on to the next module and observe
the same study procedure.
7. When you have accomplished all the modules of the course you are enrolled, you have to
come to CCC to take the written examination in person.
********************************DISCLAIMER********************************
No reproduction of any part of the module may be used, sold or distributed for commercial
purposes or be changed or included in any other Colleges and Universities, work or publication,
whether in print or electronic, including sending, publishing or incorporating them to another
module unless prior permission has been granted.

Modules are reviewed, evaluated and checked by:

Dr. Regina G. Almonte Ms. Jesse Ann Salvador

Content Editor Technical Editor
Director, DCE Faculty Member, DCE
 4

LEARNING MODULE INFORMATION

i. Course Code PROG301

II. Course Title Application Development and Emerging Technologies
III. Module Number 1
IV. Module Title Understanding the basis of principles of a Software
V. Overview of the Module This module will allow the reader to understand the importance
of requirements gathering in software development. With this
module, students would be able to determine kinds of
requirements specifications in software development and
demonstrate data gathering techniques and its guidelines. In the
end, readers would be able to present requirements gathering
framework as baseline for software development.
VI. Module Outcomes
As for the outcome of the module, you are about to
 Learn on how to interpret a data
 Learn different ways on how to manage a data.
 Describe the requirements analysis process and
techniques
 Use the correct usability testing method for a software
development
 Distinguish a proper deployment plan based on real-life
scenarios.
 5

LESSON 1. WHAT IS A SOFTWARE?

Lesson Objectives:
At the end of this lesson, you will be able to:
1. Define what is a software and its classes
2. Identify the basic principles of a software
3. Identify the software evolution and laws

Getting Started:

Software is capable of performing many tasks, as

opposed to hardware which can only perform
mechanical tasks that they are designed for.
Software provides the means for accomplishing
many different tasks with the same basic hardware

Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be collection of executable programming
code, associated libraries and documentations. Software, when made for a specific requirement is
called software product.

Classes of Software
• System software: Helps
run the computer hardware
and computer system itself.
System software includes
operating systems, device
drivers, diagnostic tools and
more. System software is
almost always pre-installed
on your computer.
 6

• Application software: Allows users to

accomplish one or more tasks. It
includes word processing, web
browsing and almost any other task for
which you might install software.
(Some application software is pre-
installed on most computer systems.)

• Programming software is a set of tools

to aid developers in writing programs.
The various tools available are
compilers, linkers, debuggers,
interpreters and text editors.

Basic Principles
1. Software, commonly known as programs or apps, consists of all the instructions that tell the
hardware how to perform a task.
2. These instructions come from a software developer in the form that will be accepted by
the platform (operating system + CPU) that they are based on.
3. For example, a program that is designed for the Windows operating system will only work for
that specific operating system. Compatibility of software will vary as the design of the software
and the operating system differ. Software that is designed for Windows XP may experience a
compatibility issue when running under Windows 2000 or NT.
4. Software, in its most general sense, is a set of instructions or programs instructing a computer
to do specific tasks. Software is a generic term used to describe computer programs. Scripts,
applications, programs and a set of instructions are all terms often used to describe software.
 7

Software Evolution
The process of developing a software
product using software engineering
principles and methods is referred to
as software evolution. This includes the
initial development of software and its
maintenance and updates, till desired
software product is developed, which
satisfies the expected requirements.
Evolution starts from the requirement
gathering process. After which developers
create a prototype of the intended software
and show it to the users to get their
feedback at the early stage of software
product development. The users suggest
changes, on which several consecutive
updates and maintenance keep on
changing too. This process changes to the
original software, till the desired software is accomplished. Even after the user has desired software
in hand, the advancing technology and the changing requirements force the software product to
change accordingly. Re-creating software from scratch and to go one-on-one with requirement is
not feasible. The only feasible and economical solution is to update the existing software so that it
matches the latest requirements.

Laws in Software Evolution

• Eight laws for software evolution:
• Continuing change - A software system must continue to adapt to the real world
changes, else it becomes progressively less useful.
• Increasing complexity - A software system evolves, its complexity tends to
increase unless work is done to maintain or reduce it.
• Conservation of familiarity - The familiarity with the software or the knowledge
about how it was developed, why was it developed in that particular manner etc.
must be retained at any cost, to implement the changes in the system.
• Continuing growth- In order for a system intended to resolve some business
problem, its size of implementing the changes grows according to the lifestyle
changes of the business.
 8

• Reducing quality - A software system declines in quality unless rigorously

maintained and adapted to a changing operational environment.
• Feedback systems- The software systems constitute multi-loop, multi-level
feedback systems and must be treated as such to be successfully modified or
improved.
• Self-regulation - a system evolution processes are self-regulating with the
distribution of product and process measures close to normal.
• Organizational stability - The average effective global activity rate in an
evolving a system is invariant over the lifetime of the product.
 9

LESSON 2. SOFTWARE PARADIGMS

Lesson Objectives:
At the end of this lesson, you will be able to:
1. Define the software paradigms
2. Identify the characteristics of a good software
3. Identify examples and use case scenarios

Software Development Paradigm

• Software paradigms refer to the methods and steps, which

are taken while designing the software. There are many methods
proposed and are in work today, but we need to see where in the
software engineering these paradigms stand.
• These can be combined into various categories, though each
of them is contained in one another
• Programming paradigm is a subset of Software design
paradigm which is further a subset of Software development
paradigm.

• This Paradigm is known as software engineering paradigms where all the engineering
concepts pertaining to the development of software are applied. It includes various
researches and requirement gathering which helps the software product to build. It
consists of the following
• Requirement gathering
• Software design
• Programming
 10

Software Design Paradigm

• This paradigm is a part of Software Development and includes the following
• Design
• Maintenance
• Programming
Programming Paradigm
• This paradigm is related closely to programming aspect of software development. This
includes –
• Coding
• Testing
• Integration
Characteristics of good software
A software product can be judged by what it offers and how well it can be used. This software
must satisfy on the following grounds:
• Operational
• Transitional
• Maintenance

Operational
• This tells us how well software works in operations. It can be measured on:
• Budget - cost
• Usability - the degree of ease with which products such as software and Web
applications can be used to achieve required goals effectively and efficiently.
• Efficiency - is defined as a level of performance that uses the lowest amount of
inputs to create the greatest amount of outputs.
 11

• Correctness - adherence to the

specifications that determine how
users can interact with the
software and how
the software should behave when
it is used correctly.
• Functionality - is the ability of the
system to do the work for which it
was intended.
• Dependability - is the ability to
provide services that can
defensibly be trusted within a
time-period.
• Security – secured system
• Safety
Transitional
• This aspect is important when the software is moved from one platform to another:
• Portability - he usability of the same software in different environments
• Interoperability - the ability of computer systems or software to exchange and
make use of information
• Reusability- the use of existing assets in some form within the software product
development process; these assets are products and by-products of the software
development life cycle and include code, software components, test suites,
designs and documentation.
• Adaptability - an open system that is able to fit its behavior according to changes
in its environment or in parts of the system itself
 12

Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the ever-
changing environment:
• Modularity the extent to which
a software/Web application may be
divided into smaller modules.
• Maintainability - is defined as the
degree to which an application is
understood, repaired, or enhanced.
• Flexibility - it normally refers to the ability for the solution to adapt to possible or
future changes in its requirements.
• Scalability - is the ability of a program to scale
 13

LESSON3. SOFTWARE DEVELOPMENT LIFE CYCLE

Lesson Objectives:
At the end of this lesson, you will be able to:
1. Define what is a Software Development Life Cycle or SDLC
2. Define the steps and procedures in SDLC
3. Provide examples for each steps and procedures in SDLC
4. Define the SDL Models

Software Development Life Cycle

• Software Development Life Cycle, SDLC for
short, is a well-defined, structured sequence of
stages in software engineering to develop the
intended software product.

Steps in SDLC

• Communication – initiate the request

• Requirement Gathering – bringing out the
information on what the project requirement is
• Feasibility Study - he team analyzes if a software
can be made to fulfill all requirements of the user and if
there is any possibility of software being no more
useful.
• System Analysis - decide a roadmap of their plan
and try to bring up the best software model suitable for
the project. Understanding the software limitations and
changes to be done
• Software design - The inputs from users and
information gathered in requirement gathering phase
are the inputs of this step. Output will be the logical design and the physical design
 14

• Coding – programming phase

• Testing – End user testing
• Integration – integration with other entity
• Implementation - installing the software on user machines
• Operation and Maintenance – maintaining the code, the systems for patch updates
• Disposition – retirement; legacy system

SDLC Model
Waterfall Model
Waterfall model is the simplest model of software
development paradigm. It says the all the phases of
SDLC will function one after another in linear
manner. That is, when the first phase is finished then
only the second phase will start and so on.

Iterative Model
This model leads the software development process in
iterations. It projects the process of development in
cyclic manner repeating every step after every cycle of
SDLC process.
 15

Spiral Model
Spiral model is a combination of both, iterative
model and one of the SDLC model. It can be
seen as if you choose one SDLC model and
combine it with cyclic process (iterative model).

System Implementation

Implementation

Implementation refers to activities that occur before the system is turned over to its users.
Its purpose is to:

 build a properly working system install it in the organization

 replace the old systems and work methods
 finalize system and user documentation
 train users
 prepare support systems to assist users

In addition, implementation involves project closedown, including personnel evaluation, staff

reassignment, project success assessment, and all resources turnover on those who will support
and maintain the system. Implementation is considered to be expensive because there are a lot
people involved in the process. It is also time-consuming since all the work must be completed.
The discussion on implementation covers six major activities and these are coding, testing,
installation, documentation, user training, and support.

Coding

Coding is the process where the physical design specifications developed by the analysis team are
converted into computer codes by the programming team. This can be an involved and intensive
activity that depends on the size and complexity of the system. No matter what development
methodology is used, once the coding has begun, the testing process can begin and proceed in
parallel. With each program module produced, it can be tested individually, then as part of a larger
program, and then as part of a larger system. These different types of testing will be discussed in
the next subsections.

Testing

Even though testing is done during implementation, the planning for testing should start earlier in
the project. Planning covers determining what needs to be tested and collecting test data. Testing
is the process of examining a product to ascertain what defects it contains. To conduct a test,
 16

programmers should have already built the software and have in hand well-defined standards for
what composes a defect. The product can be tested through reviewing their construction and
composition or through exercising their function and examining the results. Software testing
usually begins early in the systems development life cycle, although many of the actual testing
activities are carried out during implementation.

Types of Testing

Components can be tested individually or in groups, or the entire system can be tested as a whole.
There are three testing types and these are:

1. Unit testing
2. Integration testing
3. System testing

Each of this type correlated to a specific phase of the SDLC. Unit Testing Sometimes called
module testing, unit testing is the process of testing individual code modules before they are
integrated with other modules. The objective of unit testing is to identify and fix as many errors as
possible before modules are combined into larger software units (such as programs, classes, and
subsystems). Unit testing is often automated but it can also be done manually. Unit testing can be
tedious and time consuming. It requires patience and meticulousness on the part of the
development team. Unit testing should be done with an awareness that it may not be possible to
test a module for every input scenario that will occur when the program is run in a real-world
environment. Once all of the modules in a program have been found to be working in the most
efficient and error-free manner possible, larger components of the program can be assessed by
means of integration testing.

Integration Testing

Combining modules and testing them is called integration testing. The use of this test is to identify
errors that were not or could not be detected by unit testing individual modules. Such errors could
result from several problems, including:

 Interface incompatibility. An example is a caller module that passes a variable of the

wrong data type to a subordinate module.
 Parameter values. A module is passed or returns a value that was unexpected (such as
negative number for a price).
 Run-time exceptions. A module generates an error such as “out of memory” or “file
already in use” due to conflicting resource needs.
 Unexpected state interactions. The conditions of two or more modules interact to cause
complex failures (such as an order class method that operates correctly for all possible
customer object conditions except one).
 17

System Testing

In system testing, instead of integrating modules into programs for testing, the programs are
integrated into systems. Not only do individual modules and programs are tested several times in
system testing, but also interfaces between modules and programs. Usually, system testing is
performed first by developers or test personnel to make sure that the system does not fail and meets
the developers’ understanding of user requirements. If a system is developed in several iterations,
system testing is performed mostly at the end of each iteration to identify significant issues such
as performance problems that will need to be dealt with in the next iteration.

Acceptance Testing

After the system tests are complete, the system is now ready for acceptance testing. This is testing
the system in the environment where it will eventually be used. Acceptance means that users
normally sign off on the system and “accept” it once they are satisfied with it. In other words,
acceptance testing is a way for users to verify if the system meets their requirements. Usually,
acceptance testing is the last round of testing before the system is handed over to its users.

There are two types of acceptance testing and these are:

1. Alpha testing – user testing of a completed information system using simulated data
2. Beta testing – user testing of a completed information system using real data in the real
user environment

In alpha testing, the whole system is implemented in a test environment to find out whether the
system is openly destructive to itself or to the rest of the environment. There are several types of
tests done during alpha testing and these are as follows:

 Recovery testing – forces the software (or environment) to fail in order to verify that
recovery is properly performed
 Security testing – verifies that protection mechanisms built into the system will protect it
from improper penetration
 Stress testing – tries to break the system
 Performance testing – determines how the system performs in the range of possible
environments in which it may be used; often the goal is to have the system perform with
similar response time and other performance measures in each environment

The purpose of beta testing is to ascertain whether the software, documentation, technical support,
and training activities work as planned. Beta testing can be considered as a preparation of the
installation phase. Problems not covered in alpha and beta testing in any of these areas should be
fixed before users can accept the system.
 18

Installation

After the new system has been developed and tested, it must be installed and placed into operation.
Installation is the process of moving from the current information system to the new one. There
are many constraints when installing a new system and making it operational. These include cost,
customer relations, employee relations, logistical complexity, and overall exposure to risk. Some
other important issues to consider when planning installation are as follows:

 Incurring costs operating both systems in parallel

 Detecting and correcting errors in the new system
 Potentially disrupting the company and its IS operations
 Training personnel and familiarizing customers with new procedures

Approaches to Installation

There are different approaches to installation and the most commonly used are:

1. Direct installation
2. Parallel installation
3. Phased installation

Details of these approaches are discussed in the succeeding subsections.

Direct Installation

In direct installation, the old system is turned off and the new system is turned on. The figure
below shows the timeline for direct installation.
In direct installation, the users use the new system. Whatever errors found from the new system
will have a direct impact on the users and how they do their jobs. If the new system fails,
considerable delay may occur until the old system can operate again and business transactions are
re-entered to make the database updated.

The main advantage of direct

installation is its simplicity. There
are fewer logistical issues to
manage fewer resources required
because the old and new systems
are not operated in parallel.
However, the drawback of direct
installation is its risk. There is no
backup when the new system fails
because older systems are not
 19

operated in parallel. Moreover, direct installation requires a complete installation of the whole
system.

In general, direct installation is used in one or both of the following conditions:

 The new system is not replacing an older system (automated or manual).

 Downtime of days or weeks can be tolerated

If neither of the condition applies, then parallel or phased installation is used to minimize the risk
of system unavailability.

Parallel Installation

In parallel installation, the old system continues to operate along with the new system until the
users and management are satisfied with the performance of the new system and has been
thoroughly tested and determined to be error-free and ready to operate independently. All of the
work done by the old system is performed in parallel by the new system. The time allotted for
parallel operation is often determined ahead and limited to minimize the cost of dual operation.
The figure below illustrates the timeline for parallel installation.

An advantage of parallel installation is its low risk of system failure and the negative consequences
that may result from that failure. If both systems are operated completely, then the old system
serves as a backup for the new system. Any failure in the new system can be mitigated by relying
on the old system.

A parallel installation can be very

expensive. Since two systems are
running, it implies employing and paying
two staffs to operate and maintain them.
In addition, parallel installation can be
confusing to users because they are
dealing with both systems.

A parallel approach may not be possible

or feasible if the users of the system (such
as customers) cannot tolerate redundant
effort or if the size of the system is large.

Phased Installation

In Phased Installation, the new system is installed and brought into operation in a series of steps
or phases. Components or functions are added to the operational system on each phase. The system
is tested in each phase to make sure that it is ready for the next phase. Phased installation can be
 20

combined with parallel installation, especially when the new system will take over the operation
of multiple existing systems.

The main benefit of phased

installation is that it reduced risk
because failure of a single phase is
less problematic than failure of an
entire system. However, its drawback
is that it increased complexity.
Dividing the installation into phases
makes more activities and milestones,
hence making the whole process more
complex. Though each individual
phase includes a smaller and more
manageable set of activities. Phased
installation is useful mainly when a
system is large, complex, and
composed of relatively independent
subsystems. If these subsystems are
not substantially independent, then it is hard or impossible to define separate installation phases.
 21

M1:L1-L3 - ENRICHMENT ACTIVITY

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

1. Good software can be characterized on three grounds: one is operability which tells us how
well software works in operations. Choose three factors where it can be measured and
discuss it in your own words.
2. Software paradigms are commonly used to develop large software applications. Give an
example where it can be applied and explain its use in that field.
3. What is the importance of continuous evolution in software? Provide an example by citing
well-known applications which have obtained transformation over the years.

MODULE #1: ASSESSMENT

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

1. In your own understanding, what is a software? How is it related to hardware and people
ware?
2. What are the software paradigms and how do they affect software development?
3. Which phase of SDLC is the most critical part? Justify you answer by citing an example.
4. Why is it important for any organization to integrate training and support in their
computing infrastructure?

Rubrics:
 22

LEARNING MODULE INFORMATION

i. Course Code PROG301
II. Course Title Application Development and Emerging Technologies
III. Module Number 2
IV. Module Title Understanding the Requirements Gathering in Software
Development
V. Overview of the Module This module will allow the reader to understand the importance
of requirements gathering in software development. With this
module, students would be able to determine kinds of
requirements specifications in software development and
demonstrate data gathering techniques and its guidelines. In the
end, readers would be able to present requirements gathering
framework as baseline for software development.
VI. Module Outcomes
As for the outcome of the module, you are about to
 Learn on how to interpret a data
 Learn different ways on how to manage a data.
 Describe the requirements analysis process and
techniques
 Use the correct usability testing method for a software
development
 Distinguish a proper deployment plan based on real-life
scenarios.
 23

LESSON 1. REQUIREMENTS GATHERING

Lesson Objectives:
1. Understand the principle of requirements gathering and specifications
2. How and what requirements to gather.
3. Define the techniques in requirements gathering
4. Identify the importance of requirements gathering

What are requirements and its specifications?

• A requirement is a statement about an intended product that specifies what it should do or
how it should perform.
• Goal: To make as specific, unambiguous, and clear as possible.
• Functional Specifications: What the system should do
• Non-Functional Specifications: what constraints there are on the system its development -
(For example that a work processor runs on different platforms)
What requirements should be gathered?
• Functional: What the product should do.
• Data requirements: Capture the type, volatility, size/amount, persistence, accuracy and the
amounts of the required data.
• Environmental requirements:
• a) context of use
• b) Social environment (eg. Collaboration and coordination)
• c) how good is user support likely to be d) what technologies will it run on
• User Requirements: Capture the characteristics of the intended user group.
• Usability Requirement: Usability goals associated measures for a particular product.

Data Gathering Techniques

• Questionnaires: Series of questions designed to elicit specific information from us.
• The questions may require different kinds of answers: some require a simple
Yes/No, others ask us to choose from a set of pre-supplied answers.
 24

• Interviews: Interviews involve asking someone a set of questions.

• Often interviews are face-to-face
• Interviews:
• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
• Good for exploring issues
• But are time consuming and may be
infeasible to visit everyone
• Focus groups and workshops
• Interviews tend to be one on one, and elicit only one person’s perspective.
It can be very revealing to get a group of stakeholders together to discuss
issues and requirements.
• Naturalistic Observation
• It can be very difficult for humans to explain what they do or to even
describe accurately how they achieve a task.
• Spend time with stakeholders in their day-to-day tasks, observing work as
it happens
• Gain insights into stakeholders’ tasks
• Good for understanding the nature and
context of the tasks
• But it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
• Ethnography is one form: entire class devoted to this.
• Studying documentation:
• Procedures and rules are often written down in a manual and these are a
good source of data about the steps involved in an activity and any
regulations governing a task.
 25

Requirements Gathering

Requirements Gathering is a
fundamental part of any software
development project. It is the
process of generating a list of
requirements (functional, system,
technical, etc.) from all the
stakeholders (customers, users,
vendors, IT staff) that will be used
as the basis for the formal
definition of what the project is.

The importance of Requirements Gathering

• The problem with the business customers is that the latter tends to expect software teams
to deliver a solution based on unspoken, incomplete or unknown requirements
• The problem with software teams is that they tend to assume that business customers will
communicate exactly what they want as succinctly as possible.
• Therefore, the requirements need to be formally captured in one document that can be used
as a reference during software development.
• Good gathering, processing and management of requirements is important as it sets clear
targets for everyone to aim for. It can be a lot of hard work, but it need not be a daunting
task if you can keep some key points in mind.
• Remember it’s all about the user. Consider always the user inputs. Find out how actual
users complete their tasks and exactly how they get things done – and how they want to
get things done. What do they need to do? How efficiently can we make that happen? And
what sorts of flexibility might be required?
 26

The User comes first

• The requirements should
detail how a user would
accomplish what they want
using the software being
developed. Awareness of
any technological
preferences and existing
system integration is also
fundamental, as it can have a
huge impact on the
development path and
subsequently impact on
performance and user task
efficiency.
 27

LESSON2. DATA GATHERING GUIDELINES

Lesson Objectives:
1. Understand the principle of data gathering guidelines
2. Understand the requirements gathering framework
3. Define the techniques in requirements gathering
4. Identify the requirements analysis techniques

Data Gathering Guidelines

 Focus on identifying the stakeholders
 Involve all the stakeholder groups
 Need more than in person from stakeholder group(s)
 Use a combination of data gathering techniques
For example: use observation to understand the context, interviews to target specific user
groups, questionnaires to reach a wider population, and focus groups to build a consensus view
 Support the data-gathering sessions with suitable props, such as task descriptions and
prototypes if available.
 Run a pilot session if possible, to ensure that your data-gathering session is likely to go as
planned
In an ideal world, you would understand what you are looking for and what kinds of analysis you
want to do, and design the data-capture exercise to collect the data you want. However, data
gathering is expensive and often a tightly constrained resource
 28

Figure 1 Requirements Gathering Framework

How to interpret the data?

• The next question would be – how to interpret the data?
• What structure and record description of requirement will be used?
• When to start the interpretation?
• We can use analysis models in object-oriented systems by using a
• Use cases diagrams:
consists of actors and user cases, discussed later
• Class diagrams
What is the Requirements Analysis?
• Requirements Analysis is the process of defining the expectations of the users for an
application that is to be built or modified. Requirements analysis involves all the tasks that
are conducted to identify the needs of different stakeholders. Therefore, requirements
analysis means to analyze, document, validate and manage software or system
requirements. High-quality requirements are documented, actionable, measurable, testable,
 29

traceable, helps to identify business opportunities, and are defined to a facilitate system
design
Requirements Analysis Techniques

• Business process modeling notation (BPMN)

• This technique is similar to creating
process flowcharts,
although BPMN has its own
symbols and elements. Business
process modeling and notation is
used to create graphs for the
business process. These graphs
simplify understanding the business
process. BPMN is widely popular
as a process improvement
methodology.
• Flowchart technique
A flowchart depicts the sequential flow and
control logic of a set of activities that are
related. Flowcharts are in different formats such
as linear, cross-functional, and top-down. The
flowchart can represent system interactions,
data flows, etc. Flow charts are easy to
understand and can be used by both the
technical and non-technical team members.
Flowchart technique helps in showcasing the
critical attributes of a process.
 30

Data flow diagram

• This technique is used to visually represent systems and processes that are complex
and difficult to describe in text. Data
flow diagrams represent the flow of
information through a process or a
system. It also includes the data
inputs and outputs, data stores, and
the various subprocess through
which the data moves. DFD
describes various entities and their
relationships with the help of
standardized notations and
symbols. By visualizing all the
elements of the system it is easier to
identify any shortcomings. These
shortcomings are then eliminated in
a bid to create a robust solution.
• Role Activity Diagrams (RAD)
• Role-activity
diagram (RAD) is
a role-oriented
process model that
represents role-
activity
diagrams. Role
activity diagrams
are a high-level
view that captures
the dynamics and
role structure of an
organization. Roles are used to grouping together activities into units of
responsibilities. Activities are the basic parts of a role. An activity may be either
carried out in isolation or it may require coordination with other activities within
the role.
 31

• Gantt Charts
• Gant charts used in
project planning as
they provide a visual
representation of tasks
that are scheduled
along with the
timelines. The Gant
charts help to know
what is scheduled to
be completed by
which date. The start
and end dates of all
the tasks in the project can be seen in a single view.

• Gap Analysis
• Gap analysis is a technique
which helps to analyze the gaps
in performance of a software
application to determine
whether the business
requirements are met or not. It
also involves the steps that are
to be taken to ensure that all
the business requirements are
met successfully. Gap denotes
the difference between the
present state and the target state.
Gap analysis is also known as
need analysis, need assessment or need-gap analysis.
 32

M2:L1-L2 - Enrichment Activity

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

After understanding the principle of requirements gathering, specifications and data gathering
guidelines, explain how these does affect the business requirements in software development. Give
an example of an existing organization or IT firm and relate how these principles affect the
business operations.

Module #2: Assessment

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

1. Why do we need to identify and establish the requirements in software development?

2. What are the kinds of specifications needed in this requirement gathering? Give
example.
3. What kind of requirements should be gathered?
4. How will you differentiate each data gathering techniques?
5. How are we going to interpret the gathered data?

Rubrics:
 33

LEARNING MODULE INFORMATION

ii. Course Code PROG301

II. Course Title Application Development and Emerging Technologies
III. Module Number 3
IV. Module Title Research design and testing
V. Overview of the Module This module will allow the reader to understand the importance
of research design and testing along with its components and
guidelines
VI. Module Outcomes
As for the outcome of the module, you are about to
 Learn on how to interpret a data
 Learn different ways on how to manage a data.
 Describe the requirements analysis process and
techniques
 Use the correct usability testing method for a software
development
 Distinguish a proper deployment plan based on real-life
scenarios.
 34

LESSON 1. SOFTWARE DESIGN BASICS

Lesson Objectives:
1. Understand the principle of software design
2. Components of software design
3. Importance of software design

Getting Started:
• Software design is a process to transform
user requirements into some suitable form,
which helps the programmer in software
coding and implementation.

• The design phase of software development

deals with transforming the customer
requirements.

• Software design is the process of

conceptualizing the software requirements
into software implementation.

• The design process establishes a plan that takes the user requirements as challenges and
works to identify optimum solutions. The plan should determine the best possible design
for implementing the intended solution.

Components of Software Design Process

• Software requirements specification. This document describes the expected behavior of
the system in the form of functional and non-functional requirements. These requirements
should be clear, actionable, measurable, and traceable to business requirements.
Requirements should also define how the software should interact with humans, hardware,
and other systems.

• High-level design. The high-level design breaks the system’s architectural design into a
less-abstracted view of sub-systems and modules and depicts their interaction with each
other. This high-level design perspective focuses on how the system, along with all its
components, implements in the form of modules. It recognizes the modular structure of
each sub-system and their interaction among one another.
 35

• Detailed design. Detailed design involves the implementation of what is visible as a

system and its sub-systems in a high-level design. This activity is more detailed towards
modules and their implementations. It defines a logical structure of each module and their
interfaces to communicate with other modules.

Why software design is important?

• Software design can be done with several different ways.
• It can be done utilizing some software using some modeling language, such as UML, it can
be written text and images or it can even be a drawing on a whiteboard.
• Important here is that the design can be saved and revisited during the development of the
software — The design will need some refining so if you don’t want to always draw the
design to the whiteboard from scratch, it might be good idea to stay with digital ways of
doing the design.
• This and how it’s done of course depends on project needs. Small projects can easily be
just drawn or written on a single paper while bigger projects usually tend to change a lot
during their lifetime affecting also the software design.

Modularity
• Split your software into smaller pieces with maybe maximum of 5–10 interfaces. These
interface “groups” are called software components. Main idea of the software component
is to provide a single purpose for the software that is being developed.
• When you have a modular software, it’s easy to move or even remove things if needed and
even share the design work between multiple developers per software component. Having
modularity also increases maintainability by making it easier to find necessary information
to edit from the right component. It can also be basis for your source code name spacing
or structure as well as isolating the test cases per component.

Maintainability
• With good software design it’s easier to maintain the software. You can spot straight away
from the design how much a bug fix or introduction of a new feature will change the
existing code base.
 36

• As good design should also show interactions between software components and their
interfaces, it will also reveal possible effects of changing code in another component that
depends on the one needing the change.

• Working especially with old code bases that do not have any software design can be very
painful and cause many unexpected bugs.

Performance

• Good software design can be used to easily pinpoint performance bottlenecks in your
software — especially if the design is done to the level of that granularity.

• This means the design should tell how your system works internally and how it uses
resources such as threads, database connections and other things that might make a hit to
the performance.

• Sometimes it’s very easy to debug or use some logging functionality to find the bottlenecks
from the source code but sometimes the design can tell it by a single image.

Portability
• By including dependencies to other software modules, such as 3rd party libraries, in to your
design makes the software much easier to port into another environment.
• Having these documented in a single place makes it super easy to discover what needs to
be changed if using another environment or if it can be done at all.

Usability
• Generating a design document for your customers from the software design is a good idea.
It provides them an overview how the software they are about to take into use works.

• You might need to consider if you want to publish only your public interfaces and leave
your internal design out of the document as good design makes it possible to very easily
write the software from scratch.

Trackability
 37

• Usually projects have requirements coming from either a customer or from an internal
source. Good design also tracks the requirements and proves on the design level that all
that is required from a piece of software is actually there and that it’s understood correctly.

• This brings even more value to the provided design document as the customers can actually
see what of their requirements are done and where.

• To integrate this with source code, some kind of linking between the design, requirements
and the source code is more than advised.

Deployment
• Design should also provide information what the software deliverables are and where
should they be placed in the deployment.

• This information is very important for your customers as well as integration as they need
to know where to look for your library/executable/whatever your software is about.
• It makes it easier to spot right away if the latest delivery is missing some crucial parts of
the software by simply taking a look at your design.
 38

LESSON 2. SOFTWARE DESIGN LEVELS AND TAXONOMY OF ARCHITECTURAL

STYLES

Lesson Objectives:
1. Understand the software design levels
2. Understand the taxonomy of architectural styles

Interface or High-level Design

• Interface design is the specification of the interaction between a system and its
environment.

• This phase proceeds at a high level of abstraction with respect to the inner workings of the
system i.e, during interface design, the internal of the systems are completely ignored and
the system is treated as a black box.
• Attention is focused on the dialogue between the target system and the users, devices, and
other systems with which it interacts.
 39

• The design problem statement produced during the problem analysis step should identify
the people, other systems, and devices which are collectively called agents.

• The high-level design breaks the ‘single entity-multiple component’ concept of

architectural design into less-abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the system along with all of
its components can be implemented in forms of modules. It recognizes modular structure
of each sub-system and their relation and interaction among each other.

Interface Design
• Interface design should include the following details:
• Precise description of events in the environment, or messages from agents to which
the system must respond.

• Precise description of the events or messages that the system must produce.
• Specification on the data, and the formats of the data coming into and going out of
the system.

• Specification of the ordering and timing relationships between incoming events or

messages, and outgoing events or outputs.

Architectural Design
• Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them.
In architectural design, the overall structure of the system is chosen, but the internal details
of major components are ignored.

• The architectural design adds important details ignored during the interface design. Design
of the internals of the major components is ignored until the last phase of the design.

• The architectural design is the highest abstract version of the system. It identifies the
software as a system with many components interacting with each other. At this level, the
designers get the idea of proposed solution domain.

• The software needs the architectural design to represents the design of software. IEEE
defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development
of a computer system.” The software that is built for computer-based systems can exhibit
one of these many architectural styles.
 40

• The use of architectural styles is to establish a structure for all the components of the
system.

• Each style will describe a system category that consists of :

• A set of components (eg: a database, computational modules) that will perform a
function required by the system.

• The set of connectors will help in coordination, communication, and cooperation

between the components.

• Conditions that how components can be integrated to form the system.

• Semantic models that help the designer to understand the overall properties of the
system.

Taxonomy of Architectural styles

• Data centered architectures
• A data store will reside at the
center of this architecture and
is accessed frequently by the
other components that update,
add, delete or modify the data
present within the store.

Data flow architectures

• This kind of architecture is used
when input data to be transformed
into output data through a series of
computational manipulative
components.

• The figure represents pipe-and-filter

architecture since it uses both pipe
and filter and it has a set of
components called filters connected
by pipes.
 41

• Pipes are used to transmit data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.

• If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

Layered architecture
• A number of different layers are
defined with each layer
performing a well-defined set of
operations. Each layer will do
some operations that becomes
closer to machine instruction set
progressively.

• At the outer layer, components

will receive the user interface
operations and at the inner
layers, components will perform
the operating system interfacing(communication and coordination with OS)

• Intermediate layers to utility services and application software functions.

 42

Architectural Design
• Issues in architectural design
includes:

• Gross decomposition of the

systems into major
components.

• Allocation of functional
responsibilities to
components.
• Component Interfaces

• Component scaling and performance properties, resource consumption properties,

reliability properties, and so forth.
• Communication and interaction between components.

Detailed Design
• Detailed design is closely related to architecture and construction; therefore successful
designers (during detailed design) are required to have or acquire full understanding of the
system’s requirements and architecture.

• They must also be proficient in particular design strategies (e.g., object-oriented),

programming languages, and methods and processes for software quality control.

• Just as architecture provides the bridge between requirements and design, detailed design
provides the bridge between design and code.
 43

The major tasks identified for carrying out the detailed design activity include:
1. Understanding the architecture and requirements
2. Creating detailed designs
3. Evaluating detailed designs
4. Documenting software design
5. Monitoring and controlling implementation
 44

LESSON 3. SOFTWARE TESTING

Lesson Objectives:
1. Understand what is software testing
2. Understand the taxonomy of architectural styles

What is Software Testing?

Software testing is a process of executing a program or application with the intent of
finding the software bugs.
It can also be stated as the process of validating and verifying that a software program or
application or product:
◦ Meets the business and technical requirements that guided it’s design and
development
◦ Works as expected
◦ Can be implemented with the same characteristic.

Let’s break down the basic definition of Software testing into the following parts:
1. Process: Testing is a process rather than a single activity.
2. All Life Cycle Activities: Testing is a process that’s take place throughout the Software
Development Life Cycle (SDLC).
◦ The process of designing tests early in the life cycle can help to prevent
defects from being introduced in the code. Sometimes it’s referred
as “verifying the test basis via the test design”.

◦ The test basis includes documents such as the requirements and design
specifications.

3. Static Testing: It can test and find defects without executing code. Static Testing is done
during verification process. This testing includes reviewing of the documents (including
source code) and static analysis. This is useful and cost effective way of testing.
4. Dynamic Testing: In dynamic testing the software code is executed to demonstrate the
result of running tests. It’s done during validation process.
 45

5. Planning: We need to plan as what we want to do. We control the test activities, we report
on testing progress and the status of the software under test.

6. Preparation: We need to choose what testing we will do, by selecting test conditions
and designing test cases.

7. Evaluation: During evaluation we must check the results and evaluate the software under
test and the completion criteria, which helps us to decide whether we have finished testing
and whether the software product has passed the tests.

8. Software products and related work products: Along with the testing of code the testing of
requirement and design specifications and also the related documents like operation, user
and training material is equally important.

Why is Software Testing needed?

 At a high level, software testing is needed in order to detect the bugs in the software and to
test if the software meets the customers’ requirements.
 This helps the development team to fix the bugs and deliver a good quality product.
 There are several points in the software development process where human error can lead
to software that does not meet customers’ requirements. Some of them are listed below.

 Customer / person providing the requirements on behalf of the customer

organization may not know what exactly is required or may forget to
provide some details, which may lead to missing features

 The person who is gathering the requirements may misinterpret or

completely miss a requirement when document them

 During the design phase, if there are issues in design, it may lead to bugs in
future

 Bugs may be introduced during development phase during to human error,

lack of expertise etc

 Testers can miss bugs during testing phase due to human error, lack of time,
insufficient experience etc

 Customers may not have the bandwidth to test every feature of the product
and may release the product to their end users which can lead to end users
finding errors in the application
 46

 An organizations business and reputation depends on the quality of its products and in some
cases even the revenue may be dependent on the sales of software product.

 Users may prefer to buy a competing product over a product that has poor quality and this
can result in loss of revenue for the organization. In today’s world, quality is one of the top
priorities for any organization.

Importance of Software Testing in Software Engineering

Software testing is an important part of software development. If software testing is not

performed properly, applications can have errors which may lead to rework, costly failure
or worse, loss of life.

Software testing is a process, to evaluate the functionality of a software application with

an intent to find whether the developed software met the specified requirements or not and
to identify the defects to ensure that the product is defect free in order to produce the quality
product.

Testing Methods
Static Testing: It is also known as Verification in Software Testing. Verification is a static
method of checking documents and files.

Verification is the process, to ensure that whether we are building the product right i.e., to
verify the requirements which we have and to verify whether we are developing the product
accordingly or not.

Activities involved here are Inspections, Reviews, Walkthroughs

Dynamic Testing: It is also known as Validation in Software Testing.

Validation is a dynamic process of testing the real product. Validation is the process,
whether we are building the right product i.e., to validate the product which we have
developed is right or not.

Activities involved in this is Testing the software application

Testing Approaches
White Box Testing: It is also called as Glass Box, Clear Box, Structural Testing.
 47

White Box Testing is based on applications internal code structure. In white-box testing,
an internal perspective of the system, as well as programming skills, are used to design test
cases.

This testing is usually done at the unit level.

Black Box Testing: It is also called as Behavioral/Specification-Based/Input-Output
Testing.

Black Box Testing is a software testing method in which testers evaluate the functionality
of the software under test without looking at the internal code structure.

Grey Box Testing: Grey box is the combination of both White Box and Black Box
Testing.
The tester who works on this type of testing needs to have access to design documents.
This helps to create better test cases in this process.

Testing Levels
Unit Testing: Unit Testing is done to check whether the individual modules of the source
code are working properly. i.e. testing each and every unit of the application separately by
the developer in the developer’s environment.
Integration Testing: Integration Testing is the process of testing the connectivity or data
transfer between a couple of unit tested modules.
It is subdivided into Top-Down Approach, Bottom-Up Approach and Sandwich
Approach (Combination of Top Down and Bottom Up).
System Testing (end to end testing): It’s a black box testing.
Testing the fully integrated application this is also called as end to end scenario testing.
To ensure that the software works in all intended target systems. Verify thorough testing
of every input in the application to check for desired outputs.
Testing of the users experiences with the application
Acceptance Testing: To obtain customer sign-off so that software can be delivered and
payments received.
Testing Artifacts
Some of the test deliverables are as follows:
 48

• Test plan
• Traceability matrix
• Test case

• Test script
• Test suite
• Test data or Test Fixture

• Test harness
Principles of Software Testing
 Testing shows presence of defects
 Exhaustive testing is impossible
 Early testing
 Defect clustering
 Pesticide paradox
 Testing is context dependent
 Absence of error – fallacy
 49

M3:L1-L3 - Enrichment Activity

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

Make a research applying the SDLC process. Include all processes identified on this module. The
user fishbone in defining the gaps and techniques on data gathering should apply only based on
the current circumstances that we have. In doing the output of the research, use the following:
i. Proposed topic
ii. Rationale
iii. Research Questions
iv. Significance of the Study

Module #3: Assessment

Name: ________________________________ Score: _______________

Year and Section: ______________________ Professor: ____________

1. Explain in your own words, what software design is. Give an example on how you can
make a good system design.
2. What is the importance of doing software testing?
3. What are the different testing styles that you can use in your system? What is more
feasible in your project?

Rubrics:
 50

SUGGESTED LINKS

Link 1
https://www.youtube.com/watch?v=SS3k1X6r7s0

Link 2
https://www.youtube.com/watch?v=I1RIhmf0IlI

Link 3
https://www.youtube.com/watch?v=bNDlg1h-za0

REFERENCES/ATTRIBUTIONS:
• Chapter 7 from J. Preece, Y. Rogers, H. Sharp: Interaction Design: Beyond Human-Computer
Interaction.
• “Applying Requirements Management with Use Cases,” Roger Oberg (IBM Rational
Software)
• Constance L. Heitmeyer. “Software cost reduction”. In John J. Marciniak, editor,
Encyclopedia of Software Engineering. John Waley & Sons, 2nd edition, 2002
• Alistai Sutcliffe, "Scenario-based requirements analysis." Requirements Engineering Journal,
London, UK, 1998.
• Satzinger, John W., Jackson, Robert B., Burd, Stephen D., (2004), Systems analysis and design
in a changing world (3rd ed.), Course Technology ß Hoffer, Jeffrey A., George, Joey F., Joseph
S., (2005), Modern systems analysis and design (3rd ed.), Upper Saddle River, N.J. : Prentice
Hall
• http://www-306.ibm.com/software/awdtools/reqpro/
• http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/module02-
03_introduction.html

• http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/module02-
03_introduction.html

• https://www.techopedia.com/definition/4356/software
• https://www.bbconsult.co.uk/blog/requirements-gathering
• https://www.tutorialspoint.com/software_engineering/software_engineering_overview