Chapter 3
System Analysis
3.1 Study of the system
To provide flexibility to the users, the interfaces have been developed that are
accessible through a browser. The GUI’S at the top level have been categorized as
1. Administrative user interface
2. The operational or generic user interface
The ‘administrative user interface’ concentrates on the consistent information that is
practically, part of the organizational activities and which needs proper authentication
for the data collection. These interfaces help the administrators with all the
transactional states like Data insertion, Data deletion and Date updation along with
the extensive data search capabilities.
The ‘operational or generic user interface’ helps the end users of the system in
transactions through the existing data and required services. The operational user
interface also helps the ordinary users in managing their own information in a
customized manner as per the included flexibilities
2.2 INPUT & OUTPOUT REPRESENTETION
Input design is a part of overall system design. The main objective during the input
design is as given below:
To produce a cost-effective method of input.
To achieve the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.
INPUT STAGES:
The main input stages can be listed as below:
Data recording
Data transcription
Data conversion
6
Data verification
Data control
Data transmission
Data validation
Data correction
INPUT TYPES:
It is necessary to determine the various types of inputs. Inputs can be categorized as
follows:
External inputs, which are prime inputs for the system.
Internal inputs, which are user communications with the system.
Operational, which are computer department’s communications to the
system?
Interactive, which are inputs entered during a dialogue.
INPUT MEDIA:
At this stage choice has to be made about the input media. To conclude
about the input media consideration has to be given to;
Type of input
Flexibility of format
Speed
Accuracy
Verification methods
Rejection rates
Ease of correction
Storage and handling requirements
Security
Easy to use
Portability
Keeping in view the above description of the input types and input media, it can be
said that most of the inputs are of the form of internal and interactive. As
Input data is to be the directly keyed in by the user, the keyboard can be considered
to be the most suitable input device.
7
OUTPUT DESIGN:
In general are:
External Outputs whose destination is outside the organization.
Internal Outputs whose destination is with in organization and they are the
User’s main interface with the computer. Outputs from computer systems are
required primarily to communicate the results of processing to users. They
are also used to provide a permanent copy of the results for later
consultation. The various types of outputs
Operational outputs whose use is purely with in the computer department.
Interface outputs, which involve the user in communicating directly with the
system.
OUTPUT DEFINITION
The outputs should be defined in terms of the following points:
Type of the output
Content of the output
Format of the output
Location of the output
Frequency of the output
Volume of the output
Sequence of the output
It is not always desirable to print or display data as it is held on a computer. It should
be decided as which form of the output is the most suitable.
8
For Example
Will decimal points need to be inserted
Should leading zeros be suppressed.
OUTPUT MEDIA:
In the next stage it is to be decided that which medium is the most appropriate for the
output. The main considerations when deciding about the output media are:
The suitability for the device to the particular application.
The need for a hard copy.
The response time required.
The location of the users
The software and hardware available.
Keeping in view the above description the project is to have outputs mainly
coming under the category of internal outputs. The main outputs desired according to
the requirement specification are:
The outputs were needed to be generated as a hard copy and as well as queries to
be viewed on the screen. Keeping in view these outputs, the format for the output is
taken from the outputs, which are currently being obtained after manual processing.
The standard printer is to be used as output media for hard copies.
2.3 PROCESS MODEL USED WITH JUSTIFICATION
SDLC (Spiral Model):
9
SDLC is nothing but Software Development Life Cycle. It is a standard which is used
by software industry to develop good software.
Stages in SDLC:
Requirement Gathering
Analysis
Designing
Coding
Testing
10
Maintenance
Requirements Gathering stage:
The requirements gathering process takes as its input the goals identified in the
high-level requirements section of the project plan. Each goal will be refined into a
set of one or more requirements. These requirements define the major functions of
the intended application, define
operational data areas and reference data areas, and define the initial data entities.
Major functions include critical processes to be managed, as well as mission critical
inputs, outputs and reports. A user class hierarchy is developed and associated with
these major functions, data areas, and data entities. Each of these definitions is
termed a Requirement. Requirements are identified by unique requirement identifiers
and, at minimum, contain a requirement title and
textual description.
These requirements are fully described in the primary deliverables for this
stage: the Requirements Document and the Requirements Traceability Matrix (RTM).
The requirements document contains complete descriptions of each requirement,
including diagrams and references to external documents as necessary. Note that
detailed listings of database tables and fields are not included in the requirements
document.
11
The title of each requirement is also placed into the first version of the RTM,
along with the title of each goal from the project plan. The purpose of the RTM is to
show that the product components developed during each stage of the software
development lifecycle are formally connected to the components developed in prior
stages.
In the requirements stage, the RTM consists of a list of high-level requirements,
or goals, by title, with a listing of associated requirements for each goal, listed by
requirement title. In this hierarchical listing, the RTM shows that each requirement
developed during this stage is formally linked to a specific product goal. In this
format, each requirement can be traced to a specific product goal, hence the term
requirements traceability.
The outputs of the requirements definition stage include the requirements
document, the RTM, and an updated project plan.
Feasibility study is all about identification of problems in a project.
No. of staff required to handle a project is represented as Team Formation, in this
case only modules are individual tasks will be assigned to employees who are
working for that project.
Project Specifications are all about representing of various possible inputs
submitting to the server and corresponding outputs along with reports maintained
by administrator
Analysis Stage:
The planning stage establishes a bird's eye view of the intended software
product, and uses this to establish the basic project structure, evaluate feasibility and
risks associated with the project, and describe appropriate management and
technical approaches.
12
The most critical section of the project plan is a listing of high-level product
requirements, also referred to as goals. All of the software product requirements to
be developed during the requirements definition stage flow from one or more of these
goals. The minimum information for each goal consists of a title and textual
description, although additional information and references to external documents
may be included. The outputs of the project planning stage are the configuration
management plan, the quality assurance plan, and the project plan and schedule,
with a detailed listing of scheduled activities for the upcoming Requirements stage,
and high level estimates of effort for the out stages.
Designing Stage:
The design stage takes as its initial input the requirements identified in the
approved requirements document. For each requirement, a set of one or more
design elements will be produced as a result of interviews, workshops, and/or
prototype efforts. Design elements describe the desired software features in detail,
and generally include functional hierarchy diagrams, screen layout diagrams, tables
of business rules, business process diagrams, pseudo code, and a complete entity-
relationship diagram with a full data dictionary. These design elements are intended
13
to describe the software in sufficient detail that skilled programmers may develop the
software with minimal additional input.
When the design document is finalized and accepted, the RTM is updated to show
that each design element is formally associated with a specific requirement. The
outputs of the design stage are the design document, an updated RTM, and an
updated project plan.
Development (Coding) Stage:
The development stage takes as its primary input the design elements
described in the approved design document. For each design element, a set of one
or more software artifacts will be produced. Software artifacts include but are not
limited to menus, dialogs, data management forms, data reporting formats, and
specialized procedures and functions. Appropriate test cases will be developed for
each set of functionally related software artifacts, and an online help system will be
developed to guide users in their interactions with the software.
14
The RTM will be updated to show that each developed artifact is linked to a
specific design element, and that each developed artifact has one or more
corresponding test case items. At this point, the RTM is in its final configuration. The
outputs of the development stage include a fully functional set of software that
satisfies the requirements and design elements previously documented, an online
help system that describes the operation of the software, an implementation map that
identifies the primary code entry points for all major system functions, a test plan that
describes the test cases to be used to validate the correctness and completeness of
the software, an updated RTM, and an updated project plan.
Integration & Test Stage:
During the integration and test stage, the software artifacts, online help, and
test data are migrated from the development environment to a separate test
environment. At this point, all test cases are run to verify the correctness and
completeness of the software. Successful execution of the test suite confirms a
robust and complete migration capability. During this stage, reference data is
finalized for production use and production users are identified and linked to their
appropriate roles. The final reference data (or links to reference data source files)
and production user list are compiled into the Production Initiation Plan.
15
The outputs of the integration and test stage include an integrated set of
software, an online help system, an implementation map, a production initiation plan
that describes reference data and production users, an acceptance plan which
contains the final suite of test cases, and an updated project plan.
Installation & Acceptance Test:
During the installation and acceptance stage, the software artifacts, online help,
and initial production data are loaded onto the production server. At this point, all test
cases are run to verify the correctness and completeness of the software. Successful
execution of the test suite is a prerequisite to acceptance of the software by the
customer.
After customer personnel have verified that the initial production data load is
correct and the test suite has been executed with satisfactory results, the customer
formally accepts the delivery of the software.
16
The primary outputs of the installation and acceptance stage include a
production application, a completed acceptance test suite, and a memorandum of
customer acceptance of the software. Finally, the PDR enters the last of the actual
labor data into the project schedule and locks the project as a permanent project
record. At this point the PDR "locks" the project by archiving all software items, the
implementation map, the source code, and the documentation for future reference.
Maintenance:
Outer rectangle represents maintenance of a project, Maintenance team will
start with requirement study, understanding of documentation later employees will be
assigned work and they will under go training on that particular assigned category.
For this life cycle there is no end, it will be continued so on like an umbrella (no
ending point to umbrella sticks).
17
2.4 SYSTEM ARCHITECTURE
Architecture flow:
Below architecture diagram represents mainly flow of requests from users to
database through servers. In this scenario overall system is designed in three tires
separately using three layers called presentation layer, business logic layer and data
link layer. This project was developed using 3-tire architecture.
Presentation Layer
Request Response
Business Logic
Layer
Data Link
Layer
Data Base
18