PROJECT REPORT

ON

STUDENT INFORMATION
MANAGEMENT SYSTEM

GUIDED BY:
Mr Anil Kumar

PREPARED BY:

Naincy Chittransh 15HCS4354 CS BSc (hons.) (2nd Year)

Jassa Singh 15HCS4353 CS BSc (hons.) (2nd Year)
Deepika Kabra 15HCS4352 CS BSc (hons.) (2nd Year)

Department of Computer Science

Deen Dayal Upadhyaya College
University of Delhi
Sector-3, Dwarka, New Delhi - 110078.
Website: http://dducollegedu.ac.in/
 Acknowledgement

There are many people who have helped us directly or indirectly in the successful
completion of our project. We would like to take this opportunity to thank one and all.

We are very thankful to our project guide Mr Anil Kumar who has been inspiring guide
and committed caretaker for his unflinching devotion. The encouragement and support by
him, especially in carrying out this project motivated me to complete this project.

 We would like to thank all our friends for their help and constructive criticism during our
project period. Finally, we are very much indebted to our parents for their moral support
and encouragement to achieve goals.

Naincy Chittransh
Deepika Kabra
Jassa Singh
 Certificate

This is to certify that the major project entitled “Student Information Management
System” has been successfully completed by Naincy Chittransh, Deepika Kabra and Jassa
Singh in partial fulfilment of the requirements for the Bachelor in Computer Science
honours, University of Delhi. This work was carried out by them under our supervision
and guidance during the academic year 2016-2017.

To the best of my knowledge, the matter embodied in the project has not been submitted
to any other University/Institute for the award of any Degree or Diploma.

Mr Anil Kumar                            

(Assistant Professor)
Depatment of Computer Science,
Deen Dayal Upadhyaya College,
University Of Delhi.
 Index

1. Introduction
1.1. Problem statement
1.2. Process model
2. Requirement Analysis
2.1. Software Requirement Specification
2.2. Data Flow Creation/Diagram
2.3. Data Dictionary
3. Project Management
3.1. Computing Function Point
3.2. Effort
3.3. Schedule, Risk analysis and management, Timeline chart
4. Design Engineering
4.1. Design Concept and Principles
4.2. Data Design
4.3. Architectural Design
4.4. Interface Design
5. Testing
5.1. Software Testing
5.2. Cyclomatic Complexity
 Chapter 1
Introduction

1.1 Problem statement

Need and Justification

In most of the colleges, basic working related to student records is manual, a lot of
paperwork which definitely saves money but to an extent that there is a compromise with
time. Time saved, may otherwise be invested for other important tasks
Attendance is taken manually, and teachers have to keep records in registers, and even
the internal marks evaluation is done manually, and calculating average marks can be a
tiring task at times and whether a student submitted an assignment or not and the marks
in that particular assignment. Maintaining practical list is another hard task for both
students and teachers.
Student issues a book from the library and forgets to return it even when he is not using it
and on top of that, has to pay penalty for late submission of book issued and a person in
need could not use it even and for that a notification on his/her dashboard will be of help.
For any small issues and for acquiring any information, whether related to fee or
attendance, students have to wait as there are other important works going on in
administration office or faculty room or any other place where they could get the
information.

It will make things easier for faculty members, college management department, and
most importantly students, if they could know their personal information and status
anytime they want, through an online portal with a simple interface specifically designed
for them. Teachers no longer would have to keep track of all the student information, just
update all the information through a simple desktop application or let the admin do that.

Our software product will use two independent applications, a LAN based application
through which inputs from various area will be taken and an Online Portal through which
student will be able to retrieve all the information or rather restricted information. This
application can be used by any institution to keep its students updated and the only thing
they need to do is to connect the application with an appropriate database.
Core purpose of designing “Student information Management System” will be to manage
the task related to the college students and to reduce time to search appropriate
information about the students.
GENERAL DESCRIPTION

User Characteristics

The target audience for S.I.M.S product is the college students/staff. The users of this
system are:

 Administrator – The Super user of the system.

 Student – A user with limited access rights.
 Staff – A user of the system who has more access rights than a student.

Product Perspective

The product will be two standalone applications, a LAN based application for most of the
inputs and a web application for students specifically. The minimum hardware
requirements for the product are specified in this document.

Overview of Functional Requirements

 The administrator governs the working of the system.

 The staff can view/change the student’s details.
 A mechanism to uniquely identify each student.
 Basic changes by students and faculty members in personal info.
 The students can view their marks/attendance/fees status/library status/assignment
status.
 The system should have a login.

1.2 Process model

A process model for software engineering is chosen based on the nature of the project
and application, the methods and tools to be used, and the controls and deliverables that
are required. All software development can be characterized as a problem solving loop in
which four distinct stages are encountered: status quo, problem definition, technical
development, and solution integration. Status quo represents the “the current state of
affairs”; problem definition identifies “the specific problem to be solved”; technical
development solves “the problem through the application of some technology”; and
solution integration delivers “the results”.

The software project that we aim to create requires a process model that keeps on
developing itself with the advent in technology and never comes to the point where
there is no more advancement. This product will not need many changes once it is
implemented but during the course some changes may be required in the product
related to the structure of the database and so there will be a need to change some
basic interfacing of the application. We need the project to be in sync with the
technology of the new era and so we need a process model in which we can do
modifications whenever we want to do. So, because of this reason we have chosen
the spiral model which will according to us, be the most suitable one for S.I.M.S.
Moreover, Spiral Model works for the entire lifetime of the software.

The Spiral Model, originally proposed by Boehm, is an evolutionary software process

model that couples the iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model. It provides the potential for rapid development of
incremental versions of software. Using spiral model, software is developed in a series of
incremental releases. During early iterations, the incremental release is in the form of
paper model or prototyping. During later iterations, increasingly more complete versions
of the system are produced.
Spiral model is divided into number of framework activities, also known as task regions,
as given below:
 Customer Communication: Tasks required to establish effective communication
between developer and customer.
 Planning: Tasks required to define resources, timelines and other project-related
information.
 Risk Analysis: Tasks required to access both technical and management risks.
 Engineering: Tasks required to build one or more representations of the
application.
 Construction and Release: Tasks required to construct, test, install, and provide
user support.
 Customer Evaluation: Tasks required to obtain customer’s feedback and
implement the requirement in the next stage.
The spiral model is a realistic approach to the development of large-scale systems and
software. Because software involves as the process progresses, the developer and
customer better understand and react to risks at each evolutionary level. The spiral model
uses prototyping as a risk mechanism and also enables the developer to apply the
prototyping approach at any stage in the evolution of the product. The spiral model
surely demands a direct consideration of technical risks at all stages of the project and, if
properly applied, it reduces risk before they become problematic.
Even though Spiral Model is one of the realistic models used in software engineering
projects, but it may be difficult to convince customers that the evolutionary approach is
controllable. It demands considerable risk management. If risks are not uncovered and
managed, problems will undoubtedly occur. Therefore, it is important for proper risk
management while using the spiral model. In content with our project, the main risk is
involved with the command given that can be of any form or type i.e. the resultant
command may affect any of the system files or may change content of some operating
system files, resulting to hardware/software crash.
 Chapter 2
Requirement
Analysis

2.1 Software requirements specification

INTRODUCTION

Purpose
The purpose of this SRS document is to illustrate the requirements of the project and is
intended to help any institution to maintain and manage its student database. It will
contain detailed functional, non-functional and detailed requirements and establishes a
baseline for development of system. The SRS serves as the official means of
communicating user requirements to the developer and provides a common reference
point for both the developer team and the stakeholders. The SRS will evolve over time as
users and developers work together to validate, clarify and expand its contents.

Different intended audience will have different requirements from this SRS.

1. The customers will use this SRS to verify that the developer team has created a
product that is acceptable to the customer.

2. The project manager of developer team will use this SRS to plan milestones and a
delivery date and ensure that the team is on the track during development of the system.

3. The designers will use it as a basis of creating the system’s design. The designers will
continually refer back to this SRS to ensure that the system they are designing will fulfil
the customer’s needs.

4. The developers will use this SRS as a basis of developing the system’s functionality.
They will link the requirements defined in the SRS to the software they create to ensure
that the software they have created will fulfil customer’s demands.

5. The testers will use the SRS to derive test plans and test cases for each requirement.

System Overview
The project aims at:

1. Having a centralized control over the records of the students.

2. Providing an online student portal where students will be provided with all the
necessary details like:
 Attendance.
 Internal marks assessment.
  Class schedule.
 Library books with issue and return date.
 Fee details.

3. A LAN based interface for other intended employees where they can upload
attendance and internals marks of students (saving a lot of effort and paper work), fees
details, library details.

OVERALL DESCRIPTION

Product Perspective

User interfaces

Admin, who has all type of permission to update data and can change schema of
database. He will also grant permission to other user i.e. Teachers, students etc. He will
keep a track of student fee, practical list, book issue and all other information related to
student. He can also change and maintain the basic information about Staff members.

Teachers will update the assignments, projects and test information, further they will also
update will student marks (if not submitted automatically 0), they will provide these
information will student attendance to The Admin on daily or weekly basis. Library head
will add the book issued to student and the date when student will return it. He would
have a panel with name of all the departments, on clicking a drop down menu naming the
year will come and on selecting any of them the admin could see the students’ status and
could update that. Fee admin will update fee information of all students; he can see the
status of student fee and can update them.

Student who can only see their marks, attendance, fee status, book issued and any other
notice or information in their respective student panel by login from their student ID.
SPECIFIC REQUIREMENTS

Functional Requirements

a. Login: this function will take username and password as input (student id in case
of students) and output will be the corresponding user panel i.e. different panels for
different users. During processing, it will validate the user by matching the details from
the database to avoid unauthorized access.
b. Request Credentials: takes student id, roll number and security answer as input
and provides you with your credentials.
c. Change password: takes username or student id, old password, new password as
input and after verifying updates the password.
d. Logout: Simple let you out of your panel and will direct you to the home page.
e. Add attribute: will take attribute name as input and add it to the corresponding
table. During processing, it will add a new column to the corresponding database table.
f. Add student: will take student name as input and add a corresponding row to the
table. During processing, it will add a new row to the corresponding database table.
g. Edit: lets you edit the corresponding table and make changes in the database as
well.
h. Add class: it will let you select a class name i.e. department name and a particular
semester within that and will add a corresponding block to your interface.
i. Add subject: will let you add a new subject under a particular class and will add
a fresh table corresponding to that class in your interface.
j. Edit details: takes email id, contact number, security answer as input and after
verifying updates it.

Software System Attributes

a. Security: admin, faculty members, other relevant users will be able to log in to
the student information management System using their login id and a password. Student
may also login through the online interface provided to them using a student id and
password. So any intruder will not be able to access the system in normal situations.
b. Availability: The system shall be available all the time. Student may login
anytime and get the relevant information.
c. Maintainability: How easy is to keep the system as it is and correct defects with
making changes.
d. Portability: Student Information Management System shall run in any Microsoft
Windows environment
e. Reliability: Specify the factors required to establish the required reliability of the
software system at time of delivery. Mean time between failures and mean time to
recovery
f. Reusability: S.I.M.S will be reusable after making few changes.
g. Usability: S.I.M.S is very easy to use i.e. it has a user friendly interface

Design and implementation constraints

Software development crew provides their best effort in developing the system. In order
to maintain the reliability and durability of system, some design and implementation
constraints are applied. Availability of an android app for taking attendance, and marking
assignment marks could make the system much simple and easy, but due to time
constraint it is not possible. System will need a minimum memory of 512MB. But it is
recommended to have a memory of 1GB. Considering the client’s budget we decided to
create those interfaces in a simple realistic manner using affordable technology.

2.2 Data Flow Creation/Diagram

A Data Flow Diagram is a graphical representation of the “flow” of data through
information system, modeling its process aspects. A DFD is often used as a preliminary
step to create an overview of the system without going into great details. Data Flow
Diagram can also be used for the visualization of data processing (structured diagram).
The whole architectural structure stems from the original flow design. Below are the
Level0, Level 1, and Level 2 Data Flow Diagrams (DFD). The diagrams below more
accurately portray the data flow through our system.

Level 0:
A context diagram is a top level (also known as "Level 0") data flow diagram. It only
contains one process node ("Process 0") that generalizes the function of the entire system
in relationship to external entities.

Level 1:
The context-level DFD is then “exploded”, to produce a Level 1 DFD. The Level 1
DFD shows how the system is divided into sub-systems (processes), each of which deals
with one or more of the data flows to or from an external agent, and which together
provide all of the functionality of the system as a whole.
Level 2:
Level 1 DFD is further divided into subsystems, each of which deals with one or more of
the data flows to or from an external agent, and which together provide all of the
functionality of the system as a whole. It also identifies internal data stores that must be
present in order for the system to do its job, and shows the flow of data between the
various parts of the system.
2.3 DATA DICTIONARY
Data dictionary is the centralized collection of information about data. It stores meaning
and origin of data, its relationship with other data, data format for usage etc. Data
dictionary has rigorous definitions of all names in order to facilitate user and software
designers.

Data dictionary is often referenced as meta-data (data about data) repository. It is created
along with DFD (Data Flow Diagram) model of software program and is expected to be
updated whenever DFD is changed or updated.

The data is referenced via data dictionary while designing and implementing software.
Data dictionary removes any chances of ambiguity. It helps keeping work of
programmers and designers synchronized while using same object reference everywhere
in the program.

S. Field Type Purpose

No.
1. Name varchar(25) Student’s name
2. roll_number varchar(30) Student’s college Roll number
3. student_id int(10) ID provided for login
4. Password varchar(25) Login password
5. security_answer varchar(50) An answer for security
6. book_name varchar(50) Book issued from library
7. issued_on date Date on which book issued
8. return_on date Date on which book returned
9. Sub_name int(10) Subject name
10. Assign_marks int(10) Assignment marks
11. Personal info file Personal information of users
12. Course varchar(30) Course to which student belongs
13. Admin user Administrator of the system
14. Remarks varchar(100) Remarks, on basis of grades
15. Feedback varchar(30) Feedback given by a student to teacher
16. Average varchar(15) Average assessment marks
17. Member_name varchar(25) Staff member name
18. member_id int(10) Staff member id
19. Date of joining varchar(30) Date of joining of the staff member
20. Department varchar(30) Department to which staff member belongs
21. Post varchar(25) Post of the staff member.
22. Fee details varchar(100) Fee details of the student
23. Library details varchar(30) Library Details of the student
24. Grade varchar(15) Grade, on basis of internal marks
25. Specialization varchar(30) Specialization of the staff member
26. Years of experience varchar(15) For staff member
27. Teaching status varchar(10) Adhoc or permanent
28. Fee Notification varchar(100) Notification, if fee not submitted
29. Credentials file Credentials of the student
30. Library details file Library details of the student
31. Assignment marks int(10) Assignment/project marks of student
32. Evaluation details file File containing marks details of student
33. Login verification process Checks whether valid user or not.
 Chapter 3
Project
management

INTRODUCTION
Project management involves planning, monitoring and control of people, processes and
events that occur, as software evolves from a preliminary concept to an operational
implementation. Effective software project management focuses on the 4 P’s: People,
Product, Process, and Project.

THE PEOPLE Software engineering institute has developed a people management

capability maturity model (PM-CMM). The people management maturity model defines
the key practice areas [KPA’s] for software people like recruiting, selection, performance
management, training, compensation, carrier development, organization and work design
and team / culture development.

THE PRODUCT Before a project is planned, product objectives and scope should be
established, alternative solutions should be considered and technical and management
constraints should be identified. Objectives identify the overall goal of the product from
customer’s point. Scope identifies the primary data, functions and behaviours that
characterize the product. Alternatives enable managers to select the best approach given
constraints imposed by technical interfaces, personnel availability, delivery deadlines and
budgetary restrictions.

Thus the product factor helps to define the accurate cost estimation, effective risk
assessment and a manageable project schedule.

THE PROCESS A software process provides the framework from which a

comprehensive plan for software development can be established. Framework activities
are populated with tasks, milestones, work products and quality assurance points. These
activities characterize the software product and the project team. Umbrella activities i.e.
software quality assurance, software configuration management and measurement
overlay the process model.

THE PROJECT Planned and controlled software projects are conducted to manage
complex. To avoid project failure, the project manager must avoid a set of common
warning signs, understand critical success factors and develop a common sense approach
for planning, monitoring and controlling the project.
3.1 Computing Function Point

Information Weighting factor

Domain Value Count Simple
Average Complex

External Inputs (EIs) 7 3 4 6

External Outputs (EOs) 2 4 5 7
External Inquiries (EQs) 5 3 4 6
Internal Logical Files (ILFs) 1 7 10 15
External Interface Files (EIFs) 3 5 7 10

Count total (Unadjusted Function Count) = 28+8+20+10+21 = 87

The Fi (i _ 1 to 14) are value adjustment factors (VAF) based on responses to the
following questions:

1. Does the system require reliable backup and recovery?

Ans. 5
2. Are specialized data communications required to transfer information to or from the
application?
Ans. 5
3. Are there distributed processing functions?
Ans. 4
4. Is performance critical?
Ans. 4
5. Will the system run in an existing, heavily utilized operational environment?
Ans. 4
6. Does the system require online data entry?
Ans. 5
7. Does the online data entry require the input transaction to be built over multiple
screens or operations?
Ans. 2
8. Are the ILFs updated online?
Ans. 5
9. Are the inputs, outputs, files, or inquiries complex?
Ans. 1
10. Is the internal processing complex?
Ans. 1
11. Is the code designed to be reusable?
Ans. 4
12. Are conversion and installation included in the design?
Ans. 1
13. Is the system designed for multiple installations in different organizations?
Ans. 5
14. Is the application designed to facilitate change and ease of use by the user?
Ans. 5

Σ fi= 51
TCF (Technical Complexity Factor) = 0.65 + 0.01* (Σ fi) = 0.65 + 0.01*51 = 0.65 +
0.51 = 1.16
FP = UFC * TCF = 87*1.16 = 100.92

3.2 EFFORT
As the name suggests, ‘effort’ is the number of work units that is vital to complete an
activity. If you want to determine any of the other two, you will need to determine the
effort in a project first.

In simpler terms, it is the number of hours we put in, focused on a particular task, to get a
certain job done.
Stakeholders often want to know how much a project will cost. This chiefly depends on
the measure of time members of the project spend on the project.

Effort is most often expressed in Staff - hours, days or weeks.

This project required an overall effort of: 1.5(hours each day)*60(days) =90 hours for
each team member, which is total of 270 hours for three team members.

3.3 RISK ANALYSIS & MANAGEMENT

Risk always involves two characteristics: Uncertainty, Loss

Risk analysis and management is a series of steps that help a software team to
understand and manage uncertainty. Many problems can plague a software project. A risk
is a potential problem-it might happen, it might not. But regardless of the outcome, it’s
really a good idea to identify it, assess its probability of occurrence, estimate its impact,
and establish a contingency plan should the problem actually occur.

Types of risk
PROJECT RISK They identify potential budgetary, schedule, personnel, resource,
custom potential and requirements problem and their impact on software project. They
threaten the project plan.

TECHNICAL RISK They identify potential design, implementation, interface

verification, and maintenance problem. They threaten the quality and timeliness of
software to be produced.

BUSINESS RISK They often jeopardize the project or the product and include market
risk, strategic risk, management risk and budget risk.

Risk strategies

REACTIVE A reactive strategy monitors the risk project for likely risk and set aside
resources to deal with them, should they become actual problems. Software team does
nothing about risks until something goes wrong.

PROACTIVE A proactive strategy begins long before technical work is initiated.

Potential risks are identified, their probability impact is assessed, and they are ranked by
importance.

Risk analysis

Risk analysis is a technique to identify and assess factors that jeopardize the success of a
project or achieving a goal. This technique also helps define preventive measures to
reduce the probability of these factors from occurring and identify counter measures to
successfully deal with these constraints when they develop to avert possible negative
effects on the competitiveness of the company.

This is achieved by: Risk avoidance, Risk monitoring, Risk management and
contingency plan

RMMM PLAN (Risk Mitigation, Monitoring and Management Plan) It documents

all work performed as a part of risk analysis and is used by project manager as a part of
 overall project plan. Once RMMM has been documented and the project has begun, risk
mitigation and monitoring steps commence.

Risk management following steps can be taken for resolution of the mentioned risks:

Try to develop healthy communication with clients’ staff so as to easily gather

requirements and to train and guide them about the software.

Divide the work among team members properly to meet the deadlines.

Try to finish the work at least 10 days before the deadline, as many changes have to be
incorporated after that.

Timely check the space availability and size of the software.

TIME - LINE CHART

S.NO. TASK DATE OF START DATE OF END

1. REQUIREMENT GATHERING AND ANALYSIS 15/2/2017 25/2/2017

2. DESIGN

2.1. Data design 26/2/2017 28/2/2017

2.2. Architectural design 1/3/2017 3/3/2017

2.3. Interface design 3/3/2017 8/3/2017

3. Testing 8/3/2017 11/3/2017

 Chapter 4
Design
engineering
Introduction
Design phase of the software development deals with transforming the requirements of
the client into a form implement able using a programming language. Software design is
applied regardless of the software process model that is used. Beginning once software
requirements have been analysed and specifies, software design is the first of three
technical activities—design, code generation, tests that are required to build and verify
the software. A good software design is a series of step-by-step procedures to do the
desired act.

4.1 Design concepts and principles

Principles of Software Design
Developing design is a cumbersome process as most expansive errors are often
introduced in this phase. Moreover, if these errors get unnoticed till later phases, it
becomes more difficult to correct them. Therefore, a number of principles are followed
while designing the software. These principles act as a framework for the designers to
follow a good design practice.
                                 

Software Design Concepts

The fundamental concepts underlining the software design process remain the same,
some of which are described here.
Abstraction

There are three commonly used abstraction mechanisms in software design, namely,
functional abstraction, data abstraction and control abstraction. All these mechanisms
allow us to control the complexity of the design process by proceeding from the abstract
design model to concrete design model in a systematic manner.

Architecture

Software architecture refers to the structure of the system, which is composed of various
components of a program/ system, the attributes (properties) of those components and the
relationship amongst them.

Note that software architecture comprises two elements of design model, namely, data
design and architectural design.

Modularity

Modularity is achieved by dividing the software into uniquely named and addressable
components, which are also known as modules. Note that larger the number of modules a
system is divided into, greater will be the effort required to integrate the modules.

Modularizing a design helps to plan the development in a more effective manner,

accommodate changes easily, conduct testing and debugging effectively and efficiently,
and conducts maintenance work without adversely affecting the functioning of the
software.

Information Hiding

Modules should be specified and designed in such a way that the data structures and
processing details of one module are not accessible to other modules. They pass only that
much information to each other, which is required to accomplish the software functions.
The way of hiding unnecessary details is referred to as information hiding.
Developing a design model

Data Design It transforms the information domain model created during analysis into the
data structures that will be required to implement the software.

Architectural Design It defines the relationship between major structural elements of the
software.

Interface Design It describes how the software communicates within itself, with systems
that interoperate with it and with the users who use it.

Component Level Design It transforms structural elements of software architecture into

a procedural description of software components.

4.2 Data design

Credentials:
Column Type Null Default
Name varchar(25) Yes NULL
roll_number varchar(30) Yes NULL
student_id int(10) No
Password varchar(25) Yes NULL
security_answer varchar(50) No

Library details:

Column Type Null Default

Name varchar(25) No
student_id int(10) No
book_name varchar(50) No
issued_on Date Yes NULL
return_on Date Yes NULL

Fee details:

Column Type Null Default

Name varchar(25) No
student_id int(10) No
Hostel_fees varchar(50) No
Annual_fees Date Yes NULL
Mess_charges Date Yes NULL

Evaluation details:

Column Type Null Default

Name varchar(25) No
student_id int(10) No
PHP int(10) No
Software int(10) No
DBMS int(10) No
Algorithms int(10) No
Assignment1 int(10) No
Assignment2 int(10) No
Classes attended int(10) No
Lectures held int(10) No

Student details:

Column Type Null Default

in_dex int(3) Yes NULL
Name varchar(25) Yes NULL
student_id int(10) No
roll_number varchar(30) Yes NULL
Course varchar(30) Yes NULL
Batch varchar(25) Yes NULL
Address varchar(100 Yes NULL
)
email_id varchar(30) Yes NULL
contact_numbe varchar(15) Yes NULL
r
Staff details:

Column Type Null Default

in_dex int(3) Yes NULL
Name varchar(25) Yes NULL
member_id int(10) No
Date of joining varchar(30) Yes NULL
Department varchar(30) Yes NULL
Post varchar(25) Yes NULL
Address varchar(100 Yes NULL
)
email_id varchar(30) Yes NULL
contact_number varchar(15) Yes NULL
Specialization varchar(30) Yes NULL
Years of varchar(15) Yes NULL
experience
Teaching status varchar(10) No NULL

4.3 Architectural design

Architectural design represents the structure of data and program components that are
required to build a computer-based system. The architectural design acts as the blueprint
to the software development.

Architectural mapping using data flow

A mapping technique, called structured design is often characterized as a data flow-

oriented design method because it provides a convenient transition from a data flow
diagram to software architecture. The transition from information flow (represented as a
DFD) to program structure is accomplished as part of a six step process:

(1) Type of information flow is established

(2) Flow boundaries are indicated

(3) DFD is mapped into the program structure

(4) Control hierarchy is defined

(5) Resultant structure is refined using design measures and heuristics, and

(6) Architectural description is refined and elaborated.

To map these data flow diagrams into software architecture, you would initiate the
following design steps:

Step 1.Review the fundamental system model.

Shows the basic transfer of data (level 0 and level 1 dfd)
Step 2.Review and refine data flow diagrams for the software.
Shows the refined DFD (level 2)

Step 3.Determine whether the DFD has transform or transaction flow characteristics.

This project has a transaction data flow

Step 4.Isolate the transform centre by specifying incoming and outgoing flow boundaries

Step 5.Perform “first-level factoring.” Factoring leads to a program structure in which

top-level components perform decision making and lowlevel components perform most
input, computation, and output work. Middle-level components perform some control and
do moderate amounts of work.

Step 6.Perform “second-level factoring.” Second-level factoring is accomplished by

mapping individual transforms (bubbles) of a DFD into appropriate modules within the
architecture.

Step 7.Refine the first-iteration architecture using design heuristics for improved
software quality.
4.4 INTERFACE DESIGN
 Chapter 5
TESTING

5.1 SOFTWARE TESTING

Software testing is an investigation conducted to provide stakeholders with information
about the quality of the product or service under test. Software testing can also provide an
objective, independent view of the software to allow the business to appreciate and
understand the risks of software implementation. Test techniques include, but are not
limited to, the process of executing a program or application with the intent of finding
software bugs (errors or other defects).

It involves the execution of a software component or system component to evaluate one

or more properties of interest. In general, these properties indicate the extent to which the
component or system under test:

 meets the requirements that guided its design and development,

 responds correctly to all kinds of inputs,
 performs its functions within an acceptable time,
 is sufficiently usable,
 can be installed and run in its intended environments, and
 achieves the general result its stakeholders desire.

As the number of possible tests for even simple software components is practically
infinite, all software testing uses some strategy to select tests that are feasible for the
available time and resources. As a result, software testing typically (but not exclusively)
attempts to execute a program or application with the intent of finding software bugs
(errors or other defects).

Software testing can provide objective, independent information about the quality of
software and risk of its failure to users and/or sponsors.[1]

Software testing can be conducted as soon as executable software (even if partially

complete) exists. The overall approach to software development often determines when
and how testing is conducted. For example, in a phased process, most testing occurs after
system requirements have been defined and then implemented in testable programs. In
contrast, under an Agile approach, requirements, programming, and testing are often
done concurrently.

Testing Strategies
A test strategy is an outline that describes the testing approach of the software
development cycle. It is created to inform project managers, testers, and developers about
some key issues of the testing process. This includes the testing objective, methods of
testing new functions, total time and resources required for the project, and the testing
environment.

Levels of testing

 Unit testing
 Integration testing
 Validation testing
Focus is on software requirements
 System testing
Focus is on system integration
 Alpha/Beta testing
Focus is on customer usage
 Recovery testing
Forces the software to fail in a variety of ways and verifies that recovery is properly
performed
 Security testing
Verifies that protection mechanisms built into a system will, in fact, protect it from
improper penetration
 Stress testing
Executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
 Performance Testing
Test the run-time performance of software within the context of an integrated system

5.2 CYCLOMATIC COMPLEXITY

Cyclomatic Complexity is a measure of the number of linearly independent paths through
the unit/component. It can therefore be used in structural testing to determine the
minimum number of tests that must be executed for complete basis path coverage.
Process: Internal marks evaluation
Flow chart

Flow Graph
There are 3 methods to calculate cyclomatic complexity:

By calculating number of regions

Cyclomatic complexity = Number of regions = 3

By calculating number of predicate nodes

Cyclomatic complexity = Number of Predicate Nodes + 1

A limitation on the predicate nodes formula is that it assumes that there are only two
outgoing flows for each of such nodes which is not a problem in this case.

Cyclomatic complexity = 2+1 = 3

By calculating number of nodes and number of edges

Cyclomatic complexity = E – N + 2 = 8 – 7+ 2 = 3
 BIBLIOGRAPHY

1. http://www.whiteboxtest.com/cyclomatic-complexity.php.
2. http://www.westfallteam.com/sites/default/files/papers/Basis_Path_Testing_Pap
er.pdf
3. Roger S. Pressman, “Software Engineering A Practitioner Approach”
4. Pankaj Jalote, “A concise Introduction to software engineering”