Upload
neeraj-dixit
View
307
Download
5
Tags:
Embed Size (px)
Citation preview
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 Under the Guidance of
ANISHA VERMA(07070103014) Ms. ENA JAIN
HARSHITA RAI( 98070103123) ASSISTANT PROFESSOR
ANKITA ASWAL(07070104017) DEPARTMENT OF IT
DIVYA SHARMA(07070106019)
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: - Under the Supervision of:-
Anisha Verma (07070103014) Ms. Ena Jain
Harshita Rai (98070103123 Assistant Professor
Ankita Aswal (07070104017) Department Of IT
Divya Sharma(07070106019)
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
candidate’s 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 07070103014
HARSHITA RAI 98070103123
ANKITA ASWAL 07070104017
DIVYA SHARMA 07070106019
HOD: Supervisor/Guide:
Prof. G.P. Saroha Ms. ENA JAIN
Deptt. Of IT Deptt. Of CSE/IT
Dehradun Institute of Technology Dehradun Institute of Technology
Dehradun Dehradun
Table of Contents
1. ABSTRACT
2. INTRODUCTION
2.1 Brief Overview2.2 Objective of the Project
3. SYSTEM FEATURES
3.1 Feature & Scope of Old and New System3.2 Benefit of Proposed System3.3 Team Structure3.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 tools are
needed to support
operations?
What skills will
operators need to be
trained in?
What processes
need to be created
and/or updated?
What
documentation does
operations need?
What
documenta
tion will
users be
given?
What
training
will users
be given?
How will
change
requests be
managed?
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 Model–View–Controller (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 place-
holder 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 site’s 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 try-
catch 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: ♯ )) is not present on the standard keyboard, the
number sign (U+0023 # NUMBER SIGN (HTML: # )) 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 compile-
time, 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
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)
Engineering (interior
quality)
Adaptability (future
quality)
Correctness Efficiency Flexibility
Reliability Testability Reusability
Usability Documentation Maintainability
Integrity Structure
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 don’t 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 5–6 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.).