A PROJECT REPORT ON

(LIBRARY MANAGEMENT SYSTEM)

Submitted by

(MAN MOHAN CHAURASIA)

(879277)

in partial fulfillment for the award of the degree of

BACHELOR OF COMPUTER APPLICATIONS

Under the guidance of

Mr. AVDHESH GUPTA

DEPARTMENT OF COMPUTER APPLICATIONS IFTM, MORADABAD

(AFFILIATED TO MJP ROHILKHAND UNIVERSITY, BARIELLY) (2 0 0 9 2 0 10)

Table of Contents

CONTENTS
S.NO
1. 2. 3. 4. 5. 6. 7.

PARTICULAR
Introduction Objectives System Analysis Identification of Need Preliminary Investigation Feasibility Study Software & Hardware Requirement Specification System Design Data Flow Diagram E-R Diagram Code Efficiency Optimization of Code Validation Checks System Testing System Security Measures Cost Estimation of Project

8. 9. 10. 11. 12. 13. 14. 15. 16.

17. 18. 19. 20. 21. 22. 23.

PERT Chart Software Development Life Cycle Design & Coding Implementation & Maintainers Forms Database Bibliography

ACKNOWLEDGEMENT
First and foremost, I would like to thank Mr. Avdhesh Gupta (my honorable guide), Assistant Professor, Department of Computer Applications, IFTM, Moradabad, for his prodigious, persuasions, painstaking, and attitude, reformative and prudential suggestions throughout my project.

Man Mohan Chaurasia Girijesh Kumar Mishra Manish kumar Sharma BCA VI

BONAFIDE CERTIFICATE
This is to certify that this project titled LIBRARY MANAGEMENT SYSTEM is the bonafide work of (Man Mohan Chaurasia) that carried out the project under my supervision. Certified further that to the best of my knowledge the work reported here in does not include any duplicacy.

(Name & Sign of Project In-charge/Project Guide)

INTRODUCTION

INTRODUCTION
The Library Management System is designed & developed for a receipt and issuance of books in the library along with the students details. The books received in the library are entered in books entry form and the new student is entered in the student entry form. The issue of book in library for one semester . The issuance and due date for the returning of the book is also entered into the Book Issue form. When the student wants to get the desired book the same is issued on the availability basis to the student. The student has to pay the penalty when they loss the book. If the admin has to check how much books are allowed to a particular student then they have to check easily with use of our project. In our project if the student wants to issue some another book then they has to collect the book with some special authority and give special permission to his Head of Department.

OBJECTIVES
The major objectives of my project Library Management System are:
1. To issue the separate book for each student. 2. The issue of book in library for one semester. 3. The admin can check all the information about the Books & Students. 4. Admin can update, create, deletes the record of students as per requirement. 5. Students can give the penalty if they lost her Books. 6. This project has Administrative, and both are controlled by administrator. 7. This project has Issue & Return report. 8. This project also provides the library card number for check the correct student 9. In this Project there is facility to modify the Student record or Book record. 10. In this project there are different-different forms are available, to record Books & Students Information. 11. In the project there is password verification in necessary step. 12. To provide database of Students, Books. details.

SYSTEM ANALYSIS

SYSTEM ANALYSIS
System Analysis refers to the process of examining a situation with the intent of improving it through better procedures and methods. System design is the process of planning a new system to either replace or complement an existing system. But before any planning is done, the old system must be thoroughly understood and the requirements determined. System Analysis is therefore, the process of gathering and interpreting facts, diagnosis problems and using the information to re-comment improvements in the system. Or in other words, System Analysis means a detailed explanation or description. Before computerizing a system under consideration, it has to be analyzed. We need to study how it functions currently, what are the problems, and what are the requirements that the proposed system should meet. The main components of making software are: System and software requirements analysis Design and implementation of software Ensuring, verifying and maintaining software integrity

System analysis is an activity that encompasses most of the tasks that are collectively called Computer System Engineering. Confusion sometimes occurs because the term is often used in context that all dues it only to software requirement analysis activities, but system analysis focuses on all the system elements- not just software.

System analysis is conducted with the following objectives in mind: Identify the customers need Evaluate the system concept for feasibility Perform economic and technical analysis Allocate functions to hardware, software, people, database and other

system elements

Establish cost and schedule constraints Create a system definition that forms the foundation for all the subsequent

engineering work. System Analysis is consisting of two main works i.e. Identify the need and Preliminary Investigation.

IDENTIFICATION OF NEED

IDENTIFICATION OF THE NEED

REQUIREMENT ANALYSIS
Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs. Analysis is a detail study of the various operations performed by a system and their relationships within and outside the system. The problem could be automating an existing manual process, developing a new automated system, or a combination of the two. A key question is: what is needed for the system, not how the system will achieve its goal. During analysis, data are collected on the available files, decision points, and transactions handled by the present system. For large systems that have many features, and that need to perform many different tasks, understanding the requirements of the system is a major task. Data flow diagrams, interviews, on-site observations, and questionnaires are the examples of requirement analysis. Training, experience, and common sense are required for collection of the information needed to do the analyst. Once the analysis is completed, the analyst has a firm understanding of what is to done. This task is complicated by the fact that there are often at least two parties involved in software development-a client and a developer. The developer usually does not understand the clients problem domain, and the client often does not understand the issues in the software systems. This causes a communication gap between client and developer. The goal of the requirement specification phase is to produce the software requirements specification document (also called the requirement document). The person responsible for the requirement analysis is often called the analyst. There are two major activities in this phase: Problem understanding or analysis and requirement specification. In problem analysis, the analyst has top understand the problem and its context. Analysis requires a thorough understanding of the system, parts of which have to be automated. The goal of this activity is to understand the requirement of the new system that is to

be developed. The client may not really know the need s of the system. The analyst has to make the client aware of the new possibilities, helping both client and the analyst the requirements for the new system. Once the problem is analyzed and the essentials understood, the requirement is specified in the requirement document. For requirement specification in the form of document, some specification language has to be selected (e.g. English, regulates expressions, tables, or combination of these). A preliminary user manual that describes all the major uses interfaces frequently form a part of the requirement document. The first step of system analysis process involves the identification of need. The analyst (system engineer) meets with the customer & the end user (if different from customer). Identification of need is the starting point in the evolution of a computer based system. The analyst assists the customer on defining the goals of the system: What information will be produced? What information is to be provided? What functions and performance are required?

The analyst makes sure to distinguish between customer needs and customer wants. That is what the main aim behind the system is. Defining aim is very vital in system work. If we do not know where we want to go, we will not know when we have reached their. Once we know our aim, we can try to achieve it in the best possible way. The user department has to define these objectives in terms of their needs. These become the outputs which the system analyst keeps in to mind. Once we know the output, we can easily determine what the input should be. The essential elements of inputs are timeliness, accuracy, proper format and economy. Information gathered during the need identification step is specified in a System Concept Document. The customer before meetings sometimes prepares the original concept document with the analyst. Invariably, customer-analyst communication results in the modifications to the documents.

PRELIMINARY INVESTIGATION

PRELIMINARY INVESTIGATION
Limitations or failure of existing systems, or the awareness of technological advances relating to the particular are involved in particular systems which competitors are developing. Information systems projects originate from many reasons: to achieve greater speed in processing data, better accuracy and improved consistency, faster information retrieval, integration of business areas, reduced cost and better security. The sources also vary project proposals originate with department managers, senior executives and systems analysis. Sometimes the real origin is an outside source, such as a government agency, which stipulates systems requirements the organization must meet. When the request is made, the first systems activity, the preliminary investigation, begins. The activity has three parts: request clarification, feasibility study and request approval.

Request Clarification
Many requests from employees and users in organizations are not clearly stated. Therefore, before any systems investigation can be considered, the project request must be examined to determine precisely what the originator wants. A simple telephone call may suffice if the requester has a clear idea but does not know how to state it. On the other hand, the requester may merely be asking for help without knowing what is wrong or why there is a problem. Problem clarification in this case is much more difficult. In either case, before any further steps can be taken, the project requests must be clearly states.

This phase (initial study) involves estimating whether or not a development project is worthwhile. Problems with the current automated or manual system are identified, as well as the

benefits and costs of an alternative system. If the benefits seem to outweigh the costs (especially when compared with competing projects), a green signal may be given to continue the project, and detailed plans and schedules are drafted for making the system a reality. The proposed solution to the users problem may involve something between dramatic change (completely new system) and slight change to the present system. If the present system is manual and a computer system is proposed, the development project will probably be very large. At the other extreme are small development project that represent slight changes to existing systems, such as sorting information in a different way or inserting subtotals or adding new columns to a report. The objectives of this phase are:

1 To determine the feasibility of computerization of a particular system or area of operation. 2. To define clearly the objectives, scope and limitations of the project. 3. To establish a good working relationship between the user department and the data processing (DP) department. 4. To acquaint user management with the approach and method of work in systems development. 5. To estimate the resources required for system development, live running and maintenance. 6. To identify the likely benefits, which should accrue from the introduction of the system.

FEASIBILITY STUDY

FEASIBILITY STUDY
The data collection that occurs during preliminary investigations examines system feasibility, the likelihood that the system will be beneficial to the organization. Four tests of

feasibility are studies: technical, economical and operational. All are equally important.

1. Technical Feasibility:

It involves determining whether or not a system can

actually be constructed to solve the problem at hand. Some users expect too much of computers, assuming that computers can accurately predict the future, immediately reflect all information in an organization, easily understand speech, or figure out how to handle difficult problems. Such systems, even if they exist, are not yet available for widespread use.

The technical issues raised during the feasibility stage of the investigation are:

1. Does the necessary technology exist (can it be acquired) to do what is suggested?

2. Does the proposed equipment have the technical capacity to hold the data required to use the new system?

3. Will the proposed system and components provide adequate responses to inquires, regardless of the number or location of users?

4. Can the system be expanded, if developed?

5. Are there technical guarantees of accuracy, reliability, ease of access and data security?

For example, if the proposal includes a printer that prints at the rate of 2,000 lines per minute, a brief search shows that this is technically feasible. Whether it should be included in the configuration because of its cost is an economic decision. On the other hand, if a user is requesting audio input to write, read, and change stored data, the proposal may not be technically feasible.

2. Economical Feasibility:

It involves estimating benefits and costs. These

benefits and costs may be tangible or intangible. Because of confusion between the types of costs, it is sometimes very difficult to decide if the benefits outweigh the costs.

Tangible benefits may include decreasing salary costs (by automating manual procedures), preventing costly but frequent errors, sending bills earlier in the month, and increasing control over inventory levels. Such benefits may be directly estimated in rupees without much trouble. Intangible benefits may include increasing quality of goods produced, upgrading or creating new customer services, reducing repetitive or monotonous work for employees, and developing a better understanding of the market. Such benefits may be much more important than tangible benefits, but they may be ignored because estimating their rupee values involves pure guesswork.

Tangible costs are easily estimated. They include the one-time cost of developing the system and the continuous costs of operating the system. Examples of development costs are the salaries of programmers and` analysts, the prices of the computer equipment, and the expenses connected with user training. Operating costs include the salaries of computer operators and the costs of computer time and computer supplies. Intangible costs are usually not discussed

because they are rarely large. Examples of such costs include those associated with early user dissatisfaction and with the problems of converting to the new system.

A system that can be developed technically and will be used if installed must still be a good investment. That is, financial benefits must equal or exceed the financial costs. The economic and financial questions raised by analysts during the preliminary investigation seek estimates of:

1. The cost to conduct a full systems investigation.

2. The cost of hardware and software for the class of application being considered.

3. The benefits in the form of reduced costs or fewer costly errors.

4. The cost if nothing changes (the system is not developed).

Cost and benefit estimates on each project provide a basis for determining which projects are most worthy of consideration. Each estimate can be analyzed to determine how rapidly costs are recovered by benefits, to calculate both the absolute and interest-adjusted amounts of excess benefits, and to establish the ratio of benefits to costs. All of these factors are considered when developing an overall sense of the project's economic feasibility.

To be judged feasible, a project proposal must pass all these tests. Otherwise, it is not a feasible project. For example, a personnel record system that is financially feasible and

operational attractive, is not feasible if the necessary technology does not exist. Or a medical system which can be developed at reasonable cost but which nurses will avoid using cannot be judged operationally feasible.

3. Operational Feasibility:

Proposed projects are of course beneficial only if

they can be turned into information systems that will meet the organization's operation requirements. Simply stated, this test of feasibility asks if the system will work when developed and installed. Are there major barriers to implementation? Here are questions that will help test the operational feasibility of a project:

1. Is there sufficient support for the project from the management and from users? If the current system is well liked and used to the extent that persons will not see reasons for a change, there may be resistance.

2. Are current business methods acceptable to the user? If they are not, user may welcome a change that will bring about a more operational and useful system.

3. Have the users been involved in the planning and development of the project? Early involvement reduces the chances of resistance to the system and change in general, and increases the likelihood of successful projects.

4. Will the proposed system cause harm? The following questions are related to this issue:

Will the system produce result in any respect or area?

Will loss of control result in any area?

Will accessibility of information be lost?

Will individual performance be poorer after implementation than before?

Will customers be affected in an undesirable way?

Will it slow performance in any areas?

Operational feasibility is a measure of how people are able to work with the system. For example, a system may require managers to write BASIC, COBOL, or FORTRAN programs to access data. However, managers probably receive the greatest help from a system when they can concentrate on the problems to solve rather than on how programs should be constructed to solve them.

SOFTWARE AND HARDWARE REQUIREMENT SPECIFICATIONS

SOFTWARE AND HARDWARE REQUIREMENT SPECIFICATIONS

Software Requirements
Front end Back end Platform VISUAL BASIC Ms-Access WINDOWS 98, NT, 2000, XP

Hardware Requirements (Minimum)

Intel Pentium Processor 128 MB RAM 2 GB Hard Disk Monitor Mouse Printer

SYSTEM DESIGN

SYSTEM DESIGN
It describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation. The most creative and challenges phase of the software development life cycle is software design. The term design describes final software and the process by which it is developed. The purpose of the design phase is to plan a solution of the problem specified by the requirements document. It also includes the construction of programs and program testing. Design takes us toward how to satisfy the needs. The design of a system is perhaps the most critical factor affecting the quality of the software; it has a major impact on the later phase, particularly testing and maintenance. The output of this phase is the design document.

The first step is to determine how the output is to be produced and in what format. Samples of the output and input are to present second, input data and master files (database) have to be designed to meet the requirement of the purposed output. The operational (processing) phases are handled through program construction and testing, including a list of the programs needed to meet the software objectives and complete documentation.

The design activity is often dived into two phases-system design and detailed design. System design, which is sometimes also called top-level design, all the major data structures, file formats, output formats, and the major modules in the system and their specification are decided.

During detailed design, the internal logic of each of the modules specified in system design is decided. During this phase further details of the data structure and algorithmic design of each of the modules is specified.

In system design focus is on identifying the modules, whereas during detailed design focus is on designing the logic for each of the modules. In other words, in system design the attention is on what components are needed, while in detailed design how the component can be implemented in software is the issue.

The design of an information system produces the details that state how a system will meet the requirements identified during systems analysis. Often systems specialists refer to this stage as logical design, in contrast to developing program software, which is referred to as physical design.

As soon as the user accepts the system proposal, work can start on preparing the system specification. This phase takes the requirements as agreed and the work, which has led up to producing the proposal and develops the system to the level of details necessary to prepare the way for programming. At this point the analysts is concerned with the detail of input and output, the processing required, and the way in which the system will operate on a day-to-day basis. Depending on the level of complexity of the system and the amount and quality of work done at the earlier stages, this phase can take many months of hard work. It is concerned with the computer-oriented design of the system--the detail of the input transactions, the details of the printed reports, screens and other outputs, the file or database structure, the contents of records, the processing required and the efficiency of the system from a computer processing point of view.

Systems analysts start by identifying reports and other outputs the system will produce. Then the specific data on each is pinpointed, including its exact location on the paper, display

screen, or other medium. Usually designers sketch the form or display as they expect it to appear when the system is completed.

The system design also describes the data to be input, calculated or stored. Individual data items and calculation procedures are written in detail. Designers select file structures and storage devices, such as magnetic disk, magnetic tape, or even paper files. The procedures they write tell how to process the data and produce the output.

The documents containing the design specifications use different ways to portray the design-- charts, tables, and special symbols--some of which you may have used and others that may be totally new to you. The detailed design information is passed onto the programming staff so that software development can begin.

Designers are responsible for providing programmer with complete and clearly outlines specifications that state what the software should do. As programming starts, designers are available to answer questions, clarify fuzzy areas, and handle problems that can front the programmers when using the design specifications.

A typical system specification will contain:

1. An introduction converting the relevance of the document and how it has evolved from the previous phases.

2. A description of the system. This is usually an outline in a narrative from with accompanying flow charts, procedure charts, and data flow diagrams or data models.

3. Detailed description of inputs, outputs and files, for example document layouts (input), screen layouts, report layouts, file/record layouts, and database schemes.

4. A description of the control, which operate within the system. This includes control over input and processing, restriction on access (e.g., passwords and control over input and processing, restrictions on access (e.g., passwords and control on output (e.g. numbering of checks)

5. Processing required. This may in fact be handled by specifying generally what watch program in the system is expected to do and by backing this up with individual program specifications issued separately. Arrangements for testing may also be described in this section.

6. Implementation consideration -- arrangements for converting existing files checking parallel runs, production of user procedures and production of computer -related procedures.

7. A detailed development and implementation time-table. This section should list all of the tasks to be done, including individual programs, showing the interrelationship between each task and the planned start and completion date for each task.

8. A back -up plan. This should describe be procedures to be developed for taking security dumps of files, for ensuring system resilience (e.g., duplexing) and for running the system at an alternative site in the event of the computer not being available.

It is at this stage that the first reliable estimate of the amount of computer programming effort required can be produced. Up to this point the estimates are to a large extent informed guesses and what comes out at the end of this exercise may be quite frightening compared with

the previously available estimates. This is a valid reason for ensuring that senior management continues to have an approval role at the conclusion of this stage.

DATA FLOW DIAGRAM

CONTENT LEVEL:

Book Information

Library Management system

Issue/Return

1s Level:

Book Information

Library Management System

Issue/Return

Book issue management

Member Record

Student Information

2s Level:

Book Information

Library Management system

Student

Issue/Return Details Student Information Book Issue Details Student Details

Book Issue

Book Issue Management

Book Details Book Information

Member Record

Student Information

Students Details

Book Details

Book Information

Report Management

Library Management System

ER-DIAGRAM

Library

Book_Id

Book Name

Book

Author Name

Subject

Publication

Issue Address

Student

Phone No.

Student_ id Book Name Class Class Name

Student Name Session Return Date Issue Date Batch Name

Class

Return

Student_ Id Student Name

Author Name

Issue

Book Code Book Name Student Name

Return Date

Book Code Issue Date

Student _Id

Book Name

CODE EFFICIENCY

CODE EFFICIENCY
The degree to which the software makes optimal use of system resources as indicated by the following sub attributes: time behavior, resource behavior. The efficiency is the amount of computing resources and code required by a program to perform its functions.

A design should clearly be very verifiable, complete (implements all the specification), and traceable (all design elements can be traced to some requirements). However, the two most important properties that concerned designers are efficiency and simplicity. Efficiency of any system is concerned with the proper use of scarce resources by the system. The need for efficiency arises due to cost considerations. If some resources are scarce and expansive, it is desirable that those resources be used efficiently. In computer systems, the resources that are most often considered for efficiency are processors time and memory. An efficient system is one that consumes less processors time and require less memory. In earlier days, the efficient use of CPU and memory was important due to the high cost of hardware. Now that the hardware cost are small compared to the software costs, for many software systems traditional efficiency concerns now take a back seat compared to other consideration. One of the exceptions is realtime system, where there are strict execution time constraints. For example, often the tricks used to increase the efficiency of a system result in making the system more complex. Therefore, design decisions frequently involve trade-offs. It is the designers job to recognized the tradeoffs and achieve the best balance. For our purposes, simplicity is the primary property of interest, and therefore the objective of the design process is to produce designs that are simple to understand.

OPTIMIZATION OF CODE

OPTIMIZATION OF CODE
The Term Code Optimization refers to techniques a compiler can employ in an attempt to produce a better object language program than the most obvious for a given source program.

The primary questions are how beneficial a given optimization is and how much its costs to implement. In some situations it is unnecessary to consider any optimization; a quick and straightforward translation of the source program is sufficient. Typical of this situation is a student job which will be run a few times and than discarded. Exactly the opposite is true of a program, which is to be run an indefinitely large number of times. Virtually any amount of time spent improving the running time of the program will be paid back by even a small percentage speedup each time the program is run.

In most cases, however, a program will not run indefinitely without being change and recompile. It is economic therefore to have available an optimizing compiler which make well judged attempts to improve the code it produces. It is important that the optimizing compiler attempt transformations that are likely to improve the code with out costing too much time at compilation. The equation to bear in mind is that the running time we expect to save over the expected numbers of run of the optimized object program must exceed the time spent by the compiler doing the optimization. The trend is to make available for each programming language several compilers, or options within one compiler, that spend varying amounts of time improving the code they generate and produce code of increasing quality. In this way the user can decide how much time he wishes to spend optimizing his program.

Code optimization techniques are generally applied after syntax analysis, usually both before and during code generation.

Code optimization depends on the type of application what is writing. In most cases, you will be optimizing small, tight sections of code that are executed frequently (such as loops or frequently called procedures). Code optimization requires a combination of experience, and eye for detail, and a basic understanding of the architecture of the language and how processors work.

VALIDATION CHECKS

VALIDATION CHECKS
Verification and validation (V & V) is the generic name given to the checking processes which ensure that software conforms to its specification and meets the need of the software customer. The system should be verified and validated at each stage of the software process using documents produced during the previous stage. Verification and validation i.e. starts with requirements reviews and continues through design and code reviews to product testing.

Verification involves checking that the program conforms to its specification. Validation involves checking that the program implemented meets the expectations of the software customer. Requirements validation techniques, such as prototyping, help in this respect. However, flaws and deficiency in the requirements can sometimes only be discovered when the system implementation is complete.

To satisfy the objectives of the V & V process, both static and dynamic techniques of system checking and analysis should be used. Static techniques are concerned with the analysis and checking of system representations such as the requirements document. Design diagram and the program source code. They may be applied at all stages of the process through structured reviews. Dynamic techniques or test involve exercising and implementation. Static techniques include program inspections, analysis and formal verification. Some purists have suggested that these techniques should completely replace dynamic techniques in the verification and validation process and that testing is unnecessary. This is nonsense. Static techniques can only check the correspondence between a program and its specification; they cannot demonstrate that the software is operationally useful.

Although static verification techniques are becoming more widely used, program testing is still the predominant verification and validation technique. Testing involves exercising the program using data like the real data processed by the program. The existence of program defects or inadequacies is inferred from unexpected system output. Testing may be carried out during the implementation phase to verify that the software behaves as intended by its designer and after the implementation is complete. This later testing phase checks conformance with requirements and assesses the reliability of the system.

SYSTEM TESTING

SYSTEM TESTING
It brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Software testing is the process of testing the software product. Effective software testing will contribute to the delivery of higher quality software products, more satisfied users, lower maintenance costs, more accurate, and reliable results. However, ineffective testing will lead to the opposite results; low quality products, unhappy users, increased maintenance costs, unreliable and inaccurate results.

Testing is the major quality control measure used during software development. Its basic function is to detect errors in the software. It is a very expensive process and consumes one-third to one-half of the cost of a typical development project. It is the process of executing program (or a part of a program) with the intention of finding the errors, however, testing cannot show the absence of errors it can show that errors are present. Errors are present within the software under test. This cannot be the aim of software designers they must have designed the software with the aim of producing it with zero errors. Software testing is becoming increasingly important in the earlier part of the software development life cycle, aiming to discover errors before they are deeply embedded within systems. In the software development life cycle the earlier the errors are discovered and removed, the lower is the cost of their removal. The most damaging errors are those, which are not discovered during the testing process and therefore remain when the system goes live.

The testing requires the developers to find errors from their software. It is very difficult for software developer to point out errors from own creations. A good test is one that has a high

probability of finding an as yet undiscovered error. A successful test case unearths an undiscovered error. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. The goal of testing is to uncover requirement, design, and coding errors in the programs. Different levels of testing are used:

Unit testing: A module is tested separately and is often performed by the coder himself simultaneously along with the coding of the module. The purpose is to exercise the different parts of the modules code to detect coding errors.

Integration Testing: The modules are gradually integrated into subsystems, which are then integrated to eventually from the entire system. Integration testing is performed to detect design errors by focusing on testing the interconnection between modules.

System Testing: After the system is put together, it is performed. The system is tested against the system requirement to see if the entire requirement are met and if the system performs as specified by the requirement.

Acceptance Testing: The final stage of initial development, where the software is put into production and runs actual business. It is performed to demonstrate to the client, on the real life data of the client, the operation of the system.

Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall testing process. The test plan specifies conditions that should be tested, different units to be tested, and the manner in which the modules will be integrated together. The final output of the testing phase is the test report and the error report, or a set of such reports (one for each unit tested).

The importance of software testing and its implications with respect to S/W Quality cannot be overemphasized. Because of this importance & the large amount of project effort associated with the system development, it becomes quite necessary to become well planned and through testing. Inadequate testing & no-adequate testing lead's to errors that may be costly when they appear months later. Effective testing translates into cost savings from reduced errors & saves a lot of project efforts. It follows major factors that decide the occurrences of errors in a new design from the very early stage of the development.

1.

Communication between the user & the designer

This factor is handled by frequently communicating with the finance department and the gate entry.

2.

The Time factor for the design

This factor is handled by giving comparatively more time to the designing of the system.

Objectives of System Testing

Once a system has been designed, it is necessary to undergo an exhaustive testing before installing the system. This is important because in some cases a small error, not detected and corrected early before installation, may explode into a much large problem later on. Testing is being performed when users are asked to assist in identifying all possible situations. That might arise as regards the factor that efforts were put to tackle the problem under consideration. A plan was decided to be followed for testing the system. The complete testing procedure was divided into several steps, to be performed at different stages. Tests were to be done as follows: -

Testing Criteria

A. White Box Testing

(i) Transaction path Testing

In this phase each and every condition within a unit program were tested. As and when a loop or condition statement was incorporated into a unit the loops were tested for correctness, for foundry conditions and for not getting into infinite execution cycle. The data used was whatever necessary at that instance. The path of each transaction from origin to destination was tested for reliable results.

(ii) Module Testing

This was carried out during the programming stage itself. Individual programs were tested at the time of coding and necessary changes are made there on to make sure that the modules in the form program, is working satisfactory as regards the expected output from the module. All aspects of the program viz. All choices available were properly tested.

(iii) String Testing

After loading all individual program string was performed for each one of programs where the output generated by one program is used as input by another program. This step was completed after making necessary changes wherever required.

B. Black Box Testing

(i) System Testing

After module and string testing, the systems were tested as a whole system Tests were undertaken to check bundled modules for errors. The errors found in the couple system as a whole was corrected. A testing on the Actual data of the company followed this. During this phase the existing System and this package was running in parallel to enable us to verify and compare the result sets. The following criteria were used while testing the system.

(ii) Output Testing

No systems could be useful if it does not produced the required operation for that matter operation in the required format the outputs generated or displayed by the system under consider was tested by asking the format required by them. (iii) User Acceptance Testing

User acceptance of a system is a key factor for the success of any system. The system under consideration was tested for user acceptance by constantly keeping in touch with the prospected system users at the time of developing and making changes.

Wherever required this was done in regard to the user satisfaction.

Testing Procedure
Different type of checks like duplicate checks, completeness check, validity, checks etc. are incorporated in this system, as the data has to be entered in different forms.

The user is not familiar with new system the data entry screens are designed in such a way that they are

Consistent Compatible Easy to use Had quick response

The following conventions are used while designing of the various screens to make the system user friendly environment.

All the items that are logically related are together. Error and validation messages are provided wherever required. System testing is against its initial objectives, it is done in a simulated

Test Review
Test review is the process, which ensures that testing is carried out, as planned test review decides whether or not the program is ready to ship out for the implementation.

For each data entry screen, we prepared test data with extreme values and under all relevant data- entry screen against real this process helped in rectifying the modules time.

SYSTEM SECURITY MEASURES

SYSTEM SECURITY MEASURES

Security involves both policies and mechanism to protect data and ensure that it is not accessed, altered or deleted without proper authorization. Integrity implies that any properly authorized access, alteration or deletion of the data in the database does not change the validity of the data. Security and integrity though distinct, are related. Implementation of both security and integrity requires that certain controls in the form of constraints must be built in to the system. The DBA, in consultation with the security administration specify these controls. The system enforces the controls by monitoring the actions of the users and limiting their actions with in the constraints for them.

To prevent the dissemination of sensitive information from the data base to unauthorized users and thence to outside competitive or hostile agents, an organization must established effective security policies. Database security policies are guidelines for present and future designers regarding the maintenance of the data base security. Database security mechanisms are the function used to enforced database security policies. These functions could be

implemented by a combination of one or more of the following: administrative control procedures, hardware functions, software function, firmware functions.

The administrative controls procedures are the implementations of security policies to provide protection, external to the database, operating systems, and computer hardware. An example of such type is that a password to provide for a program be a random string of alphanumeric characters, at least eight in length, and be changed regularly.

The operating system must ensure that files belonging to the database are not used directly without proper authorization.

This authorization can consist of the user providing the proper passwords for the file. The operating system must also ensure that illegal users using public communication facilities are not allowed access to the system. Users must be required to use adequate identification and passwords.

The authorization mechanism prepares the user profile for a user and indicates the portion of the database accessible to that user and the mode of access allowed. The enforcement the security policies in the database system require that the system knows the identity of the user making the requests. This in turn requires that before making any request, the user has to identify him / her to the system and authenticate the identification to confirm that the user is in fact the correct person. The simplest and most common authentication scheme used is a The user enters the user name or number and than

password to authenticate the user.

authenticate himself/herself by the password. Typically, these identification/authentication steps are used once for the initial sign-on to the system. However, for sensitive data, this step could be repeated for each operation.

COST ESTIMATION OF THE PROJECT

COST ESTIMATION OF THE PROJECT

Project estimation and project scheduling are carried out together. However, some cost estimation may be required at an early stage of the project before detailed schedules are drawn up. These estimates may be needed to establish a budget for the project or to set a price for the software for a customer.

Once a project is underway, estimates should be updated regularly. This assist with the planning process and allows the effective use of resources. If actual expenditure is significantly greater than the estimates than the project manager must take some action. This may involve applying for additional resources for the project or modifying the work to be done.

There are three parameters involved in computing the total cost of a software development project:

Hardware & Software Costs including maintenance Travel and training costs Effort cost (The costs of paying software engineers).

For most projects, the dominant cost is the effort cost. Computers that are powerful enough for software developments are relatively cheep. Although travel costs can be significant where a project is developed at different sites, they are relatively low for most projects. Further more, the use of e-mail; fax and teleconferencing can reduce the travel required.

Effort costs are not simply the cost of the salaries of the software engineers involved in the project. Organization compute effort costs in terms of overhead costs where they take the

total cost of running the organization and divide this by the number of productive staff. Therefore, the following cost are all part of the total effort cost:

Costs of providing, cooling and lighting office space; Costs of support staff such as Accountant, Secretaries, peon and so on; Costs of networking and communication; Costs of central facilities such as library, recreational facilities and so on; Costs of health insurance and so on.

Typically this overhead factor is somewhere around twice the software engineers salary. Therefore, if a software engineers are paid Rs. 2.5 Lakhs per year, the total cost to the organization is Rs 10 Lakhs per year or Rs 83 thousands per month.

If the project has been computed as part of the project bid to a customer, a decision then has to be made about the price quoted to the customer. Classically, price is simply cost plus profit. However, the relationship between the project cost and the price to the customer is not usually so simple.

Software should be carried out objectively with the aim of accurately predicting the cost to the contractor of developing the software. Software pricing must take into account broader organizational, economic, political and business consideration.

A software designer can develop architecture for a new application, system, or product by defining domain architecture and than populating it with structure point. These structure points are either individual reusable components or packages of reusable components.

Even though structure point is reusable, their qualification, adaptation, integration, and maintenance cost are nontrivial. Before proceeding with reuse, the project manager must

understand the costs associated with the use of structure points.

Since all structure points have a past history, cost data can be collected for each. In an ideal setting, the qualification, adaptation, integration, and maintenance cost associated with each component in a reuse library is maintained for each instance of usage. These data can then be analyzed to develop projected costs for the next instance of reuse.

PERT CHART

PROGRAM EVALUATION REVIEW TECHNIQUE (PERT) CHART

The chart shows clearly that the project consists of the activities of Analysis, design, front-end coding, back-end coding and report generation.

The figure shows that the project will start on March 15, 2010. The analysis work will start on 20 March, 2010. Since the analysis is estimated to take 30 days, any activity that follows the design may start on April 23, 2010 at the earliest. The dependency arrows help us compute these earliest start dates based on our estimates of the duration of each activity. These dates are shown in the figure. We could also compute the earliest finish dates or latest start dates or latest finish dates, depending on the kind of analysis we want to perform.

The chart shows that the path through the project that consists of the design activity is the critical path for the project. Any delay in any activity in this path will cause a delay in the entire project. We will clearly want to monitor the activities on the critical path much more closely than the other activities.

Front end coding

Start

Analysis

Design

Testing

Report Generation

Back end coding

Finish

SOFTWARE DEVLOPMENT LIFE CYCLE

INTRODUCTION
Software Development Life Cycle (SDLC) is the overall process of developing information software through a multi step process from investigation of initial requirements through analysis, design, coding, testing and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages. Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.

To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, Iterative enhancement, spiral, and prototyping. The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. The basic objective of software is to develop methods and procedures for software development that can scale up for a large systems and that can be used to consistently produce high quality software at low cost and with a small cycle time. i.e. the key objectives are consistency, low cost, high quality ,small cycle time and scalability. Design of a proper software processes and their control then becomes the primary goal of software engineering. It is this focus on process that distinguishes it from most other computing disciplines. Most other computing disciplines focus on some type of product- algorithms, operating system, databases, etc.

The software process must necessarily have components of project management in addition to procedures for development. To better manage the development process and to achieve

consistency, it is essential that the software development done in phases. A phased development process is central to the software development life cycle. Besides having a phased development process, it is essential that monitoring of a project for quality and cost involve is objective of our problem.

A development process consists of various phases, each phase ending with a defined output. The phases are performed in an order specified by the process model being followed. The main reason for having a phased process is that it breaks the problem of developing software into successfully performing a set of phases, each handling a different concern of software development. It allows proper checking for quality and progress for given software during development (end of phases). One phase would have to wait until the end what software has been produced. This will not work for large system. Hence for managing the complexity, project tracking, and quality, all the development process consists of set of phases. Various process models have been proposed for developing software. Each organization that follows a process has its own version. The different process can have different activities.

In general, we can say that any problem solving in software must consist of these activities: Requirement specification for understanding and clearly stating the problem. Design for deciding a plan for a solution. Coding for implementing the planned solution Testing for verifying the programs

For small problem these activities may not be clearly defined, and no written record of the activities may be kept. But for the complex and large system where the problem solving activity may last couple of years and where many persons are involved in development, and each of these four problems solving activities has to be done formally. Each of these activities is a major task for large software projects.

DESIGN & CODING

SOFTWARE CODING
Once the design is complete, most of the major decisions about the system have been made. Coding phase are often depend on the programming language chosen, are not specified during design phase. The goal of the coding phase is to translate the design of the system into code in a given programming language. The aim of this phase is to implement the design in the best possible manner.

The coding phase both affects both testing and maintenance. If the developer use well written code that can reduce the testing and maintenance effort. The cost of testing and maintenance phase is higher than the coding phase. During the coding phase programmer has written a programs that are easy to write. Simplicity and clarity should be strived during the coding phase.

The main thing arises in the coding phase is to write a program with the help of structured programming. The goal of the structured programming is to linearize the control flow in the program. It means that the program text should be organized as a sequence of statements, and during execution the statement are executed in the sequence given in the program. In case of structured programming, a few single-entry-single-exit constructs should be used. These constructs incl8ude selection (if-then-else) and iteration (while-do, repeat-until, etc). With the help of these constructs it is possible to construct a program as a sequence of single-entry-singleexit constructs.

IMPLEMENTATION AND MAINTENANCE

SOFTWARE MAINTENANCE
What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever. After installation phase is completed and the user staff is adjusted to the changes created by the candidate system, evaluation and maintenance begin. The importance of maintenance is to continue to bring the new system to standards. Software maintenance is a task that every development group has to face when the software is delivered to the customers site, installed and is operational. The time spent and effort required keeping software operational after release is very significant and consumes about 40-70% of the cost of the entire life cycle.

The term Maintenance is a little strange when applied to software. In common speech, it means fixing things that break or wear out. In software nothing wears out; it is either wring from beginning, or we decode later that we want to do something different. It is a very broad activity that includes error corrections, enhancements of capabilities, deletion of obsolete capabilities, and optimization.

There are three major categories of software maintenance:

Corrective Maintenance: This refers to modifications initiated by defects in the software. It means repairing processing or performances failures or making changes because of the previously uncorrected problems. A defect can result from design errors, logic errors and coding errors. Design errors occur when, changes made to the software are incorrect, incomplete, wrongly communicated or the change request is misunderstand. Logic errors result from invalid

tests and conclusions, incorrect implementation of design specification, faulty logic flow or incomplete test data. Coding errors are caused by data processing errors and system performances errors.

Adaptive Maintenance: It includes modifying the software to match changes in the everchanging environment. The term environment in this context refers to the totally of all conditions and influences which act from outside upon the software, for example, business rules, government policies, work patterns, software and hardware operating platforms. This type of maintenance includes any work initiated as a consequence of moving the software to a different hardware or software platform-compiler, operating system or new processor. It means changing the program function.

Perfective Maintenance: It means improving processing efficiency or performance, or restructuring the software to improve changeability. When the software becomes useful, the user trend to experiment with the new cases beyond the scope for which it was initially developed. It means enhancing the performance or modifying the programs to respond to users additional or changing needs.

In comparison with all the three maintenance, perfective takes more time and spent more money.

Maintenance covers a wide range of activities, including correcting coding and design errors, updating documentation and test data and upgrading user support. Maintenance means restoring something to its original condition unlike hardware, however, software does not wear out, it is corrected. A major problem with software maintenance is its labor-intensive nature.

FORMS

Private Sub Form Load() frmSplash.Left = 25000 frmSplash.Top = 12000 Pb.Value = 0 Label1.Caption = "" End Sub Private Sub Timer1_Timer () Label1.Caption = "Loading Library Management System..." Pb.Value = Pb.Value + 1 If Pb.Value >= 100 Then PASSWORD. Show Unload Me End If End Sub Private Sub Timer2_Timer () Label1.Visible = Not (Label1.Visible) End Sub

Private Sub Command1_Click () f=0 If Text1.Text = "" And Text2.Text = "" Then MsgBox "please enter user_id & password Text1.Text = "" Else If Text1.Text = "iftm@library" And Text2.Text = "IFTM" Then Unload Me MDIForm1.Show Else If f = 0 Then MsgBox "User Name or Password Incorrect ", vbInformation, "Login Error" Text1.Text = "" Text2.Text = "" End If End Sub Private Sub Timer1_Timer () Label1.Caption = "LIBRARY MANAGEMENT SYSTEM" End Sub Private Sub Timer2_Timer () Label1.Visible = Not (Label1.Visible) End Sub

Private Sub Bkinfo_Click() Bookinfo.Show End Sub Private Sub Exitissue_Click() End End Sub Private Sub Exitreturn_Click() End End Sub Private Sub Exitst_Click() End End Sub Private Sub InfoExit_Click() End End Sub Private Sub Openbook_Click() Bookissue.Show End Sub Private Sub Openre_Click() ReturnForm.Show End Sub Private Sub Openst_Click() Studentinfo.Show End Sub Private Sub Reform Click () ReturnForm.Show End Sub Private Sub StInfo_Click() Studentinfo.Show End Sub

Private Sub Command1_Click() Adodc1.Recordset.Save End Sub Private Sub Command2_Click() Command3.Enabled = False Text4.Enabled = False Text5.Enabled = False End Sub Private Sub Command3_Click() Command2.Enabled = False Text4.Enabled = False Text5.Enabled = False End Sub Private Sub Command4_Click() Unload Me Bookissue.Show End Sub Private Sub Command5_Click() Unload Me ReturnForm.Show End Sub Private Sub Command6_Click() Unload Me MDIForm1.Show End Sub

Private Sub Command1_Click() Unload Me Bookissue.Show End Sub Private Sub Command2_Click() Command1.Enabled = False End Sub Private Sub Command3_Click() Unload Me Bookissue.Show End Sub Private Sub Command4_Click() Unload Me ReturnForm.Show End Sub Private Sub Command5_Click() Unload Me MDIForm1.Show End Sub Private Sub Command6_Click() Adodc1.Recordset.Save End Sub

Private Sub Command1_Click() Adodc1.Recordset.Save End Sub Private Sub Command2_Click() Adodc1.Recordset.Requery Command3.Enabled = False Text1.Enabled = False Text2.Enabled = False Text3.Enabled = False Text7.Enabled = False Text8.Enabled = False Combo1.Enabled = False End Sub Private Sub Command3_Click() Adodc1.Recordset.Requery Command2.Enabled = False Text2.Enabled = False Text3.Enabled = False Text7.Enabled = False Text8.Enabled = False End Sub Private Sub Command4_Click() Unload Me ReturnForm.Show End Sub Private Sub Command5_Click() Unload Me Studentinfo.Show End Sub Private Sub Command6_Click() Unload Me MDIForm1.Show End Sub

Private Sub Command1_Click() Adodc1.Recordset.Save End Sub Private Sub Command2_Click() Unload Me Bookissue.Show End Sub Private Sub Command3_Click() Unload Me Studentinfo.Show End Sub Private Sub Command4_Click() Unload Me MDIForm1.Show End Sub

DATABASE

TABLE 1:- BOOK INFORMATION S.NO

1. 2. 3. 4. 5.

NAME
Book Name Author Name Book Id Subject Publisher

Date Type
Text Text Integer Text Text

Length
100 100 2 100 100

Description
Name of the Book Name of the Author Unique identification of Book Subject Publication of Book

TABLE 2:- BOOK ISSUE

S.NO
1. 2. 3. 4. 5. 6. 7. 8. 9.

NAME
Batch Name Class Student Id Student Name Book Name Book Code Author Name Issue Date Return Date

Date Type
Text Text Integer Text Text Integer Text Integer Integer

Length
100 100 2 100 100 2 100 2 2

Description
Name of the batch Name of the class Unique identification of student Name of the student Name of the book Code of the book Name of the author Date of issue Date of return

TABEL 3:- BOOK RETURN S.NO

1. 2. 3. 4. 5. 6. 7. 8.

NAME
Batch Name Class Student Id Student Name Book Name Book Code Issue Date Return Date

Date type
Text Text Integer Text Text Integer Integer Integer

length
100 100 2 100 100 2 2 2

Description
Name of the book Class Unique identification of student Name of the student Name of the book Code of the book Date of issue Date of return

TABLE 4:-STUDENT INFORMATION

S.NO
1. 2. 3. 4. 5. 6.

NAME
Session Class Name Student Id Student Name Phone Num Address

Date type
Integer Text Integer Text Double Double

Length
2 100 2 100 8 8

Description
Session Name of the class Unique identification of student Name of the student Phone num Address

BIBLOGRAPHY

BIBLIOGRAPHY
1. An Introduction to Database Management System by Bipin C Desai. 2. Software Engineering by Roger S. Pressman.. 3. Software Engineering by Jalote. 4. PL/SQL by Evan Barros. 5. An Introduction to Database Management System by C. J. Date. 6. Database Concepts by Korth, Silbertz 7. Guide to Visual Basic 6.0 by Norton & Groh