MCS 044 by ABIR - DAS

Created by ABIR DAS, Belonia, Tripura (S) , email: abiranna@gmail.com , https://www.facebook.
com/abiranna 1
Which Systems Development Life Cycle (SDLC) will you propose for the specification given above? Justify
you selection by evaluating suitability of at least two SDLCs. (10 Marks)
Answer:
There is no specific SDLC model that can be used for all types of projects and situations. If none of the
popular SDLC models suit for a specific project then, pick the closest matching SDLC model and modify it
as per needs. Identify how important is risk assessment and use spirals risk assessment methodology if its a
risk critical project. Project should be delivered in small chunks, ideally merging the incremental model with
V-shaped model. One must spend ample time in choosing the right model or customizing one to suit a
project for its successful and efficient completion.
So, Spiral Model seems to a better choice for School Information System (SIS)
The spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up
concepts.
Advantages :
> On a project earlier. Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because
important issues are discovered earlier.
> It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software
engineers (who can get restless with protracted design processes) can get their hands in and start working
> Select has been a major player in the development of iterative and incremental development processes over the last
20 years. Our tools therefore provide relevant facilities for those looking to use such processes like SIS.
Causes for selecting Spiral Model as S/w paradigm :
Spiral model should be used when:
a. Large, complex and high budget projects
Created by ABIR DAS, Belonia, Tripura (S) , email: abiranna@gmail.com , https://www.facebook.com/abiranna 2
Without maintaining name, parent name, address etc SIS maintains the components like tuition fee,
activity fee, material fee, bus fee and day to day attendance with informing principal of the school too. It
also maintains the records of the last 20 years. So it is not a simple project.
b. Requirements are not very clearly defined,
Hence SIS requires also health record like uncommon field. It maintains tuition fee, activity fee, material
fee and bus fee. In later it can be extended with hostel and hostel fee can be added in the form, so it can be
said that requirements are not defined exactly.
c. When risk assessment is very critical,
As SIS is a large complex project so risk is as usual for this project. So we need to understand these to make
sure there's enough extra time to deal with identified risks and with unidentified risks (risks are identified
with thorough Risk AnalySIS).
d. The organization does not have much experience with the domain.
SIS will use in an academic or educational institute, most of the staff should be inexperienced in handling
the domain/ project. So it must be such that can be modifiable. Thus it would be easily changed with respect
to their requirements.
e. Ample time is available,
it is not a business software that it is depend on share market which is always changing. So for maintaining
it there should be a ample time for the development and users also.
Why Spiral model is suitable comparing with other SDLC models?
The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model, therein providing the potential for rapid development of incremental versions of the
software. In this model the software is developed in a series of incremental releases like School Information
System ie. SIS 1
st
yr, 2
nd
yr 20
th
year so on. Hence, with the early stages being either paper models or
prototypes. Later iterations become increasingly more complete versions of the product.
Requirement speciafication:
Hardware Requirement:
Processor: Intel Pentium 4
Memory: 2 GB RAM.
Network Adaptor: Ethernet Adaptor
Modem: 512 Kbps Voice, Fax & Data
Secondary Storage: Seagate SATA Hard disk (250
GB)
Software Requirements:
Platform: Windows
The Operating System: Windows XP Professional
sp2 or later
Front-End Tool: Java Server Pages/ asp.net
Editing tool: Net Beans IDE 6.5.1
Browser: Internet Explorer/ Mozilla etc.
Database: SQL Community Server
Question 2:
What would be major costs of installing the system? What are going to be the benefits in terms of finance?
Perform a cost-benefit analySIS for the proposed software. List the major tasks and milestones of the Project
and make a project schedule. Your schedule must include both GANTT and PERT charts. Explain the two
charts drawn by you.
Answer:
Development Cost
Personal cost:-
System AnalySIS : 20,000/- PM
Programmer : 15,000/- PM
Data-Entry Operation : 5,000/- PM
Total personal cost for one month is 40,000/-
Training:-
Training to Administratating user : 10,000/- PM
Total training cost for one month is 10,000/-
New hardware and software:-
Development desktop Pentium IV : 40,000/-
Operating system : 10,000/-
SQL Server : 40,000/-
Visual Studio / Java Server : 50,000/-
Total H/W and S/W costs = 1, 40, 000/-
What benefits will the system provide?
Tangible benefits It is measured in terms of monthly or annual savings or of profit to the School
The tangible benefits of School Information System (SIS) are:
Fewer processing errors
Increased output
Decreased response time
Elimination of job steps
Reduced expenses like stationary, file folder, registers, printing costs etc in SIS
Time Feasibility study:
It is a type of feasibility study, through which we examine whether our proposed project can be
completed in the specified time frame or not.
Legal Feasibility study:
This feasibility study evaluates whether the project breaks any law or not.
Project Scheduling
The management of large projects like our SIS requires analytical tools for scheduling activities and
allocating resources. This note describes a set of tools that has proven to be conSIStently valuable to project
managers. The tools are collectively known as the Project Evaluation and Review Technique (PERT) and
the Critical Path Method (CPM).
Schedules also help you do the following:
They provide a baSIS for you to monitor and control project activities.
They help us determine how best to allocate resources so any one can achieve the project goal.
Schedule Inputs :-
We need several types of inputs to create a project schedule:
Personal and project calendars Understanding working days, shifts, and resource availability is
critical to completing a project schedule.
Description of project scope From this, we can determine key start and end dates, major
assumptions behind the plan, and key constraints and restrictions. we can also include stakeholder
expectations, which will often determine project milestones.
Scheduling Tools:
Here are some tools and techniques for combining these inputs to develop the schedule:
Schedule Network AnalySIS This is a graphic representation of the project's activities, the time it
takes to complete them, and the sequence in which they must be done. Project management software
is typically used to create these analyses Gantt charts and PERT Charts are common formats.
Critical Path AnalySIS This is the process of looking at all of the activities that must be
completed, and calculating the 'best line' or critical path to take so that we'll complete the
project in the minimum amount of time.
GANTT CHART:-A Gantt charts have become a common technique for representing the phases and
activities of a project work breakdown structure (WBS), so they can be understood by a wide audience all
over the world
PERT Charts
PERT = Project Evaluation and Review Technique
PERT chart = graphical representation of the scheduling of events in a project
A PERT chart is a graph
Edges are tasks/activities that need to be done
Nodes are the events or milestones
Task edge T from event node E1 to event node E2 signifies:
Until event E1 happens, task T cannot be started
Until task T finishes, event E2 cannot happen
Question 3:
Study the system and create a software requirement specification. You must identify either the processes or
objects while analyzing. During the analySIS give consideration to possible input and output of the
processes. After identifying the requirements, create AnalySIS Models. You may either use the classical
approach and draw Entity relationship diagram and data flow diagrams (DFDs) up to level 2-3; or you may
take object oriented analySIS approach and create class diagram, use case diagram, use cases, etc.
(10+15 Marks)
Answer:
Software Requirement Specification:
Introduction:-
Purpose- This document completely describes what the Information System should do
without describing how the software will do it. The basic goal of the requirement phase is
to produce the SRS, which describing the complete external behavior of the purposed
software.
Scope- This document is the only one that describes the requirements of the system. It is
meant for use by the developer and will be the baSIS for validating the final delivered
system. Any changes made to the requirements in the future will have to go through a
formal changes approval process. The developer is responsible for asking for
clarifications, where necessary, and will not make any alteration without the permission
of the client.
Developers responsibility-
The developer is responsible for:
(a) Developing the system.
(b) Installing the software on the clients hardware.
(c) Conducting any user training that might be needed for using the system.
(d) Maintaining the system for a period of one year after installation.
Project Description:-
This section provides an overview of the software. This section describes the goal and objective of
the software. This section also briefly describes the general requirements of the software. This section is
very important for the verification of the software after the completion whether the objective and
requirements of the software will meet or not.
Goals and Objectives-
The goals of School Information System are:
To automate the time consuming process to go to entry Students details dynamically.
To update attendance when needed as an example, attendance is needed at the time of exam.
To manage the records of students and guardians also.
To provide a searchable database of all students and staff of the institute.
To minimize the amount of paper work required in the daily services.
To manage students various type of fee securely.
To provide an interface so that user can take advantage of anytime, anywhere.
General requirement- During the Requirement AnalySIS Phase, the development team analyzes the
requirements to be fulfilled by the SIS and identifies the probable approach for meeting these requirements.
Finally, it was identified that the the Student Information System should:
Enable the visitors to fill Registration form.
Provide details of the various products available in Stores.
Provide the information about the rate of the available students in each dept.
Be secure enough against the malicious security attack, identity verification of the registered user
and authorization.
Be able to handle various run time exceptions and errors.
It should provide proper interfaces to manage and view details.
The forms should be user friendly and well design to attract visitors.
E-R Diagramfor SIS (Student Information system) :
DFD for SIS (Student Information system) :
Object Oriented Analysis Approach in SIS
There have been basically 3 approaches in information system development area: process-oriented, data-
oriented and object-oriented approaches. As information technology (both hardware and software) has been
advancing, people have moved from the earliest process-oriented approach to data-oriented approach and
now begun to adopt the latest object-oriented analySIS methodology.
Mechanism of Object-oriented Approach
The principals of objects, encapsulation, inheritance, and polymorphism are the foundation for object-
oriented systems development. To understand and express the essential and interesting features of an
application in the complex real world, an object-oriented model is built around objects. An object
encapsulates both data and behavior, implying that analysts can use the object-oriented approach for both
data modeling and process modeling.
Unified Modeling Langufage
The Unified Modeling Language (UML) is an object-oriented language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business modeling (UML
Document Set, 2001). The UML was developed by Rational Software and its partners. It is the successor to
the modeling languages found in the Booch (Booch 1994), OOSE/Jacobson, OMT and other methods.
Question 4:
Design the system architecture and the database as per the needs of the system. You must perform
normalization on tables up to 3
rd
normal form. The table design must include Primary and Foreign keys and
constrains. Create the systems flow chart or detailed process design and state transition diagrams. Also
design the user input screens and output report formats. (15+10 Marks)
Answer:
DATABASE DESIGN DOCUMENT SYSTEM ARCHITECTURE OF SIS
Overview of Students Information System (SIS)
The System Design Document describes the system requirements, operating environment, system and
subsystem architecture, files and database design, input formats, output layouts, human-machine interfaces,
detailed design, processing logic, and external interfaces.
INTRODUCTION
Purpose and Scope
This section provides a brief description of the Students Information System (SIS) Design Documents
purpose and scope.
SIS Executive Summary
This section provides a description of the SIS project from a management perspective and an overview
of the framework within which the conceptual system design was prepared. If appropriate, include the
information discussed in the subsequent sections in the summary.
SIS System Overview
This section describes the system in narrative form using non-technical terms. It should provide a
high-level system architecture diagram showing a subsystem breakout of the system, if applicable.
The high-level system architecture or subsystem diagrams should, if applicable, show interfaces to
external systems. Supply a high-level context diagram for the system and subsystems, if applicable.
Refer to the requirements trace ability matrix (RTM) in the Functional Requirements Document
(FRD), to identify the allocation of the functional requirements into this design document.
SIS Design Constraints
This section describes any constraints in the system design (reference any trade-off analyses
conducted such, as resource use versus productivity, or conflicts with other systems) and includes
any assumptions made by the project team in developing the system design.
Future Contingencies
This section describes any contingencies that might arise in the design of the system that may change
the development direction. Possibilities include lack of interface agreements with outside agencies or
unstable architectures at the time this document is produced. Address any possible workarounds or
alternative plans.
SIS Document Organization
This section describes the organization of the Systems Design Document.
Points of Contact
This section provides the organization code and title of the key points of contact (and alternates if
appropriate) for the information system development effort. These points of contact should include
the Project Manager, System Proponent, User Organization, Quality Assurance (QA) Manager,
Security Manager, and Configuration Manager, as appropriate.
Project References
This section provides a bibliography of key project references and deliverables that have been
produced before this point.
Glossary
Supply a glossary of all terms and abbreviations used in this document. If the glossary is several
pages in length, it may be included as an appendix.
SIS SYSTEM ARCHITECTURE
In this section of SIS, it describes the system and/or subsystem(s) architecture for the project.
References to external entities should be minimal, as they will be described in detail in Section 6,
External Interfaces.
System Hardware Architecture
In this SIS section, describe the overall system hardware and organization. Include a list of hardware
components (with a brief description of each item) and diagrams showing the connectivity between the
components. If appropriate, use subsections to address each subsystem.
SIS System Software Architecture
In this SIS section, describe the overall system software and organization. Include a list of software
modules (this could include functions, subroutines, or classes), computer languages, and programming
computer-aided software engineering tools (with a brief description of the function of each item). Use
structured organization diagrams/object-oriented diagrams that show the various segmentation levels
down to the lowest level. All features on the diagrams should have reference numbers and names.
Include a narrative that expands on and enhances the understanding of the functional breakdown. If
appropriate, use subsections to address each module.
Note: The diagrams should map to the data flow diagrams, providing the physical process and data
flow related to the ER logical process and data flow.
Internal Communications Architecture
In this SIS section, describe the overall communications within the system; for example, LANs, buses,
etc. Include the communications architecture(s) being implemented, such as X.25, Token Ring, etc.
Provide a diagram depicting the communications path(s) between the system and subsystem modules.
If appropriate, use subsections to address each architecture being employed.
Note: The diagrams should map to the ER context diagrams.
FILE AND DATABASE DESIGN
Interact with the Database Administrator (DBA) when preparing this section. The section should reveal
the final design of all database management system (DBMS) files and the non-DBMS files associated
with the system under development. Additional information may add as required for the particular
project. Provide a comprehensive data dictionary showing data element name, type, length, source,
validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs,
aliases, and description. Can be included as an appendix.
Database Management System Files
This section reveals the final design of the DBMS files and includes the following information, as
appropriate (refer to the data dictionary):
Refined logical model; provide normalized table layouts, entity relationship diagrams, and other
logical design information
A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page
sizes, etc.
Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)
Estimate of the DBMS file size or volume of data within the file, and data pages, including
overhead resulting from access methods and free space
Definition of the update frequency of the database tables, views, files, areas, records, sets, and
data pages; estimate the number of transactions if the database is an online transaction-based
system
Non-Database Management System Files
In this section, SIS provide the detailed description of all non-DBMS files and include a narrative
description of the usage of each fileincluding if the file is used for input, output, or both; if this file
is a temporary file; an indication of which modules read and write the file, etc.; and file structures
(refer to the data dictionary). As appropriate, the file structure information should:
Identify record structures, record keys or indexes, and reference data elements within the records
Define record length (fixed or maximum variable length) and blocking factors
Define file access methodfor example, index sequential, virtual sequential, random access, etc.
Estimate the file size or volume of data within the file, including overhead resulting from file
access methods
Define the update frequency of the file; if the file is part of an online transaction-based system,
provide the estimated number of transactions per unit time, and the statistical mean, mode, and
distribution of those transactions
HUMAN-MACHINE INTERFACE
This section provides the detailed design of the system and subsystem inputs and outputs relative to the
user/operator. Any additional information may be added to this section and may be organized according
to whatever structure best presents the operator input and output designs.
Inputs
This section is a description of the input media used by the operator for providing information to the
system; Provide the layout of all input data screens or graphical user interfaces (GUI) (for example,
windows). Provide a graphic representation of each interface. Define all data elements associated
with each screen or GUI, or reference the data dictionary.
Discuss the miscellaneous messages associated with operator inputs, including the following:
Copies of form(s) if the input data are keyed or scanned for data entry from printed forms
Description of any access restrictions or security considerations
Each transaction name, code, and definition, if the system is a transaction-based processing
system
Outputs
System outputs include reports, data display screens and GUIs, query results, etc. The output files are
described in Section 3 and may be referenced in this section. The following should be provided, if
appropriate:
Identification of codes and names for reports and data display screens
Description of report and screen contents (provide a graphic representation of each layout and
define all data elements associated with the layout or reference the data dictionary)
DETAILED DESIGN OF SIS
This section provides the information needed for a system development team to actually build and
integrate the hardware components, code and integrate the software modules, and interconnect the
hardware and software segments into a functional product.
Hardware Detailed Design
A hardware component is the lowest level of design granularity in the system. Depending on the
design requirements, there may be one or more components per system.
Include the following information in the detailed component designs (as applicable):
Power input requirements for each component
Signal impedances and logic states
Connector specifications (serial/parallel, 11-pin, male/female, etc.)
Memory and/or storage space requirements
Processor requirements (speed and functionality)
Graphical representation depicting the number of hardware items (for example, monitors,
printers, servers, I/O devices), and the relative positioning of the components to each other
Cable type(s) and length(s)
User interfaces (buttons, toggle switches, etc.)
Hard drive/floppy drive/CD-ROM requirements
Monitor resolution
Software Detailed Design
A software module is the lowest level of design granularity in the system. Depending on the software
development approach, there may be one or more modules per system. Include the following
information in the detailed module designs:
A narrative description of each module, its function(s), the conditions under which it is used.
For COTS packages, specify any call routines or bridging programs to integrate the package with
the system and/or other COTS packages (for example, Dynamic Link Libraries)
Data elements, record structures, and file structures associated with module input and output
Graphical representation of the module processing, logic, flow of control, and algorithms, using
an accepted diagramming approach (for example, structure charts, action diagrams, flowcharts,
etc.)
Internal Communications Detailed Design of SIS
If the SIS system includes more than one component there may be a requirement for internal
communications to exchange information, provide commands, or support input/output functions.
Include the following information in the detailed designs (as appropriate):
The number of servers and clients to be included on each area network
Specifications for bus timing requirements and bus control
Format(s) for data being exchanged between components
LAN topology
What is normalisation?
Normalisation is the process of taking data from a problem and reducing it to a set of relations while
ensuring data integrity and eliminating data redundancy Data integrity - all of the data in the
database are conSIStent, and satisfy all integrity constraints.
Data redundancy if data in the database can be found in two different locations ( direct
redundancy ) or if data can be calculated from other data items ( indirect redundancy ) then the data
is said to contain redundancy.
Data should only be stored once and avoid storing data that can be calculated from other data
already held in the database. During the process of normalization redundancy must be removed, but
not at the expense of breaking data integrity rules.
Example:
Student Table:
Std_ID Std_Name Parents Name/
guardian Name
Permanent_A
ddress
Std_Phone
_No
gurdians
email
Health_
Report
S01 Abir Das Sribash, Sathi PO : Rajnagar
Pin : 799150
9774915363 abiranna@gmai
l.com
Good
S02 Piya Nirmal, Gayatri PO : Belonia,
Pin : 799155
8794880988 piyadgpt@gmai
l.com
Good
S03 Sukanta Abc PO : Radhngr
Pin : 799145
8974858485 Rdn.sukanta@g
mail.com
Good
S04 Pulak Xyz PO : Rdhangr
Pin : 799145
7308652583
9862794815
Pulak.indraDa
@yahoo,com
Good
First Normal Form(1NF )
1NF deals with the `shape' of the record type
A relation is in 1NF if, and only if, it contains no repeating attributes or groups of attributes.
AFTER APPLYING 1NF THE TABLE WILL BE :
Student Table:
Std_ID Std_Name Parents/
guardian Name
Permanent_
Address
Std_Phone
_No
gurdians email Health_
Report
S01 Abir Das Sribash &
Sathi
PO : Rajnagar
Pin : 799150
9774915363 abiranna@gmail.
com
Good
S02 Piya Nirmal &
Gayatri
PO : Belonia,
Pin : 799155
8794880988 piyadgpt@gmail.
com
Good
S03 Sukanta Abc PO : Radhngr
Pin : 799145
8974858485 Rdn.sukanta@g
mail.com
Good
Pin : 799145
7308652583 Pulak.indraDa@
yahoo.com
Good
Pin : 799145
9862794815 Pulak.indraDa@
yahoo.com
Good
Second Normal Form
Second normal form (or 2NF) is a more stringent normal form defined as:
A relation is in 2NF if, and only if, it is in 1NF and every non-key attribute is fully functionally
dependent on the whole key.
Example:
Student Details Table:
Std_ID Std_Name Std_Phone
_No
Health_
Report
S01 Abir Das 9774915363 Good
S02 Piya 8794880988 Good
S03 Sukanta 8974858485 Good
S04 Pulak 9862794815 Good
S04 Pulak 9862794815 Good
Students family DetailsTable:
Std_ID Parents/
guardian Name
Permanent_
Address
gurdians email
S01 Sribash &
Sathi
PO : Rajnagar
Pin : 799150
abiranna@gmail.
com
S02 Nirmal &
Gayatri
PO : Belonia,
Pin : 799155
piyadgpt@gmail.
com
S03 Abc PO : Radhngr
Pin : 799145
Rdn.sukanta@g
mail.com
S04 Xyz PO : Rdhangr
Pin : 799145
Pulak.indraDa@
yahoo,com
Std_Id is Key for Students Details table and Hence, Std_ID + Parents/ guardian Name is key for
Students family Details table
Third Normal Form
3NF is an even stricter normal form and removes virtually all the redundant data :
A relation is in 3NF if, and only if, it is in 2NF and there are no transitive functional
dependencies
Transitive functional dependencies arise:
when one non-key attribute is functionally dependent on another non-key attribute:
FD: non-key attribute -> non-key attribute
and when there is redundancy in the database
Consider the following table:
Std_ID Std_Name Health_Report
S01 Abir Das Good
S02 Piya Good
S03 Sukanta Good
S04 Pulak Good
S04 Pulak Good
The table has 2 non-key attributes(Std name and Health report) and they have transitive
dependency upon each other.
Std_ID Std_Name Health_
Report
S01 Abir Das Good
S02 Piya Good
S03 Sukanta Good
S04 Pulak Good
Name table Std_Health table
Std_ID Std_Name Std_ID Health_Report
S01 Abir Das S01 Good
S02 Piya S02 Good
S03 Sukanta S03 Good
S04 Pulak S04 Good
Simple Flow Chart for SIS:
User input Screen for SIS:
User Output Report of a Student in SIS:
Question 5:
Design various unit test cases for different testing techniques/strategies. (10 Marks)
Answer :
Testing and Implementation of SIS
SIS Testing:-
In SIS Software testing is a critical element of software quality assurance and represents the ultimate review
of specification, design and code generation. The increasing visibility of software as a system element and
the attendant costs associated with a software failure are motivating forces for well planned through
testing.
Once source code has been generated, software must be tested to uncover as many errors as possible before
delivery to customer. The goal is to design a series of test cases that have a high likelihood of finding errors.
That is where software testing techniques enter the pictures.
Testing Objectives of SIS-
Testing is a process of executing a program with the intent of finding an error.
A good test case is one that has a high probability of finding an as-yet-undiscovered error.
A successful test is that uncovers an as-yet- undiscovered error.
Testing Principles of SIS -
All tests should be traceable to customer requirement.
Tests should be planned long before testing begins.
The Pareto principle applies to software testing.
Exhaustive testing is not possible.
To be most effective, an independent third party should conduct testing.
All tests should be traceable to customer requirement.
Tests should be planned long before testing begins.
The Pareto principle applies to software testing.
Exhaustive testing is not possible.
To be most effective, an independent third party should conduct testing.
Software like SIS testing involves executing an implementation of the software with test data and
examining the outputs of the software and its operational behavior to check that it is performing as required.
Testing is a dynamic technique of verification and validation because it works with an executable
representation of the system.
Unit Testing of SIS
In SIS, unit testing focuses verification effort on the smallest unit of software design-the software component or
module. Using the component level design description as a guide, important control paths are tested to uncover errors
within the boundary of the module. The relative complexity of tests and uncovered errors is limited by the constrained
scope established for unit testing. The unit test is white-box oriented and the step can be conducted in parallel for
multiple components.
Login Module of Administrator of student information system (SIS)
Sl. No
Test Case
Description
Input
Expected
Behavior
Observed behavior
Test
Result
1
Can ID field be
Null?
Null ID ID cannot be NULL
Warning msg "ID can't
be NULL"
Success
2
Can password be
Null?
Null password
Password Can't
be NULL
Warning msg
"password can't
be Null"
Success
3
Login button is
working or not?
Button
pressed
Perform login
processing
Call proxy Inbox
frame
Success
4.
Is Login Frame
displaying properly?
Invoke Login
Frame
All text fields are
displayed and are
properly aligned
Little alignment
problem
Success
Server-side Login Module of SIS
Serial
No
Test Case
Description
Input
Expected
Behavior
Observed
behavior
Test
Result
1
Is Database
Connection
establishing?
Connection
object is
created
Connection
establishes
No error during
connection was
found
Success
2
Is able to retrieve Login
ID and password from
database
Login ID+Pass-
Word
Able to fetch
data from
Database
No error found during
data fetching
Success
3
Is able to match Login ID
&Password
Login Id +
Password
Proper
matching
Matching done Success
Client- Server Login Module of SIS combined Testing
Serial
No
Test Case
Description
Input
Expected
Behavior
Observed
behavior
Test
Result
1
Client Server
Connection
Connection
cmd
Connection
Established
Connection is
established
Success
2
Server response
handled properly
or not?
Login cmd
Proper Message
Displayed to
User
All type of
messages are
displayed in proper
format to user
Success
3
Communication
between client
and
Server
Login cmd
Login cmd is
received by
server and
response is
send to client
Communication is
taking place.
Success
4
What if User Id
doesn't exist
Login cmd+
UserlD
Server should
report non
existence of
UserlD
Error msg: "Login
ID doesn't exist"
Success
5
What if wrong
password is
entered?
Login cmd +
UserID +
Password
User should be
prompt for
reentry of
password
Error msg: "Invalid
Password"
Success
Add students record Module of SIS
Serial.
No
Test Case
Description
Input
Expected
Behavior
Observed
behavior
Test
Result
1.
Is Database
Connection
establishing?
Connection
object is
created
Connection
establishes
No error during
connection was
found
Success
2
Addition of student
details.
Student Name,
email
/Marks/attendan
ce
Addition
Completed.
Addition
completed
Success
3
Addition of
students details if
already exits
Student Name,
email
/Marks/attendan
ce
Addition
should not
complete
Addition is not
completed, because
record already exists.
Success
Integration Testing in SIS
Integration testing is a systematic technique for constructing the program structure while at the same time
conducting tests to uncover errors associated with interfacing. The objective is to take unit tested
components and build a program structure that has been dictated by design.
Incremental integration is the antitheSIS of the big bang approach. The program is constructed and tested in
small increments, where errors are easier to isolate and correct, interfaces are more likely to be tested
completely, and a systematic test approach may be applied.
System Testing in SIS
System testing in SIS is actually a series of different tests whose primary purpose is to fully exercise the
computer-based system. Although each test has a different purpose, all work to verify that system elements
have been properly integrated and perform allocated functions.
Functional Requirement of SIS
Serial.
No
Test Case
Description
Input
Expected
Behavior
Observed behavior Test Result
1
Can New User
Register?
Personal Info of
User
User should Be
registered on
DTIS server
User is Registered only If
desired Id does Not
collide with Existing Ids
Success
2 Can User Login?
Login ld +
password
User should Be
login
User is login only When
Login Id & password is
valid
Success
3
Can User Add
Records
Students Name /
Marks details /
attandence etc
User should be
able to Add
records
Added records will be
displayed
Success
4.
Can User Delete
Records
Students Name /
Marks details /
attandence etc
User should be
able to delete
records
Deleted records will not
be displayed
Success
5
Can User Update
Records
Students Name /
Marks details /
attandence etc
User should be
able to update
records
Updated records will be
displayed
Success
6.
Can User Search
Records
Students Name /
Marks details /
attandence etc
User should be
able to search
records
Result of search will be
displayed.
Success
7.
Can User Read
information available
on the site.
Click the link
User should be
able to Read
information
Information will be
displayed.
Success
8 Can User Logout
Click On
Logout
User should be
able to Logout
Logout Message Success
Salient Features of the student information system
The SIS is completely menu driven.
Students details entry screens are completely user friendly with validation.
All editing features and navigation from one field to another, one page to another, etc is possible.
Exit from any page is possible.
In SIS, validation checks have been incorporated in each page at the appropriate fields.
Database has been secured by means of password protection.
Authorization is necessary for all the internal users of the SIS project.
------------------------------ < > ------------------------------
Gud Bye Frnds, for others solutions and laboratory report,
suggestion, query and other problem dnt 4get to contact me.

MCS 044 by ABIR - DAS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MCS 044 by ABIR - DAS

Transféré par

Droits d'auteur :

Formats disponibles

Created by ABIR DAS, Belonia, Tripura (S) , email: abiranna@gmail.com , https://www.facebook.

Vous aimerez peut-être aussi