A

PROJECT REPORT ON

TIME TABLE GENERATOR

Submitted in partial fulfillment of the requirement of UTTARAKHAND TECHNICAL UNIVERSITY, DEHRADUN For the degree of B.Tech In INFORMATION TECHNOLOGY

Submitted by ANISHA VERMA(07070103014) HARSHITA RAI( 98070103123) ANKITA ASWAL(07070104017) DIVYA SHARMA(07070106019)

Under the Guidance of Ms. ENA JAIN ASSISTANT PROFESSOR DEPARTMENT OF IT

DEPARTMENT OF INFORMATION TECHNOLOGY DEHRADUN INSTITUTE OF TECHNOLOGY Dehradun MAY 2011

A Project report on TIME TABLE GENERATOR

Submitted in partial fulfillment of the requirement of Uttarakhand Technical University, Dehradun for the degree of B.Tech. In Information Technology
Submitted by: Anisha Verma (07070103014) Harshita Rai (98070103123 Ankita Aswal (07070104017) Divya Sharma(07070106019) Under the Supervision of:Ms. Ena Jain Assistant Professor Department Of IT

Information Technology Department DEHRADUN INSTITUTE OF TECHNOLOGY DEHRADUN (UTTARAKHAND) MAY 2011

ACKNOWLEDGEMENT

It is a great pleasure to have the opportunity to extend our heartiest felt gratitude to everybody who helped us throughout the course of this project. It is distinct pleasure to express our deep sense of gratitude and indebtedness to our learned supervisor Ms. Ena Jain, Assistant Professor ,for their invaluable guidance, encouragement and patient reviews. With their continuous inspiration only, it becomes possible to complete this Project. We would also like to take this opportunity to present our sincere regards to our teachers Mr. G. P Saroha(HOD), Mr. Vivudh Fore for their support and encouragement.

We would also like to thank all the faculty members of the Department for their support and encouragement.

ANISHA VERMA(07070103014) HARSHITA RAI(98070103123) ANKITA ASWAL(07070104017) DIVYA SHARMA(07070106019)

CERTIFICATE
This is to certify that Project Report entitled TIME TABLE GENERATOR which is submitted by following students in partial fulfillment of the requirement for the award of degree B.Tech. In Computer Science and Engineering to Uttarakhand Technical University, Dehradun is a record of the candidates own work carried out by them under my supervision. The matter embodied in this report is original and has not been submitted for the award of any other degree.

ANISHA VERMA HARSHITA RAI ANKITA ASWAL DIVYA SHARMA

07070103014 98070103123 07070104017 07070106019

HOD: Prof. G.P. Saroha Deptt. Of IT Dehradun Institute of Technology Dehradun

Supervisor/Guide: Ms. ENA JAIN Deptt. Of CSE/IT Dehradun Institute of Technology Dehradun

Table of Contents

1. ABSTRACT 2. INTRODUCTION 2.1 Brief Overview 2.2 Objective of the Project 3. SYSTEM FEATURES 3.1 Feature & Scope of Old and New System 3.2 Benefit of Proposed System 3.3 Team Structure 3.4 Hardware & Software Requirements 4. FEASIBILITY STUDY 4.1 Economic Feasibility 4.2 Technical Feasibility 4.3 Operational Feasibility 5. SYSTEM ANALYSIS & DATA FLOW DIAGRAMS 5.1 Existing System 5.2 Proposed System 5.3 Data Flow Diagram 6. SYSTEM DESIGN

6.1 System Flow Chart 6.2 Database Design 7. GRAPHICAL USER INTERFACE 8. SYSTEM TESTING

9. IMPLEMENTATION & TESTING 10. CONCLUSION 11. REFERENCES 12.APPENDIX

ABSTRACT

The project called Time Table Generator is a software for generating conflict free time tables. This project is aimed at developing a Time Table Generator for Colleges. Colleges are supposed to make time tables for each semester which used to be a very tedious and pain staking job. Each teacher and Student is eligible for viewing his own timetable once they are finalized for a given semester but they can not edit them.

This timetable generator is a semi automatic time table scheduling software. The manual method of generating time table is very cumbersome and requires a lot of time and not even completely removes all the conflicts . this project will be generating time tables that will ensure the conlict free allocation of subjects assigned to various faculties.

This project will be suitable from the security point of view as well. The project differentiates between users on the basis of their designation. Only the administrator will be having the authority to create the timetable and faculties and students will only be viewing the time table. We provide another facility to export the generated time table to ms excel from where it can be printed.

SYSTEM FEATURES

FEATURE AND SCOPE OF OLD AND NEW SYSTEM The manual method of generating time table is very cumbersome and requires a lot of time and not even completely removes all the conflicts. This was about the old system. The new system will be generating time tables semi-automatically that will ensure the conflict free allocation of subjects assigned to various faculties. The system includes the administrative login as well as the student login. Through the student login we can only view the timetable which has been generated, whereas through the administrative login, the faculty and the administrative block can login where the various functions can be performed. The faculty members are given a provision to register themselves and view the timetable. If required, they can request for changing the lecture timings also. The work of the administrative block is to keep a track of all the registered faculty members, assign them the subjects, and generate the timetable for various sections of students.they also accept the requests made by the faculty members and make changes as per the requirements so that still there is no conflict in the timetable generated. Since all the timetables are generated manually in the college, the college can use this project to generate the timetable semi-automatically, by reducing the chances of conflicts of any kind.

BENEFITS OF PROPOSED SYSTEM The first and foremost benefit of the proposed system is that it is useful for the college administrative authorities The generation of the timetable will be fast. The timetable will be accurate. The system will provide error-free timetable without any conflicts. The resources can be used else-where since the time table will be generated within few seconds. The faculty members have the provision of sending request for changing the time table according to the timing that best suits them. The proposed system is extensible; i.e. it can be extended to generate the time table for as many branches as required.

FEASIBILITY STUDY

Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest term, the two criteria to judge feasibility are cost required and value to be attained. As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, accounting statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations. Generally, feasibility studies precede technical development and project implementation.

Five common factors (TELOS)

Technology and system feasibility
The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project when writing a feasibility report, the following should be taken to consideration:

A brief description of the business The part of the business being examined The human and economic factor The possible solutions to the problems

At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost).

Economic feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. An entrepreneur must accurately weigh the cost versus benefits before taking an action. Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system. Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor.

Legal feasibility
Determines whether the proposed system conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts.

Operational feasibility
Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.

Schedule feasibility
A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Some projects are initiated with specific deadlines. You need to determine whether the deadlines are mandatory or desirable.

Other feasibility factors

Market and real estate feasibility

Market Feasibility Study typically involves testing geographic locations for a real estate development project, and usually involves parcels of real estate land. Developers often conduct market studies to determine the best location within a jurisdiction, and to test alternative land uses for given parcels. Jurisdictions often require developers to complete feasibility studies before they will approve a permit application for retail, commercial, industrial, manufacturing, housing, office or mixed-use project. Market Feasibility takes into account the importance of the business in the selected area.

Resource feasibility
This involves questions such as how much time is available to build the new system, when it can be built, whether it interferes with normal business operations, type and amount of resources required, dependencies,

Cultural feasibility
In this stage, the project's alternatives are evaluated for their impact on the local and general culture. For example, environmental factors need to be considered and these factors are to be well known. Further an enterprise's own culture can clash with the results of the project.

Financial feasibility
In case of a new project,financial viability can be judged on the following parameters:

Total estimated cost of the project Financing of the project in terms of its capital structure, debt equity ratio and promoter's share of total cost

Existing investment by the promoter in any other business Projected cash flow and profitability

ECONOMIC FEASIBILITY STUDY

Feasibility studies are crucial during the early development of any project and form a vital component in the business development process. Accounting and Advisory feasibility studies enable organizations to assess the viability, cost and benefits of projects before financial resources are allocated. They also provide independent project assessment and enhance project credibility. Built on the information provided in the feasibility study, a business case is used to convince the audience that a particular project should be implemented. It is often a prerequisite for any funding approval. The business case will detail the reasons why a particular project should be prioritized higher than others. It will also sum up the strengths, weaknesses and validity of assumptions as well as assessing the financial and non-financial costs and benefits underlying preferred options. For any system if the expected benefits equal or exceed the expected costs, the system can be judged to be economically feasible. In economic feasibility, cost benefit analysis is done in which expected costs and benefits are evaluated. Economic analysis is used for evaluating the effectiveness of the proposed system. In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an analysis of the costs to be incurred in the system and benefits derivable out of the system. Click on the link below which will get you to the page that explains what cost benefit analysis is and how you can perform a cost benefit analysis. A Deloitte feasibility study can help your organization to:

Define the business requirements that must be met by the selected project and include the critical success factors for the project

Detail alternative approaches that will meet business requirements, including comparative cost/benefit and risk analyses

Recommend the best approach for preparing a business case or moving through the implementation process

Our feasibility studies and business cases can help you answer crucial questions such as:

Have the alternatives been carefully, thoroughly and objectively examined? What are the consequences of each choice on all relevant areas?

What are the results of any cost/benefit studies? What are the costs and consequences of no action? What are the impacts on the various interest groups? What are the timelines for decisions? Are the consequences displayed to make comparisons easier?

Cost Benefit Analysis:

Developing an IT application is an investment. Since after developing that application it provides the organization with profits. Profits can be monetary or in the form of an improved working environment. However, it carries risks, because in some cases an estimate can be wrong. And the project might not actually turn out to be beneficial. Cost benefit analysis helps to give management a picture of the costs, benefits and risks. It usually involves comparing alternate investments. Cost benefit determines the benefits and savings that are expected from the system and compares them with the expected costs. The cost of an information system involves the development cost and maintenance cost. The development costs are one time investment whereas maintenance costs are recurring. The development cost is basically the costs incurred during the various stages of the system development. Each phase of the life cycle has a cost. Some examples are :

Personnel Equipment Supplies Overheads Consultants' fees

Cost and Benefit Categories

In performing Cost benefit analysis (CBA) it is important to identify cost and benefit factors. Cost and benefits can be categorized into the following categories. There are several cost factors/elements. These are hardware, personnel, facility, operating, and supply costs. In a broad sense the costs can be divided into two types
1. Development costs-

Development costs that are incurred during the development of the system are one time investment.

Wages Equipment 2. Operating costs,

e.g. , Wages Supplies Overheads Another classification of the costs can be:
Hardware/software costs:

It includes the cost of purchasing or leasing of computers and it's peripherals. Software costs involves required software costs.
Personnel costs:

It is the money, spent on the people involved in the development of the system. These expenditures include salaries, other benefits such as health insurance, conveyance allowance, etc.
Facility costs:

Expenses incurred during the preparation of the physical site where the system will be operational. These can be wiring, flooring, acoustics, lighting, and air conditioning.

Operating costs:

Operating costs are the expenses required for the day to day running of the system. This includes the maintenance of the system. That can be in the form of maintaining the hardware or application programs or money paid to professionals responsible for running or maintaining the system.
Supply costs:

These are variable costs that vary proportionately with the amount of use of paper, ribbons, disks, and the like. These should be estimated and included in the overall cost ofthe system.

Benefits
We can define benefit as Profit or Benefit = Income - Costs Benefits can be accrued by : - Increasing income, or - Decreasing costs, or - both The system will provide some benefits also. Benefits can be tangible or intangible, direct or indirect. In cost benefit analysis, the first task is to identify each benefit and assign a monetary value to it. The two main benefits are improved performance and minimized processing costs. Further costs and benefits can be categorized as
Tangible or Intangible Costs and Benefits

Tangible cost and benefits can be measured. Hardware costs, salaries for professionals, software cost are all tangible costs. They are identified and measured.. The purchase of hardware or software, personnel training, and employee salaries are example of tangible costs. Costs whose value cannot be measured are referred as intangible costs. The cost of breakdown of an online system during banking hours will cause the bank lose deposits.

Benefits are also tangible or intangible. For example, more customer satisfaction, improved company status, etc are all intangible benefits. Whereas improved response time, producing error free output such as producing reports are all tangible benefits. Both tangible and intangible costs and benefits should be considered in the evaluation process.
Direct or Indirect Costs and Benefits

From the cost accounting point of view, the costs are treated as either direct or indirect. Direct costs are having rupee value associated with it. Direct benefits are also attributable to a given project. For example, if the proposed system that can handle more transactions say 25% more than the present system then it is direct benefit. Indirect costs result from the operations that are not directly associated with the system. Insurance, maintenance, heat, light, air conditioning are all indirect costs.
Fixed or Variable Costs and Benefits

Some costs and benefits are fixed. Fixed costs don't change. Depreciation of hardware, Insurance, etc are all fixed costs. Variable costs are incurred on regular basis. Recurring period may be weekly or monthly depending upon the system. They are proportional to the work volume and continue as long as system is in operation. Fixed benefits don't change. Variable benefits are realized on a regular basis.

TECHNICAL FEASIBILITY
A feasibility study is an important phase in the development of business related services. The need for evaluation is great especially in large high-risk information service development projects. A feasibility study focuses in the study of the challenges, technical problems and solution models of information service realisation, analyses the potential solutions to the problems against the requirements, evaluates their ability to meet the goals and describes and rationalises the recommended solution. The term technical feasibility establishes that the product or service can operate in the desired manner. Technical feasibility means achievable. This has to be proven without building the system. The proof is defining a comprehensive number of technical options that are feasible within known and demanded resources and requirements. These options should cover all technical sub-areas. The goal of a feasibility study is to outline and clarify the things and factors

connected to the technical realisation of a information service system. It is good to outline, recognise and possibly solve these things before the actual design and realisation. Other goals for feasibility studies are: Produce sufficient information: Is the development project technically feasible? Produce base data for the requirement definition phase. E.g. what technical requirements does the production of the service place on the clients current technology i.e. help direct research and development investments to right things. What are the realisation alternatives? Is there a recommended realisation alternative? Evaluation answers: The evaluation of technical feasibility tries to answer whether the desired information service is feasible and what are the technical matters connected to the feasibility: Technical feasibility from the organisation viewpoint. How practical is the technical solution? The availability of technical resources and know-how? The evaluation backs the selection of the most suitable technical alternative. The feasibility study is a critical document defining the original system concepts, goals, requirements and alternatives. The study also forms the framework for the system development project and creates a baseline for further studies. The evaluation process can be utilised at different stages of an information service development project: At the beginning of an information service development project: evaluation of the technical feasibility of the desired information service and the implementation alternatives based on the available information. Usually a more concise evaluation. At the beginning of an information service development project alongside requirement definition (and partly after): Produces data for requirement definition and utilises the data produced by the requirement definition process. A more demanding and in-depth evaluation process.

The evaluation of the technical feasibility of an information system produces information and answers e.g. the following points: Definitions of feasible alternatives for information service system design and development. Identifies, raises and clarifies issues connected to the technical implementation of an information system. Produces data for requirement definition i.e. complements and utilises the information service requirement definition. The feasibility evaluation studies the information system from different viewpoints: Technical feasibility Financial feasibility Operational feasibility The other modules connected to the Technical feasibility module are thus: Markets and foresight (technology foresight, mega-trends) Risk analyses (reliability, technical risks (?)) Revenue and finance (economical profitability and project feasibility) In technical feasibility the following issues are taken into consideration.

Whether the required technology is available or not Whether the required resources are available -

- Manpower- programmers, testers & debuggers

- Software and hardware Once the technical feasibility is established, it is important to consider the monetary factors also. Since it might happen that developing a particular system may be technically possible but it may require huge investments and benefits may be less. For evaluating this, economic feasibility of the proposed system is carried out.

OPERATIONAL FEASIBILITY

Not only must an application make economic and technical sense, it must also make operational sense. The basic question that you are trying to answer is Is it possible to maintain and support this application once it is in production? Building an application is decidedly different than operating it, therefore you need to determine whether or not you can effectively operate and support it. TABLE below summarizes critical issues which you should consider. Issues to consider when determining the operational feasibility of a project. Operations Issues Support Issues

What documenta tion will users be given?

What tools are needed to support operations?

What skills will operators need to be trained in?

What training will users be given?

What processes need to be created and/or updated?

How will change requests be managed?

What documentation does operations need?

Very often you will need to improve the existing operations, maintenance, and support infrastructure to support the operation of the new application that you intend to develop. To determine what the impact will be you will need to understand both the current operations and support infrastructure of your organization and the operations and support characteristics of your new application. If the existing operations and support infrastructure can handle your

application, albeit with the appropriate training of the affected staff, then your project is operationally feasible. The operational feasibility parameters are:

Does this project require some investment in tools, skill levels, hiring, infrastructures? Do we have the right mix of team to take up this project? Is there any time zone advantage? Did we anticipate any operational risk like staffing, people leaving the company in the middle of the project?

Identify the anticipated impact on customer satisfaction, retention, and loyalty? Based on this the operational feasibility of the project is checked and the score is generated.

SYSTEM ANALYSIS AND DATA FLOW DIAGRAMS

EXISTING SYSTEM:
every college or institution requires time tables and the manual generation of time table is quite a cumbersome task and requires lot of sharp observation and time. Thus far, the time tables are generated manually, so, this project is aimed at developing a system that will generate a time table semi automatically which will be conflict free and thus replace the existing system of manual time table generation with a time table generator. Their must have been other time table generators too but this project that we have completed is quite customised for use in our institution specially.

PROPOSED SYSTEM: INTRODUCTION TO THE PROPOSED SYSTEM:

Time Table generator is revolutionary software which helps in reducing human efforts in generating time table. It not only helps in managing time schedule but also helps in allocating the classes and laboratories. It makes the work of time table generation error free and accurate. It is a powerful software tool not only for the management but also for students. It gives benefit to: administrator, the head of concerned department, faculty and students. It is an organizational based software which helps in maintain the time management in the organization and helps faculty and students.

ABOUT THE TECHNOLOGY USED

ASP.NET is a web application framework developed and marketed by Microsoft to allow programmers to build dynamic web sites, web applications and web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages.

Characteristics
PAGES ASP.NET web pages or webpage, known officially as "web forms", are the main building block for application development. Web forms are contained in files with an ".aspx" extension; these files typically contain static (X)HTML markup, as well as markup defining server-side Web Controls and User Controls where the developers place all the required static and dynamic content for the web page. Additionally, dynamic code which runs on the server can be placed in a page within a block <% -- dynamic code -- %>, which is similar

to other web development technologies such as PHP, JSP, and ASP. With ASP.NET Framework 2.0, Microsoft introduced a new code-behind model which allows static text to remain on the .aspx page, while dynamic code remains in an .aspx.vb or .aspx.cs file (depending on the programming language used). CODE BEHIND MODEL Microsoft recommends dealing with dynamic program code by using the code-behind model, which places this code in a separate file or in a specially designated script tag. Code-behind files typically have names like MyPage.aspx.cs or MyPage.aspx.vb while the page file is MyPage.aspx (same filename as the page file (ASPX), but with the final extension denoting the page language). This practice is automatic in Microsoft Visual Studio and other IDEs. When using this style of programming, the developer writes code to respond to different events, like the page being loaded, or a control being clicked, rather than a procedural walk through of the document. ASP.NET's code-behind model marks a departure from Classic ASP in that it encourages developers to build applications with separation of presentation and content in mind. In theory, this would allow a web designer, for example, to focus on the design markup with less potential for disturbing the programming code that drives it. This is similar to the separation of the controller from the view in ModelViewController (MVC) frameworks. DIRECTIVES A directive is special instructions on how ASP.NET should process the pages. The most common directive is <%@ Page %> which can specify many things, such as which programming language is used for the server-side code. USER CONTROLS User controls are encapsulations of sections of pages which are registered and used as controls in ASP.NET. User controls are created as ASCX markup files. These files usually contain static (X)HTML markup, as well as markup defining server-side web controls. These are the locations where the developer can place the required static and dynamic content. A user control is compiled when its containing page is requested and is stored in memory for subsequent requests. User controls have their own events which are handled during the life of ASP.NET requests. An event bubbling mechanism provides the ability to pass an event fired

by a user control up to its containing page. Unlike an ASP.NET page, a user control cannot be requested independently; one of its containing pages is requested instead. CUSTOM CONTROLS Programmers can also build custom controls for ASP.NET applications. Unlike user controls, these controls do not have an ASCX markup file, having all their code compiled into a dynamic link library (DLL) file. Such custom controls can be used across multiple web applications and Visual Studio projects RENDERING TECHNIQUE ASP.NET uses a visited composites rendering technique. During compilation, the template (.aspx) file is compiled into initialization code which builds a control tree (the composite) representing the original template. Literal text goes into instances of the Literal control class, and server controls are represented by instances of a specific control class. The initialization code is combined with user-written code (usually by the assembly of multiple partial classes) and results in a class specific for the page. The page doubles as the root of the control tree. Actual requests for the page are processed through a number of steps. First, during the initialization steps, an instance of the page class is created and the initialization code is executed. This produces the initial control tree which is now typically manipulated by the methods of the page in the following steps. As each node in the tree is a control represented as an instance of a class, the code may change the tree structure as well as manipulate the properties/methods of the individual nodes. Finally, during the rendering step a visitor is used to visit every node in the tree, asking each node to render itself using the methods of the visitor. The resulting HTML output is sent to the client. After the request has been processed, the instance of the page class is discarded and with it the entire control tree. This is a source of confusion among novice ASP.NET programmers who rely on class instance members that are lost with every page request/response cycle. STATE MANAGEMENT ASP.NET applications are hosted by a web server and are accessed using the stateless HTTP protocol. As such, if an application uses stateful interaction, it has to implement state

management on its own. ASP.NET provides various functions for state management. Conceptually, Microsoft treats "state" as GUI state. Problems may arise if an application needs to keep track of "data state"; for example, a finite state machine which may be in a transient state between requests (lazy evaluation) or which takes a long time to initialize. State management in ASP.NET pages with authentication can make Web scraping difficult or impossible. APPLICATION STATE Application state is held by a collection of shared user-defined variables. These are set and initialized when the Application_OnStart event fires on the loading of the first instance of the application and are available until the last instance exits. Application state variables are accessed using the Applications collection, which provides a wrapper for the application state. Application state variables are identified by name. SESSION STATE Server-side session state is held by a collection of user-defined session variables that are persistent during a user session. These variables, accessed using the Session collection, are unique to each session instance. The variables can be set to be automatically destroyed after a defined time of inactivity even if the session does not end. Client-side user session is maintained by either a cookie or by encoding the session ID in the URL itself. ASP.NET supports three modes of persistence for server-side session variables.
In-Process Mode The session variables are maintained within the ASP.NET process. This is the fastest way; however, in this mode the variables are destroyed when the ASP.NET process is recycled or shut down. ASPState Mode ASP.NET runs a separate Windows service that maintains the state variables. Because state management happens outside the ASP.NET process, and because the ASP.NET engine accesses data using .NET Remoting, ASPState is slower than In-Process. This mode allows an ASP.NET application to be load-balanced and scaled across multiple servers. Because the

state management service runs independently of ASP.NET, the session variables can persist across ASP.NET process shutdowns. However, since session state server runs as one instance, it is still one point of failure for session state. The session-state service cannot be load-balanced, and there are restrictions on types that can be stored in a session variable. SqlServer Mode State variables are stored in a database, allowing session variables to be persisted across ASP.NET process shutdowns. The main advantage of this mode is that it allows the application to balance load on a server cluster, sharing sessions between servers. This is the slowest method of session state management in ASP.NET.

VIEW STATE View state refers to the page-level state management mechanism, utilized by the HTML pages emitted by ASP.NET applications to maintain the state of the web form controls and widgets. The state of the controls is encoded and sent to the server at every form submission in a hidden field known as __VIEWSTATE. The server sends back the variable so that when the page is re-rendered, the controls render at their last state. At the server side, the application may change the viewstate, if the processing requires a change of state of any control. The states of individual controls are decoded at the server, and are available for use in ASP.NET pages using the ViewState collection. The main use for this is to preserve form information across postbacks. View state is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a postback. This behavior can (and should) be modified, however, as View state can be disabled on a per-control, per-page, or server-wide basis. Developers need to be wary of storing sensitive or private information in the View state of a page or control, as the base64 string containing the view state data can easily be de-serialized. By default, View state does not encrypt the __VIEWSTATE value. Encryption can be enabled on a server-wide (and server-specific) basis, allowing for a certain level of security to be maintained.

SERVER SIDE CACHING ASP.NET offers a "Cache" object that is shared across the application and can also be used to store various objects. The "Cache" object holds the data only for a specified amount of time and is automatically cleaned after the session time-limit elapses.
OTHER:

Other means of state management that are supported by ASP.NET are cookies, caching, and using the query string.
TEMPLATE ENGINE

When first released, ASP.NET lacked a template engine. Because the .NET Framework is object-oriented and allows for inheritance, many developers would define a new base class that inherits from "System.Web.UI.Page", write methods there that render HTML, and then make the pages in their application inherit from this new class. While this allows for common elements to be reused across a site, it adds complexity and mixes source code with markup. Furthermore, this method can only be visually tested by running the application - not while designing it. Other developers have used include files and other tricks to avoid having to implement the same navigation and other elements in every page. ASP.NET 2.0 introduced the concept of "master pages", which allow for template-based page development. A web application can have one or more master pages, which, beginning with ASP.NET 2.0, can be nested. Master templates have place-holder controls, called ContentPlaceHolders to denote where the dynamic content goes, as well as HTML and JavaScript shared across child pages. Child pages use those ContentPlaceHolder controls, which must be mapped to the placeholder of the master page that the content page is populating. The rest of the page is defined by the shared parts of the master page, much like a mail merge in a word processor. All markup and server controls in the content page must be placed within the ContentPlaceHolder control. When a request is made for a content page, ASP.NET merges the output of the content page with the output of the master page, and sends the output to the user.

The master page remains fully accessible to the content page. This means that the content page may still manipulate headers, change title, configure caching etc. If the master page exposes public properties or methods (e.g. for setting copyright notices) the content page can use these as well.
DIRECTORY STRUCTURE

In general, the ASP.NET directory structure can be determined by the developer's preferences. Apart from a few reserved directory names, the site can span any number of directories. The structure is typically reflected directly in the URLs. Although ASP.NET provides means for intercepting the request at any point during processing, the developer is not forced to funnel requests through a central application or front controller. The special directory names (from ASP.NET 2.0 on) are: App_Code
This is the "raw code" directory. The ASP.NET server automatically compiles files (and subdirectories) in this folder into an assembly which is accessible in the code of every page of the site. App_Code will typically be used for data access abstraction code, model code and business code. Also any site-specific http handlers and modules and web service implementation go in this directory. As an alternative to using App_Code the developer may opt to provide a separate assembly with precompiled code. App_Data default directory for databases, such as Access mdb files and SQL Server mdf files. This directory is usually the only one with write access for the application. App_LocalResources E.g. a file called CheckOut.aspx.fr-FR.resx holds localized resources for the French version of the CheckOut.aspx page. When the UI culture is set to French, ASP.NET will automatically find and use this file for localization. App_GlobalResources

Holds resx files with localized resources available to every page of the site. This is where the ASP.NET developer will typically store localized messages etc. which are used on more than one page. App_Themes Adds a folder that holds files related to themes which is a new ASP.NET feature that helps ensure a consistent appearance throughout a Web site and makes it easier to change the Web sites appearance when necessary. App_WebReferences holds discovery files and WSDL files for references to web services to be consumed in the site. Bin Contains compiled code (.dll files) for controls, components, or other code that you want to reference in your application. Any classes represented by code in the Bin folder are automatically referenced in your application.

PERFORMANCE ASP.NET aims for performance benefits over other script-based technologies (including Classic ASP) by compiling the server-side code to one or more DLL files on the web server.This compilation happens automatically the first time a page is requested (which means the developer need not perform a separate compilation step for pages). This feature provides the ease of development offered by scripting languages with the performance benefits of a compiled binary. However, the compilation might cause a noticeable but short delay to the web user when the newly-edited page is first requested from the web server, but will not again unless the page requested is updated further. The ASPX and other resource files are placed in a virtual host on an Internet Information Services server (or other compatible ASP.NET servers; see Other implementations, below). The first time a client requests a page, the .NET Framework parses and compiles the file(s) into a .NET assembly and sends the response; subsequent requests are served from the DLL files. By default ASP.NET will compile the entire site in batches of 1000 files upon first

request. If the compilation delay is causing problems, the batch size or the compilation strategy may be tweaked. Developers can also choose to pre-compile their "codebehind" files before deployment, using MS Visual Studio, eliminating the need for just-in-time compilation in a production environment. This also eliminates the need of having the source code on the web server. EXTENSION Microsoft has released some extension frameworks that plug into ASP.NET and extend its functionality. Some of them are:
ASP.NET AJAX An extension with both client-side as well as server-side components for writing ASP.NET pages that incorporate AJAX functionality. ASP.NET MVC Framework An extension to author ASP.NET pages using the MVC architecture.

ASP.NET compared with ASP classic

ASP.NET simplifies developers' transition from Windows application development to web development by offering the ability to build pages composed of controls similar to a Windows user interface. A web control, such as a button or label, functions in very much the same way as its Windows counterpart: code can assign its properties and respond to its events. Controls know how to render themselves: whereas Windows controls draw themselves to the screen, web controls produce segments of HTML and JavaScript which form parts of the resulting page sent to the end-user's browser. ASP.NET encourages the programmer to develop applications using an event-driven GUI model, rather than in conventional web-scripting environments like ASP and PHP. The framework combines existing technologies such as JavaScript with internal components like "ViewState" to bring persistent (inter-request) state to the inherently stateless web environment. Other differences compared to ASP classic are:

Compiled code means applications run faster with more design-time errors trapped at the development stage.

Significantly improved run-time error handling, making use of exception handling using trycatch blocks.

Similar metaphors to Microsoft Windows applications such as controls and events. An extensive set of controls and class libraries allows the rapid building of applications, plus user-defined controls allow commonly-used web template, such as menus. Layout of these controls on a page is easier because most of it can be done visually in most editors.

ASP.NET uses the multi-language abilities of the .NET Common Language Runtime, allowing web pages to be coded in VB.NET, C#, J#, Delphi.NET, Chrome, etc.

Ability to cache the whole page or just parts of it to improve performance. Ability to use the code-behind development model to separate business logic from presentation.

Ability to use true object-oriented design for programming pages and controls If an ASP.NET application leaks memory, the ASP.NET runtime unloads the AppDomain hosting the erring application and reloads the application in a new AppDomain.

Session state in ASP.NET can be saved in a Microsoft SQL Server database or in a separate process running on the same machine as the web server or on a different machine. That way session values are not lost when the web server is reset or the ASP.NET worker process is recycled.

Versions of ASP.NET prior to 2.0 were criticized for their lack of standards compliance. The generated HTML and JavaScript sent to the client browser would not always validate against W3C/ECMA standards. In addition, the framework's browser detection feature sometimes incorrectly identified web browsers other than Microsoft's own Internet Explorer as "downlevel" and returned HTML/JavaScript to these clients with some of the features removed, or sometimes crippled or broken. However, in version 2.0, all controls generate valid HTML 4.0, XHTML 1.0 (the default) or XHTML 1.1 output, depending on the site configuration. Detection of standards-compliant web browsers is more robust and support for Cascading Style Sheets is more extensive.

Web Server Controls: these are controls introduced by ASP.NET for providing the UI for the web form. These controls are state managed controls and are WYSIWYG controls.

FRAMEWORKS

It is not essential to use the standard webforms development model when developing with ASP.NET. Noteworthy frameworks designed for the platform include:

Base One Foundation Component Library (BFC) is a RAD framework for building .NET database and distributed computing applications.

DotNetNuke is an open-source solution which comprises both a web application framework and a content management system which allows for advanced extensibility through modules, skins, and providers.

Castle Monorail, an open-source MVC framework with an execution model similar to Ruby on Rails. The framework is commonly used with Castle ActiveRecord, an ORM layer built on NHibernate.

Spring.NET, a port of the Spring framework for Java. Skaffold.NET, A simple framework for .NET applications, used in enterprise applications. Survey Project is an open-source web based survey and form engine framework written in ASP.NET and C#.

C#
C# is a multi-paradigm programming language encompassing imperative, declarative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines. It was developed by Microsoft within the .NET initiative and later approved as a standard by Ecma (ECMA-334) and ISO (ISO/IEC 23270). C# is one of the programming languages designed for the Common Language Infrastructure. C# is intended to be a simple, modern, general-purpose, object-oriented programming language. Its development team is led by Anders Hejlsberg. The most recent version is C# 4.0, which was released on April 12, 2010.

DESIGN GOALS

The ECMA standard lists these design goals for C#

C# language is intended to be a simple, modern, general-purpose, object-oriented programming language.

The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity are important.

The language is intended for use in developing software components suitable for deployment in distributed environments.

Source code portability is very important, as is programmer portability, especially for those programmers already familiar with C and C++.

Support for internationalization is very important. C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.

Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

NAME

The name "C sharp" was inspired by musical notation where a sharp indicates that the written note should be made a semitone higher in pitch. This is similar to the language name of C++, where "++" indicates that a variable should be incremented by 1. Due to technical limitations of display (standard fonts, browsers, etc.) and the fact that the sharp symbol (U+266F (HTML: &#9839; )) is not present on the standard keyboard, the number sign (U+0023 # NUMBER SIGN (HTML: &#35; )) was chosen to represent the sharp symbol in the written name of the programming language.This convention is reflected in the ECMA-334 C# Language Specification. However, when it is practical to do so (for example, in advertising or in box art), Microsoft uses the intended musical symbol. The "sharp" suffix has been used by a number of other .NET languages that are variants of existing languages, including J# (a .NET language also designed by Microsoft which is derived from Java 1.1), A# (from Ada), and the functional F#. The original implementation of

Eiffel for .NET was called Eiffel#, a name since retired since the full Eiffel language is now supported. The suffix has also been used for libraries, such as Gtk# (a .NET wrapper for GTK+ and other GNOME libraries), Cocoa# (a wrapper for Cocoa) and Qt#

FEATURES By design, C# is the programming language that most directly reflects the underlying Common Language Infrastructure (CLI). Most of its intrinsic types correspond to value-types implemented by the CLI framework. However, the language specification does not state the code generation requirements of the compiler: that is, it does not state that a C# compiler must target a Common Language Runtime, or generate Common Intermediate Language (CIL), or generate any other specific format. Theoretically, a C# compiler could generate machine code like traditional compilers of C++ or Fortran. Some notable distinguishing features of C# are:

There are no global variables or functions. All methods and members must be declared within classes. Static members of public classes can substitute for global variables and functions.

Local variables cannot shadow variables of the enclosing block, unlike C and C++. Variable shadowing is often considered confusing by C++ texts.

C# supports a strict Boolean datatype, bool. Statements that take conditions, such as while and if, require an expression of a type that implements the true operator, such as the boolean type. While C++ also has a boolean type, it can be freely converted to and from integers, and expressions such as if(a) require only that a is convertible to bool, allowing a to be an int, or a pointer. C# disallows this "integer meaning true or false" approach, on the grounds that forcing programmers to use expressions that return exactly bool can prevent certain types of common programming mistakes in C or C++ such as if (a = b) (use of assignment = instead of equality ==).

In C#, memory address pointers can only be used within blocks specifically marked as unsafe, and programs with unsafe code need appropriate permissions to run. Most object access is done through safe object references, which always either point to a "live" object or have the well-defined null value; it is impossible to obtain a reference

to a "dead" object (one which has been garbage collected), or to a random block of memory. An unsafe pointer can point to an instance of a value-type, array, string, or a block of memory allocated on a stack. Code that is not marked as unsafe can still store and manipulate pointers through the System.IntPtr type, but it cannot dereference them.

Managed memory cannot be explicitly freed; instead, it is automatically garbage collected. Garbage collection addresses the problem of memory leaks by freeing the programmer of responsibility for releasing memory which is no longer needed.

In addition to the try...catch construct to handle exceptions, C# has a try...finally construct to guarantee execution of the code in the finally block.

Multiple inheritance is not supported, although a class can implement any number of interfaces. This was a design decision by the language's lead architect to avoid complication and simplify architectural requirements throughout CLI.

C# is more type safe than C++. The only implicit conversions by default are those which are considered safe, such as widening of integers. This is enforced at compiletime, during JIT, and, in some cases, at runtime. There are no implicit conversions between booleans and integers, nor between enumeration members and integers (except for literal 0, which can be implicitly converted to any enumerated type). Any user-defined conversion must be explicitly marked as explicit or implicit, unlike C++ copy constructors and conversion operators, which are both implicit by default. Starting with version 4.0, C# supports a "dynamic" data type that enforces type checking at runtime only.

Enumeration members are placed in their own scope. C# provides properties as syntactic sugar for a common pattern in which a pair of methods, accessor (getter) and mutator (setter) encapsulate operations on a single attribute of a class.

Full type reflection and discovery is available. C# currently (as of version 4.0) has 77 reserved words. Checked exceptions are not present in C# (in contrast to Java). This has been a conscious decision based on the issues of scalability and versionability

GRAPHICAL USER INTERFACE

graphical user interface (GUI, sometimes pronounced gooey,) is a type of user interface that allows users to interact with electronic devices with images rather than text commands. GUIs can be used in computers, hand-held devices such as MP3 players, portable media players or gaming devices, household appliances and office equipment . A GUI represents the information and actions available to a user through graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels or text navigation. The actions are usually performed through direct manipulation of the graphical elements. Next ,we have presented the snap shots of all the pages that are encountered while using the software for generating time table. Home page Login page New student login page Welcome page for admin only Page for changing password Show/delete user login page Add subject page Show all faculty list

HOME PAGE:

LOGIN PAGE

NEW STUDENT LOGIN PAGE

WELCOME PAGE FOR ADMIN ONLY

PASSWORD CHANGE PAGE

CREATE NEW USER LOGIN PAGE

SHOW/DELETE USER LOGIN PAGE

ADD NEW SUBJECT PAGE

SHOW ALL FACULTY LIST PAGE

ASSIGN SUBJECTS TO FACULTY PAGE

SHOW/DELETE ASSIGNED SUBJECT

ADD LECTURE TIMINGS PAGE

SHOW/DELETE LECTURE TIMINGS PAGE

SHOW SEMESTER WISE SUBJECT LIST

GENERATE TIME TABLE PAGE

SYSTEM TESTING
Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality. Software Testing is the process of executing a program or system with the intent of finding errors. [Myers79] Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Software is not unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes for software is generally infeasible. Unlike most physical systems, most of the defects in software are design errors, not manufacturing defects. Software does not suffer from corrosion, wear-and-tear -- generally it will not change until upgrades, or until obsolescence. So once the software is shipped, the design defects -- or bugs -- will be buried in and remain latent until activation. Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable -- and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out. Discovering the design defects in software, is equally difficult, for the same reason of complexity. Because software and any digital systems are not continuous, testing boundary values are not sufficient to guarantee correctness. All the possible values need to be tested and verified, but complete testing is infeasible. Exhaustively testing a simple program to add only two integer inputs of 32-bits (yielding 2^64 distinct test cases) would take hundreds of

years, even if tests were performed at a rate of thousands per second. Obviously, for a realistic software module, the complexity can be far beyond the example mentioned here. If inputs from the real world are involved, the problem will get worse, because timing and unpredictable environmental effects and human interactions are all possible input parameters under consideration. A further complication has to do with the dynamic nature of programs. If a failure occurs during preliminary testing and the code is changed, the software may now work for a test case that it didn't work for previously. But its behavior on pre-error test cases that it passed before can no longer be guaranteed. To account for this possibility, testing should be restarted. The expense of doing this is often prohibitive. An interesting analogy parallels the difficulty in software testing with the pesticide, known as the Pesticide Paradox [Beizer90]: Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. But this alone will not guarantee to make the software better, because the Complexity Barrier principle states: Software complexity(and therefore that of bugs) grows to the limits of our ability to manage that complexity. By eliminating the (previous) easy bugs you allowed another escalation of features and complexity, but his time you have subtler bugs to face, just to retain the reliability you had before. Society seems to be unwilling to limit complexity because we all want that extra bell, whistle, and feature interaction. Thus, our users always push us to the complexity barrier and how close we can approach that barrier is largely determined by the strength of the techniques we can wield against ever more complex and subtle bugs. [Beizer90] Regardless of the limitations, testing is an integral part in software development. It is broadly deployed in every phase in the software development cycle. Typically, more than 50% percent of the development time is spent in testing. Testing is usually performed for the following purposes:

To improve quality.

As computers and software are used in critical applications, the outcome of a bug can be severe. Bugs can cause huge losses. Bugs in critical systems have caused airplane crashes, allowed space shuttle missions to go awry, halted trading on the stock market, and worse.

Bugs can kill. Bugs can cause disasters. The so-called year 2000 (Y2K) bug has given birth to a cottage industry of consultants and programming tools dedicated to making sure the modern world doesn't come to a screeching halt on the first day of the next century. [Bugs] In a computerized embedded world, the quality and reliability of software is a matter of life and death. Quality means the conformance to the specified design requirement. Being correct, the minimum requirement of quality, means performing as required under specified circumstances. Debugging, a narrow view of software testing, is performed heavily to find out design defects by the programmer. The imperfection of human nature makes it almost impossible to make a moderately complex program correct the first time. Finding the problems and get them fixed [Kaner93], is the purpose of debugging in programming phase.

For Verification & Validation (V&V)

Just as topic Verification and Validation indicated, another important purpose of testing is verification and validation (V&V). Testing can serve as metrics. It is heavily used as a tool in the V&V process. Testers can make claims based on interpretations of the testing results, which either the product works under certain situations, or it does not work. We can also compare the quality among different products under the same specification, based on results from the same test. We can not test quality directly, but we can test related factors to make quality visible. Quality has three sets of factors -- functionality, engineering, and adaptability. These three sets of factors can be thought of as dimensions in the software quality space. Each dimension may be broken down into its component factors and considerations at successively lower levels of detail. Table 1 illustrates some of the most frequently cited quality considerations.

Functionality (exterior quality) Correctness Reliability

Engineering (interior quality) Efficiency Testability

Adaptability (future quality) Flexibility Reusability

Usability Integrity

Documentation Structure

Maintainability

Table 1. Typical Software Quality Factors [Hetzel88]

Good testing provides measures for all relevant factors. The importance of any particular factor varies from application to application. Any system where human lives are at stake must place extreme emphasis on reliability and integrity. In the typical business system usability and maintainability are the key factors, while for a one-time scientific program neither may be significant. Our testing, to be fully effective, must be geared to measuring each relevant factor and thus forcing quality to become tangible and visible. [Hetzel88] Tests with the purpose of validating the product works are named clean tests, or positive tests. The drawbacks are that it can only validate that the software works for the specified test cases. A finite number of tests can not validate that the software works for all situations. On the contrary, only one failed test is sufficient enough to show that the software does not work. Dirty tests, or negative tests, refers to the tests aiming at breaking the software, or showing that it does not work. A piece of software must have sufficient exception handling capabilities to survive a significant level of dirty tests. A testable design is a design that can be easily validated, falsified and maintained. Because testing is a rigorous effort and requires significant time and cost, design for testability is also an important design rule for software development.

For reliability estimation [Kaner93] [Lyu95]

Software reliability has important relations with many aspects of software, including the structure, and the amount of testing it has been subjected to. Based on an operational profile (an estimate of the relative frequency of use of various inputs to the program [Lyu95]), testing can serve as a statistical sampling method to gain failure data for reliability estimation.

Software testing is not mature. It still remains an art, because we still cannot make it a science. We are still using the same testing techniques invented 20-30 years ago, some of which are crafted methods or heuristics rather than good engineering methods. Software testing can be costly, but not testing software is even more expensive, especially in places that human lives are at stake. Solving the software-testing problem is no easier than solving the Turing halting problem. We can never be sure that a piece of software is correct. We can never be sure that the specifications are correct. No verification system can verify every correct program. We can never be certain that a verification system is correct either.

Black-box testing

The black-box approach is a testing method in which test data are derived from the specified functional requirements without regard to the final program structure. [Perry90] It is also termed data-driven, input/output driven [Myers79], or requirements-based [Hetzel88] testing. Because only the functionality of the software module is of concern, black-box testing also mainly refers to functional testing -- a testing method emphasized on executing the functions and examination of their input and output data. [Howden87] The tester treats the software under test as a black box -- only the inputs, outputs and specification are visible, and the functionality is determined by observing the outputs to corresponding inputs. In testing, various inputs are exercised and the outputs are compared against specification to validate the correctness. All test cases are derived from the specification. No implementation details of the code are considered. It is obvious that the more we have covered in the input space, the more problems we will find and therefore we will be more confident about the quality of the software. Ideally we would be tempted to exhaustively test the input space. But as stated above, exhaustively testing the combinations of valid inputs will be impossible for most of the programs, let alone considering invalid inputs, timing, sequence, and resource variables. Combinatorial explosion is the major roadblock in functional testing. To make things worse, we can never be sure whether the specification is either correct or complete. Due to limitations of the language used in the specifications (usually natural language), ambiguity is often inevitable. Even if we use some type of formal or restricted language, we may still fail to write down all the possible cases in the specification. Sometimes, the specification itself becomes an intractable problem:

it is not possible to specify precisely every situation that can be encountered using limited words. And people can seldom specify clearly what they want -- they usually can tell whether a prototype is, or is not, what they want after they have been finished. Specification problems contributes approximately 30 percent of all bugs in software. The research in black-box testing mainly focuses on how to maximize the effectiveness of testing with minimum cost, usually the number of test cases. It is not possible to exhaust the input space, but it is possible to exhaustively test a subset of the input space. Partitioning is one of the common techniques. If we have partitioned the input space and assume all the input values in a partition is equivalent, then we only need to test one representative value in each partition to sufficiently cover the whole input space. Domain testing [Beizer95] partitions the input domain into regions, and consider the input values in each domain an equivalent class. Domains can be exhaustively tested and covered by selecting a representative value(s) in each domain. Boundary values are of special interest. Experience shows that test cases that explore boundary conditions have a higher payoff than test cases that do not. Boundary value analysis [Myers79] requires one or more boundary values selected as representative test cases. The difficulties with domain testing are that incorrect domain definitions in the specification can not be efficiently discovered. Good partitioning requires knowledge of the software structure. A good testing plan will not only contain black-box testing, but also white-box approaches, and combinations of the two.

White-box testing

Contrary to black-box testing, software is viewed as a white-box, or glass-box in white-box testing, as the structure and flow of the software under test are visible to the tester. Testing plans are made according to the details of the software implementation, such as programming language, logic, and styles. Test cases are derived from the program structure. White-box testing is also called glass-box testing, logic-driven testing [Myers79] or design-based testing [Hetzel88]. There are many techniques available in white-box testing, because the problem of intractability is eased by specific knowledge and attention on the structure of the software under test. The intention of exhausting some aspect of the software is still strong in white-box testing, and some degree of exhaustion can be achieved, such as executing each line of code

at least once (statement coverage), traverse every branch statements (branch coverage), or cover all the possible combinations of true and false condition predicates (Multiple condition coverage) Control-flow testing, loop testing, and data-flow testing, all maps the corresponding flow structure of the software into a directed graph. Test cases are carefully selected based on the criterion that all the nodes or paths are covered or traversed at least once. By doing so we may discover unnecessary "dead" code -- code that is of no use, or never get executed at all, which can not be discovered by functional testing. In mutation testing, the original program code is perturbed and many mutated programs are created, each contains one fault. Each faulty version of the program is called a mutant. Test data are selected based on the effectiveness of failing the mutants. The more mutants a test case can kill, the better the test case is considered. The problem with mutation testing is that it is too computationally expensive to use. The boundary between black-box approach and white-box approach is not clear-cut. Many testing strategies mentioned above, may not be safely classified into black-box testing or white-box testing. It is also true for transaction-flow testing, syntax testing, finite-state testing, and many other testing strategies not discussed in this text. One reason is that all the above techniques will need some knowledge of the specification of the software under test. Another reason is that the idea of specification itself is broad -- it may contain any requirement including the structure, programming language, and programming style as part of the specification content. We may be reluctant to consider random testing as a testing technique. The test case selection is simple and straightforward: they are randomly chosen. Study in [Duran84] indicates that random testing is more cost effective for many programs. Some very subtle errors can be discovered with low cost. And it is also not inferior in coverage than other carefully designed testing techniques. One can also obtain reliability estimate using random testing results based on operational profiles. Effectively combining random testing with other testing techniques may yield more powerful and cost-effective testing strategies. Performance testing: Not all software systems have specifications on performance explicitly. But every system will have implicit performance requirements. The software should not take infinite time or infinite

resource to execute. "Performance bugs" sometimes are used to refer to those design problems in software that cause the system performance to degrade. Performance has always been a great concern and a driving force of computer evolution. Performance evaluation of a software system usually includes: resource usage, throughput, stimulus-response time and queue lengths detailing the average or maximum number of tasks waiting to be serviced by selected resources. Typical resources that need to be considered include network bandwidth requirements, CPU cycles, disk space, disk access operations, and memory usage [Smith90]. The goal of performance testing can be performance bottleneck identification, performance comparison and evaluation, etc. The typical method of doing performance testing is using a benchmark -- a program, workload or trace designed to be representative of the typical system usage. [Vokolos98] Reliability testing Software reliability refers to the probability of failure-free operation of a system. It is related to many aspects of software, including the testing process. Directly estimating software reliability by quantifying its related factors can be difficult. Testing is an effective sampling method to measure software reliability. Guided by the operational profile, software testing (usually black-box testing) can be used to obtain failure data, and an estimation model can be further used to analyze the data to estimate the present reliability and predict future reliability. Therefore, based on the estimation, the developers can decide whether to release the software, and the users can decide whether to adopt and use the software. Risk of using software can also be assessed based on reliability information. [Hamlet94] advocates that the primary goal of testing should be to measure the dependability of tested software. There is agreement on the intuitive meaning of dependable software: it does not fail in unexpected or catastrophic ways. Robustness testing and stress testing are variances of reliability testing based on this simple criterion. The robustness of a software component is the degree to which it can function correctly in the presence of exceptional inputs or stressful environmental conditions. Robustness testing differs with correctness testing in the sense that the functional correctness of the software is not of concern. It only watches for robustness problems such as machine crashes, process hangs or abnormal termination. The oracle is relatively simple, therefore robustness testing

can be made more portable and scalable than correctness testing. This research has drawn more and more interests recently, most of which uses commercial operating systems as their target. Stress testing, or load testing, is often used to test the whole system rather than the software alone. In such tests the software or system are exercised with or beyond the specified limits. Typical stress includes resource exhaustion, bursts of activities, and sustained high loads.

IMPLEMENTATION AND MAINTENANCE

IMPLEMENTATION
Implementation is the carrying out, execution, or practice of a plan, a method, or any design for doing something. As such, implementation is the action that must follow any preliminary thinking in order for something to actually happen. In an information technology context, implementation encompasses all the processes involved in getting new software or hardware operating properly in its environment, including installation, configuration, running, testing, and making necessary changes. An implementation is a realization of a technical specification or algorithm as a program, software component, or other computer system through programming and deployment. Many implementations may exist for a given specification or standard. For example, web browsers contain implementations of World Wide Web Consortium-recommended specifications, and software development tools contain implementations of programming languages. Implementation includes the following phases: Writing Computer Software (Coding) this means actually writing the code. This is primarily done by the programmers. Testing software this involves using test data scenario to verify that each component and the whole system work under normal and abnormal circumstances. Converting from old system to new system- this includes not only installing the new system in organizational sites but also dealing with documentation. Training users and others- this may include a variety of human and computer-assisted sessions as well as tools to explain the purpose and use of the system. There are other implementation techniques also like Direct Installation (in this the old system is turned off and the new system replaces the old system. This type of a system is a bit risky because users are at the mercy of new system) and Phased Installation (Under this, new system is brought on-line in functional components; different parts of the old and new system are in cooperation until the whole new system is installed). After a thorough testing of the different aspects of the system as described in earlier section, the system is to be put to actual use by using live data by user staff after sufficient training for the use of the software has been provided to staff members. We have used parallel installation technique in the implementation of the new system.

USER TRANING:
The type of necessary training varies by type of system and expertise of users. The list of potential points we have taken in mind while estimating the amount of user training needed are as follows: Use of system General computer concepts Information system concepts System management System installation

As the end users in our case are computer literates, therefore we dont have to give them any computer fundamentals training (eg. How to operate computer system).

MAINTENANCE
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes. A common perception of maintenance is that it is merely fixing bugs. However, studies and surveys over the years have indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system. Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of eight Laws of Evolution (Lehman 1997). Key findings of his research include that maintenance is really evolutionary developments and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity. The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, and maintainability measurement. Best and Worst Practices in Software Maintenance Because maintenance of aging legacy software is very labour intensive it is quite important to explore the best and most cost effective methods available for dealing with the millions of applications that currently exist. The sets of best and worst practices are not the same. Just as practice that has the most positive impact on maintenance productivity is the use of trained maintenance experts, while the factor that has the greatest negative impact is the presence error-prone modules in application being maintained. The software maintenance is categorized into four classes:

Adaptive dealing with changes and adapting in the software environment Perfective accommodating with new or changed user requirements which concern functional enhancements to the software Corrective dealing with errors found and fixing it

Preventive concerns activities aiming on increasing software maintainability and prevent problems in the future

SOFTWARE MAINTENANCE PLANNING

The integral part of software is the maintenance part which requires accurate maintenance plan to be prepared during software development and should specify how users will request modifications or report problems and the estimation of resources such as cost should be included in the budget and a new decision should address to develop a new system and its quality objectives. The software maintenance which can last for 56 years after the development calls for an effective planning which addresses the scope of software maintenance, the tailoring of the post delivery process, the designation of who will provide maintenance, an estimate of the life-cycle costs .

SOFTWARE MAINTENANCE PROCESSES

This section describes the six software maintenance processes as: 1. The implementation processes contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management. 2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications. 3. The process considering the implementation of the modification itself. 4. The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution. 5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform

without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task. 6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software. There are a number of processes, activities and practices that are unique to maintainers, for example:

Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer;

Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers;

Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive;

Modification Request acceptance/rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.

CATEGORIES OF MAINTENANCE IN ISO/IEC 14764

E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective. These have since been updated and ISO/IEC 14764 presents:

Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.

Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.

Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.

Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling

and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Note also that some academic institutions are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available.).