Chapter I

INTRODUCTION

Software systems are now ubiquitous. The specification, development, management and evolution of these software systems make up the discipline of software engineering. A web-based system is an application running on a server that a user accesses through a web browser. This thesis was produced in fulfillment of the requirement to document the software engineering approach for the implementation of a web-based Aircrew Information System (AIS).

Nowadays, most companies have automated their financial records with accounting software. Similarly, there is a pressing need to automate the aviation records for air carriers and corporate flight operations. This requires custom designed software tailored to the needs of the company and the Civil Aviation Orders that govern them. AIS was developed to fulfill this need and has evolved almost entirely from the feedback of the user community, which consists of pilots and other aircrew.

Chapter II deals with the real-life case study of an aviation organization. The study helped to discover end-user and organizational requirements that formed the basis of the development of AIS.

Chapter III describes the basic activities of the software engineering process that were carried out, including the software process models prepared. It explains the documentation and the choice of system models used.

Chapter IV describes the methodology used for developing the software product and lists the development techniques and tools used. It explains the underlying reasons for choosing these techniques and tools.

Chapter V describes findings and conclusions at the end of the development phase of the web-based system. It lists the achievements and limitations of the system and the future possibilities.

Appendix A contains the Project Requirements Specification. This document is a statement of what services the system is expected to provide and the constraints under which it must operate. It was generated using customer-supplied information.

Appendix B contains the Software Project Management Plan. This document describes the objectives of the project and sets out the constraints that affect the project management. It also describes possible project risks and the hardware and support software required to carry out the development. In addition, it describes the breakdown of the project into activities and identifies the milestones and deliverables associated with each activity.

Appendix C contains the Work Assignment Schedule. This document sets out the work breakdown and a schedule for carrying out the work.

Appendix D contains the Data Dictionary. This document describes the logical organization of the data used by the system and its interrelationships. The tables’ schemas include a description of the named entity, its default value if any, its type, and whether it is a primary key.

Appendix E contains the Test Plan. This document describes the testing process, the tested items, the testing schedule, and recording procedures. It also contains a sample Software Problem Report (SPR) and a Software Modification Report (SMR).

Appendix F contains Javadoc documentation of a Java utility class that was developed by the author. The utility class has a number of static methods and serves as an example of software code reuse.

Appendix G contains Installation Notes for the software required to implement the web-based application for aircrew.

Appendix H contains the User Manual. It has help topics that are common to all users and separate sections for the different user groups. An on-line version was also developed and acts as an additional resource for users.

Chapter II

Case Study

Most aviation companies operating in the world employ pilots and some managers and other staff. Pilots are required to maintain a record of various items to ensure that they do not exceed limitations set out in the Civil Aviation Orders.

In the organization which was the subject of the case study conducted, the pilots submitted handwritten reports to the management. In 1999, the pilots began to use individual, desktop-based Microsoft Excel files to submit the same information. These Excel files were developed by the author of this thesis and can be considered as a prototype of the web-based project. Each Excel file consisted of 13 worksheets of 28-day periods for a year.

2.1 Statement of Problem

The problems associated with using the Excel based system are:

1. The dates for each period of a year have to be manually updated for the next year.

2. The formulas for calculating totals have to be manually linked from cell to cell, one worksheet to another and from one Excel file to another.

3. Errors made when copying and pasting formulas are difficult to detect.

4. There are no built-in checks for wrong data entry.

5. The pilots forget to make a backup of their data and lose the information in the event of machine failure.

6. The management is dependent on individual pilots handing in the reports on time.

7. The management does not have up-to-date information unless the pilots hand in the reports.

2.2 Purpose of Study

A study was conducted to develop a web-based Aircrew Information System (AIS) that would alleviate all of the problems with the Excel based system. The choice of a web-based application was obvious. The aviation company has offices in different locations and needs to share data across a large distance.

One of the fundamental strengths of the Internet is the set of standards that define how users connect to servers and how data will be displayed. AIS takes advantage of the network capabilities of the Internet and the presentation standards of the World Wide Web. By developing an application to run on a web site, the developer ensured the widest possible compatibility and accessibility to the system. Pilots can submit reports even if they are not physically present at the company offices (as long as they have access to a web browser).

In addition to the major benefit of being web-based, AIS offers these features:

1. The period dates for each year are automatically generated and the reports are available in the prescribed format.

2. There is only one formula for each type of total needed. If an error in totaling is noted, the code has to be changed in one place only.

3. There are built-in checks for data entry on client-side.

4. Pilots can enter and submit data and the report is instantly available for the management to view.

5. Along with Flight Duty Time, other information related to licenses and medicals can also be entered by pilots and be viewed instantly by the management.

6. The management is aware whenever pilots exceed the flying hours limits or are within 20 hours of exceeding the limit.

7. The management is aware of dates of licenses and medicals which are due within 30 days or less and those which are overdue.

8. Data backup is centralized and information for a number of years can be stored collectively.

2.3 Description of Terms

Developer: Thota Neena Jawaharlal.
AIS: Aircrew Information System.
Flt. Ops: The Flight Operations department responsible for handling flying related duties and tasks.
HKSQA: Hong Kong Software Quality Assurance model.

Chapter III

Conceptual Framework

Since the development of personal computers, software products produced by companies such as Microsoft have dominated the market. These products account for the vast majority of software sales and are usually cheap as the development cost is spread across hundreds or thousands of different customers. The marketing department of the product company produces generic product specifications internally. They reflect what they think will sell. They are usually flexible and non-prescriptive. However, there is still a large market, for specially designed systems like AIS.

The software engineering approach is ideal for developing a customized product such as AIS. The specifications for bespoke systems are often the basis for the contract between customer and contractor. AIS is a single-developer project and there is a need to define all specifications and changes in detail. It models parts of the real world and since these models are abstract and complex, they must be made visible in documents such as project plans and user manuals. By following the software engineering approach for the development of AIS, the task of software specification, design and implementation was methodically documented.

There are a number of different models or paradigms of software development. The ‘Waterfall model’ was used for the software development process of AIS [18]. It maps the software life cycle into separate process phases such as requirements specification, software design, implementation, testing and so on. After each stage is defined it is ‘signed-off’ and development proceeds to the next stage. Because of the cascade from one phase to another, this model is referred to as the ‘Waterfall model’ (see figure 3-1).

Figure 3‑1 Waterfall model

3.1 Requirements Analysis and Definition

The process of discovering, understanding, negotiating, documenting, validating and managing the set of requirements for the web-based system was accomplished through the Project Requirement Specification document (attached as Appendix A). In this document the system’s services, constraints and goals were established by consultation with the system users [6]. It was written in natural language and served as a contract between the client and the software developer (the author). An overview of the requirements management process is shown in figure 3-2.

Figure 3‑2 Overview of requirements management process of AIS

The process of planning, organizing, staffing, monitoring, controlling and leading the software project was accomplished through the Software Project Management Plan (attached as Appendix B). In this document the time and personnel requirements, the project deliverables, project organization and managerial and technical processes were defined.

A Work Assignment Plan was prepared for project scheduling (attached as Appendix C). The work breakdown, activity dependencies and staff allocation (in this case only one developer) was defined.

3.2 System and Software Design

3.2.1. System Models

Complementary system models show different aspects of the system specification. Structural models show how the system or its data is decomposed.

Examples of some types of system models, which might be produced as part of the analysis process, are as follows:
A data-processing model: Data-flow diagrams may be used to show how data is processed at different stages in the system.
A composition model: Entity-relation diagrams may be used to show how some entities in the system are composed of other entities and how they are related.
A classification model: Object class/inheritance diagrams may be used to show how entities have common characteristics.
A stimulus-response model: State transition diagrams may be used to show how the system reacts to internal and external events.
A process model: Process models may be used to show the principal activities and deliverables involved in carrying out some process.

The following design models of AIS were prepared to show an overview of the system structure, how sub-systems share data, how they are distributed and how they interface with each other:

1. Block diagram

2. Repository model

3. Data flow diagrams

4. Semantic data model

5. Three-tier architecture model

3.2.1.1 Block diagram:

An architectural block diagram presents an overview of the system structure. Each box in a block diagram represents a sub-system and boxes within boxes indicate that the sub-system has itself been decomposed to sub-systems. Arrows mean that data/or control is passed from sub-system to sub-system in the direction of the arrows.

AIS is structured into three principal sub-systems namely, System Administrator services, Pilot services and Staff services. The Manager services sub-system is an amalgamation of the Pilot and Staff services sub-systems. Each sub-system is an independent software unit. Each sub-system is further decomposed into modules representing the services offered. This abstract view of the system aided the developer in modular decomposition, leading to maintainability of the system.

3.2.1.2 Repository model

Sub-systems making up a system must exchange information so that they can work together effectively. This was achieved in AIS by having all shared data in a central database that could be accessed by all sub-systems.

The repository model is suitable for applications where data is generated by one sub-system and used by another. For e.g. in AIS, the Staff sub-system uses data generated by the Pilot services sub-system. Similarly, data generated by the Administrator sub-system is used by the Pilot services sub-system. In this way there is efficient use of data, and activities such as backup, security, access control and recovery from error are centralized.

3.2.1.3 Data Flow diagrams

In a data-flow model, the subsystems process their inputs and produce outputs. Data flows from one to another and is transformed as it moves through the sequence. The rounded rectangles represent sub-systems that may themselves be complete programs. Rectangles are used to represent data stores and circles mean user interaction.

The data-flow models of AIS show the intuitive way in which people think of their work in terms of input and output. Once the administrator, pilot, manager or staff has logged in, he/she can access a menu selection and perform any of the services entitled as a privileged user.

3.2.1.4 Semantic data model

Semantic data models define the logical form of the data processed by the system. Using entity-relationship model, the logical data structure is defined as a set of tables in a relational database, with some tables having common keys.

The database defined for AIS follows the rules of data normalization. Data normalization is the process of defining tables properly to provide flexibility, minimize redundancy and ensure data integrity. The goal was to design database tables to save space, minimize duplication and protect the data to ensure its consistency [17]. (See Data Dictionary attached as Appendix D.)

3.2.1.5 Three-tier architecture model

AIS is designed with three-tier architecture. It is a Java servlet application interfaced through a web server with which it communicates using HyperText Transport Protocol (HTTP).

The Java^TM Platform has revolutionized computing with the introduction of a stable, secure and feature-complete development and deployment environment designed from the ground up for the Web. It provides cross-platform compatibility, safe network delivery, and smartcard to supercomputer scalability [11]. In addition, the choice of Java for AIS took into account the fact that Java has an extensive library of routines for coping easily with TCP/IP protocols like HTTP.

Servlets are the Java platform technology of choice for extending and enhancing web servers. Servlets provide a component-based, platform-independent method for building web-based applications, without the performance limitations of CGI programs [2]. The advantages of using servlets for AIS are:

Platform and vendor independence: All the major web servers and application servers support the Java Servlet 2.2 specification. As servlets are written in the Java programming language they can be used on any operating system with a Java runtime environment. AIS has been tested on Windows 98/Me and Unix platforms.

Integration: Servlets take advantage of other Java technologies such as JDBC for database access. AIS was implemented with the MM.MySQL 2.0.2 Type IV JDBC driver for MySQL database.

Efficiency: Servlets execute in a process that runs until the servlet-based application is shut down. This is more efficient than using the CGI model where a new process is created for each request. Servlets can also access resources that remain loaded in the process memory, such as database connections and client state, both of which figure in the implementation of AIS.

Scalability: A servlet-based application is extremely scalable. AIS was developed and tested on Windows Me using the standalone servlet container Tomcat, and is now deployed on a more powerful server running Unix and Apache Web server.

Robustness and security: Java is a strongly typed programming language and mistakes are caught in the compilation phase unlike during runtime if using a scripting language like Perl. AIS servlets were compiled using Java compiler Kawa IDE 4.1.

The javax.servlet package is the core of the Servlet API. It includes the basic Servlet interface, which all servlets must implement and an abstract GenericServlet class. This package also includes classes for communication with the host server and client (ServletRequest and ServletResponse) and communicating with the client (ServletInputStream and ServletOutputStream). The javax.servlet.http package allows development of servlets that support the HTTP protocol. While the core functionality in the javax.servlet package provides everything necessary for web development, the specialized classes in this package automate many tedious tasks. For example, the abstract HttpServlet class includes support for different HTTP request methods and headers [9]. In AIS, the HttpServletRequest and HttpServletResponse interfaces allow additional direct interaction with the web server, while HttpSession provides built-in session tracking functionality.

AIS implements three-tier architecture (see figure 3-3). The client tier consists of a web browser as a user interface. The server tier accepts client requests and returns a response. This tier handles all the application and business logic. The data tier is the data store.

Figure 3‑3 Three-tier architecture of AIS

The HTTP Request/Response model forms the basis of communication in AIS (see figure 3-4). JavaServer Pages (JSP) built on Java servlets return dynamic content to the client using the HTTP Request/Response objects. JavaServer Pages allow for direct insertion of servlet code into an otherwise static HTML file. Behind the scenes, the server automatically creates, compiles, loads, and runs a special servlet to generate the content of the page. The static portions of the HTML are generated by the servlet using the equivalent of out.println() calls while the dynamic portions are included directly.

JavaServer PagesTM (JSPTM) technology allows web developers and designers to rapidly develop and easily maintain, information-rich, dynamic web pages that leverage existing business systems. As part of the JavaTM family, JSP technology enables rapid development of web-based applications that are platform independent. JavaServer Pages technology separates the user interface from content generation, enabling designers to change the overall page layout without altering the underlying dynamic content [13].

Figure 3‑4 Generating JavaServer Pages

AIS uses JSP as it has a number of advantages over many of its alternatives.

Versus Active Server Pages (ASP): The dynamic part of JSP pages is written in Java and not VBScript or another ASP-specific language so it is more powerful and better suited to complex applications that require reusable components. JSP is portable to other operating systems and web servers and AIS need not be locked into WindowsNT/2000 and IIS [5].

Versus PHP: Again, the dynamic part of JSP is written in Java which has JDBC, which is an SQL-level API specification for accessing different relational databases. It supports a variety of objects and interfaces for manipulating data and executing SQL statements. AIS makes extensive use of the following JDBC API interfaces:

Connection: The interface that connects the Java application to the database.

Driver: The interface that is built specifically for each individual vendor database.

ResultSet: The interface that accepts results from a SQL Select statement.

Statement: The interface that executes SQL statements and stored procedures.

Versus pure Servlets: Changing the look and feel of the application requires the servlet code to be updated and recompiled. Even though JSP documents are automatically translated to servlets, it is more convenient to write and modify regular HTML than use outprintln statements that generate HTML. Advantage can be taken of web page development tools and there is no need to manually embed HTML into servlet code, a process that is time-consuming, error-prone and extremely boring. The JSP pages for AIS were edited in the HTML Editor, Microsoft FrontPage 2000.

Versus JavaScript: With the exception of cookies, the HTTP request data, or server-side resources like database access is not available to client-side JavaScript routines. Even though JavaScript can be used on Netscape servers, Java is more powerful, flexible, reliable and portable. Even though AIS makes extensive use of JavaScript routines for client-side validation of input data, Java routines provide server-side validation in case the user has disabled scripts.

Versus static HTML: Static HTML pages cannot be based upon user input or server-side data sources. JSP provides eight predefined variables to aid in the generation of dynamic content, some of which are used extensively in AIS:

application: The ServletContext provides resources shared within a web application. It holds attribute values representing the JSP application scope. It also defines a set of methods that a JSP page or servlet uses to communicate with its container.

config: A ServletConfig instance is used by a web container to pass information to a servlet or JSP page during initialization

exception: The exception variable is assigned to the subclass of Throwable that caused the error page to be invoked.

out: The out variable is assigned to a concrete subclass of the JspWriter abstract class by the web container.

pageContext: A PageContext instance provides access to all the JSP scopes and several page attributes.

request: The request variable is assigned a reference to an internal container-dependent class that implements a protocol-dependent interface extending the javax.servlet.ServletRequest.

response: The response variable is assigned a reference to an internal container-dependent class that implements a protocol-dependent interface extending the javax.servlet.ServletResponse.

session: The session variable is assigned a reference to the HttpSession object that represents the current client session.

3.3 Implementation, Integration and Testing

During this phase the software design was realized as a set of programs. Then the process of evaluating the system to confirm that it satisfies specified requirements was conducted. This led to the identification and correction of defects in the system before implementation. Unit testing involving verification that each unit met its specification was conducted. (See Test Plan attached as Appendix E.) Then the individual program units were integrated and tested as a complete system to ensure that the software requirements had been met. An overview of the testing process for AIS can be seen in figure 3-5.

Figure 3‑5 Overview of the testing process for AIS

3.4 Operation and Maintenance

Maintenance will involve correcting any errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered. An overview of the post implementation support process of AIS can be seen in figure 3-6.

Figure 3‑6 Overview of post implementation support process of AIS

Chapter V

Findings and SUMMARY

Building applications that function over the Internet can be a complicated task. It requires programming know-how and considerable database, network, and security management skills. The development and deployment of AIS using the software engineering approach led to some interesting and educative findings. The objective was to produce a bespoke or customized product commissioned by a particular customer. The challenge was to produce high quality software by a single developer with no previous programming experience, and with a finite amount of resources and to a predicted schedule.

5.1 Description of Findings

The use of the software engineering approach for a small-scale software project by a single developer had both advantages and drawbacks.

The approach resulted in meticulous elicitation and analysis of user requirements. This aided in the design of system components requiring very little module change or code rework. The Excel based prototype served as a basis for writing the requirements specification and as a means to quickly demonstrate the feasibility and usefulness of the application to the management. It obviated the need for UML use case diagrams as a means of eliciting user requirements.

In addition, the prototype is being used to run ‘back-to-back’ tests. Some volunteer pilots are acting as test-users and are using the Excel totals to crosscheck the information. This has reduced the need for tedious manual checking of test runs.

Judged by the following criteria, AIS has fared well in its trial run with actual test users:

Maintainability: It is possible for the software to evolve as modules can be easily added. User feedback in early acceptance stage indicated that the aircrew information module should show due dates and accordingly it was easily modified to include the extra information.

Dependability: System downtime due to coding errors has been minimal and security has not been breached as yet.

Efficiency: There is no wasteful use of system resources such as memory and processor cycle because of reuse of code, modules and objects as discussed earlier.

Usability: Users have commented on the simple and friendly user interface and the number of hints and error messages given.

The following principles have been adhered to in the development of the user interface for AIS:

User familiarity: The interface uses terms and concepts that are drawn from the experience of the user with the previous Excel based program and requires minimum training.

Consistency: The interface is consistent in that comparable operations are activated in the same way. For example, the buttons on various pages of the menu have a consistent look, feel and method of operation. (See Appendix H for the User Manual.)

Minimal surprise: Users will not be surprised by the behavior of the system as messages inform the user of any unexpected errors. In addition, messages confirm successful actions like updates.

Recoverability: The interface includes mechanisms to allow users to recover from their errors. As discussed earlier, both JavaScript and server generated messages allow the user to edit incorrect information.

User guidance: The interface incorporates on-line help for user guidance and assistance from the main menu page for each user class.

In spite of the obvious advantages of the software engineering approach for a web-based project, numerous problems surfaced during the development and implementation of AIS.

The problem with the Waterfall model used, is its inflexible partitioning of the project into the distinct stages described earlier. In practice, in the development of AIS, these stages overlapped and fed information to each other.

During design, problems with requirements were identified; during coding some design problems were found. For example the initial requirements elicitation phase had the manager logging in separately as pilot and manager. It was only when the designs were submitted, that the need to have both manager and pilot services available to the manger with a single login was discovered. This requirement was not obvious earlier, as the Excel prototype did not have any user authentication mechanism.

During the coding phase it was discovered that the initial design of having separate user services and shift code services sub-menus for the administrator led to unnecessary delay in choosing options. The design was then refined to include all services for an administrator from a single main menu.

In the testing phase errors and omissions in the original software requirements were discovered. Program and design errors emerged and the need for new functionality was identified. For example the initial specification had the pilots entering time-on, time-off and duty hours. The design and code was later changed to incorporate automatic calculation of duty hours with an additional facility for user defined duty hours.

Modifications thus became necessary for the software to remain useful. Making these changes involved repeating some of the previous process stages and led to the delays summarized in figure 5-1.

No.	Name	Major activities	Deliverables	Status
1.	Requirements	-Analyze organizational, strategic, business & user opportunities. -Prioritize opportunities and requests. -Prepare user requests & justifications for IT work.	-Project Requirements Document	On time
2.	Analysis	Analyze high-level systems options & recommend approach. -Develop project plan. -Construct functional/logical software & data flow model. -Identify software requirements.	-Software Management Plan -Systems Test Plans	On time
3.	Design	-Analyze/finalize software components & job streams. -Analyze/finalize logical & physical database design. -Complete program specifications.	-Design Specifications -Test Designs, cases and procedures	On time
4.	Coding	-Design software modules. -Code software modules. -Conduct unit tests.	-Code (unit tested) -Unit test results	Delayed
5	Testing	-Conduct integration tests. -Conduct system tests.	-Software User Manual (including Installation notes)	Delayed
6.	Acceptance	-Conduct user acceptance tests.	-User Acceptance test results.	In process
7.	Implementation	-Install Software. -Final acceptance tests.	Installation results.	Not done

Figure 5‑1 Summary of AIS project life-cycle phases

The initial work schedule envisaged a plan of eleven weeks for completion of the project. However the deadline for coding was extended because of software limitations with MySQL (discussed later). This in turn delayed the testing phase. The original work schedule also ignored acceptance testing, mostly due to the inexperience of the developer in forecasting time schedules. At the time of writing this thesis, the system is undergoing user acceptance tests. Actual implementation and maintenance at the user site is now targeted for January 2002.

As the development team consisted of only one member, it might be expected that the process of design and development would progress smoothly. While there is no general agreement on the notion of a ‘good’ design, the developer’s familiarity with certain design models largely influenced the choice of system models rather than the fact that particular models were more suitable for the application. For example, user interface could have been modeled using UML techniques and diagrams like collaboration and sequence diagrams. However the existence of the Excel based prototype, the developer’s relative inexperience with UML and the time allocated to the design phase all influenced the choice of design models.

Large software development teams are unproductive as the communication overheads dominate the work of the team. However, the advantage of having a small team rather than a lone developer is that it represents intellectual capital and a wealth of semantic and syntactic knowledge. This could have possibly resulted in a better-designed and tested program. AIS is currently in the user acceptance test phase and while the testers have been working according to the schedule and the expectations of the developer, there is no denying the fact that extensive, in-house testing by a small development team would have resulted in a more structured and error free program.

Java as a programming language is fully object oriented. Yet the object oriented approach for Java classes was not fully developed in AIS. This was primarily because by definition servlets implement a single method and there is no easy way to group multiple servlets together into a class and achieve true object orientation [8].

5.2 Problem Solving

The major problems requiring effort during software development were MySQL’s limitations in handling negative numbers and browser compatibility with Cascading Style Sheets.

5.2.1 MySQL limitations

MySQL retrieves and displays TIME values only in the range –838:59:59 to 838:59:59. However aircrew require the totals for a year, which could exceed this range [3].

One solution considered was to store numbers in the database as negative numbers thereby using the full range. Thus 500:00:00 was subtracted from the time values using Java statements and then the values were inserted in the database. The corresponding SQL statement to retrieve data was:

SELECT TIME_FORMAT (SUM (IF (hours<0, hours-16777216, hours) + 5000000), "%H:%i") FROM tablename

There are two magic numbers used: 16777216 is 24-th power of 2 and 16777216-x is how MySQL stores the negative numbers. 5000000 is the '500:00:00' subtracted in Java from each time value before inserting into MySQL. What the query actually does is the following: it checks whether the time is negative and then either converts it to the proper negative number or (for all non-negative numbers) leaves as it was. For each value 5000000 is added to get the correct time and the SUM function is applied.

However the solution worked only if there was no fractional part i.e. minutes. The second solution was to modify the query as follows:

SELECT TIME_FORMAT (SUM ( IF ( hours < 0, (hours-16777216) - IF (MOD (hours - 16777216, 10000) < 0, 4000, 0), hours) + 5000000),"%H:%i") FROM tablename

This query does the following: The added IF part checks for minutes in 'hours', and in case of any subtracts 4000 which means the 40 minutes which are additionally counted while adding 500 hours represented as 5000000 (so for minutes it adds 100 instead of 60).

Strangely enough, MySQL gives errors while handling negative numbers of TIME data type in TIME_FORMAT() along with SUM() function. This bug was reported to the MySQL Development team but unfortunately there has been no response as yet.

The final workable solution was to handle all time value sum functions in Java. This resulted in the elegant method Utilities.doTotals(). (See Appendix F for the Javadoc output of Utilities.java.)

5.2.2 Browser compatibility

AIS users are expected to use Internet Explorer or Netscape on Windows and MacOS systems. This created a number of compatibility problems especially for the custom designed reports that are generated. Moreover, since both browsers have announced new versions at the time of writing this thesis, additional testing had to be conducted for compatibility.

The use of style sheets in AIS has a downside. The biggest problem is the imperfect CSS implementations that today's browsers offer [16]. Even though the W3C issued their CSS1 recommendation way back in 1996, not every browser fully supports it. Although recent browsers from Microsoft and (most notably) Opera Software include fairly complete CSS1 support, older browsers - Internet Explorer 3 and Netscape 4 in particular - are not only incomplete in their CSS support, but what they do support is often very buggy as well. This makes it very difficult to create style sheets that work across all browsers, since what looks elegantly formatted in one browser may look disastrous in another.

The style-editor TopStyle Lite [20] was invaluable in testing for browser compatibility. The author was able to validate style sheets against multiple style definitions for CSS1, CSS2, CSS Mobile Profile 1, Internet Explorer 3, 4, 5, 5.5 and 6, Netscape 4 and 6, Opera 3.5, 4 and 5, and WebTV Plus (see figure 5-2). In addition, websites that feature browser style compatibility charts proved to be useful [14]. However, the use of TopStyle Pro (as opposed to TopStyle Lite), would have enabled the author to take advantage of the fact that the style checker validates code, warning not only of errors in the style sheet, but also of bugs in popular browsers that may affect its rendering.

Figure 5‑2 Browser compatibility chart in TopStyle Lite

5.3 Summary

The aim of this thesis has been:

1. To study the software engineering approach for a web-based software project.

2. To introduce the notion of programming-in-the-small, that is, the development of a small software system by an individual programmer.

3. To study issues involved in project management.

4. To apply the concepts of good software design and programming practice to a non-trivial software project.

5. To produce a user-friendly web-based application for handling aircrew information.

The future scope of the project could include the following enhancements:

User guidance: The interface should incorporate some form of context-sensitive user guidance and assistance. This would obviate the necessity of returning to the main menu page to access the on-line help.

Database management techniques: Use of prepared statements (precompiled queries) could aid in executing SQL statements. The use of a connection pool, which preallocates and waits for connections to become available, would help if and when the actual number of users increases from the current expected number.

In conclusion, this project has challenged the developer’s knowledge of Java and SQL programming and of database design, the understanding of cutting edge technology like Java servlets, JSP and CSS, and the skills of analysis and report writing. It has also resulted in the development of a real life application with tremendous impact on resource scheduling and safety factors of an aviation based company.