Course Code : MCS-044
Course Title : Mini Project
Assignment Number : MCA (4)/044/Assign/2014-15
Maximum Marks : 100
Weightage : 25%
Last Dates for Submission : 15th October, 2014 (For July 2014 Session)
15th April, 2015 (For January 2015 Session)
There are five questions in this assignment carrying 80 marks. Rest 20 marks are
for viva-voce. You may use illustrations and diagrams to enhance the explanations. Please go through the guidelines regarding assignments given in the Program Guide for the format of presentation. Assumptions made if any, should be stated.
Question: 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.
Solution:-
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 spiral’s risk assessment methodology if it’s 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
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 1st yr, 2nd yr…… 20th 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 specification:
Hardware Requirement:
Software Requirements:
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)
Platform: Windows
Operating System: Windows XP Professional SO2 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.
Solution:-
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.
Solution:-
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.
Developer’s responsibility-
The developer is responsible for:
(a) Developing the system.
(b) Installing the software on the client’s 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 Diagram for 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 Language
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 3rd 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.
Solution:-
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 Document’s 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 file—including 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 method—for 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
gurdian’s
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
R.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
gurdian’s 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
R.sukanta@g
mail.com
Good
S04
Pulak
Xyz
PO : Rdhangr
Pin : 799145
7308652583
Pulak.indraDa@
yahoo.com
Good
S04
Pulak
Xyz
PO : Rdhangr
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:
AFTER APPLYING 2NF THE TABLE WILL BE :
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
Student’s family Details Table:
Std_ID
Parents/
guardian Name
Permanent_ Address
gurdian’s 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
R.sukanta@g
mail.com
S04
Xyz
PO : Rdhangr
Pin : 799145
Pulak.indraDa@
yahoo,com
Std_Id is Key for Student’s Details table and Hence, Std_ID + Parents/ guardian Name is key for Student’s 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.
AFTER APPLYING 3NF THE TABLE WILL BE :
Std_ID
Std_Name
Health_ Report
S01
Abir Das
Good
S02
Piya
Good
S03
Sukanta
Good
S04
Pulak
Good
Name table
Std_ID
Std_Name
S01
Abir Das
S02
Piya
S03
Sukanta
S04
Pulak
Std_Health table
Std_ID
Health_Report
S01
Good
S02
Good
S03
Good
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.
Solution:-
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 student’s 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 student’s 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.
Student’s 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.
*************************************************************************************************