LEARNING MODULE INFORMATION

i. Course Code IT 08
II. Course Title Application Development
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.
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.
 • 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.
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.
• 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.
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
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.
• 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
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
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
 • 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.
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,
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).
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.
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
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
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.