Unit-4

Management of IS
4.0 INTRODUCTION

Management information system (MIS) refers to the processing of information through

computers and other intelligent devices to manage and support managerial decisions within an
organization. The concept may include systems termed transaction processing system, decision
support system, expert system, or executive information system. The term is often used in the
academic study of businesses and has connections with other areas, such as information systems,
information technology, informatics, e-commerce and computer science; as a result, the term is
used interchangeably with some of these areas.

Management information systems (plural) as an academic discipline studies people,

technology, organizations, and the relationships among them. This definition relates specifically
to "MIS" as a course of study in business schools. Many business schools (or colleges of
business administration within universities) have an MIS department, alongside departments of
accounting, finance, management, marketing, and many award degrees (at undergraduate,
master, and doctoral levels) in Management Information Systems.

MIS professionals help organizations to maximize the benefit from investments in

personnel, equipment, and business processes.

4.1 PROJECT PLANNING

Before starting a software project, it is essential to determine the tasks to be performed

and properly manage allocation of tasks among individuals involved in the software
development. Hence, planning is important as it results in effective software development.

Project planning is an organized and integrated management process, which focuses on

activities required for successful completion of the project. It prevents obstacles that arise in the
project such as changes in projects or organization's objectives, non-availability of resources, and
so on. Project planning also helps in better utilization of resources and optimal usage of the
allotted time for a project. The other objectives of project planning are listed below.

 It defines the roles and responsibilities of the project management team members.
 It ensures that the project management team works according to the business objectives.
 It checks feasibility of the schedule and user requirements.
 It determines project constraints.

Several individuals help in planning the project. These include senior management and
project management team. Senior management is responsible for employing team members and
providing resources required for the project. The project management team, which generally
includes project managers and developers, is responsible for planning, determining, and tracking

1|Page
the activities of the project. Table lists the tasks performed by individuals involved in the
software project.

Tasks of Individuals involved in Software Project

Senior Management Project Management Team

 Approves the project, employ
personnel, and provides resources
required for the project.
 Reviews project plan to ensure that
it accomplishes the business
objectives.
 Resolves conflicts among the team
members.
 Considers risks that may affect the
project so that appropriate measures
can be taken to avoid them.
 Reviews the project plan and
implements procedures for
completing the project.
 Manages all project activities.
 Prepares budget and resource
allocation plans.
 Helps in resource distribution,
project management, issue
resolution, and so on.
 Understands project objectives and
finds ways to accomplish the
objectives.
 Devotes appropriate time and effort
to achieve the expected results.
 Selects methods and tools for the
project.

Project planning should be effective so that the project begins with well-defined tasks.
Effective project planning helps to minimize the additional costs incurred on the project while it
is in progress. For effective project planning, some principles are followed. These principles are
listed below.

 Planning is necessary: Planning should be done before a project begins. For effective
planning, objectives and schedules should be clear and understandable.
 Risk analysis: Before starting the project, senior management and the project
management team should consider the risks that may affect the project. For example, the
user may desire changes in requirements while the project is in progress. In such a case,
the estimation of time and cost should be done according to those requirements (new
requirements).
 Tracking of project plan: Once the project plan is prepared, it should be tracked and
modified accordingly.
 Meet quality standards and produce quality deliverables: The project plan should
identify processes by which the project management team can ensure quality in software.
Based on the process selected for ensuring quality, the time and cost for the project is
estimated.
 Description of flexibility to accommodate changes: The result of project planning is
recorded in the form of a project plan, which should allow new changes to be
accommodated when the project is in progress.

2|Page
 Project planning comprises project purpose, project scope, project planning process, and
project plan. This information is essential for effective project planning and to assist project
management team in accomplishing user requirements.

Project Purpose

Software project is carried out to accomplish a specific purpose, which is classified into
two categories, namely, project objectives and business objectives. The commonly followed
project objectives are listed below.

 Meet user requirements: Develop the project according to the user requirements after
understanding them.
 Meet schedule deadlines: Complete the project milestones as described in the project
plan on time in order to complete the project according to the schedule.
 Be within budget: Manage the overall project cost so that the project is within the
allocated budget.
 Produce quality deliverables: Ensure that quality is considered for accuracy and overall
performance of the project.

Business Software Engineering

Business objectives ensure that the organizational objectives and requirements are
accomplished in the project. Generally, these objectives are related to business process
improvements, customer satisfaction, and quality improvements. The commonly followed
business objectives are listed below.

 Evaluate processes: Evaluate the business processes and make changes when and where
required as the project progresses.
 Renew policies and processes: Provide flexibility to renew the policies and processes of
the organization in order to perform the tasks effectively.
 Keep the project on schedule: Reduce the downtime (period when no work is done)
factors such as unavailability of resources during software development.
 Improve software: Use suitable processes in order to develop software that meets
organizational requirements and provides competitive advantage to the organization.

Project Scope

With the help of user requirements, the project management team determines the scope of
the project before the project begins. This scope provides a detailed description of functions,
features, constraints, and interfaces of the software that are to be considered. Functions describe
the tasks that the software is expected to perform. Features describe the attributes required in the
software as per the user requirements. Constraints describe the limitations imposed on software
by hardware, memory, and so on. Interfaces describe the interaction of software components
(like modules and functions) with each other. Project scope also considers software performance,
which in turn depends on its processing capability and response time required to produce the
output.

3|Page
 Once the project scope is determined, it is important to properly understand it in order to
develop software according to the user requirements. After this, project cost and duration are
estimated. Lf the project scope is not determined on time, the project may not be completed
within the specified schedule. Project scope describes the following information.

 The elements included and excluded in the project

 The processes and entities
 The functions and features required in software according to the user requirements.

Note that the project management and senior management team should communicate
with the users to understand their requirements and develop software according to those
requirements and expected functionalities.

Project Planning Process

The project planning process involves a set of interrelated activities followed in an

orderly manner to implement user requirements in software and includes the description of a
series of project planning activities and individual(s) responsible for performing these activities.
In addition, the project planning process comprises the following.

1. Objectives and scope of the project

2. Techniques used to perform project planning
3. Effort (in time) of individuals involved in project
4. Project schedule and milestones
5. Resources required for the project
6. Risks associated with the project.

Project planning process comprises several activities, which are essential for carrying out a
project systematically. These activities refer to the series of tasks performed over a period of
time for developing the software. These activities include estimation of time, effort, and
resources required and risks associated with the project.

4|Page
Project planning process consists of the following activities.

 Identification of project requirements: Before starting a project, it is essential to

identify the project requirements as identification of project requirements helps in
performing the activities in a systematic manner. These requirements comprise
information such as project scope, data and functionality required in the software, and
roles of the project management team members.

 Identification of cost estimates: Along with the estimation of effort and time, it is
necessary to estimate the cost that is to be incurred on a project. The cost estimation
includes the cost of hardware, network connections, and the cost required for the
maintenance of hardware components. In addition, cost is estimated for the individuals
involved in the project.
 Identification of risks: Risks are unexpected events that have an adverse effect on the
project. Software project involves several risks (like technical risks and business risks)
that affect the project schedule and increase the cost of the project. Identifying risks
before a project begins helps in understanding their probable extent of impact on the
project.
 Identification of critical success factors: For making a project successful, critical
success factors are followed. These factors refer to the conditions that ensure greater
chances of success of a project. Generally, these factors include support from
management, appropriate budget, appropriate schedule, and skilled software engineers.
 Preparation of project charter: A project charter provides a brief description of the
project scope, quality, time, cost, and resource constraints as described during project
planning. It is prepared by the management for approval from the sponsor of the project.

5|Page
  Preparation of project plan: A project plan provides information about the resources
that are available for the project, individuals involved in the project, and the schedule
according to which the project is to be carried out.
 Commencement of the project: Once the project planning is complete and resources are
assigned to team members, the software project commences.

Once the project objectives and business objectives are determined, the project end date
is fixed. The project management team prepares the project plan and schedule according to the
end date of the project. After analyzing the project plan, the project manager communicates the
project plan and end date to the senior management. The progress of the project is reported to the
management from time to time. Similarly, when the project is complete, senior management is
informed about it. In case of delay in completing the project, the project plan is re-analyzed and
corrective actions are taken to complete the project. The project is tracked regularly and when
the project plan is modified, the senior management is informed.

Project Plan

As stated earlier, a project plan stores the outcome of project planning. It provides
information about the end date, milestones, activities, and deliverables of the project. In addition,
it describes the responsibilities of the project management team and the resources required for
the project. It also includes the description of hardware and software (such as compilers and
interfaces) and lists the methods and standards to be used. These methods and standards include
algorithms, tools, review techniques, design language, programming language, and testing
techniques.

A project plan helps a project manager to understand, monitor, and control the
development of software project. This plan is used as a means of communication between the
users and project management team. There are various advantages associated with a project plan,
some of which are listed below.

 It ensures that software is developed according to the user requirements, objectives, and
scope of the project.
 It identifies the role of each project management team member involved in the project.
 It monitors the progress of the project according to the project plan.
 It determines the available resources and the activities to be performed during software
development.
 It provides an overview to management about the costs of the software project, which are
estimated during project planning.

Note that there are differences in the contents of two project plans depending on the kind
of project and user requirements. Atypical project plan is divided into the following sections.

1. Introduction: Describes the objectives of the project and provides information about the
constraints that affect the software project.
2. Project organization: Describes the responsibilities assigned to the project management
team members for completing the project.

6|Page
 3. Risk analysis: Describes the risks that can possibly arise during software development as
well as explains how to assess and reduce the effect of risks.
4. Resource requirements: Specifies the hardware and software required to carry out the
software project. Cost estimation is done according to these resource requirements.
5. Work breakdown: Describes the activities into which the project is divided. It also
describes the milestones and deliverables of the project activities.
6. Project schedule: Specifies the dependencies of activities on each other. Based on this,
the time required by the project management team members to complete the project
activities is estimated.

In addition to these sections, there are several plans that may be a part of or 'linked to a
project plan. These plans include quality assurance plan, verification and validation plan,
configuration management plan, maintenance plan, and staffing plan.

Quality Assurance Plan

The quality assurance plan describes the strategies and methods that are to be followed to
accomplish the following objectives.

1. Ensure that the project is managed, developed, and implemented in an organized way.
2. Ensure that project deliverables are of acceptable quality before they are delivered to the
user.

Verification and Validation Plan

The verification and validation plan describes the approach, resources and schedule used
for system validation. The verification and validation plan, which comprises the following
sections.

General information: Provides description of the purpose, scope, system overview,

project references, acronyms and abbreviations, and points of contact. Purpose describes the
procedure to verify and validate the components of the system. Scope provides information about
the procedures to verify and validate as they relate to the project. System overview provides
information about the organization responsible for the project and other information such as
system name, system category, operational status of the system, and system environment. Project
references provide the list of references used for the preparation of the verification and validation
plan. Acronyms and abbreviations provide a list of terms used in the document. Points of contact
provide information to users when they require assistance from organization for problems such
as troubleshooting and so on.

Reviews and walkthroughs: Provides information about the schedule and procedures.
Schedule describes the end date of milestones of the project. Procedures describe the tasks
associated with reviews and walkthroughs. Each team member reviews the document for errors
and consistency with the project requirements. For walkthroughs, the project management team
checks the project for correctness according to software requirements specification (SRS).

7|Page
 System test plan and procedures: Provides information about the system test strategy,
database integration, and platform system integration. System test strategy provides an overview
of the components required for integration of the database and ensures that the application runs
on at least two specific platforms. Database integration procedure describes how database is
connected to the Graphical User Interface (GUI).Platform system integration procedure is
performed on different operating systems to test the platform.

Acceptance test and preparation for delivery: Provides information about procedure,
acceptance criteria, and installation procedure. Procedure describes how acceptance testing is to
be performed on the software to verify its usability as required. Acceptance criteria describes that
software will be accepted only if all the components, features and functions are tested including
the system integration testing. In addition, acceptance criteria checks whether the software
accomplishes user expectations such as its ability to operate on several platforms. Installation
procedure describes the steps of how to install the software according to the operating system
being used.

Configuration Management Plan

The configuration management plan defines the process, which is used for making
changes to the project scope. Generally, the configuration management plan is concerned with
redefining the existing objectives of the project and deliverables (software products that are
delivered to the user after completion of software development).

Maintenance Plan

The maintenance plan specifies the resources and processes required for making the
software operational after its installation. Sometimes, the project management team (or software
development team) does not carry out the task of maintenance. In such a case, a separate team
known as software maintenance team performs the task of software maintenance.

The maintenance plan, which comprises the sections listed below.

Introduction and background: Provides a description of software to be maintained and

the services required for it. It also specifies the scope of maintenance activities that are to be
performed.

Budget: Specifies the budget required for carrying out software maintenance and
operational activities.

Roles and responsibilities: Specifies the roles and responsibilities of the team members
associated with the software maintenance and operation. It also describes the skills required to
perform maintenance and operational activities. In addition to software maintenance team,
software maintenance comprises user support, user training, and support staff.

8|Page
 Performance measures and reporting: Identifies the performance measures required
for carrying out software maintenance. It also describes how measures required for enhancing the
performance of services (for the software) are recorded and reported.

Management approach: Identifies the methodologies that are required for establishing
maintenance priorities of the projects. For this purpose, the management either refers to the
existing methodologies or identifies new methodologies. Management approach also describes
how users are involved in software maintenance and operations activities as well as how users
and project management team communicate with each other.

Documentation strategies: Provides a description of the documentation that is prepared

for user reference. Generally, documentation includes reports, information about problems
occurring in software, error messages, and the system documentation.

Training: Provides information about the training activities.

Acceptance: Defines a point of agreement between the project management team and
software maintenance team after the completion of implementation and transition activities.
Once the agreement has been made, the software maintenance begins.

Staffing Plan

The staffing plan describes the number of individuals required for a project. It includes
selecting and assigning tasks to the project management team members. It provides information
about appropriate skills required to perform the tasks to produce the project deliverables and
manage the project. In addition, it provides information of resources such as tools, equipment,
and processes used by the project management team.

Staff planning is performed by a staff planner, who is responsible for determining the
individuals available for the project. Other responsibilities of a staff planner are listed below.

The staff planner determines individuals, who can be from existing staff, staff on
contract, or newly employed staff. It is important for the staff planner to know the structure of
the organization to determine the availability of staff.

The staff planner determines the skills required to execute the tasks mentioned in the
project schedule and task plan. In case staff with required skills is not available, staff planner
informs the project manager about the requirements.

The staff planner ensures that the required staff with required skills is available at the
right time. For this purpose, the staff planner plans the availability of staff after the project
schedule is fixed. For example, at the initial stage of a project, staff may consist of a project
manager and a few software engineers whereas during software development, staff consists of
software designers as well as the software developers.

9|Page
 The staff planner defines roles and responsibilities of the project management team
members so that they can communicate and coordinate with each other according to the tasks
assigned to them. Note that the project management team can be further broken down into sub-
teams depending on the size and complexity of the project.

The staffing plan comprises the following sections.

General information: Provides information such as name of the project and project
manager who is responsible for the project. In addition, it specifies the start and end dates of the
project.

Skills assessment: Provides information, which is required for assessment of skills. This
information includes the knowledge, skill, and ability of team members who are required to
achieve the objectives of the project. In addition, it specifies the number of team members
required for the project.

Staffing profile: Describes the profile of the staff required for the project. The profile
includes calendar time, individuals involved, and level of commitment. Calendar time specifies
the period of time such as month or quarter for which individuals are required to complete the
project. Individuals who are involved in the project have specific designations such as project
manager and the developer. Level of commitment is the utilization rate of individuals such as
work performed on full-time and part-time basis.

Organization chart: Describes the organization of project management team members.

In addition, it includes information such as name, designation, and role of each team member.

4.2 SDLC-SOFTWARE DEVELOPMENT LIFE CYCLE

Software Development Life Cycle (SDLC) is a process used by the software industry to
design, develop and test high quality softwares. The SDLC aims to produce a high-quality
software that meets or exceeds customer expectations, reaches completion within times and cost
estimates.

 SDLC is the acronym of Software Development Life Cycle.

 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software development
process.
 ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be
the standard that defines all the tasks required for developing and maintaining software.

What is SDLC?

SDLC is a process followed for a software project, within a software organization. It

consists of a detailed plan describing how to develop, maintain, replace and alter or enhance
specific software. The life cycle defines a methodology for improving the quality of software and
the overall development process.

10 | P a g e
The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is

performed by the senior members of the team with inputs from the customer, the sales
department, market surveys and domain experts in the industry. This information is then used to
plan the basic project approach and to conduct product feasibility study in the economical,
operational and technical areas.

Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage. The outcome of the technical feasibility study
is to define the various technical approaches that can be followed to implement the project
successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This is

11 | P a g e
done through an SRS (Software Requirement Specification) document which consists of all
the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters
as risk assessment, product robustness, design modularity, budget and time constraints, the best
design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with
its communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the code.
Different high level programming languages such as C, C++, Pascal, Java and PHP are used for
coding. The programming language is chosen with respect to the type of software being
developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing
only stage of the product where product defects are reported, tracked, fixed and retested, until the
product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometimes product deployment happens in stages as per the business
strategy of that organization. The product may first be released in a limited segment and tested in
the real business environment (UAT- User acceptance testing).

12 | P a g e
 Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market, its
maintenance is done for the existing customer base.

Software Development Life Cycle, SDLC for short, is a well-defined, structured

sequence of stages in software engineering to develop the intended software product.

SDLC Activities

SDLC provides a series of steps to be followed to design and develop a software product
efficiently. SDLC framework includes the following steps:

Communication

This is the first step where the user initiates the request for a desired software product. He
contacts the service provider and tries to negotiate the terms. He submits his request to the
service providing organization in writing.

13 | P a g e
Requirement Gathering

This step onwards the software development team works to carry on the project. The
team holds discussions with various stakeholders from problem domain and tries to bring out as
much information as possible on their requirements. The requirements are contemplated and
segregated into user requirements, system requirements and functional requirements. The
requirements are collected using a number of practices as given -

 studying the existing or obsolete system and software,

 conducting interviews of users and developers,
 referring to the database or
 collecting answers from the questionnaires.

Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process. At
this step the 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. It is found out, if the project is
financially, practically and technologically feasible for the organization to take up. There are
many algorithms available, which help the developers to conclude the feasibility of a software
project.

System Analysis

At this step the developers decide a roadmap of their plan and try to bring up the best
software model suitable for the project. System analysis includes Understanding of software
product limitations, learning system related problems or changes to be done in existing systems
beforehand, identifying and addressing the impact of project on organization and personnel etc.
The project team analyzes the scope of the project and plans the schedule and resources
accordingly.

Software Design

Next step is to bring down whole knowledge of requirements and analysis on the desk
and design the software product. The inputs from users and information gathered in requirement
gathering phase are the inputs of this step. The output of this step comes in the form of two
designs; logical design and physical design. Engineers produce meta-data and data dictionaries,
logical diagrams, data-flow diagrams and in some cases pseudo codes.

Coding

This step is also known as programming phase. The implementation of software design
starts in terms of writing program code in the suitable programming language and developing
error-free executable programs efficiently.

14 | P a g e
Testing

An estimate says that 50% of whole software development process should be tested.
Errors may ruin the software from critical level to its own removal. Software testing is done
while coding by the developers and thorough testing is conducted by testing experts at various
levels of code such as module testing, program testing, product testing, in-house testing and
testing the product at user’s end. Early discovery of errors and their remedy is the key to reliable
software.

Integration

Software may need to be integrated with the libraries, databases and other program(s).
This stage of SDLC is involved in the integration of software with outer world entities.

Implementation

This means installing the software on user machines. At times, software needs post-
installation configurations at user end. Software is tested for portability and adaptability and
integration related issues are solved during implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and less errors. If
required, the users are trained on, or aided with the documentation on how to operate the
software and how to keep the software operational. The software is maintained timely by
updating the code according to the changes taking place in user end environment or technology.
This phase may face challenges from hidden bugs and real-world unidentified problems.

Disposition

As time elapses, the software may decline on the performance front. It may go
completely obsolete or may need intense upgradation. Hence a pressing need to eliminate a
major portion of the system arises. This phase includes archiving data and required software
components, closing down the system, planning disposition activity and terminating system at
appropriate end-of-system time.

4.3 SYSTEM DEVELOPMENT MODELS

SDLC, Software Development Life Cycle is a process used by software industry to

design, develop and test high quality software’s. The SDLC aims to produce a high quality
software that meets or exceeds customer expectations, reaches completion within times and cost
estimates.

 SDLC is the acronym of Software Development Life Cycle.

15 | P a g e
  It is also called as Software development process.

 The software development life cycle (SDLC) is a framework defining tasks performed at
each step in the software development process.

 ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to

be the standard that defines all the tasks required for developing and maintaining
software.

What is SDLC?

SDLC is a process followed for a software project, within a software organization. It

consists of a detailed plan describing how to develop, maintain, replace and alter or enhance
specific software. The life cycle defines a methodology for improving the quality of software
and the overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development life cycle consists of the following stages:

16 | P a g e
Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is

performed by the senior members of the team with inputs from the customer, the sales
department, market surveys and domain experts in the industry. This information is then used to
plan the basic project approach and to conduct product feasibility study in the economical,
operational, and technical areas.

Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage. The outcome of the technical feasibility
study is to define the various technical approaches that can be followed to implement the project
successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This is
done through .SRS. . Software Requirement Specification document which consists of all the
product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the product architecture

SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters
as risk assessment, product robustness, design modularity , budget and time constraints , the
best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with
its communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.

17 | P a g e
 Developers have to follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers etc are used to generate the code.
Different high level programming languages such as C, C++, Pascal, Java, and PHP are used for
coding. The programming language is chosen with respect to the type of software being
developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However this stage refers to the testing
only stage of the product where products defects are reported, tracked, fixed and retested, until
the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometime product deployment happens in stages as per the organizations.
business strategy. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market, its
maintenance is done for the existing customer base.

SDLC Models

There are various software development life cycle models defined and designed which
are followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development.

Following are the most important and popular SDLC models followed in the industry:

 Waterfall Model

 Iterative Model

 Spiral Model

 V-Model

 Big Bang Model

18 | P a g e
 The other related methodologies are Agile Model, RAD Model, Rapid Application
Development and Prototyping Models.

WATERFALL MODEL

The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in the
phases.

Waterfall model is the earliest SDLC approach that was used for software development .

The waterfall Model illustrates the software development process in a linear sequential
flow; hence it is also referred to as a linear-sequential life cycle model. This means that any
phase in the development process begins only if the previous phase is complete. In waterfall
model phases do not overlap.

Waterfall Model design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In Waterfall model, typically, the outcome of one
phase acts as the input for the next phase sequentially.

Following is a diagrammatic representation of different phases of waterfall model.

19 | P a g e
The sequential phases in Waterfall model are:

 Requirement Gathering and analysis: All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification doc.

 System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

 Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.

 Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.

 Deployment of system: Once the functional and non functional testing is done, the
product is deployed in the customer environment or released into the market.

 Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.

20 | P a g e
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model phases do not overlap.

Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be

followed based on the internal and external factors. Some situations where the use of Waterfall
model is most appropriate are:

 Requirements are very well documented, clear and fixed.

 Product definition is stable.

 Technology is understood and is not dynamic.

 There are no ambiguous requirements.

 Ample resources with required expertise are available to support the product.

 The project is short.

Waterfall Model Pros & Cons

Advantage
The advantage of waterfall development is that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product can
proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation,

troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order.

Disadvantage
The disadvantage of waterfall development is that it does not allow for much reflection
or revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.

21 | P a g e
The following table lists out the pros and cons of Waterfall model:

Pros Cons

 Simple and easy to  No working software is produced

understand and use until late during the life cycle.

 Easy to manage due to the  High amounts of risk and

rigidity of the model . uncertainty.
each phase has specific
deliverables and a review  Not a good model for complex and
process. object-oriented projects.

 Phases are processed and  Poor model for long and ongoing
completed one at a time. projects.

 Works well for smaller  Not suitable for the projects where
projects where requirements are at a moderate to
requirements are very well high risk of changing. So risk and
understood. uncertainty is high with this
process model.
 Clearly defined stages.
 It is difficult to measure progress
 Well understood within stages.
milestones.
 Cannot accommodate changing
 Easy to arrange tasks. requirements.

 Process and results are  No working software is produced

well documented. until late in the life cycle.

 Adjusting scope during the life

cycle can end a project.

 Integration is done as a "big-bang.

at the very end, which doesn't
allow identifying any technological
or business bottleneck or
challenges early.

22 | P a g e
INCREMENTAL MODEL

Incremental model in software engineering is a one which combines the elements of

waterfall model which are then applied in an iterative manner. It basically delivers a series of
releases called increments which provide progressively more functionality for the client as each
increment is delivered.

In incremental model of software engineering, waterfall model is repeatedly applied in

each increment. The incremental model applies linear sequences in a required pattern as calendar
time passes. Each linear sequence produces an increment in the work.
Diagram Of Incremental Model

Incremental Model

As from the diagram you can see that there are 5 phases(tasks) which are carried out in
each increment. If you want to see what activity is carried out in each phase then check out this
post : Phases of waterfall model as the phases are same .

The first increment is often a core product where the basic requirements are addressed
and the supplementary features are added in the next increments. The core product is used and
evaluated by the client. Once the core product is evaluated by the client there is plan
development for the next increment. Thus in every increment the needs of the client are kept in
mind and more features and functions are added and the core product is updated. This process
continues till the complete product is produced.

23 | P a g e
 The increments earlier to the main increment are called as “stripped down” versions of
the final product. These increments form a base for customer evaluation. On this basis client can
suggest new requirements if required.

If there are less number of employees to work on the project Incremental development
model is very useful to complete the project before the deadline. In a project early increments
can be done with less number of people. In case if the core product is well-defined and
understood more employees can be added if needed in the future increments.

One of the benefits of Incremental process model is that it can be planned to manage
technical risks.

Let’s now see the advantages and disadvantages of the incremental model.

Advantages Of Incremental Model

 Initial product delivery is faster.
 Lower initial delivery cost.
 Core product is developed first i.e main functionality is added in the first increment.
 After each iteration, regression testing should be conducted. During this testing, faulty elements
of the software can be quickly identified because few changes are made within any single
iteration.
 It is generally easier to test and debug than other methods of software development because
relatively smaller changes are made during each iteration. This allows for more targeted and
rigorous testing of each element within the overall product.
 With each release a new feature is added to the product.
 Customer can respond to feature and review the product.
 Risk of changing requirement is reduced
 Work load is less.

Disadvantages Of Incremental Model

 Requires good analysis.
 Resulting cost may exceed the cost of the organization.

24 | P a g e
 Each phase of an iteration is rigid and do not overlap each other.
 As additional functionality is added to the product, problems may arise related to system
architecture which were not evident in earlier prototypes.

SPIRAL MODEL

The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.

Spiral model is a combination of iterative development process model and sequential

linear development model i.e. waterfall model with very high emphasis on risk analysis.

It allows for incremental releases of the product, or incremental refinement through each
iteration around the spiral.

Spiral Model design

The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.

 Identification: This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication

between the customer and the system analyst. At the end of the spiral the product is
deployed in the identified market.

 Design: Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and
final design in the subsequent spirals.

 Construct or Build: Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design
is being developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.

Then in the subsequent spirals with higher clarity on requirements and design
details a working model of the software called build is produced with a version number.
These builds are sent to customer for feedback.

25 | P a g e
  Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.

Following is a diagrammatic representation of spiral model listing the activities in each phase:

Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback suggested by
the customer. The process of iterations along the spiral continues throughout the life of the
software.

Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the
natural development process of any product i.e. learning with maturity and also involves
minimum risk for the customer as well as the development firms. Following are the typical uses
of Spiral model:

 When costs there is a budget constraint and risk evaluation is important.

26 | P a g e
  For medium to high-risk projects.

 Long-term project commitment because of potential changes to economic priorities as

the requirements change with time.

 Customer is not sure of their requirements which is usually the case.

 Requirements are complex and need evaluation to get clarity.

 New product line which should be released in phases to get enough customer feedback.

 Significant changes are expected in the product during the development cycle.

Spiral Model Pros and Cons

The advantage of spiral lifecycle model is that it allows for elements of the product to be
added in when they become available or known. This assures that there is no conflict with
previous requirements and design.

This method is consistent with approaches that have multiple software builds and
releases and allows for making an orderly transition to a maintenance activity. Another positive
aspect is that the spiral model forces early user involvement in the system development effort.

On the other side, it takes very strict management to complete such products and there is
a risk of running the spiral in indefinite loop. So the discipline of change and the extent of
taking change requests is very important to develop and deploy the product successfully.

The following table lists out the pros and cons of Spiral SDLC Model:

Pros Cons

 Changing requirements can be  Management is more

accommodated. complex.

 Allows for extensive use of  End of project may not be

prototypes known early.

 Requirements can be captured  Not suitable for small or

more accurately. low risk projects and could
be expensive for small
 Users see the system early. projects.

27 | P a g e
  Development can be divided into  Process is complex
smaller parts and more risky parts
can be developed earlier which  Spiral may go indefinitely.
helps better risk management.
 Large number of
intermediate stages
requires excessive
documentation.

V-MODEL

The V - model is SDLC model where execution of processes happens in a sequential

manner in V-shape. It is also known as Verification and Validation model.

V - Model is an extension of the waterfall model and is based on association of a testing

phase for each corresponding development stage. This means that for every single phase in the
development cycle there is a directly associated testing phase. This is a highly disciplined model
and next phase starts only after completion of the previous phase.

V- Model design

Under V-Model, the corresponding testing phase of the development phase is planned in
parallel. So there are Verification phases on one side of the .V. and Validation phases on the
other side. Coding phase joins the two sides of the V-Model.

The below figure illustrates the different phases in V-Model of SDLC.

28 | P a g e
Verification Phases

Following are the Verification phases in V-Model:

 Business Requirement Analysis: This is the first phase in the development cycle where
the product requirements are understood from the customer perspective. This phase
involves detailed communication with the customer to understand his expectations and
exact requirement. This is a very important activity and need to be managed well, as
most of the customers are not sure about what exactly they need. The acceptance test
design planning is done at this stage as business requirements can be used as an input for
acceptance testing.

 System Design: Once you have the clear and detailed product requirements, it’s time to
design the complete system. System design would comprise of understanding and
detailing the complete hardware and communication setup for the product under
development. System test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for actual test execution later.

 Architectural Design: Architectural specifications are understood and designed in this

phase. Usually more than one technical approach is proposed and based on the technical
and financial feasibility the final decision is taken. System design is broken down
further into modules taking up different functionality. This is also referred to as High
Level Design (HLD).

29 | P a g e
 The data transfer and communication between the internal modules and with the outside
world (other systems) is clearly understood and defined in this stage. With this
information, integration tests can be designed and documented during this stage.

 Module Design: In this phase the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD). It is important that the design is
compatible with the other modules in the system architecture and the other external
systems. Unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. Unit tests can be designed at this
stage based on the internal module designs.

Coding Phase

The actual coding of the system modules designed in the design phase is taken up in the
Coding phase. The best suitable programming language is decided based on the system and
architectural requirements. The coding is performed based on the coding guidelines and
standards. The code goes through numerous code reviews and is optimized for best performance
before the final build is checked into the repository.

Validation Phases

Following are the Validation phases in V-Model:

 Unit Testing: Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and helps eliminate
bugs at an early stage, though all defects cannot be uncovered by unit testing.

 Integration Testing: Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and communication of the internal
modules within the system.

 System Testing: System testing is directly associated with the System design phase.
System tests check the entire system functionality and the communication of the system
under development with external systems. Most of the software and hardware
compatibility issues can be uncovered during system test execution.

 Acceptance Testing: Acceptance testing is associated with the business requirement

analysis phase and involves testing the product in user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user
environment. It also discovers the non functional issues such as load and performance
defects in the actual user environment.

30 | P a g e
V- Model Application

V- Model application is almost same as waterfall model, as both the models are of
sequential type. Requirements have to be very clear before the project starts, because it is
usually expensive to go back and make changes. This model is used in the medical development
field, as it is strictly disciplined domain. Following are the suitable scenarios to use V-Model:

 Requirements are well defined, clearly documented and fixed.

 Product definition is stable.

 Technology is not dynamic and is well understood by the project team.

 There are no ambiguous or undefined requirements.

 The project is short.

V- Model Pros and Cons

The advantage of V-Model is that it’s very easy to understand and apply. The simplicity
of this model also makes it easier to manage. The disadvantage is that the model is not flexible
to changes and just in case there is a requirement change, which is very common in today’s
dynamic world, it becomes very expensive to make the change.

The following table lists out the pros and cons of V-Model:

Pros Cons

 This is a highly disciplined  High risk and uncertainty.

model and Phases are completed
one at a time.
 Works well for smaller projects
where requirements are very
well understood.
 Simple and easy to understand
and use.
 Easy to manage due to the
rigidity of the model. each phase
 Not a good model for
complex and object-oriented
projects.
 Poor model for long and
ongoing projects.
 Not suitable for the projects
where requirements are at a
moderate to high risk of
changing.

31 | P a g e
 has specific deliverables and a  Once an application is in the
review process. testing stage, it is difficult to
go back and change a
functionality

 No working software is
produced until late during
the life cycle.

SOFTWARE PROTOTYPING

The Software Prototyping refers to building software application prototypes which

display the functionality of the product under development but may not actually hold the exact
logic of the original software.

Software prototyping is becoming very popular as a software development model, as it

enables to understand customer requirements at an early stage of development. It helps get
valuable feedback from the customer and helps software designers and developers understand
about what exactly is expected from the product under development.

What is Software Prototyping?

 Prototype is a working model of software with some limited functionality.

 The prototype does not always hold the exact logic used in the actual software
application and is an extra effort to be considered under effort estimation.

 Prototyping is used to allow the users evaluate developer proposals and try them out
before implementation.

 It also helps understand the requirements which are user specific and may not have been
considered by the developer during product design.

Following is the stepwise approach to design a software prototype:

 Basic Requirement Identification: This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details of
the internal design and external aspects like performance and security can be ignored at
this stage.

32 | P a g e
  Developing the initial Prototype: The initial Prototype is developed in this stage, where
the very basic requirements are showcased and user interfaces are provided. These
features may not exactly work in the same manner internally in the actual software
developed and the workarounds are used to give the same look and feel to the customer
in the prototype developed.

 Review of the Prototype: The prototype developed is then presented to the customer
and the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under development.

 Revise and enhance the Prototype: The feedback and the review comments are
discussed during this stage and some negotiations happen with the customer based on
factors like, time and budget constraints and technical feasibility of actual
implementation. The changes accepted are again incorporated in the new Prototype
developed and the cycle repeats until customer expectations are met.

Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the
user interface for the product and gives a broader view of the entire system, without
concentrating on internal functions. A vertical prototype on the other side is a detailed
elaboration of a specific function or a sub system in the product.

The purpose of both horizontal and vertical prototype is different. Horizontal prototypes
are used to get more information on the user interface level and the business requirements. It
can even be presented in the sales demos to get business in the market. Vertical prototypes are
technical in nature and are used to get details of the exact functioning of the sub systems. For
example, database requirements, interaction and data processing loads in a given sub system.

Software Prototyping Types

There are different types of software prototypes used in the industry. Following are the
major software prototyping types used widely:

 Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or

close ended prototyping. This type of prototyping uses very little efforts with minimum
requirement analysis to build a prototype. Once the actual requirements are understood,
the prototype is discarded and the actual system is developed with a much clear
understanding of user requirements.

 Evolutionary Prototyping: Evolutionary prototyping also called as breadboard

prototyping is based on building actual functional prototypes with minimal functionality
in the beginning. The prototype developed forms the heart of the future prototypes on
top of which the entire system is built. Using evolutionary prototyping only well

33 | P a g e
 understood requirements are included in the prototype and the requirements are added as
and when they are understood.

 Incremental Prototyping: Incremental prototyping refers to building multiple

functional prototypes of the various sub systems and then integrating all the available
prototypes to form a complete system.

 Extreme Prototyping : Extreme prototyping is used in the web development domain. It

consists of three sequential phases. First, a basic prototype with all the existing pages is
presented in the html format. Then the data processing is simulated using a prototype
services layer. Finally the services are implemented and integrated to the final prototype.
This process is called Extreme Prototyping used to draw attention to the second phase of
the process, where a fully functional UI is developed with very little regard to the actual
services.

Software Prototyping Application

Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go through
various screens before data is processed can use prototyping very effectively to give the exact
look and feel even before the actual software is developed.

Software that involves too much of data processing and most of the functionality is internal with
very little user interface does not usually benefit from prototyping. Prototype development
could be an extra overhead in such projects and may need lot of extra efforts.

Software Prototyping Pros and Cons

Software prototyping is used in typical cases and the decision should be taken very
carefully so that the efforts spent in building the prototype add considerable value to the final
software developed. The model has its own pros and cons discussed as below.

Following table lists out the pros and cons of Big Bang Model:

Pros Cons

 Increased user involvement in  Risk of insufficient requirement

the product even before analysis owing to too much
implementation dependency on prototype

34 | P a g e
  Since a working model of the
system is displayed, the users
get a better understanding of
the system being developed.
 Reduces time and cost as the
defects can be detected much
earlier.
 Users may get confused in the
prototypes and actual systems.
 Practically, this methodology
may increase the complexity of
the system as scope of the
system may expand beyond
original plans.

 Quicker user feedback is  Developers may try to reuse the

available leading to better existing prototypes to build the
solutions. actual system, even when its not
technically feasible
 Missing functionality can be
identified easily  The effort invested in building
prototypes may be too much if
 Confusing or difficult not monitored properly
functions can be identified

RAD MODEL

The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself involves the
planning required for developing the product.

Rapid Application development focuses on gathering customer requirements through

workshops or focus groups, early testing of the prototypes by the customer using iterative
concept, reuse of the existing prototypes (components), continuous integration and rapid
delivery.

What is RAD?

Rapid application development (RAD) is a software development methodology that uses

minimal planning in favor of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.

In RAD model the functional modules are developed in parallel as prototypes and are
integrated to make the complete product for faster product delivery.

Since there is no detailed preplanning, it makes it easier to incorporate the changes

within the development process. RAD projects follow iterative and incremental model and have
35 | P a g e
small teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.

The most important aspect for this model to be successful is to make sure that the prototypes
developed are reusable.

RAD Model Design

RAD model distributes the analysis, design, build, and test phases into a series of short,
iterative development cycles. Following are the phases of RAD Model:

 Business Modeling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.

 Data Modeling: The information gathered in the Business Modeling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established and
defined in detail in relevance to the business model.

 Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for
adding , deleting, retrieving or modifying a data object are given.

 Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.

 Testing and Turnover: The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow and
the interfaces between all the components need to be thoroughly tested with complete
test coverage. Since most of the programming components have already been tested, it
reduces the risk of any major issues.

36 | P a g e
Following image illustrates the RAD Model:

RAD Model Vs Traditional SDLC

The traditional SDLC follows a rigid process models with high emphasis on requirement
analysis and gathering before the coding starts. It puts a pressure on the customer to sign off the
requirements before the project starts and the customer doesn.t get the feel of the product as
there is no working build available for a long time.

The customer may need some changes after he actually gets to see the software, however
the change process is quite rigid and it may not be feasible to incorporate major changes in the
product in traditional SDLC.

RAD model focuses on iterative and incremental delivery of working models to the
customer. This results in rapid delivery to the customer and customer involvement during the
complete development cycle of product reducing the risk of non conformance with the actual
user requirements.

37 | P a g e
RAD Model Application

RAD model can be applied successfully to the projects in which clear modularization is
possible. If the project cannot be broken into modules, RAD may fail. Following are the typical
scenarios where RAD can be used:

 RAD should be used only when a system can be modularized to be delivered in

incremental manner.

 It should be used if there’s high availability of designers for modeling.

 It should be used only if the budget permits use of automated code generating tools.

 RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.

 Should be used where the requirements change during the course of the project and
working prototypes are to be presented to customer in small iterations of 2-3 months.

RAD Model Pros and Cons

RAD model enables rapid delivery as it reduces the overall development time due to
reusability of the components and parallel development.

RAD works well only if high skilled engineers are available and the customer is also
committed to achieve the targeted prototype in the given time frame. If there is commitment
lacking on either side the model may fail.

Following table lists out the pros and cons of RAD Model:

Pros Cons

 Changing requirements can  Dependency on technically strong

be accommodated. team members for identifying
business requirements.
 Progress can be measured.
 Only system that can be
 Iteration time can be short modularized can be built using
with use of powerful RAD RAD.
tools.
 Requires highly skilled
 Productivity with fewer

38 | P a g e
 people in short time. developers/designers.

 Reduced development  High dependency on modeling

time. skills.

 Increases reusability of  Inapplicable to cheaper projects as

components
 Quick initial reviews occur
 Encourages customer
feedback
 Integration from very
beginning solves a lot of
integration issues.
cost of modeling and automated
code generation is very high.
 Management complexity is more.
 Suitable for systems that are
component based and scalable.
 Requires user involvement
throughout the life cycle.

 Suitable for project requiring

shorter development times.

BIG-BANG MODEL

The Big Bang model is SDLC model where we do not follow any specific process. The
development just starts with the required money and efforts as the input, and the output is the
software developed which may or may not be as per customer requirement.

Big Bang Model is SDLC model where there is no formal development followed and
very little planning is required. Even the customer is not sure about what exactly he wants and
the requirements are implemented on the fly without much analysis.

Usually this model is followed for small projects where the development teams are very
small.

Big Bang Model design and Application

Big bang model comprises of focusing all the possible resources in software
development and coding, with very little or no planning. The requirements are understood and
implemented as they come. Any changes required may or may not need to revamp the complete
software.

39 | P a g e
 This model is ideal for small projects with one or two developers working together and is
also useful for academic or practice projects. It.s an ideal model for the product where
requirements are not well understood and the final release date is not given.

Big Bang Model Pros and Cons

The advantage of Big Bang is that its very simple and requires very little or no planning.
Easy to mange and no formal procedure are required.

However the Big Bang model is a very high risk model and changes in the requirements
or misunderstood requirements may even lead to complete reversal or scraping of the project. It
is ideal for repetitive or small projects with minimum risks.

Following table lists out the pros and cons of Big Bang Model:

Pros Cons

 This is a very simple  Very High risk and uncertainty.

model
 Not a good model for complex and
 Little or no planning object-oriented projects.
required
 Poor model for long and ongoing
 Easy to manage projects.

 Very few resources  Can turn out to be very expensive if

required requirements are misunderstood

 Gives flexibility to
developers

 Is a good learning aid for

new comers or students

ITERATIVE MODEL

In Iterative model, iterative process starts with a simple implementation of a small set of
the software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.

40 | P a g e
 An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements. This process is then
repeated, producing a new version of the software at the end of each iteration of the model.

Iterative Model design

Iterative process starts with a simple implementation of a subset of the software

requirements and iteratively enhances the evolving versions until the full system is implemented.
At each iteration, design modifications are made and new functional capabilities are added. The
basic idea behind this method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental).

Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or

iterative method and incremental build model for development. "During software development,
more than one iteration of the software development cycle may be in progress at the same time."
and "This process may be described as an "evolutionary acquisition" or "incremental build"
approach."

In incremental model the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation and
testing phases. Each subsequent release of the module adds function to the previous release. The
process continues till the complete system is ready as per the requirement.

The key to successful use of an iterative software development lifecycle is rigorous

validation of requirements, and verification & testing of each version of the software against
those requirements within each cycle of the model. As the software evolves through successive
cycles, tests have to be repeated and extended to verify each version of the software.

41 | P a g e
Iterative Model Application

Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following scenarios:

 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested

enhancements may evolve with time.

 There is a time to the market constraint.

 A new technology is being used and is being learnt by the development team while
working on the project.

 Resources with needed skill set are not available and are planned to be used on contract
basis for specific iterations.

 There are some high risk features and goals which may change in the future.

Iterative Model Pros and Cons

The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding issues at
an early stage of development enables to take corrective measures in a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software system into
further small serviceable increments/modules.

The following table lists out the pros and cons of Iterative and Incremental SDLC Model:

Pros Cons

 Some working functionality  More resources may be required.

can be developed quickly
and early in the life cycle.  Although cost of change is lesser
but it is not very suitable for
 Results are obtained early changing requirements.
and periodically.
 More management attention is
 Parallel development can be

42 | P a g e
 planned. required.

 Progress can be measured.  System architecture or design

issues may arise because not all
 Less costly to change the requirements are gathered in the
scope/requirements. beginning of the entire life cycle.

 Testing and debugging  Defining increments may require

during smaller iteration is definition of the complete
easy. system.

 Risks are identified and  Not suitable for smaller projects.

resolved during iteration;
and each iteration is an  Management complexity is more.
easily managed milestone.
 End of project may not be known
 Easier to manage risk - High which is a risk.
risk part is done first.
 Highly skilled resources are
 With every increment required for risk analysis.
operational product is
delivered.  Project’s progress is highly
dependent upon the risk analysis
 Issues, challenges & risks phase.
identified from each
increment can be
utilized/applied to the next
increment.

 Risk analysis is better.

 It supports changing
requirements.

 Initial Operating time is less.

 Better suited for large and

mission-critical projects.

 During life cycle software is

produced early which
facilitates customer

43 | P a g e
 evaluation and feedback.

4.4 PROJECT MANAGEMENT

Software Project Management

The job pattern of an IT company engaged in software development can be seen split in
two parts:

 Software Creation
 Software Project Management

A project is well-defined task, which is a collection of several operations done in order to

achieve a goal (for example, software development and delivery). A Project can be characterized
as:

 Every project may has a unique and distinct goal.

 Project is not routine activity or day-to-day operations.
 Project comes with a start time and end time.
 Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.
 Project needs adequate resources in terms of time, manpower, finance, material and
knowledge-bank.

Software Project

A Software Project is the complete procedure of software development from requirement

gathering to testing and maintenance, carried out according to the execution methodologies, in a
specified period of time to achieve intended software product.

Need of software project management

Software is said to be an intangible product. Software development is a kind of all new

stream in world business and there’s very little experience in building software products. Most
software products are tailor made to fit client’s requirements. The most important is that the
underlying technology changes and advances so frequently and rapidly that experience of one
product may not be applied to the other one. All such business and environmental constraints
bring risk in software development hence it is essential to manage software projects efficiently.

44 | P a g e
 The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget constrain
and deliver the project as per scheduled. There are several factors, both internal and external,
which may impact this triple constrain triangle. Any of three factor can severely impact the other
two.

Therefore, software project management is essential to incorporate user requirements

along with budget and time constraints.

Software Project Manager

A software project manager is a person who undertakes the responsibility of executing

the software project. Software project manager is thoroughly aware of all the phases of SDLC
that the software would go through. Project manager may never directly involve in producing the
end product but he controls and manages the activities involved in production.

A project manager closely monitors the development process, prepares and executes
various plans, arranges necessary and adequate resources, maintains communication among all
team members in order to address issues of cost, budget, resources, time, quality and customer
satisfaction.

Let us see few responsibilities that a project manager shoulders -

Managing People

 Act as project leader

 Liaison with stakeholders
 Managing human resources
 Setting up reporting hierarchy etc.

Managing Project

 Defining and setting up project scope

 Managing project management activities
 Monitoring progress and performance

45 | P a g e
  Risk analysis at every phase
 Take necessary step to avoid or come out of problems
 Act as project spokesperson

Software Management Activities

Software project management comprises of a number of activities, which contains

planning of project, deciding scope of software product, estimation of cost in various terms,
scheduling of tasks and events, and resource management. Project management activities may
include:

 Project Planning
 Scope Management
 Project Estimation

Project Planning

Software project planning is task, which is performed before the production of software
actually starts. It is there for the software production but involves no concrete activity that has
any direction connection with software production; rather it is a set of multiple processes, which
facilitates software production. Project planning may include the following:

Scope Management

It defines the scope of project; this includes all the activities, process need to be done in
order to make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what would
not be done. This makes project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun.

During Project Scope management, it is necessary to -

 Define the scope

 Decide its verification and control
 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope

Project Estimation

For an effective management accurate estimation of various measures is a must. With

correct estimation managers can manage and control the project more efficiently and effectively.

Project estimation may involve the following:

 Software size estimation

46 | P a g e
 Software size may be estimated either in terms of KLOC (Kilo Line of Code) or
by calculating number of function points in the software. Lines of code depend upon
coding practices and Function points vary according to the user or software requirement.

 Effort estimation

The managers estimate efforts in terms of personnel requirement and man-hour

required to produce the software. For effort estimation software size should be known.
This can either be derived by managers’ experience, organization’s historical data or
software size can be converted into efforts by using some standard formulae.

 Time estimation

Once size and efforts are estimated, the time required to produce the software can
be estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks
are divided into smaller tasks, activities or events by Work Breakthrough Structure
(WBS). The tasks are scheduled on day-to-day basis or in calendar months.

The sum of time required to complete all tasks in hours or days is the total time
invested to complete the project.

 Cost estimation

This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to
consider -

o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support

Project Estimation Techniques

We discussed various parameters involving project estimation such as size, effort, time
and cost. Project manager can estimate the listed factors using two broadly recognized
techniques –

Decomposition Technique

This technique assumes the software as a product of various compositions.

47 | P a g e
There are two main models -

 Line of Code Estimation is done on behalf of number of line of codes in the software
product.
 Function Points Estimation is done on behalf of number of function points in the
software product.

Empirical Estimation Technique

This technique uses empirically derived formulae to make estimation.These formulae are
based on LOC or FPs.

 Putnam Model

This model is made by Lawrence H. Putnam, which is based on Norden’s frequency

distribution (Rayleigh curve). Putnam model maps time and efforts required with
software size.

 COCOMO

COCOMO stands for COnstructive COst MOdel, developed by Barry W. Boehm. It

divides the software product into three categories of software: organic, semi-detached and
embedded.

Project Scheduling

Project Scheduling in a project refers to roadmap of all activities to be done with

specified order and within time slot allotted to each activity. Project managers tend to define
various tasks, and project milestones and them arrange them keeping various factors in mind.
They look for tasks lie in critical path in the schedule, which are necessary to complete in
specific manner (because of task interdependency) and strictly within the time allocated.
Arrangement of tasks which lies out of critical path are less likely to impact over all schedule of
the project.

For scheduling a project, it is necessary to -

 Break down the project tasks into smaller, manageable form

 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Calculate total time required for the project from start to finish

48 | P a g e
Resource management

All elements used to develop a software product may be assumed as resource for that
project. This may include human resource, productive tools and software libraries.

The resources are available in limited quantity and stay in the organization as a pool of
assets. The shortage of resources hampers the development of project and it can lag behind the
schedule. Allocating extra resources increases development cost in the end. It is therefore
necessary to estimate and allocate adequate resources for the project.

Resource management includes -

 Defining proper organization project by creating a project team and allocating

responsibilities to each team member
 Determining resources required at a particular stage and their availability
 Manage Resources by generating resource request when they are required and de-
allocating them when they are no more needed.

Project Risk Management

Risk management involves all activities pertaining to identification, analyzing and

making provision for predictable and non-predictable risks in the project. Risk may include the
following:

 Experienced staff leaving the project and new staff coming in.
 Change in organizational management.
 Requirement change or misinterpreting requirement.
 Under-estimation of required time and resources.
 Technological changes, environmental changes, business competition.

Risk Management Process

There are following activities involved in risk management process:

 Identification - Make note of all possible risks, which may occur in the project.
 Categorize - Categorize known risks into high, medium and low risk intensity as per
their possible impact on the project.
 Manage - Analyze the probability of occurrence of risks at various phases. Make plan to
avoid or face risks. Attempt to minimize their side-effects.
 Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the
effects of steps taken to mitigate or avoid them.

Project Execution & Monitoring

In this phase, the tasks described in project plans are executed according to their
schedules.

49 | P a g e
 Execution needs monitoring in order to check whether everything is going according to
the plan. Monitoring is observing to check the probability of risk and taking measures to address
the risk or report the status of various tasks.

These measures include -

 Activity Monitoring - All activities scheduled within some task can be monitored on
day-to-day basis. When all activities in a task are completed, it is considered as complete.
 Status Reports - The reports contain status of activities and tasks completed within a
given time frame, generally a week. Status can be marked as finished, pending or work-
in-progress etc.
 Milestones Checklist - Every project is divided into multiple phases where major tasks
are performed (milestones) based on the phases of SDLC. This milestone checklist is
prepared once every few weeks and reports the status of milestones.

Project Communication Management

Effective communication plays vital role in the success of a project. It bridges gaps
between client and the organization, among the team members as well as other stake holders in
the project such as hardware suppliers.

Communication can be oral or written. Communication management process may have

the following steps:

 Planning - This step includes the identifications of all the stakeholders in the project and
the mode of communication among them. It also considers if any additional
communication facilities are required.
 Sharing - After determining various aspects of planning, manager focuses on sharing
correct information with the correct person on correct time. This keeps every one
involved the project up to date with project progress and its status.
 Feedback - Project managers use various measures and feedback mechanism and create
status and performance reports. This mechanism ensures that input from various
stakeholders is coming to the project manager as their feedback.
 Closure - At the end of each major event, end of a phase of SDLC or end of the project
itself, administrative closure is formally announced to update every stakeholder by
sending email, by distributing a hardcopy of document or by other mean of effective
communication.

After closure, the team moves to next phase or project.

Configuration Management

Configuration management is a process of tracking and controlling the changes in

software in terms of the requirements, design, functions and development of the product.

50 | P a g e
 IEEE defines it as “the process of identifying and defining the items in the system,
controlling the change of these items throughout their life cycle, recording and reporting the
status of items and change requests, and verifying the completeness and correctness of items”.

Generally, once the SRS is finalized there is less chance of requirement of changes from
user. If they occur, the changes are addressed only with prior approval of higher management, as
there is a possibility of cost and time overrun.

Baseline

A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that

defines completeness of a phase. A phase is baselined when all activities pertaining to it are
finished and well documented. If it was not the final phase, its output would be used in next
immediate phase.

Configuration management is a discipline of organization administration, which takes

care of occurrence of any change (process, requirement, technological, strategical etc.) after a
phase is baselined. CM keeps check on any changes done in software.

Change Control

Change control is function of configuration management, which ensures that all changes
made to software system are consistent and made as per organizational rules and regulations.

A change in the configuration of product goes through following steps -

 Identification - A change request arrives from either internal or external source. When
change request is identified formally, it is properly documented.
 Validation - Validity of the change request is checked and its handling procedure is
confirmed.
 Analysis - The impact of change request is analyzed in terms of schedule, cost and
required efforts. Overall impact of the prospective change on system is analyzed.
 Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is
incorporated into the system. It is decided if the change is worth incorporation or not. If it
is not, change request is refused formally.
 Execution - If the previous phase determines to execute the change request, this phase
take appropriate actions to execute the change, does a thorough revision if necessary.
 Close request - The change is verified for correct implementation and merging with the
rest of the system. This newly incorporated change in the software is documented
properly and the request is formally is closed.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project, even when
the project is developed according to set methodologies.

51 | P a g e
 There are tools available, which aid for effective project management. A few are
described -

Gantt Chart

Gantt charts was devised by Henry Gantt (1917). It represents project schedule with
respect to time periods. It is a horizontal bar chart with bars representing activities and time
scheduled for the project activities.

PERT Chart

PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as
network diagram. It is capable of graphically representing main events of project in both parallel
and consecutive way. Events, which occur one after another, show dependency of the later event
over the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows depicting
sequence of tasks in the project.

52 | P a g e
Resource Histogram

This is a graphical tool that contains bar or chart representing number of resources
(usually skilled staff) required over time for a project event (or phase). Resource Histogram is an
effective tool for staff planning and coordination.

Critical Path Analysis

This tools is useful in recognizing interdependent tasks in the project. It also helps to find
out the shortest path or critical path to complete the project successfully. Like PERT diagram,
each event is allotted a specific time frame. This tool shows dependency of event assuming an
event can proceed to next only if the previous one is completed.

The events are arranged according to their earliest possible start time. Path between start
and end node is critical path which cannot be further reduced and all events require to be
executed in same order.

53 | P a g e
4.5 SYSTEM ANALYSIS

Systems analysis is a problem solving technique that decomposes a system into its
component pieces for the purpose of the studying how well those component parts work and
interact to accomplish their purpose".According to the Merriam-Webster dictionary, systems
analysis is "the process of studying a procedure or business in order to identify its goals and
purposes and create systems and procedures that will achieve them in an efficient way". Analysis
and synthesis, as scientific methods, always go hand in hand; they complement one another.
Every synthesis is built upon the results of a preceding analysis, and every analysis requires a
subsequent synthesis in order to verify and correct its results.

This field is closely related to requirements analysis or operations research. It is also "an
explicit formal inquiry carried out to help someone (referred to as the decision maker) identify a
better course of action and make a better decision than she might otherwise have made.

Overview

The terms analysis and synthesis stem from Greek, meaning "to take apart" and "to put
together," respectfully. These terms are used in many scientific disciplines, from mathematics
and logic to economics and psychology, to denote similar investigative procedures. Analysis is
defined as "the procedure by which we break down an intellectual or substantial whole into
parts," while synthesis means "the procedure by which we combine separate elements or
components in order to form a coherent whole." [3] Systems analysis researchers apply
methodology to the systems involved, forming an overall picture. System analysis is used in
every field where something is developed. Analysis can also be a series of components that
perform organic functions together, such as system engineering. Systems engineering is an
interdisciplinary field of engineering that focuses on how complex engineering projects should
be designed and managed.

Information technology

The development of a computer-based information system includes a systems analysis

phase. This helps produce the data model, a precursor to creating or enhancing a database (see
Christopher J. Date "An Introduction to Database Systems"). There are a number of different
approaches to system analysis. When a computer-based information system is developed,
systems analysis (according to the Waterfall model) would constitute the following steps:

54 | P a g e
 The development of a feasibility study: determining whether a project is economically,
socially, technologically and organizationally feasible

Fact-finding measures, designed to ascertain the requirements of the system's end-users

(typically involving interviews, questionnaires, or visual observations of work on the existing
system)

Gauging how the end-users would operate the system (in terms of general experience in
using computer hardware or software), what the system would be used for and so on

Another view outlines a phased approach to the process. This approach breaks systems
analysis into 5 phases:

 Scope Definition: denoting an instrument for observing, viewing, or examining

 Problem analysis: analyzing the problem that arises
 Requirements analysis: determining the conditions that need to be met
 Logical design: looking at the logical relationship among the objects
 Decision analysis: making a final decision

Use cases are widely used systems analysis modeling tools for identifying and expressing
the functional requirements of a system. Each use case is a business scenario or event for which
the system must provide a defined response. Use cases evolved from object-oriented analysis.

The Need For System Analysis

When you asked to computerize a system, as a requirement of the data processing or

the information need, it is necessary to analyze the system from different angles. While
satisfying such need, the analysis of the system is the basic necessity for an efficient system
design. The need for analysis stems from the following point of view.

System Objective: It is necessary to define the system objective(s). Many a times, it is

observed that the systems are historically in operation and have lost their main purpose of
achievement of the objectives. The users of the system and the personnel involved are not in a
position to define the objective(s). Since you are going to develop a computer based system, it is
necessary to redefine or reset the objective(s) as a reference point in the context of the current
business requirement.

System Boundaries: It is necessary to establish the system boundaries which would define the
scope and the coverage of the system. This helps to sort out and understand the functional
boundaries of the system, the department boundaries in the system, and the people involved in
the system. It also helps to identify the inputs and the outputs of the various sub-systems
covering the entire system.

55 | P a g e
System Importance: It is necessary to understand the importance of the system in the
organization. This would throw more light on its utility and would help the designer to decide
the design features of the system. It would be possible then to position the system in relation to
the other systems for deciding the design strategy and development.

Nature of The System: The analysis of the system will help the system designer to conclude
whether the system is the closed type or open, and a deterministic or probabilistic. Such an
understanding of the system is necessary, prior to design the process to ensure the necessary
design architecture.

Role of the System as an Interface: The system, many a times, acts as an interface to the other
systems. Hence through such an interface, it activates or promotes some changes in the other
systems. It is necessary to understand the existing role of the system, as an interface, to
safeguard the interests of the other systems. Any modifications or changes made should not
affect the functioning or the objective of the other systems.

Participation of Users: The strategic purpose of the analysis of the system is to seek the
acceptance of the people to a new development. System analysis process provides a sense of
participation to the people. This helps in breaking the resistance to the new development and it
also ensure the commitment to the new system.

Understanding of Resource Needs: The analysis of the system helps in defining the resource
requirements in terms of hardware and software. Hence, if any additional resources are required,
this would mean an investment. The management likes to evaluate the investment form the point
of view of return on such investment. If the return on the investment is not attractive, the
management may drop the project.

Assessment of Feasibility: The analysis of the system helps to establish the feasibility from
different angles. The system should satisfy the technical, economic and operational feasibility.

Many times, the systems are feasible from the technical and economic point of view: but
they may be infeasible from the operational point of view.

The assessment of feasibility will save the investment and the system designer's time. It
would also save the embarrassment to the system designer as he is viewed as the key figure in
such projects. One can approach the system analysis and design exercise in a systematic manner
in steps, as shown in the Table below :

Steps Elaboration Explanation

Need for information
Define the Systems
Define the nature of Identify the users and
information. Also who application of the
wants and who uses. information for achieving
the objectives.
Decide the nature, type of Helps to determine the

56 | P a g e
 the system and its scope
Feasibility Technical success
Economic viability
system ownership, its
benefits and complexity.
Hardware and software
availability and capability,
for implementation.

Study the investment and

Operational effectiveness benefits. Assess the
improvement in value of the
information. Determine the
return on investment.

Examine whether the

system will perform as
desired in terms of time and
results. Are the users ready
to use the system?
Detailing the requirements Identify in precise terms, Study the sources of
the strategic, functional and generating the
operational information Information. Establish I/O
needs. linkages. Modify the
existing system to satisfy
the needs.
Conceptual system Determine the inputs, Conceptualization is
process and outputs, and necessary to understand the
design a conceptual model. system process.
Detailing the system Draw the document flow Helps in bringing a clarity
charts and the data-flow in the data-flow. The
diagrams, the data and responsibility centres and
system hierarchy diagrams, the process centres are
the data information versus identified.
its users mapping table.
Structuring the system Break the system into its Helps in understanding the
design hierarchical structure. data-flow from one level to
the other and the processes
carried out at each level.
Conceptual model of Define step by step the Helps to put down the data
computer system usage of files, processes and processing flow in the
interface. Define the data computerized system. Draw
structures and the validation the computer system charts.
procedures.
Break the system in Make a physical conversion Modules will be data entry,
programme modules of the system into the data validation, data
programme structures in a processing, reporting and
logical order. storing.
Develop the test data for Test the modules and the Confirms whether the

57 | P a g e
checking the system ability
Install the system
Implementation
Review and maintenance
integrity of the system in system design is
terms of input versus satisfactory. Suggests the
output. Plan while box and modifications.
black box testing.
Install on the hardware. Install, test and run the
system before the user is
exposed in alive mode.
Train the personnel. Run Help to identify the
the system in parallel. problems and provide
Prepare a system manual. solutions.
Review the system through Helps to maintain the
audit trail and test data, also system quality and the
confirm whether the quality of information
objective is fulfilled. Carry through modification, if
out the modifications, if necessary.
any.

REQUIREMENT DETERMINATION

Requirements determination and requirements structuring are two core components of

system analysis. Traditionally, interviewing, questionnaires, directly observing and analyzing
documents are four main methods adopted by system analysts to collect information. JAD and
prototyping are two modern requirements determination methodologies, which are developed
and based on the previous traditional methods. A well-structured representation of system
requirements can dramatically improve the communication among analysts, designers, users, and
programmers. DFD, structured English, decision tables, decision trees, and E-R diagrams are
traditional primary requirements structuring tools. Nowadays, RAD and OOA are emerging to
help streamline and shorten the total SDLC. While RAD SDLC packs traditional analysis phase
and part of design phase into one step, OOA tries to make the outcomes of analysis phase can be
reused by the following developing phases.

Analysis is the first SDLC phase where we begin to understand, in depth, the needs for
system. System analysis involves a substantial amount of effort and cost and is therefore
undertaken only after management had decided that the systems development project under
consideration has merit and should be pursed through this phase. Most observers would agree
than many of the errors in developed system are directly traceable to inadequate efforts in the
analysis and design phases of the life cycle. Industry studies show that 56% of systems problems
are based on poor requirements definition, as opposed to 7% that are caused by poor coding. In
the maintenance arena, 82% of the effort is due to poor requirements as opposed to 1% for poor
coding.[1] However, for many reasons, it is difficult to obtain a correct and complete set of
requirements. [12]

58 | P a g e
 As analysis can be divided into three main activities: Requirement determination,
Requirements Structuring, and Alternative generation and selection. The third one is usually
regarded as the automatic result from the first two processes. So, in this article, I focus on
requirements determination and requirements structuring.

Requirements determination is the beginning sub phase of analysis. In this sub phase,
analysts should gather information on what the system should do from as many sources as
possible. There are some traditional methods to help collecting system requirements, such as
interviewing, survey, directly observing users, etc. Nowadays, some modern requirements
colleting methods, such as JAD and prototyping, emerged.

Requirements structuring is the process to use some kind of systematical and standard, well-
structured methods to model the real world. Traditionally, we use data flow diagram for process
modeling, decision table or decision tree for logic modeling, and Entity-relationship diagram for
data modeling. These modeling tools usually separately model only one face of the real world.
So, when we try to show the integral picture of a system, we usually choose more than one of the
above requirements structuring methods.

Rapid Application Development (RAD) is an approach that promises better and cheaper
systems and more rapid deployment by having system developers and end users work tighter
jointly in real-time to develop systems. Usually, RAD allows usable systems to be built in as
little as 60-90 days. [14] RAD is not a single methodology but is more a general strategy of
developing information systems. It brings several system development components together.
Nowadays, a lot of RAD tools are available, such as VB for windows application, MBBuilder for
MapInfo MapBasic.

Object-oriented analysis and development is a brand new methodology. Although OOP has
become popular in computer world, whether OOA is superior to traditional methods is still a
question mark. However, from the view of OO world, OOA seems having an important role to
play in the future.

The objectives of this article are to introduce some widely adopted basic requirements
determination and requirements structuring methods, compare and contrast those methods and
try to find a best way for system requirements analysis.

Requirements Determination

Collection of information is at the core of systems analysis. Information requirement

determination (IRD) is frequently and convincingly presented as the most critical phase of
information system (IS) development, and many IS failures have been attributed to incomplete
59 | P a g e
and inaccurate information requirements. [13] System analysts must collect the information
about the current system and how users would like to improve their performance with new
information system. Accurately understanding the users’ requirements will help the system
developing team deliver a proper system to the end users in limited time and limited budget. If
user just wants an “ant”, definitely, an “elephant” is improper. There are many methods to collect
information. This article will discuss some basic and widely adopted ones of them.

Interviewing is one of the primary ways to gather information about an information

system. A good system analyst must be good at interviewing and no project can be conduct
without interviewing. There are many ways to arrange an effectively interview and no one is
superior to others. However, experience analysts commonly accept some following best practices
for an effective interview:

Prepare the interview carefully, including appointment, priming question, checklist,

agenda, and questions.

 Listen carefully and take note during the interview (tape record if possible)
 Review notes within 48 hours after interview
 Be neutral
 Seek diverse views

Questionnaires have the advantage of gathering information from many people in a relatively
short time and of being less biased in the interpretation of their results. Choosing right
questionnaires respondents and designing effective questionnaires are the critical issues in this
information collection method. People usually are only use a part of functions of a system, so
they are always just familiar with a part of the system functions or processes. In most situations,
one copy of questionnaires obviously cannot fit to all the users. To conduct an effective survey,
the analyst should group the users properly and design different questionnaires for different
group. Moreover, the ability to build good questionnaires is a skill that improves with practice
and experience. When designing questionnaires, the analyst should concern the following issues
at least:

 The ambiguity of questions.

 Consistence of respondents’ answers.
 What kind of question should be applied, open-ended or close-ended?
 What is the proper length of the questionnaires?

The third one is directly observing users. People are not always very reliable informants,
even when they try to be reliable and tell what they think is the truth. People often do not have a

60 | P a g e
completely accurate appreciation of what they do or how they do it. This I especially true
concerning infrequent events, issues from the past, or issues for which people have considerable
passion. Since people can not always be trusted to reliably interpret and report their own actions,
analyst can supplement and corroborate what people say by watching what they do or by
obtaining relatively objective measures of how people behave in work situation. However,
observation can cause people to change their normal operation behavior. It will make the
gathered information biased. [21]

The fourth one is analyzing procedures and other documents. By examining existing
system and organizational documentation, system analyst can find out details about current
system and the organization these systems support. In documents analyst can find information,
such as problem with existing systems, opportunities to meet new needs if only certain
information or information processing were available, organizational direction that can influence
information system requirements, and the reason why current systems are designed as they are,
etc. [21]

However, when analyzing those official documentations, analysts should pay attention to
the difference between the systems described on the official documentations and the practical
systems in real world. For the reason of inadequacies of formal procedures, individual work
habits and preferences, resistance to control, and other factors, the difference between so called
formal system and informal system universally exists.

The fifth one is Joint Application Design (JAD). JAD is a facilitated, team-based
approach for defining the requirements for new or modified information systems. JAD is started
at IBM in the late 1970s. The main idea behind JAD is to bring together the key users, managers,
and system analysts involved in the analysis of a current system. The primary purpose of using
JAD in the analysis phase is to collect systems requirements simultaneously from the key people
involved with the system. The result is an intense and structured, but highly effective, process.
Having all the key people together in one place at one time allows analysts to see where there are
areas of agreement and where there are conflicts.

The typical participants in a JAD are: JAD session leader, end users, business managers,
sponsor, system analysts, IS staff, scribe, etc. The JAD team is a group of from six to sixteen
individual who all have a stake in designing a high quality system. Approximately two thirds of
the group members are functional experts the other one third are systems professionals. [2] JAD
sessions are usually conducted in a location other than the place where the people involved
normally work, and are usually held in special purpose rooms where participants sit around
horseshoe-shaped tables. Involving so many different kinds of people in one workshop makes
how to effectively and efficiently organize the JAD session a big challenge.

61 | P a g e
 When a JAD is completed, the final result is a set of documents that detail the workings
of the current system related to study of a replacement system. These requirements definition
document generally includes business activity model and definitions, data model and definition,
data input and output requirements. It may also include interface requirements, screen and report
layouts, ad hoc query specifications, menus, and security requirements. When used at a later
point in the system development life cycle, a JAD session can also be used to refine a system
prototype, develop new job profiles for system users, or develop an implementation plan.

However, to exploit full potential of JAD, the groupware tools should be applied in JAD
workshop sessions. The use of groupware tools to support the joint Application Development
technique increases the value of this technique dramatically. When groupware tools are used in
an automated JAD workshop, they greatly facilitate the generation, analysis, and documentation
of information. This is particularly valuable for JAD workshops conducted to define and build
consensus on the requirements for new systems.

The Sixth one is Prototyping. Prototyping is a means of exploring ideas before you invest
in them. Most system developers believe that the benefits from early usability data are at least
ten times greater than those from late usability data. [19,20] Prototyping allow system analysts
quickly show users the basic requirement into a working version of the desired information
system. After viewing and testing the prototype, the users usually adjust existing requirements to
new ones. The goal with using prototyping to support requirement determination is to develop
concrete specification for the ultimate system, not to build the ultimate system from prototyping.
Prototyping is most useful for requirements determination when user requirements are not clear
or well understood, one or a few users and other stakeholders are involved with the system,
possible designs are complex and require concrete form to fully evaluate, communication
problems have existed in the past between users and analysts, and Tools and data are readily
available to rapidly build working systems, etc.

When we choose requirements determination method for a specific project, there seven
characters of them we should consider. They are Information Richness, Time Required, Expense,
Chance for Follow-up and probing, Confidentiality, Involvement of Subject, Potential Audience.
Table 1 concludes these characters of previously discussed six requirements determination
methods.

Table 1
Characteristic Interviews Questionnaire Observation Document JAD Prototypin
s analysis g
Information High Medium to High Low High Medium to
Richness low (passive) High
and old
Time Required Can be Low to Can be Low to Dedicated Moderate

62 | P a g e
 extensive moderate extensive moderate period of and can be
time of all extensive
kinds of
involved
people
Expense Can be Moderate Can be high Low to High High
high moderate
Chance for Good Limited Good Limited Good Good
Follow-up and
probing
Confidentialit Interviewe Respondent Observee is Depends on All the Usually
y e is known can be known to nature of people know each
to unknown interviewer document know each other
interviewer other
Involvement Interviewe Respondent is Interviewee None, no All kinds of Users are
of Subject e is passive, no s may or clear people are involved
involved clear may not be commitmen involved and
and commitment involved t and committed
committed and committed
committed
depending
on whether
they know if
they are
being
observed
Potential Limited Can be quite Limited Potentially Potentially Limited
Audience numbers, large, but lack numbers biased by biased by numbers; it
but of response and limited which the is difficult
complete from some can time of each documents subordinato to diffuse
responses bias results were kept or r or adapt to
from those because intentionall other
interviewe document y don’t potential
d not created want to users
for this directly
purpose point out his
superior’s
errors.

4.6 SYSTEM DESIGN

Systems design is the process of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. Systems design could be seen
as the application of systems theory to product development. There is some overlap with the
disciplines of systems analysis, systems architecture and systems engineering.

63 | P a g e
Overview

If the broader topic of product development "blends the perspective of marketing, design,
and manufacturing into a single approach to product development,"[3] then design is the act of
taking the marketing information and creating the design of the product to be manufactured.
Systems design is therefore the process of defining and developing systems to satisfy specified
requirements of the user.

Until the 1990s systems design had a crucial and respected role in the data processing
industry. In the 1990s standardization of hardware and software resulted in the ability to build
modular systems. The increasing importance of software running on generic platforms has
enhanced the discipline of software engineering.

Object-oriented analysis and design methods are becoming the most widely used methods
for computer systems design.[citation needed] The UML has become the standard language in
object-oriented analysis and design.[citation needed] It is widely used for modeling software
systems and is increasingly used for high designing non-software systems and organizations.

Architectural design

The architectural design of a system emphasizes on the design of the systems architecture
which describes the structure, behavior, and more views of that system and analysis.

Logical design

The logical design of a system pertains to an abstract representation of the data flows,
inputs and outputs of the system. This is often conducted via modeling, using an over-abstract
(and sometimes graphical) model of the actual system. In the context of systems design are
included. Logical design includes ER Diagrams i.e. Entity Relationship Diagrams.

Physical design

The physical design relates to the actual input and output processes of the system. This is
explained in terms of how data is input into a system, how it is verified/authenticated, how it is
processed, and how it is displayed as In Physical design, the following requirements about the
system are decided.

 Input requirement,
 Output requirements,
 Storage requirements,
 Processing Requirements,
 System control and backup or recovery.

Put another way, the physical portion of systems design can generally be broken down into three
sub-tasks:
64 | P a g e
  User Interface Design
 Data Design
 Process Design

User Interface Design is concerned with how users add information to the system and with how
the system presents information back to them. Data Design is concerned with how the data is
represented and stored within the system. Finally, Process Design is concerned with how data
moves through the system, and with how and where it is validated, secured and/or transformed as
it flows into, through and out of the system. At the end of the systems design phase,
documentation describing the three sub-tasks is produced and made available for use in the next
phase.

Physical design, in this context, does not refer to the tangible physical design of an
information system. To use an analogy, a personal computer's physical design involves input via
a keyboard, processing within the CPU, and output via a monitor, printer, etc. It would not
concern the actual layout of the tangible hardware, which for a PC would be a monitor, CPU,
motherboard, hard drive, modems, video/graphics cards, USB slots, etc. It involves a detailed
design of a user and a product database structure processor and a control processor. The H/S
personal specification is developed for the proposed system.

SYSTEM DESIGN OBJECTIVES

Design Objectives: System design is to deliver the requirements as specified in the

feasibility report. The main objectives of the design are

1. Practicality

2. Efficiency

3. Cost

4. Flexibility

5. Security

System design contains Logical Design & Physical Designing, logical designing
describes the structure & characteristics or features, like output, input, files, database &
procedures. The physical design, which follows the logical design, actual software & a working
system. There will be constraints like Hardware, Software, Cost, Time & Interfaces.

The processing techniques are

 Batch Processing
 Real-time
 Online

65 | P a g e
  Combination of all

Structured design is a data flow methodology. The graphical representation of data flow,
communication & defining the modules & their relationship with each is known as Structure
Chart. This method decomposes & modularizes the system so that the complexity &
manageability will come down. Thus reducing the intuitive reasoning & promotes the
maintainable provable systems.

This type of design follows top-down & hierarchy, which will have one single entry &
single exit, The advantages of this method are

 Critical interfaces are tested first

 Early versions of the design, through incomplete are useful enough to resemble
the real system
 Structuring provides control & improve morale
 The procedural characteristics define the order that determines processing.

IMPORTANCE OF SYSTEM DESIGN IN MIS

The business application system demands designing of systems suitable to the application
in project.

The major steps involved in the system design of Management Information Systems
(MIS) are the following:
Input Design – Input design is defined as the input requirement specification as per a format
required. Input design begins long before the data arrives at the device. The analyst will have to
design source documents, input screens and methods and procedures for getting the data into the
computer.
Output Design – The design of the output is based on the requirement of the user – manager,
customer etc. The output formats have to very friendly to the user. Therefore the designer has to
ensure the appropriateness of the output format.
Development – When the design and its methodology is approved, the system is developed
using appropriate business models. The development has to be in accordance to a given standard.
The norms have to be strictly adhered to.
Testing – Exhaustive and thorough testing must be conducted to ascertain whether the system
produces the right results. Testing is time consuming: Test data must be carefully prepared,

66 | P a g e
results reviewed and corrections made in the system. In some instances, parts of the system may
have to be redesigned. Testing an information system can be broken down into three types of
activities: unit testing, system testing and acceptance testing. Unit testing or program testing
consists of testing each program separately in the system. The purpose of such testing is to
guarantee that programs are error free, but this goal is realistically impossible. Instead, testing
should be viewed as a means of locating errors in programs, focusing on finding all ways to
make a program fail. Once pinpointed, problems can be corrected. System testing tests the
functioning of the information system as a whole. It tries to determine if discrete modules will
function together as planned and whether discrepancies exist between the way the system
actually works and the way it was conceived. Among the areas examined are performance time,
capacity for file storage and handling peak loads, recovery and restart capabilities and manual
procedures. Acceptance testing provides the final certification that the system is ready to be used
in a production setting. Systems tests are evaluated by users and reviewed by management.
When all parties are satisfied that the new system meets their standards, the system is formally
accepted for installation.
Implementation and Maintenance
Conversion – Conversion is the process of changing from the old system to the new system.
Four main conversion strategies can be employed. They are the parallel strategy, the direct
cutover strategy, the pilot strategy and the phased strategy.
 In a parallel strategy both the old system and its potential replacement are run together for a
time until everyone is assure that the new one functions correctly. This is the safest
conversion approach because, in the event of errors or processing disruptions, the old system
can still be used as a backup. But, this approach is very expensive, and additional staff or
resources may be required to run the extra system.
 The direct cutover strategy replaces the old system entirely with the new system on an
appointed day. At first glance, this strategy seems less costly than the parallel conversion
strategy. But, it is a very risky approach that can potentially be more costly than parallel
activities if serious problems with the new system are found. There is no other system to fall
back on. Dislocations, disruptions and the cost of corrections are enormous.

67 | P a g e
 The pilot study strategy introduces the new system to only a limited area of the organization,
such as a single department or operating unit. When this version is complete and working
smoothly, it is installed throughout the rest of the organization, either simultaneously or in
stages.
 The phased approach strategy introduces the new system in stages, either by functions or by
organizational units. If, for example, the system is introduced by functions, a new payroll
system might begin with hourly workers who are paid weekly, followed six months later by
adding salaried employees( who are paid monthly) to the system. If the system is introduced
by organizational units, corporate headquarters might be converted first, followed by
outlying operating units four months later.
Moving from an old system to a new system requires that end users be trained to use the new
system. Detailed documentation showing how the system works from both a technical and end
user standpoint is finalized during conversion time for use in training and everyday operations.
Lack of proper training and documentation contributes to system failure, so this portion of the
systems development process is very important.

Production and maintenance

After the new system is installed and conversion is complete, the system is said to be in
production. During this stage the system will be reviewed by both users and technical specialists
to determine how well it has met its original objectives and to decide whether any revisions or
modifications are in order. In some instances, a formal post implementation audit document will
be prepared. After the system has been finetuned, it will need to be maintained while it is in
production to correct errors, meet requirements or improve processing efficiency.

Once a system is fully implemented and is being used in business operations, the
maintenance function begins. Systems maintenance is the monitoring, or necessary
improvements. For example, the implementation of a new system usually results in the
phenomenon known as the learning curve. Personnel who operate and use the system will make
mistake simply because they are familiar with it. Though such errors usually diminish as

68 | P a g e
experience is gained with a new system, they do point out areas where a system may be
improved.

Maintenance is also necessary for other failures and problems that arise during the
operation of a system. End users and information systems personnel then perform a
troubleshooting function to determine the causes of and solutions to such problems. Maintenance
also includes making modifications to an established system due to changes in the business
organizations, and new e-business and ecommerce initiatives may require major changes to
current business systems.

4.7 IMPLEMENTATION PROCESS

Introduction

This page explains what you do at the organizational level to implement process and
tools in a development organization.

Implementing process and tools at the project level in a software-development project is

described on the page called Concepts: Implementing a Process in a Project.

Related Information

 Concepts: Environment Practices gives a list of proven practices that help you improve
the process and tools on a project.
 Concepts: Effect of Implementing a Process explains the effect of implementing process
and tools.
 Concepts: Pilot Project explains what a pilot project is and how to choose one.
 Guidelines: Process Discriminates explains the factors that affect how you implement a
process.
 Concepts: Managing Organizational Change gives an overview of what it means to
manage organizational change.

A Step-by-Step Procedure

Implementing a new process in a software-development organization can be described in

four steps.

69 | P a g e
The steps to implement process and tools in an organization.

Step 1: Assess Development Organization

You must understand the current state of the software-development organization in terms
of its people, its process, and its supporting tools. You need to identify problems and potential
areas for improvement, as well as collect information about outside issues, such as your
competitors and market trends. When this step is complete, you should know:

 The software development organization's current state.

 The kinds of people there, including their level of competence, skills, and motivation.
 The tools currently used by the organization.
 The current software engineering process and how it's described.
 The organization's business goals.

Reasons for assessing the current state are to:

 Use it to create a plan for getting from the organization's current state to your goal.
 Identify those areas that need to be improved first. You may not want to introduce the
entire process and all tools all at once. You may want to do it in increments, starting with
the areas that have the greatest need and the best potential for improvement.
 Explain to the sponsors why you need to change process, tools, and people.
 Create motivation and a common understanding among those people in the organization
who are directly, or indirectly, affected.

Step 2: Plan Process Implementation

Develop a plan for implementing the process and the tools in the organization. This plan
describes how to efficiently move from the organization's current state to their vision. To
develop this plan, you need to:

 Set or Revise Goals

 Identify Risks

70 | P a g e
  Select Software Development Projects
 Decide When to Launch Process and Tools
 Plan Training
 Plan Mentoring
 Decide Whether to Develop an Organization-wide Development Environment

Step 3: Execute Process Implementation

Executing the environment implementation in an organization means running software-

development projects in which you implement the process and tools. See Concepts:
Implementing a Process in a Project for more information. From a organizational point of view,
this step means that you:

 Monitor the software-development projects.

 Manage launches of the process and tools across projects.
 Monitor the development of and organization-wide environment.

Step 4: Evaluate Process Implementation Effort

When you've implemented the process and tools in a real or pilot software-development
project, you need to evaluate the effort. Did you achieve your established goals? Evaluate the
people, the process, and the tools to understand the areas to focus on during the next phase of the
process implementation effort.

Artifacts

When you implement a process and tools in an organization across individual software
development projects, there are document artifacts that might be valuable to develop. This is, of
course, in addition to the Development-Organization Assessment and the Development Case for
each project.

 First, you may need an Implementation Plan to describe the overall plan for how to
implement process and tools in an organization across individual projects. This plan
covers process, tools, and training, and normally spans several software development
projects.
 Secondly, you may need to develop Deployment Guidelines to help individual projects
implement process and tools. Deployment Guidelines contain advice and guidance on
how to plan the implementation of process and tools in an individual software
development project.

4.8 PRODUCT BASED MIS EVALUATION

The focus of the product based evaluation is on the product or the output from the
system, the evaluation may be termed as the effectiveness evaluation.

Some of the attributes of the product based MIS evaluation are:

71 | P a g e
  Timeliness
 Relevance
 Accuracy
 Completeness
 Adequacy
 Explicitness
 Exception based

4.9 COST /BENEFIT BASED EVALUATION

Cost-benefit analysis (CBA) is a technique used to compare the total costs of a

programme/project with its benefits, using a common metric (most commonly monetary units).
This enables the calculation of the net cost or benefit associated with the programme.

As a technique, it is used most often at the start of a programme or project when different
options or courses of action are being appraised and compared, as an option for choosing the best
approach. It can also be used, however, to evaluate the overall impact of a programme in
quantifiable and monetised terms.

CBA adds up the total costs of a programme or activity and compares it against its total
benefits. The technique assumes that a monetary value can be placed on all the costs and benefits
of a programme, including tangible and intangible returns to other people and organisations in
addition to those immediately impacted. As such, a major advantage of cost-benefit analysis lies
in forcing people to explicitly and systematically consider the various factors which should
influence strategic choice.

Decisions are made through CBA by comparing the net present value (NPV) of the
programme or project’s costs with the net present value of its benefits. Decisions are based on
whether there is a net benefit or cost to the approach, i.e. total benefits less total costs. Costs and
benefits that occur in the future have less weight attached to them in a cost-benefit analysis. To
account for this, it is necessary to ‘discount’ or reduce the value of future costs or benefits to
place them on a par with costs and benefits incurred today. The ‘discount rate’ will vary
depending on the sector or industry, but public sector activity generally uses a discount rate of 5-
6%. The sum of the discounted benefits of an option minus the sum of the discounted costs, all
discounted to the same base date, is the ‘net present value’ of the option.

Theory

Cost–benefit analysis is often used by organizations to appraise the desirability of a given

policy. It is an analysis of the expected balance of benefits and costs, including an account of
foregone alternatives and the status quo. CBA helps predict whether the benefits of a policy
outweigh its costs, and by how much relative to other alternatives, so that one can rank alternate
policies in terms of the cost–benefit ratio.[3] Generally, accurate cost–benefit analysis identifies
choices that increase welfare from a utilitarian perspective. Assuming an accurate CBA,
changing the status quo by implementing the alternative with the lowest cost–benefit ratio can

72 | P a g e
improve Pareto efficiency.[4] While CBA can offer a well-educated estimate of the best
alternative – perfect appraisal of all present and future costs and benefits is difficult –, perfection
in terms of economic efficiency and social welfare are not guaranteed.

Process

The following is a list of steps that comprise a generic cost–benefit analysis.[6]

1. List alternative projects/programs.

2. List stakeholders.
3. Select measurement(s) and measure all cost/benefit elements.
4. Predict outcome of cost and benefits over relevant time period.
5. Convert all costs and benefits into a common currency.
6. Apply discount rate.
7. Calculate net present value of project options.
8. Perform sensitivity analysis.
9. Adopt recommended choice.

Cost Benefit Analysis Method

The Cost Benefit Analysis Method (CBAM) is an architecture-centric method for

analyzing the costs, benefits, and schedule implications of architectural decisions. It also enables
assessment of the uncertainty surrounding judgments of costs and benefits, thereby providing a
basis for informed decision making about architectural design/upgrade. The CBAM builds on the
Architecture Tradeoff Analysis Method (ATAM), although an ATAM is not an absolute
prerequisite.

Challenges

 How do you go about taking economic considerations into account when designing or
modifying a system architecture?
 How do you account for the costs involved?
 How do you characterize and compare the benefits that will accrue to various
architectural strategies?
 How can costs and benefits be traded off against quality attributes or functionality?
 How can you characterize the uncertainties involved in your estimates?

Description

How do you know if a software architecture for a system is suitable without having to
build the system first? The answer is to conduct an evaluation of it. A formal software
architecture evaluation should be a standard part of the architecture-based software development
life cycle. Architecture evaluation is a cost-effective way of mitigating the substantial risks
associated with this highly important artifact.

73 | P a g e
 The creation and maintenance of a complex software-intensive system involves making a
series of business-critical architecture design decisions. The SEI ATAM provides software
architects with a framework for understanding the technical tradeoffs they face as they make
design or maintenance decisions. But the biggest tradeoffs in large complex systems usually have
to do with economics, and the ATAM does not provide any guidance for understanding these
economic tradeoffs. Organizations need to know how to invest their resources to maximize their
gains, meet their schedules, and minimize their risks. When economics have been addressed in
the past, the focus has usually been on costs, and even then only the costs of building the system
have been considered, not the long-term costs of maintenance and upgrade. Yet the benefits that
an architectural decision may bring to an organization are as important—or perhaps even more
important—than the costs.

Clearly we need to consider both, that is to consider the return on investment (ROI) of
any architectural decision. Because the resources for building and maintaining a system are
finite, there must be a rational process for choosing among architectural options, during the
initial design phase and during subsequent periods of upgrade. These options will have different
costs, consume different amounts of resources, implement different features (each bringing some
benefit to the organization), and have some inherent risk or uncertainty. To explore the effects of
these options, economic software models are needed that take into account costs, benefits, risks,
and schedule implications.

The ATAM uncovers the architectural

decisions that are made (or are being
considered) for the system, and links these
decisions to business goals and quality
attributes. The CBAM builds on this
foundation, as exemplified by the cubes
labeled P, A, S, and M, in this figure
(representing performance, availability,
security, and modifiability respectively).
These quality attribute decisions (and there
may be many others, for other qualities) result
in some benefit to the system's stakeholders.
The CBAM guides system engineers and other stakeholders to determine the costs and benefits
associated with the architectural decisions that result in the system's qualities. Given this
information, the stakeholders can then reflect on and choose among the potential architectural
decisions. For example, they could decide whether to use redundant hardware, check pointing, or
some other method to address concerns about the system’s reliability. Or the stakeholders could
choose to invest their finite resources in some other quality attribute, perhaps believing that
higher performance will have a better ROI.

The SEI has worked with NASA’s Earth Observing System Data Information System
(EOSDIS) Core System (ECS), applying the CBAM to aid in making investment decisions for
the project. The Earth Observing System is a constellation of NASA satellites that gathers data
about the Earth for the U. S. Global Change Research Program and other scientific communities
world-wide. By using the CBAM, the ECS managers were able to order a set of architectural

74 | P a g e
strategies based on their predicted ROI. But the true benefits of the CBAM extend far beyond the
qualitative outcomes. There have been palpable social and cultural benefits as well. The CBAM
process provided a structure to what were largely unstructured discussions where requirements
and architectural strategies and personal opinions were freely mixed together, and where stimuli
and response goals were not clearly articulated. The CBAM process forced the stakeholders to
make their scenarios clear in advance, to assign utility levels to specific response goals, and to
prioritize scenarios based on the resulting determination of utility. The CBAM forced the
stakeholders to address risks and their resulting effects explicitly, rather than simply stating an
“unease” with a particular technical direction.

The CBAM consists of the following steps:

1. choosing scenarios and architectural strategies

2. assessing quality attribute benefits
3. quantifying the benefits of architectural strategies
4. quantifying the costs and schedule implications of architectural strategies
5. calculating desirability
6. making decisions

Through the CBAM exercise, the CBAM team guides the stakeholders to determine a set
of architectural strategies that address their highest priority scenarios. These chosen strategies
furthermore represent the optimal set of architectural investments. They are optimal based on
considerations of benefit, cost, and schedule, within the constraints of the elicited uncertainty of
these judgments and the willingness of the stakeholders to withstand the risk implied by
uncertainty.

Benefits

The CBAM enables users to make informed decisions about software requirements and
software investments based on an analysis of the economic and architectural implications of
those decisions.

Evaluation

CBA attempts to measure the positive or negative consequences of a project, which may
include:

1. Effects on users or participants

2. Effects on non-users or non-participants
3. Externality effects
4. Option value or other social benefits.

A similar breakdown is employed in environmental analysis of total economic value.

Both costs and benefits can be diverse. Financial costs tend to be most thoroughly represented in
cost-benefit analyses due to relatively abundant market data. The net benefits of a project may
incorporate cost savings or public willingness to pay compensation (implying the public has no

75 | P a g e
legal right to the benefits of the policy) or willingness to accept compensation (implying the
public has a right to the benefits of the policy) for the welfare change resulting from the policy.
The guiding principle of evaluating benefits is to list all (categories of) parties affected by an
intervention and add the (positive or negative) value, usually monetary, that they ascribe to its
effect on their welfare.

The actual compensation an individual would require to have their welfare unchanged by
a policy is inexact at best. Surveys (stated preference techniques) or market behavior (revealed
preference techniques) are often used to estimate the compensation associated with a policy.
Stated preference technique is a direct way of assessing willingness to pay. Because it involves
asking people directly to indicate their willingness to pay for some environmental feature, or
some outcome that is closely connected to the state of the environment.[7] However, survey
respondents often have strong incentives to misreport their true preferences and market behavior
does not provide any information about important non-market welfare impacts. Revealed
preference technique is an indirect approaches to individual willingness to pay. People make
market choices among certain items that have different characteristics related to the environment,
they reveal the value they place on these environmental factors. [8]

One controversy is valuing a human life, e.g. when assessing road safety measures or
life-saving medicines. However, this can sometimes be avoided by using the related technique of
cost-utility analysis, in which benefits are expressed in non-monetary units such as quality-
adjusted life years. For example, road safety can be measured in terms of cost per life saved,
without formally placing a financial value on the life. However, such non-monetary metrics have
limited usefulness for evaluating policies with substantially different outcomes. Additionally,
many other benefits may accrue from the policy, and metrics such as 'cost per life saved' may
lead to a substantially different ranking of alternatives than traditional cost–benefit analysis.

Another controversy is valuing the environment, which in the 21st century is typically
assessed by valuing ecosystem services to humans, such as air and water quality and pollution.[9]
Monetary values may also be assigned to other intangible effects such as business reputation,
market penetration, or long-term enterprise strategy alignment.

Example

In 2005 the UK Government undertook a value for money analysis of Government

investment in different types of childcare. The choice was between higher cost "integrated"
childcare centres, providing a range of services to both children and parents, or lower cost "non-
integrated" centres that provided basic childcare facilities.

The analysis included both a 'hard exercise' and a 'soft exercise'. The hard exercise
identified, quantified and monetised direct costs and benefits. The soft exercise identified and
described qualitatively non-monetisable impacts, leading to option ranking.

76 | P a g e
4.10 PROCESS BASED CALCULATION

77 | P a g e
4.11 SYSTEM MAINTENANCE

What is system maintenance? What are its different types

The results obtained from the evaluation process help the organization to determine
whether its information systems are effective and efficient or otherwise. The process of
monitoring, evaluating, and modifying of existing information systems to make required or
desirable improvements may be termed as System Maintenance.

System maintenance is an ongoing activity, which covers a wide variety of activities,

including removing program and design errors, updating documentation and test data and
updating user support. For the purpose of convenience, maintenance may be categorized into
three classes, namely:

i) Corrective,

ii) Adaptive, and

iii) Perfective.

i) Corrective Maintenance: - This type of maintenance implies removing errors in a program,

which might have crept in the system due to faulty design or wrong assumptions. Thus, in
corrective maintenance, processing or performance failures are repaired.

ii) Adaptive Maintenance: - In adaptive maintenance, program functions are changed to enable
the information system to satisfy the information needs of the user. This type of maintenance
may become necessary because of organizational changes which may include:

a) Change in the organizational procedures,

b) Change in organizational objectives, goals, policies, etc.

c) Change in forms,

d) Change in information needs of managers.

e) Change in system controls and security needs, etc.

iii) Perfective Maintenance: - Perfective maintenance means adding new programs or

modifying the existing programs to enhance the performance of the information system. This
type of maintenance undertaken to respond to user’s additional needs which may be due to the
changes within or outside of the organization. Outside changes are primarily environmental
changes, which may in the absence of system maintenance, render the information system
ineffective and inefficient. These environmental changes include:

78 | P a g e
a) Changes in governmental policies, laws, etc.,

b) Economic and competitive conditions, and

c) New technology.

79 | P a g e