Motivation

I have analyzed and implemented an automated information system for manage class routine for our department. My proposed system makes easy to use the manual system. It will be able to manage class schedule of the department by modern computer. It will help to provide all the information of the class schedule and status of the department in a quicker process successfully. My project may be used as a model for the entire department.

Objectives 

We live in a world of objects. These objects exist in nature, in human made attributes, in business, and in products that we use. They can be categorized, described, organized, combined, manipulated and created. Web based technology is a new way of thinking about problems using part by part module organized around real world concepts.

I used web based technology as PHP and MySQL for database to design and develop my project proposal, Class routine management system in client server environment.

This project is designed for developing software performance the information system with at least manual intervention. The software has been designed to do informational tasks like Chairman, Teachers, Student and the Super Admin.

To analyze and design and finally implement this software I choose

• MySQL for Designing the database
• Server Side Scripting Language PHP
• HTML, CSS, Java Script and JQuery for UI Design

Methodology 

To understand system development, I need to recognize that a candidate system has a life cycle, just like a living system or a new product. System analysis and design are keyed to the system life cycle. The stages for software development are

• Recognition of need
• Feasibility Study
• Analysis
• Design
• Implementation
• Post- implementation and maintenance

The analyst must progress from one stage to another methodically, answering key questions and achieving results in each stage.

Over the years many of the best software experts have discoed and designed object oriented design techniques that raise software development and artist try to something closer to using standard engineering practices. Object oriented methodologies tend to treat development as a much more iterative process: Plan, Build, Release a version, and then repeat with refinements.

One thing that all moral methodologies have in common eases their ability to use the UML. The fact that different parts of the UML can be used for various phases of software design by almost any methodology accounts for its widespread acceptance.

 Organization of the Projects

The present work addresses the issue of Class Routine Management System of Computer Science and Engineering department of Jahangirnagar University. The goal is to manage the information through an automated system.

In chapter 2 we have discussed about Requirement Specification of Class Routine.

In chapter 3 we have discussed about Feasibility Study, System analysis and Database Design for our desired information system. This chapter includes with use case diagram, class diagram, and sequence diagram of the system.

In chapter 4, we have discussed about the Implementation Methodology and Software Testing. This chapter included with various types of technique and their testing for software development.

In chapter 5, we have discussed the Conclusion about our information system.

Requirement Specification and Class Routine Management System

  System

The term System is derived from the Greek word systema, which means an organized relationship among functioning units or components. A system exists because it is designed to achieve one or more objectives, System can be defined as: System is an orderly grouping of interdependent components linked together according to a plan to achieve a special objective. The word Components may refer to as physical parts (engines, wings of aircrafts etc) or a subsystem in a multilevel structure, a simple computer or series of intelligent terminals linked to a mainframe.

 Character of a system

The basic characteristics of a system is described by

• Organization

• Interaction

• Interdependence

• Integration

• Central Object

 Organization

Organization implies structure and order; it is the arrangement of components that helps to achieve objectives. In the design of a business system, the hierarchical relationships starting with the president on top and leading downward to the blue color worker represents the organization structure.

 Interaction

Interaction refers to the manner in which each component function with other components of the system. In on organization, purchasing must interact with production, advertising with sales and payroll with personal.

 Interdependence

It means that parts of the organization or computer system depend on one another. They are coordinate and linked together according to a plan. One subsystem depends on the input of another subsystem for proper function.

 Integration

It is concerned with how a subsystem is tied together. It means that parts of the subsystem works together within the system even though each part performs a unique function. Successful integration typical produces a synergistic effect and greater total impact than if each component works separately.

  Central Object

Objectives may be real or stated. Although a stated objective may be the real objective, it is not uncommon for an organization to state one objective and operates to achieve another. The important point is that uses must know the central objective of a computer application early in the analysis for a successful design conversion.

 Class Routine Management System

In general, the term Class Routine Management System means the system which automates any Class Schedule. The system can be both web based and as well as desktop based application. In a Class Routine management system, the teacher can choose session wise course and make schedule of his/her class. He/she also can update status of his/her class schedule. The students can view class schedule status.

The super admin can also see the all activities which are being performing in that system. Admin can add/update syllabus, semester, course, teacher information and teacher priority to place his/her schedule.

Class Routine management Systems has a number of different areas of work:

• Add/Update Syllabus information
• Add/Update Semester information
• Add/Update Course Information
• Add/Update Teacher Information
• Manage Course Allotment
• Manage Class Schedule
• Change User Password
• Forget user password

Purpose

The purpose of this application is as follows:

• The software is for automation of Class Schedule
• It provides following facilities to

 Teacher

i) Can add/update semester wise course allotment information.

ii) Can make course wise class schedule.

iii) Can update the class schedule

 Super Admin

         i) Can add/update syllabus information.

         ii) Can update, create, and delete the record of semester information

       iii) Can add/update course information

      iv)  Can set teacher priority to manage course schedule    

 Student

         i) Can view class routine.

         ii) Can view class schedule status

Scope

The difference area where we can use this application as:

• Any education institution makes use of it providing class schedule
• It can be used in offices and modifications can be easily done according to requirements.

  Technology Used

Front End: HTML, CSE, Java Script and JQuery

Back End: MySQL database and PHP as server side scripting lanaguage

 Assumptions

• This application is used to convert the manual application to the online application.

• Customized data will be used in this application.

• Students or teachers does not have right to   enter information about syllabus, course and teacher

 Overview

Project is related to Class Routine Management System which provides reading services to its members. Only the teachers and chairman of department of Computer Science and Engineering, Jahangirnagar University can manage class schedule. Students only can view class schedule.

Functionalities

i)                    Storing the syllabus, semester, course and teacher information

ii)                  Manager course allotment

iii)                Manage class schedule

iv)                Manage users

v)                  Routine view with class schedule status

vi)                Login to the system

vii)              Change Password

viii)            Forget Password

 Conclusion

I like to mention that I am going to use waterfall model, as my development methodology. I have some argument to follow this, these are

• Waterfall method is easy to make plan, because the plan is similar every time
• Waterfall method is easy to schedule the reason behind this is use the complexity of the problem and the number of developers to work out how long the development will take then divides the result by the total number of phases.
• The waterfall methodology allows us to have developers with different kinds of experience at each stage.

Feasibility Study, System Analysis and Database Design

Feasibility Study

In feasibility study phase we had undergone through various steps which are describe as under:

1. Identify the origin of the information at different level.

2. Identify the expectation of user from computerized system.

3. Analyze the drawback of existing system (manual) system.

 DRAWBACKS OF PRESENT SYSTEM

Some of the problems being faced in manual system are as follows:

1. Mange class schedule is manual process

2. Update class status is not present in system.

3. Routine view is not possible

4. Students can get updated about the class schedule

 PROPOSED SYSTEM

There will be three major components:

1. Stock maintenance.

2. Transaction entry.

3. Reports.

Proposed system provides with following solutions:

1. It provides “better and efficient” service to members.
2.  Reduce the workload of teacher and students.
3. Faster retrieval of information about the class schedule.
4. Provide facility for proper monitoring reduces paper work and provide data security.
5.  All details will be available on a click.

Data Table

Admin_tb (Admin information Table)

Course_allotment_tb (Course Allotment Table)

room_tb (Room Table)

 routine_info (Routine Table)

 teacher_tb (Teacher Table)

semester_tb (Semester Table)

 course_tb (Semester Table)

 t_day (Day Table)

 t_dayslot (Day Slot Table)

 E-R Diagram

Implementation Methodology and Software Testing

System Implementation

 I have implemented this system depends on my above analysis and database designing. To develop this system I have divided the total system in some particular modules such as user registration and login, add/update semester, course, teacher information, manage course allotment, manage schedule and view routine. These modules have been briefly discussed below.

 Login

Teacher can login into system

 Dashboard

Add/Update syllabus information

Admin like chairman can add/update syllabus information

Add/Update Semester Information

            Admin can add/update semester information by the form below.

Course List

          Admin can add/update course information by this form.

 Weekly Routine

            This module is used for view weekly routine.

Specific Routine

Class Schedule

Update Routine

Course Allotment

Testing

Software testing involves more than just running a program to see whether it works. A single test run reveals nothing about the program other than the obvious fact that it can yield results for a particular set of inputs. Software testing should be treated as an investigative exercise; one which systematically uncovers different classes of errors within the code while demonstrating that the software behaves as expected. Software testing is very much concern about two specific term validation and verification. Validation process asks the question: Are we building the right product? And on the other hand Verification process asks the question: Are we building the product right?

Implementation is the process of completing the system and turning it over to the user. The phase in the software life-cycle where the actual software is implemented. The result of this phase consists of source code, together with documentation to make the code more readable. This chapter discusses site preparation, documentation preparation, personnel training, system cutover, and system release.

The developers’ concept of the definition and objectives of software testing plays a major role in determining the efficacy of the activity. It influences the developers’ decision on what should be tested, and judgment on what is considered a `successful’ test.

For example, if the definition Software Testing is a process of proving that a program is bug free were adopted, there would be a natural tendency for developers to subconsciously write fewer or less destructive test cases with lower probabilities of breaking the program. Furthermore, the objective that this definition implies is practically impossible to achieve. It takes only one failed test to prove the existence of bugs, but requires an infinite amount of test cases to prove otherwise. Tests can only find defects, not prove that there are none.

A similarly delusive definition would be Software Testing is a process of proving that a program performs its intended function. This line of thinking often leads to test cases that focus only on program behavior that is inherently expected. However, programs that perform the right functions when given a controlled set of inputs are still erroneous if they also produce unwanted side effects or fail when given unexpected inputs. A complete test should check for both expected and unexpected behaviors, using valid as well as invalid inputs.

Myers aptly defines software testing as a process of executing a program with the intention of finding errors“. Using the analogy of a medical diagnosis, a successful investigation is one that seeks and discovers a problem, rather than one that reveals nothing and provides a false sense of well-being. Based on this definition, we establish that a good set of test cases should be one that has a high chance of uncovering previously unknown errors, while a successful test run is one that discovers these errors.

In order to detect all possible errors within a program, exhaustive testing is required to exercise all possible input and logical execution paths. Except for very trivial programs, this is economically unfeasible if not impossible. Therefore, a practical goal for software testing would be to maximize the probability of finding errors using a finite number of test cases, performed in minimum time with minimum effort.

The need of Testing

Testing is often under-valued by organizations due to a lack of understanding of its purpose within the development life cycle and the benefits it can bring to businesses. The ultimate objective to testing is to ensure that the system performs as designed and, by extension, to ensure that it meets the user’s needs. More specifically, testing is the process of exercising the system and it’s components to locate, investigate, and correct errors and bugs.

Organizations shouldn’t measure testing purely on cost and time but should look at the value it can bring. ISEB reasoning can be summarized as: ‘Software is normally written by humans, humans make mistakes, and when they make a mistake (e.g. when coding), the software is said to contain a fault (or defect or bug.) If the fault is “executed”, a failure may occur (a failure being a deviation from expectation). Testing is the process of detecting faults before software is made operational.’

It is the cost of these failures that answers the question ‘Why test?’ and this cost can be measured in many ways, for example:

• Error connecting with database;
• Loss of teachers and students information;

So, in short, testing is important to ensure that we avoid costly failures.

An information definition of testing should consider the outcomes of testing as illustrating the value it provides to the information. For example:

• Reduced risk of failures (or incidents) once systems are transferred to live operation;
• Demonstrative proof that information requirements have been met;
• Assurance that the system will function appropriately with existing legacy systems where required and will integrate with other systems as necessary;

As a rule of thumb, sufficient testing is where the costs of testing can be balanced against the potential costs of failures and over-run. The risks of failure and information benefit should be used to determine how much testing is performed.

The approach encompasses a number of standard engineering techniques to ensure effort is focused on the critical areas of any system or solution, and a major element covers tactical planning to avoid unnecessary inactivity during test execution.

Testing principles

Before applying methods to design effective test cases, a software engineer must understand the basic principles and guide software testing. Software testing is an extremely creative and intellectually challenging task. When testing follows the principles given below, the creative element of test design and execution rivals any of the preceding software development steps.

• Testing must be done by an independent party. Testing should not be performed by the person or team that developed the software since they tend to defend the correctness of the program.
• Assign best personnel to the task. Because testing requires high creativity and responsibility only the best personnel must be assigned to design, implement, and analyze test cases, test data and test results.
• Testing should not be planned under the tacit assumption that no errors will be found.
• Test for invalid and unexpected input conditions as well as valid conditions. The program should generate correct messages when an invalid test is encountered and should generate correct results when the test is valid.
• The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found.
• Testing is the process of executing software with the intent of finding errors.
• Keep software static during test. The program must not be modified during the implementation of the set of designed test cases.
• Document test cases and test results.
• Provide expected test results if possible. A necessary part of test documentation is the specification of expected results, even if providing such results is impractical.

Characteristics of Good Test

An excellent test case satisfies the following criteria:

• It has a reasonable probability of catching an error

You test to find errors. When searching for ideas for test cases, try working backwards from an idea of how the program might fail. If the program could fail in this way, how could you catch it?

• It is not redundant

If two tests look for same error, why run both?

• It’s the best of its breed

In a group of similar tests, one can be more effective than the others; you want the best of the breed, the one most likely to find the error.

• It is neither too simple nor too complex

You can save testing time by combining two or more tests into one test case. But don’t create a monster that’s too complicated to execute or understand or that takes too much time to create. It’s often more efficient to run simpler tests. Be cautious when combining invalid inputs. After rejecting the first invalid value, the program might ignore all other further input, valid or not. At some point, you might want to combine error cases to see what the program does when confronted with many disasters at once. However, you should start with simple tests to check each of the program’s error-handling capabilities on its own.

Testing Techniques

Because of the fallibility of its human designers and its own abstract, complex nature, software development must be accompanied by quality assurance activities. It is not unusual for developers to spend 40% of the total project time on testing. For life-critical software (e.g. flight control, reactor monitoring), testing can cost 3 to 5 times as much as all other activities combined. The destructive nature of testing requires that the developer discard preconceived notions of the correctness of his/her developed software.

 White Box Testing

White box testing is a test case design method that uses the control structure of the procedural design to derive test cases. Test cases can be derived that

• Guarantee that all independent paths within a module have been exercised at least once,
• Exercise all logical decisions on their true and false sides,
• Execute all loops at their boundaries and within their operational bounds, and
• Exercise internal data structures to ensure their validity.

 The Nature of Software Defects

Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. General processing tends to be well understood while special case processing tends to be prone to errors.

We often believe that a logical path is not likely to be executed when it may be executed on a regular basis. Our unconscious assumptions about control flow and data lead to design errors that can only be detected by path testing.

Typographical errors are random.

Basis Path Testing

This method enables the designer to derive a logical complexity measure of a procedural design and use it as a guide for defining a basis set of execution paths. Test cases that exercise the basis set are guaranteed to execute every statement in the program at least once during testing.

Flow Graphs

Flow graphs can be used to represent control flow in a program and can help in the derivation of the basis set. Each flow graph node represents one or more procedural statements. The edges between nodes represent flow of control. An edge must terminate at a node, even if the node does not represent any useful procedural statements. A region in a flow graph is an area bounded by edges and nodes. Each node that contains a condition is called a predicate node. Cyclomatic complexity is a metric that provides a quantitative measure of the logical complexity of a program. It defines the number of independent paths in the basis set and thus provides an upper bound for the number of tests that must be performed.

The Basis Set

• An independent path is any path through a program that introduces at least one new set of processing statements (must move along at least one new edge in the path). The basis set is not unique. Any number of different basis sets can be derived for a given procedural design.

 Automating Basis Set Derivation

The derivation of the flow graph and the set of basis paths are amenable to automation. A software tool to do this can be developed using a data structure called a graph matrix. A graph matrix is a square matrix whose size is equivalent to the number of nodes in the flow graph. Each row and column corresponds to a particular node and the matrix corresponds to the connections (edges) between nodes. By adding a link weight to each matrix entry, more information about the control flow can be captured. In its simplest form, the link weight is 1 if an edge exists and 0 if it does not. But other types of link weights can be represented:

• The probability that an edge will be executed,
• The processing time expended during link traversal,
• The memory required during link traversal, or
• The resources required during link traversal.

Graph theory algorithms can be applied to these graph matrices to help in the analysis necessary to produce the basis set.

Loop Testing

This white box technique focuses exclusively on the validity of loop constructs. Four different classes of loops can be defined:

• Simple loops,
• Nested loops,
• Concatenated loops, and
• Unstructured loops.

Simple Loops

The following tests should be applied to simple loops where n is the maximum number of allowable passes through the loop:

• Skip the loop entirely,
• Only pass once through the loop,
• m passes through the loop where m < n,
• n – 1, n, n + 1 passes through the loop.

Nested Loops

The testing of nested loops cannot simply extend the technique of simple loops since this would result in a geometrically increasing number of test cases. One approach for nested loops:

• Start at the innermost loop. Set all other loops to minimum values.
• Conduct simple loop tests for the innermost loop while holding the outer loops at their minimums. Add tests for out-of-range or excluded values.
• Work outward, conducting tests for the next loop while keeping all other outer loops at minimums and other nested loops to typical values.
• Continue until all loops have been tested.

Concatenated Loops

Concatenated loops can be tested as simple loops if each loop is independent of the others. If they are not independent (e.g. the loop counter for one is the loop counter for the other), then the nested approach can be used.

Unstructured Loops

This type of loop should be redesigned not tested!!!

Other White Box Techniques

Other white box testing techniques include:

• Condition testing

• Exercises the logical conditions in a program.
• Selects test paths according to the locations of definitions and uses of variables in the program.

• Data flow testing

Black Box Testing

Black box testing attempts to derive sets of inputs that will fully exercise all the functional requirements of a system. It is not an alternative to white box testing. This type of testing attempts to find errors in the following categories:

• Incorrect or missing functions,
• Interface errors,
• Errors in data structures or external database access,
• Performance errors, and
• Initialization and termination errors.

Tests are designed to answer the following questions:

• How is the function’s validity tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system tolerate?
• What effect will specific combinations of data have on system operation?

White box testing should be performed early in the testing process, while black box testing tends to be applied during later stages. Test cases should be derived which

• Reduce the number of additional test cases that must be designed to achieve reasonable testing, and
• Tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

Equivalence Partitioning

This method divides the input domain of a program into classes of data from which test cases can be derived. Equivalence partitioning strives to define a test case that uncovers classes of errors and thereby reduces the number of test cases needed. It is based on an evaluation of equivalence classes for an input condition. An equivalence class represents a set of valid or invalid states for input conditions.

Equivalence classes may be defined according to the following guidelines:

• If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
• If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.
• If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined.
• If an input condition is Boolean, then one valid and one invalid equivalence class are defined.

Boundary Value Analysis

• This method leads to a selection of test cases that exercise boundary values. It complements equivalence partitioning since it selects test cases at the edges of a class.

Conclusion

The project presents the work on Class Routine Management System of for The Department of C.S.E., JU.  I analyzed a designed the manual. By this technique I find out the actors, and database design for the system which is more accurate for my environment.

For coding the system I use PHP for server side scripting and HTML, CSS, Java Script and JQuery for UI design. I used MySQL for my database structure.

The proposed system will reduce the time and labor used in the current manual system.

It would be able to save the valuable information. My proposed system will cover the entire department. I think my proposed system will play a very efficient and also vital role on the department system. It is natural that the creation of an efficient system will lead to the desire of creating more efficient alternative one.

Further development

The developing software is good quality software. I am trying my best to satisfy the actual need of the department system. But there is always scope for further development. I have implemented the software and try my level best to deliver an excellent system though it has some bug it will try to recover them Insha- Allah.

References

• www.wikipedia.org
• Ian Sommerville, “Software Engineering”, Third edition, Pearson Education Singapore, 2006.
• Information system consultants handbook systems analysis and design – William S. Davis, David C. Yen, PRC Press, Washington DC, USA, 1999.
• Roger S Pressman, “Software Engineering A practical approach”, Fifth Edition, The McGraw-Hill Company, New York, USA, 2001.
• Version 1.1 is available on the internet for review and comments URL http://www.rational.com/uml
• NCC Education Services Limited, 1998:’Software Engineering Methods (Unit2)
• Roger S. Pressman, Ph. D.: ‘Software Engineering’ 1997 (4^th edition).
• Abraham Silberschatz, Henry F. Korth, S. Sudarshar: ‘Database System Concepts’, The Macgraw- Hill Companies, Inc, 1997 (3^rd Edition).
• Engineer’s Councile of Information Technology: ‘RDMS CONCEPTS’
• Pierre- Alain: ‘Instant UML’, Wrox Press Ltd. URL http://www.uml.com
• ‘Fundamentals of Object- Oriented Design in UML’ Meilir Page- Jones, Addison- Wesley, 2000, ISBN 0- 201- 69946- X.