Project Report

PROJECT REPORTOn

WEBSITE SIKHISMA project submitted to Punjab Technical University, Jalandhar.

Submitted for partial fulfillment of the requirement for the award of degree of

Bachelor of Computer Application(Session 2006-09)

PROJECT GUIDE:

PROJECT TEAM:Lect. Of Comp. Dept. Kirpal Singh(608230782)Mr. Ajay Bhatia

Sandeep Singh(608230800)

Amrik Singh(608230764) Gurpreet Sharma(608230776) CERTIFICATEThis is to certify that the project entitled SIKHISM submitted to PROF. Ajay Bhatia in practical fulfillment of the requirement for the award of degree BCA of Punjab Technical University, Jalandhar is bonafide research work carried out by KIRPAL SINGH, SANDEEP SINGH, AMRIK SINGH, GURPREET SHARMA and that no research is done on this topic and that is not part of research has been submitted for any other degree.

The assistance and help receive during the evaluation of the project has been fully acknowledged.

GUIDED BY:

PROF. AJAY BHATIA PREFACE

A professional course like Bachelor of Computer Applications demands in depth theoretical knowledge and Practical exposure for its application.

The course aims to groom the student professionally and offer them a chance to work in the real environment of the corporate world, to have an opportunity to gain experience on practical aspects and supplement their theoretical knowledge.

A sincere effort has been made to bring about the beached fact and it is hoped that this report meets the given expectations and the various requirements.

The BCA participants make a humble presentation of this report to all those persons who may have professional and academic interest in this topic.

DECLARATIONThis is to certify that the project entitled SIKHISM submitted in practical fulfillment of the requirement for the award of degree BCA of Punjab Technical University, Jalandhar is bonafide research work carried out under the supervision and that not part of research has been submitted for any other degree.

The assistance and help receive during the evaluation of the project has been fully acknowledged.

ACKNOWLEDGEMENTWe wish to express my gratitude to those who generously helped us to colour to mosaic of this research work with the titles of their knowledge and expertise. No end over can be successful without the active co-operation of the people concerned with it, which has forth coming, in full, during this study. It is extremely difficult to find words, which can do justice to this sort of co-operation. It goes in the planning & execution of this study.

We would like to thanks to Mr. AJAY BHATIA for their valuable cooperation.

Finally we would like to thanks all the persons who were instrumental in making this work possible. Our interaction with all those people has left lasting impression on our mind that will influence any behavior for all times to come. SYSTEM ANALYSISRequirement analysis is done in order to understand the problem the software system is to solve. The emphasis in requirement analysis is on identifying what is needed from the system, not how the system will achieve its goals. The developer usually does not understand the clients problems, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirement analysis.

The goal of this phase is to produce the software requirements specification document, requirement document. The person responsible for the requirements analysis is often called analyst.

There are two major activities in this phase:

Problem understanding or Analysis.

Requirement specification.

A clear understanding is needed of the important data entities in the system, major centers where action is taken, the purpose of the different actions that are performed, and the inputs and outputs.

Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of a document, some specification language has to be selected. The requirements document must specify all functional and performance requirements: the formats of inputs and outputs; and all design constraints that exist due to political, economic, environmental, and security reasons. PROJECT PLANSTeam Structure

team will be comprising of two members.

our very able and helpful project guide mr. ajay bhatia sir.

AJAY BHATIA (Trainee), CT INSTITUTE OF MGMT. AND IT.

Development Schedule

The work in developing the new system commented immediately with our first meeting with the management and users thereafter we were in continuous touch with the management and users of the company.

Phases Involved in the development of the system

Identify needs and benefits

Held meetings with the management and user

Studied and identified the existing system.

Identify needs and project constraints

Established project statements

Prepared a detailed report of the existing system at work.

Prepare the software requirement specifications .

Actual coding started

SYSTEM ENVIORNMENT HARDWARE REQUIREMENTS

SOFTWARE REQUIREMENTS

HARDWARE REQUIREMENTS

PROCESSOR P4

128 MB RAM

40 GB HARD DISK

MOUSE

KEYBOARD

MONITER

CD DRIVE

FLOPPY DRIVE

UPS

SOFTWARE REQUIREMENTS

WINDOWS XP

SYSTEM DESIGN

System design is the solution i.e. how to approach the creation of a new system. This important phase consists of several steps. Here the stress is on translating performance requirements into design specifications.

Various steps involved in system designing areas follow:

1. Problem definition

2. Input/output specifications

3. Database design

4. Modular program design

5. Testing.

INPUT DESIGN

Input design is the process of converting user-originated inputs to the computer-based format. Input data are collected and organized into group of similar data. Once identified, appropriate input media are selected for processing.

SOURCE DOCUMENTS

Source data are captured initially on original papers or source documents. Source documents initiate a processing cycle as soon as they are entered into the system from keyboard, punch card or diskettes. The may be or may be not retained by the system. Thus, each source document may be evaluated in terms of

1) Its continued use in the candidate system.

2) Replacement by an alternate source document.

OUTPUT DESIGN

Output is the most important and direct source of information to the user. Efficient, intelligible design improves system credibility and helps user in decision-making. Efficient, intelligible design should improve the systems relationships with the user and help in decision making. A major form of output is hard copy from the printer. Print outs are designed around the output requirements of the user. The output devices depend on the factors such as compatibility of the devices with the system, response time, requirements, expected print quality and number of copies needed.

Output to be produces depends on the following factors:

a. Type of user and purpose

b. Contents of the output

c. Format of the output

d. Frequency and timing of the output

e. Volume of output

f. Quality

g. Type of stationary

The following devices are available for providing computer-based output:

a. Printers.

b. Computer Output Microfilm (COM)

c. Monitors

FEASIBILITY STUDY The main objective of a feasibility study is to test the technical, social and economic feasibility of developing a computer-based system. Investigating the existing system & generating idea about the new system do this. The proposed system must be evaluated from a viewpoint first and if technically feasible then their impact on the organization & staff must be accessed. If compatible, social and technical system can be devised, then they must be tested for economic feasibility.

ACCESSING TECHNICAL FEASIBILITY :

The assessment of the technical feasibility must be based on an outline design of system requirement in terms of equipment, software & staff. This can be quantified in terms of volumes of data, trends, frequency of updating, cycles of activity etc. in order to give an indication of technical system.

SYSTEM DEVELOPMENT PROCESS:

The feasibility study must consider the ways of acquiring the system. These include the purchase of package, the use of a consultancy organization or software house to design the system & write the programs, a co-operative development with another similar organization or in-house development of the system.

The following factors must be considered before choosing the software:

Storage space needed in the disk.

Processing time required processing a record.

Volume of data to be processed is very large so storage need will be large & processing time will be high.

ASSESSING SOCIAL FEASIBILITY :

The assessment of the social feasibility will be done along with the technical feasibility. Each of the alternative solution, which emerges, must be evaluated for its social implications. The various social costs must also be evaluated, which include cost of

Education & Training of users

Communication.

Consultation

ASSESSING ECONOMIC FEASIBILITY :

Proposed system must be justified by the cost & benefit criteria to ensure that the effort is concentrated on projects which best return at earlier opportunity .

The factors for cost benefit analysis are:

Cost for development of proposed system.

Cost of operation for proposed system.

The value of benefits of proposed system

SYSTEM DEVELOPMENT

Unit Testing:-The common view of testing held by the user is that it is performed to prove that there is no error in program.

The most useful and practical approach is with the understanding that testing is the process of execution a program with the explicit intention of finding errors, that is, making the program fail. The tester, who may be an analyst, programmer, or specialist trained in software testing, is actually trying to make the program fail. A successful test, then, is one that finds an error. The two types of testing used are:

In unit testing that analyst tests the programs making up a system (For this reason unit testing is sometimes called program testing). The software units in a system are the modules and routines that are assembled and integrated at different levels are needed.

Unit testing focuses first on the modules, independently of one another, to locate errors. This enables the tester to detect error in coding and logic that are contained within that module alone. Those resulting from the interaction between modules are initially avoided.

The test cares needed for unit testing should exercise each condition and option. For example, test cases are needed to determine how the system handles attempt to check in guests who to do and do not have reservations, as well as those instances involving changing name on the reservation when a person than the one listed arrives. Also needed are test cases for checkout situations of paying the pay.

Unit testing can be performed from bottom up, starting with the smallest and lowest level modules and proceeding one at time. For each module in bottom up testing, a short program(called a driver program because it drives or runs the modules) execute the modules and provides the needed data, so that the module is asked to perform the way it will where embedded with in the large system. When bottom-level modules are tested, attention turns to those on the next level that use the lower level ones. They are tested individually and then linked with the previously examined lower level modules.

Top-down testing, as the name implies, begins with the upper-level modules. However, since the detailed activates usually performed in lower-level routine are not provided (because those shell that can be called by the upper level module and that when reached properly), will return a message to the calling module, indicating that proper intention occurred. No attempt is made to verify the correctness of the lower-level module. Often, top-down testing plans are combined with bottom-up testing; that is, some lower-level modules are unit tested and integrated into a top-down testing program.

SYSTEM TESTING: - System testing does not test the software but rather the integration of each module in the system. It also tests to find discrepancies between the system and its original objectives, current specifications, and system documentation. The primary concern is the compatibility of individual modules. Analysts are trying to find area where modules have been designed with different specifications for data length, type and data element name. For example, one module may accept the data item for student identification number to be the numeric field, while other module accepts it to be a character data item. The system itself may not report this as an error, but the output may show unexpected results. If a record created and stored in one module, using the identification number as a numeric field, is later sought on retrieval with the exception that it will a character field, the field will not be recognized and the message REQUEST RECORD NOT FOUND will be displayed.

System testing must also verify that the field size adequate and those indices have been built properly. Sorting and reindexing procedures assumed to be present in lower-level modules must be tested at the system level to see that they in fact exist and achieves the results modules expect.

SYSTEM IMPLEMENTATION:-

Implementation: -

Implementation is the process of converting a new system design into operation. Conversion is one aspect of implementation. The other aspects are the post-implementation review and software maintenance. There are three types of implementation:- Implementation of a computer system to replace a manual system. The problems encountered are converting files, training users, creating accurate files, and verifying printouts for integrity.

Implementation of a new computer system to replace an existing one.

Implementation of a modified application to replace an existing one, using the same computer. This type of conversion is relatively easy to handle, provided there are no changes in the files.

User Training: -

An analysis of user training focuses on two factors: - user capabilities and the nature of the system being installed. Users range from the native to the highly sophisticated. The requirements of the system also range from very simple tasks like using a pocket calculator to complex tasks like learning to program a database system. Tasks that require the user to follow a well-defined, step-by-step procedure require limited problem solving. This means that the training level and duration are basic and brief.

Post-Implementation Review Report: - A post-implementation review measures the system performance against predefined requirements. Unlike system testing, which determines where the system fails so that the necessary adjustments can be made, a post-implementation review determines how well the system continues to meet performance specifications. It also provides information to determine whether major redesign is necessary.

CONCLUSIONNo program or system design is perfect, communication between the user and the designer is not always complete or clear and the time usely short, this result in errors, the number and the nature of errors in a new design depends on several factors which are as follows :-

Communication between User and Designer.

The programmers ability to generate code that reflects exactly the system specifications

The Time Frame for the design

In the system designed here, which is entitled WEBSITE ON INTERNET AND NETWORKING.

We have tried our best to cover successfully and accurately all the

Requirements of the USER of the THIS WEBSITE.

TABLE OF CONTENTS INTRODUCTION TO THE PROJECT REQUIRMENT ANALYSIS PROJECT PLANS

Subpage Layout

Top