ONLINE TOURISM MANAGEMENT MANAGEMENT PROJECT REPORT | ONLINE TOURISM MANAGEMENT SYSTEM

Project Overview

All details of Customer, Tours, Packages, Country, State, registration etc are maintained in registers. All Payments & dues are also maintained in registers. All Bills are manually created and send at a desired place for further use. The daily-to-daily entries are also being manual.

Preliminary the investigation took me to the Accounts room of Agency, where I came across the current working process. Although the process of maintaining data is not a recorded one as such there were no documents to be reviewed in order to determine the efficacy of the current working process. So I had to emphasize on the observation I made while in the office. In order to complement my onsite observations, I undertook a simple interview of office bearers. The results of which are broadly cataloged below.

System Analysis

Identification Of Need

The complete understanding of software requirements is essential to the success of a software development effort. The requirements analysis task is a process of discovery, refinement modeling and specification. The software scope initially established by the system engineer and refined during software project planning is refined in detail. Modular of the required data, information and control flow, and operational behavior are created. Alternative solution are analyzed and allocated to various software elements.

Both developer and customer take an active role in requirements analysis and specification. The customer attempts to reformulate a sometimes-nebulous concept of software function and performance into concrete detail. The developer acts as interrogator consultant and problem solver.

Requirements analysis is a software engineering task that bridges the gap between system level software allocation and software design.

Requirement analysis enabler the system engineer to specify software function and performance indicate software’s interface with other system elements and establish constraints that software must meet.

Software requirements analysis may be divided into five areas of effort:

(a) Problem recognition.

(b) Evaluation and synthesis

(c) Modeling

(d) Specification

(e) Review

Initially, the analyst studies the system specification and the software project plan. Problem evaluation and solution synthesis is the next major area of effort for analysis. Upon evaluating current problems and desired information (input and output) the analyst begins to synthesize one or more solutions.

During the evaluation and solution synthesis activity, the analyst creates models of the system in an effort to better understand data and control flow, functional processing and behavioral operation, and information content. The model serves as a foundation for software design and as the basis for the creation of a specification for the software.

Preliminary Investigation

Present system is manual. The working of the organization May be described as:

All details of Customer, Tours, Packages, Country, State, registration etc are maintained in registers. All Payments & dues are also maintained in registers. All Bills are manually created, and send at desired place for further use. The daily-to-daily entries are also being manually.

Preliminary investigation took me to the Accounts room of Agency, where I came across the current working process. Although the process of maintaining data is not a recorded one as such there were no documents to be reviewed in order to determine efficacy of the current working process. So I had to emphasize on the observation I made while in the office. In order to complement my onsite observations I undertook a simple interview of office bearers. The results of which are broadly catalogued below.

In concurrence with onsite observation I conducted some interviews. To get a closer look at the present working culture and identify the problem domain I talked to some of office bearers. I presented them with the following set of questions.

Questionnaire:

Some general questions-

1.Who is behind the request for this work?

2.Who will use the software?

3.Why do you want this software?

4.Can you show me the environment in which the software will be used?

5.What is your requirement?

6.What will be the economic benefit of a successful solution?

Feasibility Study

Before getting started on the new system it was important to determine the feasibility involved in the developed system so that the new system development could be develop. Feasibility is the determination of whether or not a project is not worth doing. The project followed in making this determination is called a feasibility study. This type of study determines if a project can and should Be Taken. Once it has been determined that project is feasible, the analyst can go ahead and the prepare the project specification which finalizes project requirements.

Generally, feasibility studies are undertaken within tight time constraints and Normally culminate in a written and feasibility report.

The developed system is started after considering the main three type of feasibilities which are discussed below: -

1)-Technical feasibility
2)-Operational feasibility

3)-Economic feasibility

Technical Feasibility

As we know the technical feasibility is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may very considerably, but might include:

The facility to produce outputs in a given time.
Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed.
Facility to communicate data to distinct location.

In examination technical feasibility, configuration of the system is given more importance than the actual make of hardware. The configuration should give the complete picture about the system’s requirements: How many workstations are required, how these units are interconnected so that they could operate and communicate smoothly.

Economic Feasibility

Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as cost/benefits analysis the procedure is to determine the benefits and savings that are expected from a purposed system and compare with costs.

If benefits out weigh cost, a decision is taken to design and implement the system otherwise further justification or alternative in the proposed system will have to be made if it is to have a chance of being approved. This is an on going effort that improves in accuracy at each phase of the system life cycle.

The analysis part also clears the doubt of economic problems could be possible in developing the system. As already mentioned that the company has to just pay the developed software cost and not other investment is needed at the time of implementation of the new system as the preliminary requirement are already exist in the company.

Since the cost difference between the present system and the new proposed computerized system will be large. Considering the fact that new system will require only one time monetary investment whereas the present system keeps on adding to the cost in a daily basis. We can conclude that the breakeven point will be reached

within a year, making this proposed computerized news management system economically feasible.

Operational Feasibility

Proposed projects are beneficial only if they can be turned into information system that will meet the operating requirements of the organization. This test of feasibility asks if the system will work when it developed and installed. Are there major barriers to implementation? Some of the important questions that are useful to test the operational feasibility of a project are given below:

· Is there sufficient support for the project from the implementation? From user? If the present system is well liked and used to the extent that persons will not be able to see reasons for change, there may be resistance.

· 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.

· Have the user been involved in the planning and development of the project? If they are involved at the earliest stage of project development, the chances of resistance can be possibly reduced.

· Will the proposed system cause harm? Will it produce poorer result in any case or area? Will the performance of staff member fall down after implementation?

Issue that appears to be quite minor at the early stage can grow into major problem after implementation. Therefore, it is always advisable to consider operational aspects carefully. The system is developed in keeping mind that it should be user friendly and easy to operate hence the system is operational feasible.

Software Engineering Paradigm Applied

To develop the system Proto Type Modal is applied as the company wanted to see the software development process and appearance of the software so that the idea of functionality of the system can be understood. The software developed in three phases in first phase the dry proto type is developed in which after the analysis the screens are designed and no validations are performed and also no database functionality is incorporated. After the demonstration of dry proto type suggestions from the client are noted and the development process is moved to the second phase i.e. wet prototype the actual designed is incorporated, validations are performed and the software is submitted to the user for acceptance and testing and then after final submission of the software is produced with user manual. To under stand the better functionality of the Prototype modal the applied modal is described here given below:

Prototype Type Model:-

In general Customer defines a set of objectives for software, but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability an operating system or the form the human machine interaction should have.

In such situations, a prototyping paradigm offers the best approach. The prototyping paradigm starts with requirements gathering. Developer and customer define the overall objectives for the software, identify requirements and outline areas where definition is necessary. A “quick design “ than focuses on aspects of the software that are visible to the customer /user. The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and is used of refine requirement for the software to be developed. Iteration occurs, as the prototype is developed to satisfy the needs of the customer and enabling the developer to better understanding what needs to be done.

The prototype serves as a mechanism for identifying software requirements if a working prototype is built, the developer uses existing program fragments or applies tools to make working program quickly.

Software Requirement Specification:-

The software requirements specification is produced at the culmination of the analysis task. The function and performance allocated to software as part of system engineering are refined by establishing a complete information description a detailed functional and behavioral description, a indications of performance requirements and design constraints, appropriate validation criteria and other data pertinent to requirements.

1. Introduction

a. Purpose

b. Scope

c. Definition, Acronyms, Abbreviations

d. References

e. Developer’s Responsibilities Overview

2. General Description

a. Vehicle Functions Overview

b. User Characteristics

c. General Constraints

d. General Assumptions and Dependencies

3. Specific Requirements

a. Inputs and Outputs

b. Functional Requirements

c. External Interface Requirements

d. Performance Constraints

e. Design Constraints

(i) Software Constraints

(ii) Hardware Constraints

4. Validation and Criteria

a. Performance bounds

b. Classes of tests

c. Expected Software response

d. Special Considerations

5. Acceptance Criteria

1. Introduction: -

This is the requirements document for the project that will be used throughout the work. The system to be developed is for front office and financial work of agency, based on the inputs given. This document follows the IEEE standard for a requirement specification document, with some variations.

a). Purpose:

The purpose of this document is to describe the requirements of agency. It also describes the interfaces for the system.

b). Scope:

This document is the only one that describes the requirements of the system. It is meant for use by the developers and will be the basis for validating the final delivered system. Any changes made to the requirements in the future have to go through a formal change approval process. The developer is responsible for asking for clarifications, where necessary, and will not make any alterations without the permission of the client.

c). Definitions, Acronyms, Abbreviations:

Not applicable.

d). References:

Not applicable.

e). Developer’s Responsibilities Overview:

The developer is responsible for (i) developing the system, (ii) installing the software on the client’s hardware, (iii) conducting any user training that might be needed for using the system, and (iv) maintaining the system for a period of one year after installation.

2.General Description: -

a). Functions Overview:

In agency there is a counter for booking and various queries of the customers can be solved with ease on one table. As the software provide all information customer, registration etc provided by the agency.

b). User Characteristics:

The main users of this system will be the registration department and accounts department, who are somewhat literate with computers and can use programs efficiently.

c). General Constraints:

The system should run on win 95 /98/2000 or above.

d). General Assumptions and Dependencies:

Not applicable.

3. Specific Requirements:

a). Inputs and Outputs:

The system has all the details regarding the Customer, Tours, Packages, Country, State, employee, etc are maintained etc. The system has several inputs in form of data entry and several outputs in form of bills, reports etc.

The forms under the heading General Entries are registration, salary, leave etc are maintained.

From one the bill is generated and the other helps in report generation. Here also, the customer gets the desired registration and accordingly the bills and report are generated.

b). Functional Requirements:

It present description of each function required to solve the problem. A processing narrative is provided for each function, design constraints are stated and justified, performance characteristics are stated, and one or more diagrams are included to graphically represent the overall structure of the software and interplay among software functions and other system elements under this topic, the functional working of the various modules where give the complete picture for the data flow from one location to other.

c). External Interface Requirements:

Only one user command is required. The file name must be prompted by the system in status bar.

d). Performance Constraints:

The reports and bills should be printed in less than 1 minute.

e). Design Constraints:

The system is to run under the WINDOWS operating system.

4.Validation Criteria:

Probably the most important section of a software requirements specification is validation Criteria. The specification of validation criteria acts as an implicit review of all other requirements. The tests must be conducted to validate function, performance and constraints.

In this project I have try the various steps in testing the links and connectivity of the data Directorate of public grievances takes up a grievances where it is satisfied that eh matter has not been dealt with by the concerned SSA in a fair, just or objective manner or has been unduly delayed. It may take up such a care for investigation, call for a report and or file from the concerned SSA and ask them to reconsider the matter and to arrive at a fair decision in a time bound manner.

5. Acceptance Criteria:

Before accepting the system, the developer must demonstrate that the system works on the course data for the last 4 semesters. The developer will have to show through test cases that all conditions are satisfied.

System Design

1. Input Design:

When designing input, the objective is to ensure that the data that will be processed by the system is collected and entered into the system efficiently, according to the specified requirements, and with the minimum of errors. In description with the client, the designer will choose a method of input, which is cost effective and acceptable to the end users. The process of input design, like output design, which was described earlier, consists of four stages.

· Firstly, identifying the inputs into the system, by listing the data flows on the required logical data flow diagram which cross the system boundary on their way in

· Then determining the content of these inputs by inspecting the data dictionary

· Next choosing an appropriate input device to change the user's data into a form which can be read and processed by the computer system

· And finally completing the detailed design work involved in specifying forms, input screens and other data collection documents.

Project development required complete analysis of system right from the scratch Analysis of the system required great attention on big as well as minute transactions This required exhaustive study of Manual management system. Manual system was divided in various sections, which were dealt individually. Getting detail of each section was a tedious and a time consuming task. This involved various meetings with head of each individual section. After getting detail of each section whole process was re-evaluated and a proper design for the system was brought into existence. Design was discussed with the Workshop’s Manager and was further improved by eliminating some loopholes. Designing process is carried on very carefully as this serves as backbone for development of any software. Thus synopsis of the package was prepared.

After Design phase attention was laid upon source code of the package.

Whole project was divided into small modules. Source code for each module was individually prepared and tested both syntactically and logically (Modular Testing). In cases modules were further divided into units and tested (Unit Testing). These units were merged to get modules and these modules were further available for integration. This sort of testing comes under Integration Testing. Various tests were conducted on the package to demonstrate that the system satisfies all the requirements stated in requirements documentation. This is Acceptance Testing.

Phase 1 of the package has been prepared and is running successfully (Implementation).

Maintenance of the package would require further enhancement of the package as per requirements of the company.

2. Data Base Model Apply:

The data in a database is organized according to the data structure 'imposed' upon it by the physical data model. The physical data model is normally produced during the physical data design stage in the development life cycle and tailored specifically to the selected, or imposed, database type.

The rules regarding this implementation and its subsequent optimization will vary widely according to the type of DBMS.

The Database Management Systems available today can be grouped into four types.

These are:

File Management Systems (FMS)

Hierarchical Databases (HDS)

Network Databases (NDS)

Relational Databases (RDBMS)- The relational database model resulted from an IBM-sponsored research project by Dr. E.F.Codd. The relation model attempts to overcome some the failings of the hierarchical and network database model, and provides easy-to-use and flexible data structure.

The relational model includes data structure (table), operators that can be used to manage the data in data structure, and some integrity rules that ensure that the data obeys the business rules defined for the system.

The relational model is based on relational algebra concepts and theory and, in the early days, used some of the same technology to describe the processing that could be performed on the data structures For example, relational theory uses the words "relations" to mean tables, "tuples" to mean rows, and "attributes" to mean columns in table

Relational database are the most common type of database management systems in use today.

Relational database includes Oracle, DB2, Ingress, Informix, Sybase, and SQL Server.

Another important concept in relational databases is that relationships between tables are not hard-coded in the structure of the data that is there are no pointers in the data to relate one table to another. This means that you can specify the relationships between two sets of data at development time rather than when the tables are first created. This greatly improves the flexibility of the database management system.

Relational Database Properties- A relational database management system (RDBMS) has the following properties:

§ Represents data in the form of tables

§ Does not hard-code relationships between tables

§ Doesn't require the user to understand its physical implementation

§ Provides information about its contents and structure in system tables

§ Can be manipulated through SQL commands

§ Supports the concept of NULL values

In this project the database used is SQL.

Overview of SQL:

A relational database is an extremely simple way of thinking about and managing the data used in a business. It is nothing more than a collection of tables of data.

A relational database management system such as SQL server gives you a way of doing things in an understandable and reasonably uncompelled way. SQL server basically does three things:

Lets you put data into it.
Keeps the data.
Lets you get the data out and work with it.

The information stored in SQL server is kept in tables. There are three major characteristics of the tables.

Ø Columns

Ø Rows

Ø Name

3. Tables of Information:

SQL stores information in tables. These tables have one or more columns. The columns heading describe the kind of information kept in the column. The information is stored row after row. Each unique set of data gets is own row.

Even though the tables are independent, we can easily see that they are related. A column in one table is related to a column in the other table. This relationship is the basis for the name relational database. This is the basic idea of a relational (sometimes called a relational model). Data is stored in tables. Tables have columns, rows, and names. Tables can be related to each other if each has a column with a common type of information.

The retrieval of data from a database can be faster with primary key. A primary key is a field that uniquely identifies each record in a table is called a foreign key.

To cascade updating and deletion of related fields, we enforce the referential integrity. Whenever a change is made to primary key.

When two tables have single common field, they are said to be 'related'. The types of relationships, which the tables in SQL can have, are:

Ø One to One

Ø One to many

Ø Many to One

Ø Many to many

SQL server, objects can be defined as reusable software codes which are location independent and perform a specific task on any application environment with little or no change to the code. SQL Brands, Models are based on a concept known as the “Client/Server Technology”. This concept involves segregating the processing of an application between two systems. A client or front-end database application also interacts with the database by requesting and receiving information from the ‘database server’. It acts as an interface between the user and the database. Further, it also checks for validation against the data entered by the user. The database server or backend is used to manage the database tables optimally among multiple clients who concurrently request the server for the same data. It also enforces data integrity across all client applications and controls database access and controls database access and other security requirements.

SQL is a RDBMS and consists of a comprehensive set of application building and end-user Brands, Models, aimed at providing complete solutions. SQL applications are potable across a variety of platforms and operating systems. It provides a flexible DBMS called SQL server for storage and management of information used by all applications.

An object relational database management system (ORDBMS) extends the capabilities of the RDBMS to support object-oriented concepts. We can use Oracle as an RDBMS or take advantage of its object-oriented features. The information stored in SQL is kept in tables. The three major characteristics of most tables are columns, rows and a name.

Tables can be related to each other if each has a column with a common type of information.

SQL avoids specialized, academic terminology in order to make the vehicle more approachable. A column may be called an “attribute”, a row may be called a “tuple”, and a table may be called an entity.

SQL was the first company to release a vehicle that used the English-based Structured Query Language or SQL. This language allows end users to extract information themselves, without using a systems group for every little report. Oracle’s query language has rules of grammar and syntax. SQL is an astonishingly capable tool.

Some benefits of using SQL are:

Ø Large Databases

Ø Many Users (multiple user can work)

Ø Portable

Ø Backup & Recovery features

Ø Security

Ø Client/Server Support

Ø Data entities & Key Fields

Ø Entity & Attributes

Entity- An entity is an object, place, person, concept, or activity about which an enterprises record data.

Attribute- An attribute is the characteristic property of an existing entity. The difference between attribute type and attribute instance has to be understood.

4.Relationship Diagrams

A relationship is defined as "an association among entities". A relationship type is an association of entity, while a relationship instance is an association of entity instances.

One-to-One

If in an entity there is a one field, which is not repeated, and another entity it is related and also entered once is called One-to-One relationship.

One-to-Many (or Many-to-One)

In One-to-Many relationship in one table field is not repeated and in another table which is related to the first table the field has to be repeated like in the current project in consumer master file consumer number is not repeated and booking file there is repetitions of consumer number whenever consumer booked the refill.

Many-to-Many

In many to many relation ship both table can have repetitive data.

5. Screen Designs

The quality of screen design can have a direct impact on the performance of the users of the system, and the designer needs to consider the format as well as the content of the screens on which the dialogue, or interaction, between the user and the system is based. A number of features of screen design are worth discussing here:

· Text – Must be easily readable. In addition to choosing an appropriate font and size for the characters, readability can be improve by using lower and upper case letters, rather than the approach some times adapted in screen design of using all upper case evenly

Space text, with an unjustified right margin is easier to read than right justified text, which has spaces of varying sizes between the words. The use of concise phrase, familiar vocabulary and appropriate abbreviations make it easier for the reader to understand the text. The most visible section of the screen is the upper left-hand corner

And it is a good idea to locate important messages in this area. Again it is important that

The designers understand the characteristics of the in user in order to deliver quality Brands, Models. Beginners, who are usually looking at their fingers, will noticed error messages

Which appear on the button line on the screen, where as the top right corner of the screen is a more appropriate location for experienced keyboard operators.

· Colour- another set of the design option is possible, in addition to those described above, if the display is in colour. Being in a different colour to be rest or being enclosed in a coloured box can highlight text. Background colours can be changed or a design convention can be used in which different types of information are displayed in different colours. The consistent use of colours on screens within the same system is important, and the designer must be wary of using to many colors or creating lurid combination as these will work against the effectiveness of the screen design.

· Graphics – can be used to good effect for displaying information, especially trends in numerical data. They can be coloured, solid, three-dimensional or animated, and the designer must decided on what is appropriate to the purpose. Another use of graphics is as an integral part of the structure of the dialogue-known as a graphical user interface (GUI).

· Animation- although this is little used in screen design, it can be a powerful technique for attracting the attention of the user, because the eye is always drawn to a moving object; to mark the position of an object, for example, a blinking cursor can be used; or to communicate a message, a clock with a moving hand , or an hourglass with moving sand, indicate to the user that they have to wait while some processing is carried out by the machine.

7.File Design

The way in which data is organized and accessed can be crucial to the effectiveness of a computer system. Data can be stored in files or in a database.

Types of Files

Master file contain records, which are critical to the system and its users. The records in master file store permanent information of long-term value to an organization and are used regularly in the organization’s key system.

Transaction files contain transient data relating to business activities, such as telephone calls logged. They are used mainly to update master files. Transaction files usually contain records relating to a particular period part of time.

8. Dialog Types

A. Common Dialogs

There are a number of different approaches which can be taken when design conversation or dialog between the user and the computer system. Essentially a dialogue consists of the user responding to a prompt from the computer by providing input. The computer processes this input and a response is output to the screen, which in turn may prompt the user for the next input. The main dialogue types are summarized below. It is up to the designers having considered the alternatives, to decide which of these is most appropriate, based on the requirements and characteristic of the end users.

B. Menus

Menus are widely used in screen design because they require minimal effort, and skill, on the part of the user. This in turn reduces the training requirement when preparing individuals to used the system. A common approach is to structure the menus hierarchically in a' nest'; selecting an option is chosen, and so on. This allows the number of alternatives on any one screen to be kept to a minimum.

C. User Support

When designing off-line help, which is usually paper-based but which could also be in the form of audio or videotapes, a key principle is to think the needs of the users who will be referring to them. They will be keen to find a quick solution to their problem.

And will frequently be anxious and in a hurry. Manuals should therefore be kept simple and not overloaded with information, and should be relevant to the common types of problems encountered by users. The most useful way of developing such material is by working closely with end users and modifying the text in the light of the difficulties they experience when using the system.

On-Line help can be basic, usually in a concise form with reference to a manual where more detailed information can be obtained; it can be context-sensitive, providing appropriate information about the particular function being used at the time the help is requested; or it can be intelligent, responsive to the route a user has followed while navigating through an application and their needs when the help screen is called.

User support will also take the form of training for those who will be interacting with the computer system. Again, this can be provided off-line,

in the form of a training event (either a taught course or an open learning programme), or on-line, as a tutorial, which takes the user through the functions of the system and then through a series of structured exercises.

It must not be forgotten, when designing a computer system that users are part of this system, and can be considered almost as an extension of the computer. Their role must be defined and designed like any other component of the system, and thought must be given early on as to how they can best be supported in carrying out this role.

Code Efficiency

It has been recognized that good coding style can overcome many of the deficiencies of a primitive programming language, while poor styles can defeat the intent of an excellent language. The goal of a good coding style is to provide easily understood, straight–forward and elegant code. The guidelines for coding include:

Use of a few standard control constants.

Use of unconditional branching (go to) in a disciplined manner.

Introduction of user-defined data types to model entities in the problem domain.

Hiding of data structures behind access functions.

Providing standard documentation prologues for each subprogram and compilation unit.

Use of indentation, parenthesis, and blank spaces, blank lines, borders and comments to enhance readability.

Optimization Of Code

Object oriented programming principles have been implemented during coding for this software. Choice of Visual Basic as a language for my project was based on the fact that this language utilizes the principles of OOPS to a greater degree. By creating code objects, code reusability increases to a greater extent. With less code more efficiency can be achieved. Object-oriented means that we organize software as a collection of discrete object that incorporate both data structure and behavior. In conventional programming, data structure and behavior are loosely connected.

Implementation

Introduction: -

A crucial phase in then systems life cycle is the successful implementation of the new system design. Implementation means converting a new system design into operation. This creating computer-compatible files, training the operating staff before the system is up and running. A major factor in conversion is not disrupting the functioning of the organization.

The implementation phase of software development is also concerned with translating design specification into source code. It is necessary to write source code and internal and documentation so that conformance of the code to its specification can be easily verified, and so that debugging, testing and modification are eased. This can be achieved by making the source code as clear and straight forward as possible. The implementation team should therefore be provided with-defined set of software requirements, an architectural design specification and a detailed design description.

User training is another important area, which is responsible for minimizing resistance to change and giving the new system a chance to provide its worth. Training aids, such as user-friendly manuals, data dictionary, and jobs performance aids that communication information about the new system; help-screens provide the user with a good start on the new system.

Following conversion, it is desirable to review the performance of the system and to evaluate it against established criteria. Software maintenance follows conversion, which includes minor enhancements or corrections to problems that surface late in the system's operating.

Conversion:

The objective of conversion is to put the system into operation while holding costs, risks and personal problems to a minimum. It involves three major steps:

Creating computer-compatible files

Training the operating staff

Installing hardware/software

Procedure and documents are unique to the conversion phase. These are shown below:

Conversion begins with a review of the project plan, the system test documentation, and the implementation plan. The parties involved are the user, the project team, programmers, and operators.

The conversion portion of the implementation plan is finalized and approved.

Files are converted.

Parallel processing between the existing and the new systems is initiated.

Results of computer runs and operators for the new system are logged on a special form.

Assuming no problems, parallel processing is discounted. Implementation results are documented for reference.

Conversion is completed. Plans for the post-implementation review are prepared. Following the review, the new subsystem is officially operational.

File Conversion: -

File conversion involves capturing data and creating a computer file from existing files. There can be problems like staff shortage for loading data. Also, specialized training necessary tom prepares records in accordance with the new system specifications. In most cases, an outside agency performs this function for a flat rate .If a computerized system already exists, then copying existing files for the new system is a concern area. If a computerized system already exists, then copying existing files for the new system is a concern area. Program can be written to copy files intact for the new system and test programs on both systems. A file comparison program can be used for this purpose.

Many systems are prone to errors because of insufficient attention given to data entry control or protective features like audit control trails. These items must be part of the overall plan for conversion. Before a data entry operator starts working, a data entry validation program can be written to keep track of wrong data entered.

At the time installation of the software it is required that SQL server must be installed on the server of the company and it must contain the data files related to the software before implementing the developed system on all machines machine connected to the server. For this the exported data is imported to the client machine and the database is checked that all tables are properly imported to the client machine or not as the software is developed in SQL server data base and also going to be implemented in oracle there is no other conversion is required. A good audit control trail is the key to detecting fraud and errors in data entry.

User Training: -

Analysis of user training focuses on two factors-user capabilities and the nature of the system being installed. 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, concrete, step-by-step procedure-require limited problem solving .For this, the training level and duration is basic and brief.

Training Aids: -

The most frequently used user training aids are:

User manual- Contains information about functionality of the software available to the user, what each option can do, how these are executed and how diagnostic should be handled. The manual should be organized and indexed for quick reference. Graphics, pictures and schematic diagrams enhance the readability of the manual. The software is prohibited with both offline and online help. Offline help is document (User manual), which is the prohibited with the software that also contains user form feed, which can be used by the client company to report any bugs in the software. Offline help helps the user to read the functionality and operation manuals about the software. Online help is the

Help, which is available to the user at his figure tips, and user can get he instant help whenever he faces any problem regarding the software operations. Online help helps the user to get the immediate support, as it is not possible to read the manual for a small problem when the user is sitting on the computer and he feels comfortable if he gets the help by pressing <f1> key.

Help screens-

This feature is available in every software. The user selects a help option from a menu. The system accesses the necessary description or information for user reference.

Data Dictionary-

Can be part of user manual, describing data element names used in the manual.

Job Aids-

Communicate essential information about certain jobs. Forms are used to show the relevant information. For example:

Color printing in forms to highlight headings.

Color to identify pieces of hardware, cables etc.

Wall charts to illustrate schematics of processing information.

Flowcharts to guide the user for detecting and handling errors, restarting the system etc.

Hardware/Software Installation: -

Adequate time and resources for installation of software and hardware must be allotted in the development schedule. Users can be trained on the installation procedure. The detailed instructions can be a part of the user manual.

Maintenance

Software maintenance is used to describe the software engineering activities that occur following delivery of a software vehicle to the customer

Activities involved in maintenance of a software vehicle include:

· Analysis activities

· Standards and guidelines

· Design activities

· Implementation activities

· Supporting documents

Configuration management is concerned with tracking and controlling of the work vehicle that constitute a software vehicle

Configuration management tools include

· Configuration management data bases

· Version control libraries

Automated tools to support software maintenance include technical support tools and managerial support tools

Other automated tools include

· Text editor

· Debugging aids

· Linkage editor

Computer Maintenance covers a wide range of activities. Many activities performed during development of Airlines Reservation System for Global Airways to enhance the maintainability of it are as follows---

Analysis Activities The analysis phase of software development is concerned with determining customer requirements and constraints, and establishing feasibility of the vehicle. From maintenance view point, the most important activities that occur during analysis are establishing standards and guidelines for the project and the work Brands, Models to ensure uniformity of the Brands, Models; setting of milestones to ensured that the work Brands, Models are produce on schedule; specifying quality assurance procedures to ensure development of high quality documents; identifying vehicle enhancements that will most likely occur following initial delivery of the system; and estimating the resources( personnel, equipment, floor space) required to perform the maintenance activities.

Standards and Guidelines various types of standards and guidelines we developed to enhance the maintainability of our software.

Design Activities Design is concerned with developing the functional components, conceptual data structures and interconnection in a software system. The most important activity for enhancing maintainability during the design.

Automated tools to support software maintenance include technical support tools

and managerial support tools. Tolls to support the technical aspects of software

maintenance span the spectrum from analysis and design tolls to implementation to debugging and testing tools. Automated tolls include text editors debugging aids, cross-reference generators, linkage editors, comparators, complexity metric calculators, and version control system and configuration management databases.

Text editor permits rapid, efficient modification of source programs, test data and supporting documents. Text editors can be used to insert and replace segments of source code, internal comments, test data and supporting documents; to systematically change all occurrences of an identifier or other textual strings to locate all references to a given identifier or other string of text; and to save both old and new versions of a routine, test file or document. A syntax-directed text editor can ensure that all cross-references in text editor can ensure that all cross-references in the supporting documents are correctly updated.

Debugging aids provide traps, dumps, and traces assertion checking and history file aid in locating the causes of known errors. System-level-cross-reference generators provide cross-reference listings for procedure calls, statements usage and data references. Cross-references directories provide the calling structures of who calls whom and from where, and procedures names and statement numbers where formal parameters local variables and global variables are defined, set and used.

As we already know maintenance of the software is an important part of using it. Thus various maintenance procedures have to be followed.

Testing Techniques & Strategies

Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding testing requires that the developer discard preconceived notions of the “correctness” of software just developed and overcome a conflict of interest that occurs when errors are uncovered.

Testing is a process of executing a program care is one that have a high probability of finding an as yet undiscovered error. A successful test is one that uncovers an as-yet undiscovered error.

Testing is the necessary part of the project the various methods are used for testing the software. The new look to the project is giving by the perfect testing. I prefer the black box testing method. Black - box testing , focuses on the functional requirements of the software. That is black - box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black - box testing is not an alternative to white - box techniques Rather, it is a complementary approach that is likely to uncover a different class of errors than white - box methods.

Black - box testing attempts in following categories :-

(1) In correct or missing functions.

(2) Interface errors.

(3) Errors in data structures or external data base access.

(4) Performance errors.

(5) Initialization and termination errors.

Firstly, test the incorrect or missing function in the project design, testing all modules and their dependent modules such as for new care, detail of old care, forwarding of case reminder of case and disposal of case.

Secondly, test the interface of the software. The input and output of the project also depends upon the interface use, so that all links should be display accordingly.

Thirdly, testing on the data that are use, it should be properly fitted. The connectivity should be proper.

Fourthly, the performance error, testing is also done on the performance error, checking the display time, loading time, clear picture and message.

Finally, testing on the idealization and termination error, test the proper loading of the input data easily connection of the data and display of cases.

Unlike white - box testing, which is performed early in the testing process, black- box testing tender to be applied during later stages of testing. Because black - box testing purposely disregards control structure, alteration is focused on the information domain.

By applying black box techniques, we derive a set of test cares that satisfy the following criteria

(1) Test cares that reduce, by a count that is greater that one, the number of additional test cares that must be designed to achieve reasonable testing.

(2) Test cares that tell use something about the presence or absence of classes of errors rather then errors associated only with specify test at hand.

Cost Estimation Of The Project

For a given set of requirements it is desirable to know how much it will cost to develop the software to satisfy the given requirements, and how much time development will take. These estimates are needed before development is initiated. The primary reason for cost and schedule estimation is to enable the client or developer to perform a cost benefit analysis and for project monitoring and control. A more practical use of these estimates is in bidding for software projects, where the developers must give cost estimates to a potential client for the development contract.

For a software development project, detailed, and accurate cost and schedule estimates are essential prerequisites for managing the project. Otherwise, even simple question like “is the project late”, “are there cost overruns”, and “when is the project likely to complete” cannot be answered. Cost and schedule estimate are also required to determine the staffing level for a project a deferent phase. It can be safely said that cost and schedule estimates are fundamental to any form of management and are generally always required for a project .

Cost in a project is due to the requirement for software, hardware, and human resources. Hardware resources are such thing as the computer time, terminal time, and memory required for the project, whereas software resources include the tool and compilers needed during development .The bulk of the cost of software development is due to the human resources needed, and most cost estimation procedure focus on this aspect. Most cost estimates are determined in terms of person-month (PM). By properly including the “overheads” in rupees cost of a person-month, besides including the direct cost of the person month, most costs for a project can be incorporated by using PM as the basic measure. Estimates can be based on subjective opinion of some person or determined through the use of models.

The costs associated with the system are expenses, outlays or losses arising from developing and using a system. But the benefits are the advantages received from installing and using this system.

Cost and benefits can be classified as follow:

Tangible or intangible

Cost that are known to exist but their financial value cannot be exactly measured are referred to as intangible costs. The estimate is only an approximation. It is difficult to fix exact intangible costs. For example, employee movable problems because of installing new system are an intangible cost. How much moral of an employee has be affected can not be exactly measured in terms of financial value.

Fixed or variable

Some costs and benefits remain constant, regardless of how a system is used. Fixed costs are considered as sunk costs. Once encountered, they will not recur. For example, the purchase of an equipment for a computer center is called as fixed cost as it remains constant whether in equipment is being is called as fixed cost as it remains constant whether in equipment is being used extensively or not. Similarly, the insurance, purchase of software etc. Contrast, variable costs are incurred on a regular basis. They are generally proportional to work volume and continue as long as the system is in operation. For example, the cost of forms varies in proportion to the amount of processing or the length of the reports desired.

Direct or indirect-

Direct cost are those which are directly associated with a system. They are applied directly to the operator. For example, the purchase of floppy for Rs 500/- is a direct cost because we can associate the floppy box with money spent.

Direct benefits also can be specifically attributable to a given project. For example, a new system that can process 30 percent more transactions per day is a direct benefit.

Indirect cost are not directly associated with a specific activity in the system. They are often referred to as overhead expenses. For example, cost of space to install a system, maintenance of computer center, heat, light and air-conditioning are all tangible costs, but it is difficult to calculate the proportion of each attributable to a specific activity such as a report.

The estimation of cost of the project is a difficult task but we can estimate the cost of the project by various methods. I am using the COCOMO (Constructive Cost Model). The model has following hierarchy: -

Model 1: - The basic COCOMO model computed software development effort land cost as a function of program size expressed in estimated lines of code.

Model 2: - The intermediate COCOMO model computer software

development effort as a function of program size and a set of “cost drivers”

that include subjective assessments of vehicle, hardware personnel and

project attributes.

Model 3: - The advanced COCOMO model incorporates all characteristics

of the intermediate version with an assessment of the cost drivers impact on each step (analysis, design etc.) of the software engineering process.

The COCOMO model is defined for three classes of software projects are:

1) Organic Mode:- Relatively small, simple projects in which small teams with good application experience work to a set of less than rigid requirements.

2) Semidetached Mode:- An intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.

3) Embedded Mode:- A software project that must developed within a set of tight hardware, software and operational constraints.

The basis COCOMO equation takes the form.

E = a_b KLOC^b_b

D = C_b E^d_b

When E is the effort applied in person months, D is the development time in chronological months, and KLOC is the estimated number of delivered lines of code for the project. (Express in thousands). The coefficients a_b and c_b and the exponents b_b and d_b where taken as.

This project is an organic project so: -

a_b = 4

b_b = 1.05

c_b = 2.5

d^b = 0.38

LOC = 1555

KLOC = 3000/1000 = 3.0

E = 2.4 (KLOC)^1.05

= 2.4(3.0)^1.05

= 7.6

= 7 person-months

New calculate the D is the development time in chronological months

D = 2.5 E ^0.35 = 2.5 (8) ^0.35 = 5.2 months

= 5 months approximately

The computer project duration we use the effort estimated described above

N = E/D = 7/5

= 1.4 person = 1 person

When N is the recommended number of people for the project.

PERT Chart

A PERT chart is a graph-based chart. It can be used to determine the activities that from the “critical path”, which if delayed will cause the overall project to delay. The PERT chart for the project is:

PERT Chart

Phases	Old Project		New Project
Phases	No. Of Days	Extra Days	No. Of Days	Extra Days
Fact finding	15	5	10	3
Analysis	20	3	15	5
Designing	25	5	20	5
Coding	20	5	20	5
Testing	10	2	10	2
Maintenance	35	10	32	10

GANTT Chart

A GANTT chart uses a calendar-oriented chart to represent the project schedule. Each activity is represented as a bar in the calendar, starting from the start date of the activity and ending at the ending date for that activity. The start and end of each activity becomes milestones for the project. The GANTT chart for this project is: