'Introduction To System Analysis and Design

Website :- https://www.arjun00.com.
np
.
.
`Introduction to System Analysis and Design

System: A collection of components that work together to realize some
objectives forms a system. In a system the different components are
connected with each other and they are interdependent. The objective
of the system demands that some output is produced as a result of
processing the suitable inputs. A well designed system also includes an
additional elements referred to as ‘control’ that provides a feedback to
achieve desired objectives of the system.
There are three major components in every system, namely input,

processing and output.
Input: It involves capturing and assembling elements that enter the

system to be processed. Inputs to the system are anything to be captured
by the system from its environment i.e. raw materials.
Processing: It involves transformation processes that convert input to

output. For example, a manufacturing process.
Output: It involves transferring elements that have been produced by a

transformation process to their ultimate destination. Outputs are the
things produced by the system i.e. finished products.
System includes other two activities: these are feedback and control.
.
arjun00.com.np 1
Website :- https://www.arjun00.com.np
.
.
Feedback: It is data about the performance of a system. It is the idea of

monitoring the current system output and comparing it to the system
goal. Any variation from the goal are then fed back in to the system and
used to adjust it to ensure that it meets its goal.
Control: It involves monitoring and evaluating feedback to determine

whether a system is moving toward the achievement of its goals. The
control function then makes necessary adjustments to a system’s input
and processing components to ensure that it produces proper output.
The system has nine characteristics:
1. Components
2. Interrelated components
3. Boundary
4. Purpose
5. Environment
6. Interfaces
7. Constraints
8. Input
9. Output
A system is made up of components. A component is either an

irreducible part or an aggregate of parts, also called a subsystem.
The components are interrelated; that is, the function of one is
somehow tied to the functions of the others. A system has
boundary, within which all of its components are contained and
which establishes the limits of a system, separating it from other
systems. Components within the boundary can be changed,
.
arjun00.com.np 2
.
.
whereas systems outside the boundary cannot be changed. All of

the components work together to achieve some overall purpose
(objective) of the system.
A system exists within an environment- everything outside the
system’s boundary that influences the system. An information
system interacts with its environment by receiving data (raw
facts) and information (data processed in a useful format). The
points at which the system meets its environment are called
interfaces; an interface also occurs between subsystems. In its
functioning, a system must face constraints – the limits (in terms
of capacity, speed, or capabilities) to what it can do and how it
can achieve its purpose within its environment. The system takes
input from outside, processes it and sends the resulting output
back to its environment.
Analysis
Analysis is a process of inspecting, clearing, transforming and
modeling the data with the goal of highlighting useful information,
suggesting conclusions and supporting decision making.
Analysis is the process of breaking a complex logic into smaller

parts to gain a better understanding and feedback by performing
different operations to improve the system.
.
arjun00.com.np 3
.
.
Design
Design means the process of originating and developing a plan for
a product, structure, system, or component. Design is the planning that
lays the basis for making of the system. It means applied arts and
engineering.
Design is used for either the final (solution) plan (e.g. proposal,
drawing, model, description) or the result of implementing that plan in
the form of the final product of a design process.
Objectives of system analysis and design:

1) To determine specific needs of system.
2) To describe various data gathering and analysis tools.
3) To Evaluate tools and techniques for solving business system problems.
4) To Use appropriate methods and techniques to design software.
5) To ensure entire system will perform as per the specifications.
6) To ensure system meets client’s requirement.
7) To study the feasibility of the system.
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

The systems development life cycle (SDLC) is a conceptual model used in project
management that describes the stages involved in an information system
development project, from an initial feasibility study through maintenance of the
completed application. The Systems Development Life Cycle (SDLC) is the process
.
arjun00.com.np 4
.
.
of creating or altering systems, models and the methodologies that people use to
develop the system. The concept generally refers to computer or information
systems. The SDLC (system development life cycle) consists the following steps:
1. Problem Identification (Recognition of Need)

Recognition of need means to find out the exact problem because without
knowing the exact problem it is not possible to adopt a line of action for
improving the system performance. Need recognition relates to the
sophistication of a market, or its "education level", and its stage of
development. Clearly, if a market is not able to see the benefits of using a
category of product, a brand's demand generation activities are unlikely to
result in much business.
To recognize or find out the need one take from the following:
1. Survey
2. Initial Investigation: Survey means to collect the information from a
large group of people by different ways like directly asking the questions,
giving the question sheet (generally with tick mark option) to give the answers
and collect information by these answers. Group discussion is also a solution
to get the data.
Initial investigation is done to find out that whether the request for
improving the system is valid or not and it should also be feasible.
2. Impetus for System Change
Impetus for system change means the force for change the system,
basically two things are responsible for change in the system:
a. Customers, venders etc.
They are called the environment change elements outside the

organization.
b. Top management, user, and analyst, etc.
.
arjun00.com.np 5
.
.
They are called the change elements within the organization.
There are also several different factors which may force for the
changes. For example, high rate of labor turnover, high rejection rate
of finished product, different suspicious activities of employees.
3. Feasibility Study
The result of feasibility study is called the "formal proposal" or the
"report". This report consist the known things and the things which is going
to be happened.
It consist the following:
a. Problem Statement: Means the statements which describe that

what is the problem.
b. Findings and Recommendations (Suggestions) with Justification:

It includes different types of information which is found by different
methods.
c. Detail of Findings: The details about the findings are given in this
step. In details of finding full description is available regarding the
different information of existing system.
d. Conclusion: Finally in the conclusion part the result of feasibility

study is given with detail information regarding the cost, project
schedule and time boundations. This report becomes the formal or
official agreement after it is approved by the management.
4. Analysis
Analysis is the process of breaking a complex logic into smaller
parts to gain a better understanding and feedback by performing
different operations to improve the system. The technique has been
applied in the study of system design. Analysis is a process of
inspecting, clearing, transforming, and modeling the data with the
.
arjun00.com.np 6
.
.
goal of highlighting useful information, suggesting conclusions, and

supporting decision making. It is a brief review of the system.
5. Design
Design is the planning that lays the basis for the making of the
system. It means applied arts and engineering. Design means the
process of originating and developing a plan for a product, structure,
system, or component.
Design is used for either the final (solution) plan (e.g., proposal,
drawing, model, description) or the result of implementing that plan
in the form of the final product of a design process.
Design is the most creative and challenging phase.
6. Implementation
Implementation is the execution, or practice of a plan, a
method, or any design for doing something. As such,
implementation is the action that must follow any preliminary
thinking in order for something to actually happen. In an
information technology context, implementation encompasses all
the processes involved in getting new software or hardware
operating properly in its environment, including installation,
configuration, running, testing, and making necessary changes.
The word deployment is sometimes used to mean the same thing.
Implementation is less creative phase in comparison to the

design phase.
7. Post Implementation
A post-implementation is an assessment and review of the
completed working solution. Any systems have the characteristics
of "aging" (means after some time giving problems to user). The
solution to avoid this problem is to give the periodic maintenance
to the system.
There are three purposes for a post-implementation Review.
.
arjun00.com.np 7
.
.
1. To check the degree of success of the project, in particular,

the extent to which it met its objectives, delivered planned levels
of benefit.
2. To examine the efficiency of all elements of the working
business solution to see it further improvements can be made to
maximize the benefits.
3. To learn lessons from this project, lessons which can be used
by the team members and by the organization to improve future
project work and solutions.
8. Project Termination
Mainly there are two reasons for terminating the project:
1. Project is Cancelled After Review Process:

In this case there exist the following reasons:
(i) It is observed that by changing the existing system
the user requirement cannot be fulfilled.
(ii) During the review or feasibility process it is find
out that the total cost will be too much and it is
beyond the user's budget.
(iii) After the reviewing process or feasibility study if it
is found that to change the existing system for
example will take the one year and unfortunately
even after the period of three years the task is not
completed. Now in this case the time as well as
cost both will be increased at a great extent.
These types of cases can also be the one reason for

terminating the project.
2. New System is not Fulfilling the requirement of user:

In this case there exist the following reasons:
.
arjun00.com.np 8
.
.
(i) Very hard time boundations for the project team. It

destroys the concentration and creativity level. Also
the team may exhaust (tired) too much.
(ii) Lack of the experience of project team can also be
one reason.
(iii) If the user is not involved at crucial (difficult) phases
of designing the system.
(iv) The requirements which are given by the user are not
completely understood by the project team means if
the problem is not accurately known. (v) Old system
was providing better connectivity.
(v) New system is not user friendly.
SDLC Phases:
The development of a new information system involves several different, but
related activities. These activities, or phases, usually include planning, analysis,
design, implementation, and maintenance/support.
Phase 1: Planning
In the planning phase, project goals are determined and a high-level plan for the
intended project is established. Planning is the most fundamental and critical
organizational phase. The three primary activities involved in the planning phase
are as follows:
1. Identification of the system for development

2. Feasibility assessment
3. Creation of project plan
Phase 2: Analysis
In the analysis phase, end user business requirements are analyzed and project
goals converted into the defined system functions that the organization intends to
develop. The three primary activities involved in the analysis phase are as follows:
.
arjun00.com.np 9
.
.
1. Gathering business requirement

2. Creating process diagrams
3. Performing a detailed analysis
Phase 3: Design
In the design phase, we describe the desired features and operations of the system.
This phase includes business rules, pseudo-code, screen layouts, and other
necessary documentation. The two primary activities involved in the design phase
are as follows:
1. Designing of IT infrastructure
2. Designing of system model
In this phase, the specialist recommends the kinds of clients and servers needed on
a cost and time basis, and technical feasibility of the system. Also, in this phase,
the organization creates interfaces for user interaction. Other than that, data models
and entity relationship diagrams (ERDs) are also created in the same phase.
Phase 4: Implementation
In this phase, all the documents from the previous phase are transformed into the
actual system. Along with that the built system is tested for any technical errors,
bugs and defects, and the final system is deployed to the client environment. The
activities performed in this phase are:
• Development of IT infrastructure
• Development of database and code
• Testing of the final system using techniques like alpha testing, beta testing etc.
• Verification and Validation of system requirements.
• Final system is delivered to the client.
.
arjun00.com.np 10
.
.
Phase 5: Maintenance
In the maintenance phase, any necessary enhancements, corrections, and changes

will be made to make sure the system continues to work, and stay updated to meet
the business goals. It is necessary to maintain and upgrade the system from time to
time so it can adapt to future needs. The three primary activities involved in the
maintenance phase are as follows:
1. Support the system users

2. System maintenance
3. System changes and adjustment
.
arjun00.com.np 11
.
.
Development, Management & Supporting Processes

Development Process
In system analysis and design, a development process is the process of
creating a new system which contains a number of inter-dependent
components that perform different tasks as per the requirement.
Emergent system Properties

These are the properties of the system as a whole rather
than properties that can be derived from the properties of
components of a system. Emergent properties are a consequence
of the relationships between system components. They can
therefore only be assessed and measured once the components
have been integrated into a system.
Types of emergent properties:
1. Functional properties
These appear when all the parts of a system work
together to achieve some objective. For example, a
bicycle has the functional property of being a
transportation device once it has been assembled
from its components.
2. Non-Functional Properties
These relate to the behaviour of the system in its
operational environment. Examples are reliability,
performance, safety, and security. They are often critical
for computer-based systems as failure to achieve some
arjun00.com.np 12
.
.
minimal defined level in these properties may make the

system unusable.
a. Reliability:
Reliability is the probability that a system performs
correctly during specific time duration. During this
correct operation, no repair is required or
performed, and the system adequately follows the
defined performance specifications. Reliability may
be divided as software reliability and Hardware
reliability.
Software Reliability is defined as the probability of
failure-free software operation for a specified
period of time.
Hardware Reliability is the ability of hardware to
perform its functions for some period of time
without any issue.
b. Performance:
Performance of a system includes the speed and
accuracy. It is combined form of how fast is the
system and how accurate is the result.
c. Security
The security of a system is its ability to resist attack.
This could be either software which include
resistance against malwares and hackers or
hardware which include resistance against
environmental factors such as dust, water,
temperature etc.
arjun00.com.np 13
.
.
d. Usability
This property reflects how easy it is to use the
system. It depends on the technical system
components, its operators, and its operating
environment.
e. Repairability
This property reflects how easy it is to fix a problem
with the system once it has been discovered. It
depends on being able to diagnose the problem,
access the components that are faulty, and modify
or replace these components.
System Engineering:
Systems engineering is an interdisciplinary field of
engineering and engineering management that focuses on how to
design, integrate, and manage complex systems over their life
cycles.
Issues such as requirements engineering, reliability, coordination

of different teams, testing and evaluation, maintainability and
many other disciplines necessary for successful system design,
development, implementation, and maintenance becomes more
difficult when dealing with large or complex projects. System
engineering deals with work-processes, optimization methods,
and risk management tools in such projects. Systems engineering
ensures that all likely aspects of a system are considered and
integrated into a whole.
arjun00.com.np 14
.
.
Information system:
An information system is defined as the software/hardware that
helps organize and analyze data.
The purpose of an information system is to turn raw data into

useful information that can be used for decision making in an
organization.
Type of Information System

ransaction Processing System (TPS)
Transaction processing system (TPS) is a special class of information

system designed to process business events and transactions. Two
types of TPS exist: Batch transaction processing and Real- time
processing. Batch transaction processing collects the transaction data
as a group, or batch, and processes it later. Real-time processing is the
immediate processing of data. It provides instant confirmation of
transaction but requires access to online database.
TPS are aimed at improving the routine business activities on which all
organizations depend. They substitute computer-based processing for
manual procedure. TPS assists in carrying out the day-to-day, high-
volume activities/transactions of the organization. These transactions
are processed using standard operating procedures. There are hardly
any exceptions to these procedures. These routines are embedded in
the computer programs that control the entry of data, processing of
details, storage, and presentation of data and information.
This provides high speed and accurate processing of record keeping of

basic operational processes. These include calculation, storage and
.
arjun00.com.np 15
.
.
retrieval. Transaction processing systems provide speed and accuracy,

and can be programmed to follow routines functions of the
organization.
Example: Pay cheques and other forms of paper output, Airline
Reservation Systems, Banking Systems, Payroll Processing System,
Purchase Order Entry System, or the Accounting System of almost any
large company, etc.
Advantages:
• Handling of several thousand operations at once.
• In transaction processing there is no delay and the results of each
transaction are immediately available.
Disadvantages:
• The need to handle hundreds, even thousands of simultaneous
Users
• The need to allow many Users to work on the same set of data,
with immediate updating
arjun00.com.np 16
.
.
Management information system (MIS)
Management information system (MIS) is used by managerial

employees to support recurring decision making in managing a function
or the entire business. These systems assist lower management in
problem solving and making decisions. They use the results of
transaction processing and some other information also. It is a set of
information processing functions. It should handle queries as quickly as
they arrive. An important element of MIS is database.
arjun00.com.np 17
.
.
The information required at this level is used for making short term
decisions and plans for the organization. Information like sales analysis
for the past quarter/yearly production details etc. fall under this
category. MIS caters to such information needs of the organization. Due
to its capabilities to fulfill the managerial information needs of the
organization, MIS have become a necessity for all big organizations.
And due to its vastness, most of the big organizations have separate
MIS departments to look into the related issues and proper functioning
of the system.
MIS helps in studying the decisions taken, the factors leading to a

specific decision, and in developing reports that are useful in
formulating future decisions (Demand reports, Exceptional Schedule
reports). MIS deals with supporting well-structured decision situations.
MIS aims at improving operational efficiency. It utilizes transaction data
.
arjun00.com.np 18
.
.
obtained as the result of transaction processing, however MIS may also

use other information that is developed internally and from outside the
organization. This information is often represented as the tactical
information. In a MIS the typical information requirement can be
anticipated.
Example: Annual Budgeting, Payroll System, Sales Order System and

Personnel Management System
Advantages:
• It facilitates planning
• It minimizes information overload by changing the larger amount
of data in to summarize form.
• MIS encourages decentralization by making necessary change in
the organizational plans and procedures.
• It brings coordination as it connects all decision centers in the
organization.
• It makes control easier as MIS serves as a link between managerial
planning and control.
• MIS assembles, process, stores, retrieves, evaluates and
disseminates the information.
• MIS allows managers to make different types of reports about a
company activities.
Disadvantages:
• Highly sensitive, requires constant monitoring.

• Budgeting of MIS extremely difficult.
• Quality of outputs governed by quality of inputs.
arjun00.com.np 19
.
.
• Lack of flexibility to update itself.

• Effectiveness decreases due to frequent changes in top
management
• Takes into account only qualitative factors and ignores non-
qualitative factors like morale of worker, attitude of worker etc.
Decision Support System (DSS):
DSS is a special purpose information system designed to support

managerial level employees in organizational decision making.
DSS is an organized collection of people, procedures, databases, and

devices used to support problem-specific decision making. These
systems assist higher management to make long term decisions. These
type of systems handle unstructured or semi structured decisions. A
decision is considered unstructured if there are no clear procedures for
making the decision and if not all the factors to be considered in the
decision can be readily identified in advance.
DSS is tool that aids in the process of decision-making but it cannot

take decisions. A manager in addition to the information gained by DSS
relies on his experience and intuition. DSS are aimed at assisting
managers who are faced with unique (non-recurring) and unstructured
decision problems. DSS supports managers who are responsible for
strategic planning and who take decisions based on long range
considerations. DSS aids in decision-making in those situations where
either information is not readily available or the information needs are
difficult to predict.
arjun00.com.np 20
.
.
Example: A DSS that facilitates use of simulation and what if mechanism

for forecasting customer preferences about a product in the
forthcoming decade.
Advantages:
• Reduced decision cycle time, increased employee productivity
and more timely information for decision making.
• Improved decision making effectiveness and better decisions.
Improved communication and collaboration among decision
makers.
• Gaining a competitive advantage from computerized decision
support.
arjun00.com.np 21
.
.
• Cost saving from labor savings in making decisions and from lower
infrastructure or technology costs.
• Increase decision maker satisfaction.
• Promote learning Increase organizational control.
Disadvantages:
• The DSS requires heavy investment in information system to

collect data from many sources and analyze them to support the
decision making.
• DSS may reinforce the rational perspective and overemphasize
decision processes and decision making.
• Once DSS become common in organizations, that managers will
use them inappropriately. Building DSS, especially knowledge-
driven DSS, may be perceived as transferring decision authority to
a software program.
• DSS is conceivable and it has been demonstrated that some DSS
reduce the skill needed to perform a decision task.
• The computer does not make a "bad" decision, people do.
Unfortunately some people may deflect personal responsibility to
a DSS.
• Some managers argue using a DSS will diminish their status and
force them to do clerical work. This perceptual problem can be a
disadvantage of implementing a DSS.
arjun00.com.np 22
.
.
Management Process:
Management can be defined as the organization and coordination

of activities of a business to achieve set objectives. Management is
incorporated as a factor of production together with materials,
machines, and money.
Management process is defined as a series of actions to be

performed in order to achieve the desired goals of the organization.
Management process can be divided into a set of inter-related
functions as follows:
1. Planning and Decision Making
Decision-making is the process of identifying a set of

feasible alternatives and choosing a course of action from them.
Decision-making is a part of planning.
2. Organizing
Organizing involves assigning tasks, grouping tasks into

departments and allocating resources across the organization.
3. Leading
Leading is the use of influence to motivate, manage and

direct employees to achieve organizational goals.
4. Controlling
Controlling is the process of monitoring and evaluating

activities performed by the employees.
arjun00.com.np 23
.
.
Supporting Process:
These are the processes that are performed to maintain integrity of

the product or service developed by primary processes as well as it
ensures that products and processes comply with predefined provisions
and plans. Supporting processes accompany (support) the primary
processes, which do not typically result in final products of the
organization, but rather indirectly contributes to the value added.
Some of the supporting processes are:

1. Documentation
The collection of documents that describes the
requirements, capabilities, limitations, design, operation and
maintenance of a system.
2. configuration management(CM)
Configuration management is a systems engineering process
for establishing and maintaining consistency of a product's
performance, functional, and physical attributes with its
requirements, design, and operational information throughout its
life.
3. Verification
The goal of software verification is to determine whether
the product under construction is being built to match its
specification.
4. Audit
.
arjun00.com.n 24
p
.
.
It is a systematic and independent examination to determine

whether quality activities and related results comply with
planned arrangements and whether these arrangements are
implemented effectively and are suitable to achieve
objectives.
System Structure:
The structure of the system is composed of mainly five elements
and they are:
Input
Process
Output
Feedback
Control
Fig: Basic structure of system
arjun00.com.n 25
p
.
.
Input: It involves capturing and assembling elements that enter the

system to be processed. Inputs to the system are anything to be
captured by the system from its environment i.e. raw materials.
Processing: It involves transformation processes that convert input to

output. For example, a manufacturing process.
Output: It involves transferring elements that have been produced by a

transformation process to their ultimate destination. Outputs are the
things produced by the system i.e. finished products which is sent back
to the environment.
Feedback: It is data about the performance of a system. It is the idea of

monitoring the current system output and comparing it to the system
goal. Any variation from the goal are then fed back in to the system and
used to adjust it to ensure that it meets its goal.
Control: It involves monitoring and evaluating feedback to determine

whether a system is moving toward the achievement of its goals. The
control function then makes necessary adjustments to a system’s input
and processing components to ensure that it produces proper output.
Environment
• The environment is the “supersystem” within which an

organization operates.
• It is the source of external elements that strike on the system.
• It determines how a system must function. For example, vendors
and competitors of organization’s environment, may provide
constraints that affect the actual performance of the business.
Boundaries and Interface
arjun00.com.n 26
p
.
.
• A system should be defined by its boundaries. Boundaries are the

limits that identify its components, processes, and
interrelationship when it interfaces with another system.
• Each system has boundaries that determine its sphere of
influence and control.
• The knowledge of the boundaries of a given system is crucial in
determining the nature of its interface with other systems for
successful design.
arjun00.com.n 27
p
.
.
Approaches to System Development and Importance of Metrics

Measurement in SDLC in SAD
Finding the Problems:
In this phase of the systems development life cycle, the analyst is

concerned with correctly identifying problems, opportunities, and objectives. This
stage is critical to the success of the rest of the project, because no one wants to
waste subsequent time addressing the wrong problem. The first phase requires
that the analyst look honestly at what is occurring in a business. Then, together
with other organizational members, the analyst pinpoints problems. Once all the
current problems have been identified along with the problems that might
happen in the future a report is generated during the planning phase so that the
problems might be handled efficiently.
Methodologies and Models, Tools and Techniques:

SDLC methodologies provide a systematic framework to design, develop
and deliver software applications, from beginning to end. It is a series of steps
that offer a foundation for the system development process. Having a structure to
develop system is fundamental, which is why there are multiple system
development methodologies available to choose from. It is increasingly important
for software engineers to select the right SDLC model that meets specific
requirements and concerns of the project to drive success. All SDLC
methodologies share a common ground of distinct phases that include planning,
analysis, design, building, testing, deploying, and maintenance.
Working under SDLC methodologies provides the opportunity to deploy

solutions faster because it is a consistent, repeatable and systematic approach.
Additionally, it allows organizations to respond better to market pressure and
deliver high-quality business applications due to its structure and systematic
nature which enables developers to work in a controlled environment.
arjun00.com.n 28
p
.
.
Some of the Popular SDLC models are Waterfall Model, Prototype Model, RAD
Model Agile Model etc.
1. Waterfall Model:
Also known as the traditional methodology, waterfall is a sequential and
linear flow for developing a system application. The process is outlined by a
series of finite stages, each of which must be fully completed before
moving on to the next one. The Waterfall approach follows this order:
requirements, design, execution, testing, and release.
Advantages:
→Easy to implement and understand
→Suitable for small projects
Disadvantages:
→ Very complex if we want to go back once the stage is finished. I.e.
hard to go back and make changes.
→ More time consuming and high risk.
2. Prototyping Model:
The prototyping model is applied when detailed information related to input

and output requirements of the system is not available. In this model, it is
assumed that all the requirements may not be known at the start of the
development of the system. It is usually used when a system does not exist
or in case of a large and complex system where there is no manual process
to determine the requirements. This model allows the users to interact and
experiment with a working model of the system known as prototype. The
prototype gives the user an actual feel of the system. At any stage, if the user
is not satisfied with the prototype, it can be discarded and an entirely new
system can be developed.
3. RAD Model
RAD stands for Rapid Application Development Model. This methodology
focuses on building applications in very short amount of time. It is a high
.
arjun00.com.np 29
.
.
speed adaptation of the linear sequential model in which rapid

development is achieved by using component based construction.
RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives
and other IT resources working progressively on their component or
prototype.
4. Agile Model
Agile SDLC model is a combination of iterative and incremental process

models with focus on process adaptability and customer satisfaction by
rapid delivery of working software product. Agile Methods break the
product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks.
Every iteration involves cross functional teams working simultaneously on
various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer

and important stakeholders.
CASE Tools:
It stands for Computer-Aided Software Engineering tools. CASE tools
are used to support a wide variety of SDLC activities. CASE tools can be
used to help in the project identification and selection, project initiation
and planning, analysis and design phases and/or in the implementation and
maintenance phases of the SDLC. CASE tools helps programmers and
analysts do their jobs more efficiently and more effectively by automating
routine tasks.
.
arjun00.com.np 30
.
.
The general types of CASE tools are listed below:

• Diagramming tools enable system process, data and control
structures to be represented graphically.
• Computer display (or forms) and report generators make it easier for
the systems analyst to identify data requirements and relationships.
• Analysis tools automatically check for incomplete, inconsistent or
incorrect specifications in diagrams, forms and reports.
• A central repository enables the integrated storage of specification,
diagrams, reports, and project management information.
• Documentation generators produce technical and user
documentation in standard formats.
• Code generators enable the automatic generation of program and
database definition code directly from the design documents,
diagrams, forms and reports.
Examples:
flowchart maker, Creative Pro Office, Doxygen, Accept 360,
Animated software design, Cscope for searching code in C,
etc
Software Measurement Process:
Software measurement process is that portion of the software process

that provides for the identification, definition, collection, and analysis
of measures that are used to understand, evaluate, predict, or control
software processes or products.
To assess the quality of the engineered product or system and to better

understand the models that are created, some measures are used.
These measures are collected throughout the software development
arjun00.com.np 31
.
.
life cycle with an intention to improve the software process on a

continuous basis. Measurement helps in estimation, quality control,
productivity assessment and project control throughout a software
project. Also, measurement is used by software engineers to gain
insight into the design and development of the work products. In
addition, measurement assists in strategic decision-making as a project
proceeds.
Software measurements are of two categories:
1. Direct measures
→Direct measures include software processes like cost and effort
applied and products like lines of code produced, execution

speed, and other defects that have been reported.
2. Indirect measures.
→Indirect measures include products like functionality, quality,
complexity, reliability, maintainability, and many more.
Actually these are called metrics i.e. A software metric is a measure of

software characteristics. Hence software metrics are important for
measuring software performance, measuring productivity, measuring
complexity and many more.
Size Oriented Metrics:
arjun00.com.np 32
.
.
Size Oriented Metrics derived by normalizing quality and productivity

Point Metrics measures by considering size of the software that has
been produced. The organization builds a simple record of size measure
for the software projects. It is built on past experiences of
organizations. It is a direct measure of software.
This metrics is one of simplest and earliest metrics that is used for
computer program to measure size. Size Oriented Metrics are also used
for measuring and comparing productivity of programmers. It is a direct
measure of a Software. The size measurement is based on lines of code
(LOC) computation. The lines of code are defined as one line of text in a
source file.
>> Size-oriented metrics depend on the programming language used.
>>As productivity depends on KLOC, so assembly language code will

have more productivity.
While counting lines of code, simplest standard is:
• Don’t count blank lines

• Don’t count comments
• Count everything else
• The size-oriented measure is not a universally accepted metho d.
For Example:
arjun00.com.np 33
.
.
→So, from information given in table , a set of simple size-oriented

metrics can be developed for each projects:
Size = Kilo Lines of Code (KLOC)
Effort = Person / month
Productivity = KLOC / person-month
Quality = Number of faults(Errors) / KLOC
Cost = $ / KLOC
Documentation = Pages of documentation / KLOC
Advantages:
1. LOC can be easily counted.

2. Many software estimation models like COCOMO model uses LOC
or KLOC as input.
Disadvantages:
1. LOC measures are language dependent, programmer dependent.

2. It is difficult to estimate LOC in early stage of development.
3. It characterizes only one specific view of size, namely length, it
takes no account of functionality or complexity.
arjun00.com.np 34
.
.
Function Oriented Metrics:
Function oriented metrics is based on functionality delivered by

the software. Functionality is measured indirectly using a measure
known as function point. Function Points are derived using empirical
relationship based on countable measures of software and assessments
of software complexity. i.e. it is derived by using a relationship
between complexity of software and the information domain values.
→ This method is independent of programming language used but is

based on calculating function point (FP).
→There are 5 parameters (information domains) with the help of which

a raw FP (FP COUNT) is calculated. They are:
1. Number of user input

2. Number of user output
3. Number of user inquiries
4. Number of files
5. NJNumber of external interfaces
arjun00.com.np 35
.
.
→Along with these parameters we need to calculate the complexity

adjustment Value (CAV) which is the sum of all the 14 complexity
adjustment factors ranging from 0 to 5.
→Once the CAV is calculated the function point can be calculated as:
FP =raw FP x [0.65 + 0.01 x CAV]

After calculating the function point, various other measures can be
calculated as shown below :
Productivity = FP / person-month
Quality = Number of faults / FP
Cost = $ / FP
Documentation = Pages of documentation / FP
arjun00.com.np 36
.
.
For Example:
No of user i/p = 50
No of user o/p = 40
No of user enquiries = 35
No of user files = 06
No of external Interface = 04
And the organization table is:
Function Type Simple Average Complex

Input 3 4 6
Output 4 5 7
Inquiries 3 4 6
Files 7 10 15
Interface 5 7 10
Now calculating the raw function point i.e. FP count for an average
project:
Domain Count x Average FP count

Input 50 x 4 200
Output 40 x 5 200
Inquiry 35 x 4 140
Files 06 x 10 60
interfaces 04 x 7 28
Raw FP = 628
arjun00.com.np 37
.
.
Now, we need to calculate the complexity adjustment factor for all the
14 questions which is in the range of 0 to 5. Let us consider the
complexity adjustment factor to be 3 as it is the average value.
So,
Complexity Adjustment Value (CAV) = 14 x 3
= 42.
Finally,
Function Point (FP) = Raw FP x [0.65 + 0.01 x CAV]
= 628 x [0.65 + 0.01 x 42]

= 671.96
Defect Removal Efficiency

The defect removal efficiency (DRE) gives a measure of the
development team ability to remove defects prior to release. It is
calculated as a ratio of defects resolved to total number of defects
found. It is typically measured prior and at the moment of release.
DRE = Number of defects resolved by the development team / total

number of defects at the moment of measurement.
arjun00.com.np 38
.
.
DRE is typically measured at the moment of version release, the best

visualization is just to show current value of DRE as a number.
Example
For example, suppose that 50 defects were found during QA/testing
stage and 40 defects were resolved by the development team at the
moment of measurement. The DRE would be calculated as:
40
DRE = ∗ 100 %
50
= 80 %
Types of Metrics:
1. Process Metrics: Process metrics are measures of the

software development process, such as
o Overall development time
o Type of methodology used
➔ Process metrics are collected across all projects

and over long periods of time. So that
improvements can be done in the software
development process.
2. Project Metrics: Project Metrics are the measures of

software project and are used to monitor and control the
arjun00.com.np 39
project. They enable a software project manager.to:
.
arjun00.com.np 40
.
.
o Minimize the development time by making the

adjustments necessary to avoid delays and potential
problems and risks.
o Assess product quality on an ongoing basis and modify
the technical approach to improve quality.
3. Product metrics: Product metrics are measures of the

software product at any stage of its development, from
requirements to installed system. Product metrics may
measure:
o The complexity of the software design
o The size of the final program
o The number of pages of documentation produced.
Quality Assurance (QA): Steps taken to make sure that a company’s

products or services are of sufficiently high quality.
Quality Control: Quality control is a detection activity, which is focused

on detecting the defects once the product is manufactured.
FACTORS WHICH DETERMINE THE QUALITY OF A SYSTEM OR WHAT ARE
QUALITY FACTOR SPECIFICATIONS
Following are the factors which determine the quality of a system:
1. Correctness: Correctness means the extent to which a program satisfies its

specification and fulfills the client's objective.
2. Reliability: Reliability is figured ou t by evaluating the frequency and severity of

failure, the accuracy of output results, the mean time between failures (MTBF),
the ability to recover from failure and the predictability of the program. it defines
arjun00.com.np 41
.
.
the extent to which a program is supposed to perform its function (how much it is
trustable) with the required precision.
3. Efficiency: Efficiency in a quality system can be defined as the power to

produce the intended effects. Efficiency can be understood by the amount of
computing and code required by a program to process any function in short time
duration.
4. Usability: Usability means that how much the system is usable, the labor
required to understand, operate, prepare input and interpret output of a
program.
5. Maintainability: It describes the efforts required to locate and fix an error in a

program
6. Testability: The quality system should be able to give the correct result for
almost any input. Testability means that the system is capable for the required
testing of the programs for their functionality.
7. Portability: Portability makes the system to run the program from one platform
to other or to different hardware.
8. Accuracy: Accuracy describes the limit of correctness of result, in other words

the precision of computations and control.
9. Error Tolerance: Error tolerance describes that how much a system is capable
or sufferable or endurable (during error occurs). Error tolerance is the Damage
done when program encounters an error.
10. Security: This factor gives the control and protection of programs and
database from the unauthorized users.
11. Simplicity: Simplicity is the degree to which a program is understandable

without much difficulty.
12. Reusability: Reusability is the factor by which the program or its parts can be
used as building blocks or as prototypes for other programs.
arjun00.com.n 42
p
.
.
13. Operability. It is the quality factor which ensures the ease of programs
operation.
14. Traceability: It is the ability to trace a design representation or actual program

component back to initial objectives.
arjun00.com.np 43
.
.
Requirement Analysis
Introduction:
The objective of this phase is to define in more detail the system inputs,
processes, outputs and interfaces. At the end of this phase the system’s
processes will be defined at the functional level, meaning the functions to be
performed will be known, but not necessarily how they will be performed.
Requirements Analysis will collect the functional and non-functional

requirements of the software being developed. Basically, functional requirements
are the user requirements that the system needs to offer. Non-functional
requirements are basically the quality constraints that the system must satisfy as
per the contract. They are:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
The importance of communication:
The most important part in SDLC is communication. During SDLC period, there is
more than a single person working on the software project; communication
becomes one of the most important steps in ensuring the success of the project.
It’s is one of the most important measures for each project to ensure “that each
stakeholder communicates their thoughts clearly and concisely in a form that
everyone else understands.” This is because the lack of communications while
developing the software causes communication breakdowns and can negatively
impact the progress of development. “Indeed, most practitioners in the software
engineering field argue that poor communication and changing requirements are
.
arjun00.com.np 44
.
.
the primary causes of cost overruns and late product delivery in the software
engineering industry.”
→ One of the best approaches for reducing communication breakdown is a

creation of a project communication plan, which will effectively overlook and
guide the messages between all groups associated with software development.
Identifying the Requirement:
Requirements define the needs of the project to provide best of its utility and
benefits. If they aren’t clear or analysis is not done properly, it might lead to
failure of the project no matter how well the concept and design is.
Identifying the requirements is the initial phase of the requirement analysis. In

this phase all the requirements of the users are identified using various methods
so that no requirements are missed. Along with that this system requirement for
the given problems are also identified. Various ways that are used in identifying
the requirements are:
→Gathering Information by asking questions
→Gathering Information by Observation
→Interviewing
→Gathering information by Prototyping
Information Collection Methods:
In order to determine the requirements of a system, information must be

gathered from the customer. The analyst needs to gather requirements by a
variety of techniques and make sure that the current business processes and the
needs for the new system are well understood before moving into design.
arjun00.com.np 45
.
.
If the analyst does not discover any kind of the important requirements in early
phase, then this might bring different kinds of problems in later phases such as
design and implementation phase.
Also the analyst should carefully determine who is included in the requirements-
gathering process. The choice to include (or exclude) someone is significant;
involving someone in the process implies that the analyst views that person as an
important resource and values his or her opinions. You must include all of the key
stakeholders (the people who can affect the system or who will be affected by the
system). This might include managers, employees, staff members, and even some
customers and suppliers.
There are many different methods used by systems analysts to gather the
information required to design an information system. So analyst can gather
(collect) information by using following techniques:
1. Gathering information by asking questions:
In these techniques we ask relevant questions to the client and to other

stakeholders about the overall system and find out their view about the
system. The client who wants develop a system will be asked multiple
questions so that the analyst would find out the necessary and important
requirements of the system as per the client’s view. Also the analyst will ask
questions to other stakeholders that are directly affected by the system, about
the system and find out more about the system.
Questionnaires:
The questionnaire is considered as a tool for gathering required

information. A questionnaire is a research tool consisting of a series of
questions and other facts asked to individuals to obtain statistically useful
information about a given topic. The use of questionnaires is an
information-gathering technique that allows systems analysts to study
attitudes, beliefs, behavior, and characteristics of several key people in the
organization who may be affected by the current and proposed systems.
arjun00.com.n 46
p
.
.
Attitudes are what people in the organization say they want (in a new
system); beliefs are what people think is actually true; behavior is what
organization members do; and characteristics are properties of people or
things.
Advantages:
1. It is easier to perform as compared to the interview.

2. A wide geographical area can be covered and a large number of people
can be contacted using this method.
3. The respondents feel free to express themselves in questionnaires then
in an interview.
4. Respondents get enough time to think about the questions and the
response.
Disadvantages:
1. Many people are not good at writing

2. Low percentage of returns
3. Lack of response from some can bias results
4. Respondents can be unknown
Electronic Data Gathering:
This is another technique of gathering data or information by asking

questions and using the current technology. That is, questions are asked by
analyst by using electronic tools in the situations where clients or
stakeholders may not be in same geographical area. The analyst can send a
sequence of questions to the stakeholders using electronic tools such as e-
mail. The stakeholders will check their e-mails and locate the file sent by
the analyst and download it. After all the questions have been answered,
the stakeholders can send the answers using e-mail to the analyst.
Advantages:
1. Easy to perform as compared to interview.
arjun00.com.np 47
.
.
2. Whole world can be covered and the questions can be sent to any part
of the world.
3. Respondents get enough time to think and answer the question.
Disadvantages:
1. It is quite hard for the stakeholders to use e-mails if they are not familiar
with it.
2. People may not be good at opening documents and editing those sent
by the analyst.
3. Low percentage of return.
4. Lack of response from someone can bias results
Interviewing:
An interview is a conversation between two people (the interviewer

and the interviewee) where questions are asked by the interviewer to
obtain information from the interviewee.
Interviewing is one of the primary ways analyst gather information

about an information system project. It is the main approach used to
analyze large structured systems. During interviewing you will gather facts,
opinions, and speculation and observe body language, emotions and other
signs of what people want and how they assess current systems.
Interviews are the formal meetings where the analyst can collect
information about the working of the present system and the requirement
of any planned replacement.
Advantages:
1. The flexibility of interview makes it a superior technique for enquiring

into areas which are difficult to be explored using any other technique.
2. It provides a better opportunity then the questionnaires to evaluate the
validity of the information collected. The interviewer can not only
arjun00.com.np 48
.
.
observe what subjects but also study their body language and
expression.
3. It is an effective technique for getting information about complex
subjects and for sensing the feelings underline opinions.
4. Generally people prefer being interviewed rather than filling up lengthy
questionnaires.
5. Interviews permit the system analyst to adapt or revise questions for
each individuals.
Disadvantages:
1. This method requires more time and money for its conduction.
2. Time-consuming, it takes long preparation time.
3. Success highly dependent on analyst’s human relations skills
4. May be impractical due to location of interviewees.
2. Gathering information by observation:
Team of experts visits the client’s organization or workplace. They observe the
actual working of the existing installed systems. The direct approaches of
interviewing and questionnaires provide valuable user feedback based on the
questions asked of them; however, there are times when direct observation may
be better suited in requirement gathering. To get a better understanding of a user
in their in current work environment, the analyst may observe the user
themselves. User observation is helpful in assisting the analyst by getting a full
grasp of how the user interacts with the system, firsthand. When the objective is
to improve a task, the analyst can observe the user and how their surroundings
affect their interaction with the system. Sometimes stakeholders may find it
difficult in explaining what exactly what their tasks consists of and what their
requirements may be, observing the user in cases like these will help provide the
requirements. User observation may also be useful in validating data that had
arjun00.com.np 49
.
.
been previously collected. Be it in cases where users provide misleading

information, or cannot fully recollect all of their tasks in how they use the system.
While there are many advantages to use observation, there are some
disadvantages associated as well. As previously mentioned, observations should
take place during peak, normal, and low business times. However, it may still be
difficult to capture enough information in one of these sessions. There may be the
need for multiple sessions to verify that facts collected were constant, rather than
isolated incidents.
3. Prototyping:
Prototyping is another form a contemporary requirement gathering method.

Prototyping is iterative process that heavily involves the users to complete. The
user provides the requirements, in which the analyst can plug in directly and show
the user the outcome.
Prototyping is dependent on user interaction and cannot be utilized as its own

method of gathering requirements. The analyst must interview or perform some
other form of requirement gathering to perform before they begin prototyping.
However, prototyping is very effective in specifying requirements, because of how
heavily involved the user is.
The user will still be sitting side by side with the analyst, providing them
requirements as the analysts enters them into a working system. This will allow
the user to instantly see the outcome of their requirements. At this point the user
may change some of their requirements. They may see that what they provided
was not what they had in mind. A form may appear cluttered with information; at
this point the user can go back and adjust their information. This may also be the
case in when the user forgets important information; they may not realize it until
they actually see a working version of the system. The user and analyst will
continue to go through different iterations, until all specifications are complete.
The last prototype will be used as a model to build the actual system.
Some of the disadvantages of prototyping is the user will pay too much attention
to details on the screens, rather than what the prototype is meant to
arjun00.com.np 50
.
.
communicate. Executives can grow impatient as they see a complete prototype,

but will not understand why the finished system takes so long to complete.
Software Requirement Document:
A software requirement document is a document that is created by the analyst

after all the requirement gathering techniques are performed, which consists of
the requirements that the project needs to fulfill. It is also called as software
requirement specification (SRS) document. Software Requirements Specifications
(SRS) is a document that describes what the software will do and how it will be
expected to perform.
Without software requirement document the developers might create the

product but it may not be as per the specifications. There is a high chance to
create wrong product without proper documentation of system requirements.
This document ensures that the software development team or other

stakeholders are on the same page regarding what needs to be built and are fully
aware of the goal, scope, functional requirements, challenges, and budget
regarding the software.
A software requirement document not only fulfills the needs of all the
stakeholders (business, users) but also helps in minimizing overall development
time and costs.
arjun00.com.np 51
.
.
Process Modeling (Process Description method):
Process modeling graphically represents the processes that capture, manipulate,

store and distribute data between a system and its environment and among
system components. It utilizes the information gathered during requirements
determination. Main focus is to model the processes and data structures.
A process model is a formal way of representing how a business operates. It is a

core diagram in structured analysis and design. It shows the flow of information
through a system. Each process transforms inputs into outputs. Process models
are based on behavior and actions. Example: data flow diagram.
Data Flow Diagram (DFD):
A DFD is a pictorial representation of the movement of data between external

entities and the processes and data stores within a system. It is common
technique for creating process models. A DFD shows how data moves through an
information system but does not show program logic or processing steps. DFDs
can also be used for the visualization of data processing (structured design).
DFD symbols:
arjun00.com.np 52
.
.
Data Flow
A dataflow is data that are in motion and moving as a unit from one place in a
system to another. A data flow is depicted as an arrow. The arrow is labeled with
a meaningful name for the data in motion; for example, customer order, sales
receipt or paycheck.
Process
A process is the work or actions performed on data so that they are transformed,
stored, or distributed. The symbol for a process is a rectangle with rounded
corners. Inside the rectangle are written both the number of the process and a
name, which indicates what the process does. For example, the process may
generate paychecks, calculate overtime pay, or compute grade-point average.
Data Store
A data store is data at rest. A data store may represent one of many different
physical locations for data, including a file folder, one or more computer-based
file(s), or a notebook. The symbol for a data store is a rectangle with the right
vertical line missing. Its label includes the number of the data store (e.g. D1 and
D2) and a meaningful label, such as student file, transcript, etc.
Source/Sink (External Entities)
Source/Sink is the origin and/or destination of the data (outside of the system).
Source/sinks are sometimes referred to as external entities because they are
outside the system and define the system’s boundaries. Data must originate
outside a system from one or more sources, and the system must produce
information to one or more sinks. It is drawn as a square symbol. The name states
what the external agent is. Because they are external, many characteristics are
not of interest to us. A person, organization, or system that is external to the
system but interacts with it.
arjun00.com.np 53
.
.
arjun00.com.np 54
.
.
arjun00.com.np 55
.
.
DFD Levels:
➔ Context Diagram
o Overview of the organizational system
➔ Level-0 DFD
o Representation of system’s major processes at high level of
abstraction
➔ Level-1 DFD
o Results from the decomposition of level 0 diagram
➔ Level-n DFD
o Results from decomposition of level n-1 diagram.
Context Diagram:
Context diagram shows the system boundaries, external entities that interact with
the system, and major information flows between entities and the system. It is
the first DFD in every business process. It shows the context into which the
business process fits. It also shows the overall business process as just one
process (process 0). It shows all the external entities that receive information
from or contribute information to the system.
arjun00.com.np 56
.
.
Note: only one process symbol and no data stores are shown in context
diagram.
Level-0 DFD:
Level-0 DFD shows the system’s major processes, data flows, and data stores at a
high level of abstraction.
It shows all the major processes that comprises the overall system- the internal
components of process 0. It also shows how the major processes are interrelated
by data flows. It shows external entities and the major processes with which they
interact. It adds data stores.
Note: processes are labeled 1.0, 2.0, etc. These will be decomposed into more
primitive (lower-level) DFDs.
arjun00.com.np 57
.
.
Level-1 DFD:
Level-1 DFD shows the sub-processes of one of the processes in the level-0 DFD.
Generally, one level 1 diagram is created for every major process on the level 0
diagram. It shows all the internal processes that comprises a single process on the
level 0 diagram. It also shows how information moves from and to each of these
processes.
If a parent process is decomposed into, for example, three child processes, these
three child processes wholly and completely make up the parent process.
Note: processes are labeled 1.1, 1.2, 4.1, 4.2 etc. These can be further
decomposed in more primitive (lower-level) DFDs if necessary. Sources and sinks
are optional on level-1 diagrams.
.
arjun00.com.np 58
.
.
arjun00.com.np 59
.
.
Level-n DFD
Level-n DFD shows the sub-processes of one of the processes in the level n-1 DFD.
It shows how information moves from and to each of these processes.
Fig: level-2 diagram showing the decomposition of process 4.3 from the level-1
diagram for process 4.0
Logical and Physical DFDs:
Data flow diagrams are categorized as either logical or physical. A logical data
flow diagram focuses on the business and how the business operates. It is not
concerned with how the system will be constructed. Instead, it describes the
business events that take place and the data required and produced by each
event. Conversely, a physical data flow diagram shows how the system will be
implemented, including the hardware, software, files, and people involved in the
system.
Logical DFD
• Logical DFD depicts how the business operates.

• The processes represent the business activities.
• The data stores represent the collection of data regardless of how the data
are stored.
• It shows how business is controlled.
arjun00.com.n 60
p
.
.
The use of a logical model has many benefits including:
• Better communication: A logical diagram is easier to use when

communicating with the user of a system, because it is centered on
business activities.
• More stable system: Systems formed using a logical data flow diagram are
often more stable than those that are not because they are based on
business events and not on a particular technology or method of
implementation.
• Better understanding of business: A logical data flow diagram has a
business emphasis and helps the analyst to understand the business being
studied, to grasp why procedures are performed, and to determine the
expected result of performing a task.
• Flexibility and maintenance: The new system will be more flexible and
easier to maintain if its design is based on a logical model and the business
functions are not subject to frequent change. Physical aspects of the
system change more frequently than do business functions.
• Simple to develop: The logical model is easy to create and simpler to use
because it does not often contain data stores other than files or a
database.
• Easy conversion to physical model: Once the logical data flow diagrams
are created, the creation of physical data flow diagrams becomes easy.
Physical DFD
• Physical DFD depicts how the system will be implemented (or how the
current system operates).
• The processes represent the programs, program modules, and manual
procedures.
• The data stores represent the physical files and databases, manual files.
• It show controls for validating input data, for obtaining a record, for
ensuring successful completion of a process, and for system security.
Benefits of Physical Data Flow Diagram
• Clarifying which processes are manual and which are automated: Manual
processes require detailed documentation and automated process require
computer programs to be developed.
.
arjun00.com.np 61
.
.
• Describing processes in more detail than do logical DFDs: Describes all

steps for processing of Data.
• Sequencing processes that have to be done in a particular order:
Sequence of activities that lead to a meaningful result are described. For
example, update must be performed before producing a summary report.
• Identifying temporary data storage: Temporary storage such as a sales
transaction file for a customer receipt (report) in a grocery store, are
described.
• Specifying actual names of files and printouts: Logical data flow diagrams
describe actual filenames and reports, so that the programmers can relate
those with the data dictionary during the developmental phase of the
system.
• Adding controls to ensure the processes are done properly: These are
conditions or validations of data that are to be met during input, delete,
and other processing of data.
arjun00.com.np 62
.
.
arjun00.com.np 63
.
.
Advantages of DFDs:
• Since they are easily understood by users (i.e presented in a non-technical
format), they are easier to validate for correctness. It is therefore easy to
determine whether requirements are correct. The probability of a better
system is increased.
• It is argued that a picture can convey meaning more quickly than more
traditional methods such as textual narrative.
• Further understanding of the inter-relatedness of systems and subsystems
are developed.
• Provides a means of analysis of a proposed system to determine if the
necessary data are processes have been defined.
• It is used as a part of system documentation files.
Disadvantages:
• For large systems it can be a time consuming and complex task to produce
all necessary levels of DFDs.
• It can be difficult to read and understand what is going on at a first glance.
• The symbols used are not common to all DFDs. Different models use
different symbols for the structure of a DFD.
System Flow Diagram (SFD)/system Flowchart:
A system flowchart is a visual representation of processes, decisions, inputs and

outputs that together form a system. System flowcharts are a way of displaying
how data flows in a system and how decisions are made to control events.
To illustrate this, symbols are used. They are connected together to show what
happens to data and where it goes.
Note that system flow charts are very similar to data flow diagram. Data flow
diagrams do not include decisions, they just show the path that data takes, where
it is held, processed, and then output.
SFD symbols:
.
arjun00.com.np 64
.
.
arjun00.com.np 65
.
.
Fig: system flowchart for hospital service
Decision Tables:
Decision tables are a concise visual representation for specifying which actions to
perform depending on given conditions. They are algorithms whose output is a
set of actions. A decision table is an excellent tool to use in both testing and
requirements management.
Decision tables are used when the process is logically complex involving large
number of conditions and alternate solutions.
It is useful in situations where the resulting actions depend on the occurrence of
one or several combinations of independent conditions.
consider the following sample business requirement:
A company’s employees are paid bonuses if they work more than a year in the
company and achieve individually agreed targets.
Try to list out all the conditions and actions mentioned in the requirements.
Hopefully, you would have listed out the conditions as listed below.
Conditions:
• Employment for more than 1 year?

• Agreed target?
• Achieved target?
Actions / Outcome :
• Bonus payment?
With all these details, let’s draw the decision table.
arjun00.com.np 66
.
.
• In the given requirement, there are 3 different conditions. Each of these

conditions has two options (YES/NO). Hence the total number of possible
combinations is 8 (i.e. 23).
• In a decision table, conditions consider as inputs and actions as outputs. Each
rule can be interpreted as a test case. In this way, decision table testing
ensures complete coverage.
Structured English:
Structure English is derived from structured programming language which gives
more understandable and precise description of process. It is based on procedural
logic that uses construction and imperative sentences designed to perform
operation for action.
→It is best used when sequences and loops in a program must be considered and
the problem needs sequences of actions with decisions.
→It does not have strict syntax rule. It expresses all logic in terms of sequential
decision structures and iterations.
→Intention is to give precise description of a process.
arjun00.com.np 67
.
.
For example, see the following sequence of actions −
if customer pays advance

then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if
arjun00.com.np 68
.
.
Advantages of structured English:
• Clarifying the logic and relationships found in human languages.

• Structured English is intended to be used as an effective communication
technique for analysts and users.
• It can be made precise and readable.
• It can be written quickly and naturally.
Disadvantages of structure English:
•
• It takes some time to build structured English skills.
• It seems to be more formal than it is.
• It can scare off the user.
Advantages of decision tables:

• Simple and easy to understand by non-computer literate users and
managers.
• Good documentation of rules used in data processing.
• Simple representation of complex decision rules.
• Easy to check for possible errors.
• Enhances readability.
Disadvantages of Decision Tables:
• Where the logic of a system is simple, flowcharts nearly always serve the
purpose better than a decision table.
• Decision tables do not scale up well. We need to “factor” large tables into
smaller ones to remove redundancy.
• All programmers may not be familiar with decision tables and therefore
flowcharts are more common.
arjun00.com.np 69
.
.
Object Modeling and designing
Data dictionary:
A data dictionary is a table providing a comprehensive description of each field in

the database. This commonly includes: field name, data type, data format, field
size, description and examples.
This is shown in the example below:
Data dictionary is a structured repository of data about data(metadata).

It contains information about each of the component of DFDs, data stores,
processes and data flow. Data Dictionary is an integral part of system
specifications, since without it, DFDs are just pictures with no details.
Data dictionary is a structured repository of data. It is a catalogue of all data

elements, data structure and processes described in logical DFDs. Although we
give descriptive name to the data flows, process and data stores in a DFD, it does
not give the details. Hence to keep the details of the contents of data flows,
process and data stores we also require a data dictionary.
arjun00.com.np 70
.
.
arjun00.com.np 71
.
.
Consider the following DFD:
arjun00.com.np 72
.
.
Advantages:
• May be used at high or low level of analysis

• Provides good system documentation at granular level
• Improves consistency in data use.
• Easier data analysis
• Reduces data redundancy
• Simpler programming
• Improves knowledge about the data resources
Disadvantages:
• Doesn’t provide the details about data.

• Needs careful planning, defining the exact requirements planning, its
contents, testing and implementation.
• For large computer based systems, the data dictionary grows rapidly in size
and complexity increases.
• Difficult to maintain it manually.
arjun00.com.np 73
.
.
ER-Diagram:
arjun00.com.np 74
.
.
arjun00.com.np 75
.
.
arjun00.com.np 76
.
.
arjun00.com.np 77
.
.
arjun00.com.np 78
.
.
arjun00.com.np 79
.
.
arjun00.com.np 80
.
.
arjun00.com.np 81
.
.
Example:
arjun00.com.np 82
.
.
arjun00.com.np 83
.
.
arjun00.com.np 84
.
.
arjun00.com.np 85
.
.
arjun00.com.np 86
.
.
Here all the fields are functionally dependent on the primary key.
arjun00.com.np 87
.
.
arjun00.com.np 88
.
.
Object Modeling:
Object Modeling is a general framework for designing information systems. It

focuses in objects, the actions they perform and the messages they send to one
another to cause those actions to be taken.
An object model is a logical interface, software or system that is modeled through

the use of object-oriented techniques. It enables the creation of an architectural
software or system model prior to development or programming. An object
model is part of the object-oriented programming (OOP) lifecycle.
arjun00.com.np 89
.
.
An object model helps describe or define a software/system in terms of objects

and classes. It defines the interfaces or interactions between different models,
inheritance, encapsulation and other object-oriented interfaces and features.
The Object Modeling Technique (OMT) software engineering methodology is

another well known example of a software engineering methodology. The OMT
software engineering methodology deals with object-oriented development in
the analysis and design phases.
Class Diagram
In software engineering, a class diagram in the Unified Modeling Language (UML)

is a type of structure diagram that describes the structure of a system by showing
the system's classes, their attributes, operations (or methods), and the
relationships among objects.
Class Notation
A class notation consists of three parts:
1. Class Name
o The name of the class appears in the first partition.
2. Class Attributes
o Attributes are shown in the second partition.
o The attribute type is shown after the colon.
o Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
o Operations are shown in the third partition. They are services the
class provides.
o The return type of a method is shown after the colon at the end of
the method signature.
o The return type of method parameters is shown after the colon
following the parameter name.
o Operations map onto class methods in code
arjun00.com.np 90
.
.
Class Relationships
A class may be involved in one or more relationships with other classes. A

relationship can be one of the following types:
Relationship Type Graphical Representation
Inheritance (or Generalization):
• Represents an "is-a" relationship.

• SubClass1 and SubClass2 are
specializations of Super Class.
• A solid line with a hollow arrowhead that
point from the child to the parent class
Simple Association:
• A structural link between two peer

classes.
• There is an association between Class1
and Class2
• A solid line connecting two classes
Aggregation:
A special type of association. It represents a

"part of" relationship.
• Class2 is part of Class1.
arjun00.com.np 91
.
.
• Many instances (denoted by the *) of

Class2 can be associated with Class1.
• Objects of Class1 and Class2 have
separate lifetimes.
• A solid line with an unfilled diamond at
the association end connected to the
class of composite
Composition:
A special type of aggregation where parts are

destroyed when the whole is destroyed.
• Objects of Class2 live and die with Class1.

• Class2 cannot stand by itself.
• A solid line with a filled diamond at the
association connected to the class of
composite
Dependency (Realization):
• Exists between two classes if the changes

to the definition of one may cause
changes to the other (but not the other
way around).
• Class1 depends on Class2
• A dashed line with an open arrow
Relationship Names
• Names of relationships are written in the middle of the association line.

• Good relation names make sense when you read them out loud:
o "Every spreadsheet contains some number of cells",
o "an expression evaluates to a value"
• They often have a small arrowhead to show the direction in which
direction to read the relationship, e.g., expressions evaluate to values, but
values do not evaluate to expressions.
.
arjun00.com.np 92
.
.
Visibility of Class attributes and Operations
In object-oriented design, there is a notation of visibility for attributes and

operations. UML identifies four types of visibility: public, protected, private.
The +, -, # symbols before an attribute and operation name in a class denote the
visibility of the attribute and operation.
• + denotes public attributes or operations

• - denotes private attributes or operations
• # denotes protected attributes or operations
Multiplicity
How many objects of each class take part in the relationships and multiplicity can
be expressed as:
• Exactly one - 1
• Zero or one - 0..1
• Many - 0..* or *
• One or more - 1..*
• Exact Number - e.g. 3..4 or 6
• Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of
objects other than 2 or 5
arjun00.com.np 93
.
.
arjun00.com.np 94
.
.
Fig: Hotel Management system
Fig: online shopping system
Use Case Diagram:
A use case diagram is used to represent the dynamic behavior of a system. It

encapsulates the system's functionality by incorporating use cases, actors, and
their relationships. It models the tasks, services, and functions required by a
system/subsystem of an application. It depicts the high-level functionality of a
system and also tells how the user handles a system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the
system.
4. It represents the interaction between the actors.
arjun00.com.np 95
.
.
It is essential to analyze the whole system before starting with drawing a use case
diagram, and then the system's functionalities are found. And once every single
functionality is identified, they are then transformed into the use cases to be used
in the use case diagram. Other than use cases, it also contains the actors and the
relationships between the actor and the use cases. Basically, an actor is an
external entity i.e. person that interacts with the system. An actor can interact
with multiple use cases.
Example:
arjun00.com.np 96
.
.
Example 2:
The View Items is further extended by several use cases such as; Search Items,
Browse Items, View Recommended Items, Add to Shopping Cart, Add to Wish list.
All of these extended use cases provide some functions to customers, which
allows them to search for an item. The View Items is further extended by several
use cases such as; Search Items, Browse Items, View Recommended Items, Add to
Shopping Cart, Add to Wish list. All of these extended use cases provide some
functions to customers, which allows them to search for an item.
Both View Recommended Item and Add to Wish List include the Customer
Authentication use case, as they necessitate authenticated customers, and
simultaneously item can be added to the shopping cart without any user
authentication.
arjun00.com.np 97
.
.
Sequence Diagram:
The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It portrays the communication between any two
lifelines as a time-ordered sequence of events, such that these lifelines took part
at the run time. In UML, the lifeline is represented by a vertical bar, whereas the
message flow is represented by a vertical dotted line that extends across the
bottom of the page.
Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is

positioned at the top of the diagram.
arjun00.com.np 98
.
.
Actor
A role played by an entity that interacts with the subject is called as an actor. It is
out of the scope of the system. It represents the role, which involves human users
and external hardware or subjects.
arjun00.com.np 99
.
.
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in

which an operation is performed by an element, such that the top and the bottom
of the rectangle is associated with the initiation and the completion time, each
respectively.
arjun00.com.np 100
.
.
Messages
The messages depict the interaction between the objects and are represented by
arrows. They are in the sequential order on the lifeline. The core of the sequence
diagram is formed by messages and lifelines.
Following are types of messages enlisted below:
• Call Message: It defines a particular communication between the lifelines

of an interaction, which represents that the target lifeline has invoked an
operation.
• Return Message: It defines a particular communication between the

lifelines of interaction that represent the flow of information from the
arjun00.com.np 101
.
.
receiver of the corresponding caller message.
• Self Message: It describes a communication, particularly between the

lifelines of an interaction that represents a message of the same lifeline,
has been invoked.
Note
A note is the capability of attaching several remarks to the element. It basically

carries useful information for the modelers.
Sequence Fragments
→ Sequence fragments have been introduced by UML 2.0, which makes it

quite easy for the creation and maintenance of an accurate sequence
diagram.
arjun00.com.np 102
.
.
→ It is represented by a box called a combined fragment, encloses a part of

interaction inside a sequence diagram.
Types of fragments
1. alt: alternative multiple fragments: The one fragment for which the
condition is true will execute.
2. Opt: optional. It is just like alt but with only one trace.
3. Loop: fragments are run multiple time.
Fig: simple sequence diagram for food ordering system.
arjun00.com.np 103
.
.
arjun00.com.np 104
.
.
Quality Assurance
Introduction:
What is Quality?
Quality is defined as the product or services that should be "fit for use and
purpose."
Quality is all about meeting the needs and expectations of customers concerning
functionality, design, reliability, durability, and price of the product.
A process or procedure for minimizing errors and ensuring quality in

products. Poor quality can result from inaccurate requirements, design problems,
coding errors, faulty documentation, and ineffective testing. A quality assurance
(QA) team reviews and tests all applications and systems changes to verify
specifications and software quality standards. A successful organization must
improve quality in every area, including its information systems. Top management
must provide the leadership, encouragement, and support needed for high-
quality IT resources. The main objective of quality assurance is to avoid problems
or to detect them as soon as possible. In an effort to achieve high standards of
quality, software systems developers should consider software engineering
concepts, internationally recognized quality standards, and careful project
management techniques.
Levels of assurance (implementation of quality assurance): Analysts use four

levels of quality assurance: testing, verification, validation, and certification.
a. Testing: Systems testing is an expensive but critical process that can take as
much as 50 percent of the budget for program development. The common
view of testing held by users is that it is performed to prove that there are
no errors in a program. However, this is virtually impossible, since analysts
cannot prove that software is free and clear of errors. Therefore, the most
useful and practical approach is with the understanding that testing is the
.
arjun00.com.np 105
.
.
process of executing a program with explicit intention of finding errors that

is, making the program fail. The tester, who may be an analyst,
programmer, or specialist trained in software testing, is actually trying to
make the program fail. A successful test, then, is one that finds an error.
Analysts know that an effective testing program does not guarantee
systems reliability. Reliability is a design issue. Therefore, reliability must be
designed into the system. Developers cannot test for it.
Alpha Testing is a type of software testing performed to identify bugs

before releasing the product to real users or to the public. Alpha Testing is
one of the user acceptance testing.
➔ performed by developers
➔ performed in virtual environment.
➔ Involves both black and white box testing.
➔ This is a long process then beta testing.
Beta Testing is performed by real users of the software application in a real

environment. Beta testing is one of the type of User Acceptance Testing.
➔ Performed by customers.
➔ Performed in real environment.
➔ Involve black box testing only.
➔ This is short process then alpha testing.
Black Box Testing: in black box testing, the knowledge of internal working
structure (code) is not required. i.e. only GUI is required for this testing.
White Box Testing: in white box testing, knowledge of internal working

structure (coding of software) is necessarily required. i.e. testing in the
source code is called white box testing.
Grey Box Testing: partially knowledge of the internal working structure of

the system is required.
arjun00.com.np 106
.
.
b. Verification and Validation: Like testing, verification is also intended to find

errors. Executing a program in a simulated environment performs it. Validation
refers to the process of using software in a live environment in order to find
errors. When commercial systems are developed with the explicit intention of
distributing them to dealers for sale or marketing them through company –
owned field offices, they first go through verification, some-times called alpha
testing. The feedback from the validation phase generally produces changes in the
software to deal with errors and failures that are uncovered. Then a set of user
sites is selected that puts the system into use on a live basis. These beta test sites
use the system in day- to - day activities; they process live transactions and
produce normal system output. The system in live is very sense of the word,
except that the users are aware they are using a system that can fail. But the
transactions that are entered and the persons using the system are real.
Validation many continue for several months. During the course of validating the
system, failure may occur and the software will be changed. Continued use may
produce additional failures and the need for still more change.
Verification in Software Testing is a process of checking documents, design, code,

and program in order to check if the software has been built according to the
requirements or not. The main goal of verification process is to ensure quality of
software application, design, architecture etc. The verification process involves
activities like reviews, walk-through and inspection.
c. Certification: Software certification is an endorsement of the correctness of the

program, an issue that is rising in importance for information systems
applications. There is an increasing dependence on the purchase or lease of
commercial software rather than on its in-house development. However, before
analysts are willing to approve the acquisition of a package, they often require
certification of the software by the developer or an unbiased third party. For
example, selected accounting firms are now certifying that a software package in
fact does what the vendor claims it does and in a proper manner. To so certify the
software, the agency appoints a team of specialists who of specialists who
carefully examine the documentation for the system to determine what the
arjun00.com.np 107
.
.
vendor claims the system does and how it is accomplished. Then they test the
software against those claims. If no serious discrepancies or failures are
encountered, they will certify that the software does what the documentation
claims. They do not, however, certify that the software is the right package for a
certain organization. That responsibility remains with the organization and its
team of analysts.
The following six characteristics can define the quality of the software:
1. Functionality
Quality of software is defined as how effectively the software interacts with other
components of the system. The software must provide appropriate functions as
per requirement, and these functions must be implemented correctly.
2. Reliability
It is defined as the capability of the software to perform under specific conditions

for a specified duration.
3. Usability
Usability of software is defined as its ease of use. Quality of the software is also
identified as how easily a user can understand the functions of the software and
how much efforts are required to follow the features.
4. Efficiency
The efficiency of the software is dependent on the architecture and coding

practice followed during development.
5. Maintainability
Maintainability is also one of the significant factors to define the quality of the
software. It refers to identify the fault and fix in the software. It should be stable
when the changes are made.
arjun00.com.np 108
.
.
6. Portability
Portability of the software, defined as how easily a system adapts to changes in

the specifications. Quality of the software is also determined by the portability of
the system how easy it is to install the software and how easy it is to replace a
component of the order in a given environment.
What is Quality Control?
Quality Control popularly abbreviated as QC is a software engineering process

used to ensure quality in a product. It does not deal with the processed used to
create a product. Instead, it examines the quality of the end product and the
outcome.
Inspection:
Inspection is the process of measuring, examining, and testing to gauge one or

more characteristics of a product or service and the comparison of these with
specified requirements to determine conformity. Products, processes, and various
other results can be inspected to make sure that the object coming off a
production line, or the service being provided, is correct and meets specifications.
Inspection is performed by a team which is called QA inspection team.
arjun00.com.np 109
.
.
Introduction to Software Engineering

Introduction:
The term software engineering is the product of two words, software, and
engineering.
The software is a collection of integrated programs.
Software subsists of carefully-organized instructions and code written by

developers on any of various particular computer languages.
Computer programs and related documentation such as requirements, design

models and user manuals.
Engineering is the application of scientific and practical knowledge to invent,

design, build, maintain, and improve frameworks, processes, etc.
arjun00.com.np 110
.
.
Software Engineering is an engineering branch related to the evolution of

software product using well-defined scientific principles, techniques, and
procedures. The result of software engineering is an effective and reliable
software product.
Why is Software Engineering required?
Software Engineering is required due to the following reasons:
• To manage Large software

• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management
Need of Software Engineering
The necessity of software engineering appears because of a higher rate of

progress in user requirements and the environment on which the program is
working.
• Huge Programming: It is simpler to manufacture a wall than to a house or

building, similarly, as the measure of programming become extensive
engineering has to step to give it a scientific process.
• Adaptability: If the software procedure were not based on scientific and
engineering ideas, it would be simpler to re-create new software than to
scale an existing one.
• Cost: As the hardware industry has demonstrated its skills and huge
manufacturing has let down the cost of computer and electronic hardware.
But the cost of programming remains high if the proper process is not
adapted.
• Dynamic Nature: The continually growing and adapting nature of
programming hugely depends upon the environment in which the client
works. If the quality of the software is continually changing, new upgrades
need to be done in the existing one.
• Quality Management: Better procedure of software development provides
a better and quality software product.
arjun00.com.np 111
.
.
Characteristics of a good software engineer
The features that good software engineers should possess are as follows:
→Exposure to systematic methods, i.e., familiarity with software engineering

principles.
→Good technical knowledge of the project range (Domain knowledge).
→Good programming abilities.
→Good communication skills. These skills comprise of oral, written, and

interpersonal skills.
→High motivation.
→Sound knowledge of fundamentals of computer science.
→Intelligence.
→Ability to work in a team
→Discipline, etc.
The importance of Software engineering is as follows:
1. Reduces complexity: Big software is always complicated and challenging to

progress. Software engineering has a great solution to reduce the
complication of any project. Software engineering divides big problems into
various small issues. And then start solving each small issue one by one. All
these small problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hard work and software
engineers are highly paid experts. A lot of manpower is required to develop
software with a large number of codes. But in software engineering,
programmers project everything and decrease all those things that are not
.
arjun00.com.np 112
.
.
needed. In turn, the cost for software productions becomes less as

compared to any software that does not use software engineering method.
3. To decrease time: Anything that is not made according to the project
always wastes time. And if you are making great software, then you may
need to run many codes to get the definitive running code. This is a very
time-consuming procedure, and if it is not well handled, then this can take
a lot of time. So if you are making your software according to the software
engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and
they need lots of patience, planning, and management. And to invest six
and seven months of any company, it requires heaps of planning, direction,
testing, and maintenance. No one can say that he has given four months of
a company to the task, and the project is still in its first stage. Because the
company has provided many resources to the plan and it should be
completed. So to handle a big project without any problem, the company
has to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered

the software, then it should work for at least its given time or subscription.
And if any bugs come in the software, the company is responsible for
solving all these bugs. Because in software engineering, testing and
maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the

standards. Software standards are the big target of companies to make it
more effective. So Software becomes more effective in the act with the
help of software engineering.
arjun00.com.np 113
.
.
Software Development Process:
The Waterfall Model was the 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.
The 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. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the 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 this
Waterfall model, typically, the outcome of one phase acts as the input for the
next phase sequentially.
The following illustration is a representation of the different phases of the

Waterfall Model.
arjun00.com.np 114
.
.
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 document.
• System Design − The requirement specifications from first phase are
studied in this phase and the system design is prepared. This system design
helps in specifying hardware and system requirements and helps in defining
the overall system architecture.
• Implementation − With inputs from the 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.
arjun00.com.np 115
.
.
Advantages:
1. Simple and easy to understand and use
2. Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
3. Phases are processed and completed one at a time.
4. Works well for smaller projects where requirements are very well understood.
5. Clearly defined stages.
6. Well understood milestones.
Disadvantages:
1. No working software is produced until late during the life cycle.
2. High amounts of risk and uncertainty.
3. Not a good model for complex and object-oriented projects.
4. Poor model for long and ongoing projects.
5. Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
Evolutionary model:
The evolutionary model is the model of software engineering. In the evolutionary

model, all the work is done during the development phase. In this model, all
work divided into small chunks or modules. For example, the Waterfall model in
which all the users are able to get access to the product at the end of each cycle.
This model is a combination of incremental and iterative models.
It is a very suitable model because of user feedback and other factors that make
the model very suitable for the development of complete Software. The user
.
arjun00.com.np 116
.
.
feedback is very helpful for the development of the next stage because after the
completion of one stage we get the feedback to the user, the user feedback is
very essential for the development of the next phase.
If you want any changes in the software requirements, all changes will be applied
within a time.
In the evolutionary model, all work divided into smaller chunks. These chunks
present to the customer one by one. The confidence of the customer increased.
This model also allows for changing requirements as well as all development done
into different pieces and maintains all the work as a chunk.
The following are the evolutionary models.
1. The prototyping model

2. The spiral model
3. The agile model
.
arjun00.com.np 117
.
.
Advantages:
1. The big advantage of the evolutionary model is that the user has checked
every stage during the development and it is helpful in achieving customer
confidence.
2. There are fewer chances of errors because all the modules are well seen.
3. It helps to reduce the risk of software projects.
4. It also reduces the cost of development.
5. Minimize serious problems during testing.
Disadvantages:
1. The delivery of full software can be late due to different changes by

customers during development.
2. It is difficult to divide the problem into several parts, that would be
acceptable to the customer which can be incrementally implemented and
delivered.
Spiral Model:
Spiral model is one of the most important Software Development Life Cycle
models, which provides support for Risk Handling. In its diagrammatic
representation, it looks like a spiral with many loops. The exact number of loops
of the spiral is unknown and can vary from project to project. Each loop of the
spiral is called a Phase of the software development process. The exact number
of phases needed to develop the product can be varied by the project manager
depending upon the project risks. As the project manager dynamically determines
the number of phases, so the project manager has an important role to develop a
product using spiral model.
he Radius of the spiral at any point represents the expenses(cost) of the project
so far, and the angular dimension represents the progress made so far in the
current phase.
.
arjun00.com.np 118
.
.
Below diagram shows the different phases of the Spiral Model:
Each phase of Spiral Model is divided into four quadrants as shown in the above
figure. The functions of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements

are gathered from the customers and the objectives are identified,
elaborated and analyzed at the start of every phase. Then alternative
solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible
solutions are evaluated to select the best possible solution. Then the risks
associated with that solution is identified and the risks are resolved using
the best possible strategy. At the end of this quadrant, Prototype is built for
the best possible solution.
3. Develop next version of the Product: During the third quadrant, the
identified features are developed and verified through testing. At the end
of the third quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning
for the next phase is started.
arjun00.com.np 119
.
.
A risk is any adverse situation that might affect the successful completion of a
software project. The most important feature of the spiral model is handling
these unknown risks after the project has started.
Advantages of Spiral Model: Below are some of the advantages of the Spiral
Model.
• Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.
• Flexibility in Requirements: Change requests in the Requirements at later
phase can be incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the product
at the early phase of the software development and thus, they habituated
with the system by using it before completion of the total product.
Disadvantages of Spiral Model: Below are some of the main disadvantages of the
spiral model.
• Complex: The Spiral Model is much more complex than other SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it is expensive.
• Too much dependable on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly
experienced expertise, it is going to be a failure to develop a project using
this model.
• Difficulty in time management: As the number of phases is unknown at the
start of the project, so time estimation is very difficult.
arjun00.com.np 120

'Introduction To System Analysis and Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

'Introduction To System Analysis and Design

Uploaded by

Copyright:

Available Formats

Website :- https://www.arjun00.com.

`Introduction to System Analysis and Design

There are three major components in every system, namely input,

Input: It involves capturing and assembling elements that enter the

Processing: It involves transformation processes that convert input to

Output: It involves transferring elements that have been produced by a

Feedback: It is data about the performance of a system. It is the idea of

Control: It involves monitoring and evaluating feedback to determine

The system has nine characteristics:

A system is made up of components. A component is either an

whereas systems outside the boundary cannot be changed. All of

Analysis is the process of breaking a complex logic into smaller

Objectives of system analysis and design:

2) To describe various data gathering and analysis tools.

3) To Evaluate tools and techniques for solving business system problems.

4) To Use appropriate methods and techniques to design software.

5) To ensure entire system will perform as per the specifications.

6) To ensure system meets client’s requirement.

7) To study the feasibility of the system.

SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

1. Problem Identification (Recognition of Need)

They are called the environment change elements outside the

b. Top management, user, and analyst, etc.

They are called the change elements within the organization.

It consist the following:

a. Problem Statement: Means the statements which describe that

b. Findings and Recommendations (Suggestions) with Justification:

d. Conclusion: Finally in the conclusion part the result of feasibility

goal of highlighting useful information, suggesting conclusions, and

Implementation is less creative phase in comparison to the

1. To check the degree of success of the project, in particular,

1. Project is Cancelled After Review Process:

These types of cases can also be the one reason for

2. New System is not Fulfilling the requirement of user:

(i) Very hard time boundations for the project team. It

1. Identification of the system for development

1. Gathering business requirement

• Development of database and code

• Verification and Validation of system requirements.

• Final system is delivered to the client.

In the maintenance phase, any necessary enhancements, corrections, and changes

1. Support the system users

Development, Management & Supporting Processes

Emergent system Properties

Types of emergent properties:

minimal defined level in these properties may make the

Issues such as requirements engineering, reliability, coordination

The purpose of an information system is to turn raw data into

Type of Information System

Transaction processing system (TPS) is a special class of information

This provides high speed and accurate processing of record keeping of

retrieval. Transaction processing systems provide speed and accuracy,

Management information system (MIS)

Management information system (MIS) is used by managerial

MIS helps in studying the decisions taken, the factors leading to a

obtained as the result of transaction processing, however MIS may also

Example: Annual Budgeting, Payroll System, Sales Order System and

• Highly sensitive, requires constant monitoring.

• Lack of flexibility to update itself.

Decision Support System (DSS):

DSS is a special purpose information system designed to support

DSS is an organized collection of people, procedures, databases, and

DSS is tool that aids in the process of decision-making but it cannot