2.0 Methodology

The formal methodology to be used is the Build and Test - Spiral Model which best fits the thesis project for the reasons that;

“The spiral method is similar to the prototyping approach to systems development. However, the Spiral method adds an assessment of the risks inherent in the construction. At each iteration, the development team, in conjunction with the end-user, looks at the risks, costs and alternatives open to the user. In each iteration, the user requirements are refined and a more complex prototype is produced either by building on the existing version or by creating a new one.” [4CON2002]

Figure 2-1 Spiral Model

Furthermore, according the the same document, there are four stages of the Spiral Method: Planning, Risk Analysis, Engineering, and Customer Evaluation. The stages of the project are as follows:

Planning is where the objectives and constraints of the application are identified and alternatives defined.[4CON2002]

The system is supposed to replace the paper meal tickets and thus requiring a POS with database backend. Security should be good since transactions will deal with credits. Availability should be also high since failure of the POS system will put the cafeteria in a state where they cannot serve the clients properly. The system should be low-cost, low-maintenance, and easy for non-experts to use.

Risk Analysis is where alternatives are considered, risks are identified and resolved (where possible). Risk analysis also results in a GO/NO GO decision having to be made in which the project may be abandoned if the risks are considered too great.[4CON2002]

The current known risks of the project thesis are:

• risk of not being implemented

• risk of brownout

• risk of hacking. Denial of Service (DOS), eavesdropping, session hijacking

• risk of harddisk crash

• risk of voltage spike

• risk of student not being able to eat due to lack or used up credits

• risk of juice spilling over the POS terminal

• risk of server hardware failure

• risk of network failure (cables, switches)

• risk of database system crash

• risk of DHCPD server crash

Engineering is where the next version of the application is developed. The development process could use Life Cycle, Prototyping or any other method depending on the certainty of the specifications.[4CON2002]

The engineering method to be prototyping wherein a prototype program, hardware, or network setup would be made and tested and after some other changes it would be put to work for the customer to evaluate or the technical people to load test.

Customer Evaluation is where the end user examines and tests each evolution of the application, clarifies the requirements, extends the functionality and reports on faults testing.[4CON2002]

Customer Evaluation would measure the correctness of the system. In this stage new or changed requirements are expected to fuel the next loop in the spiral model which starts with planning again.

The Software Life Cycle development process would be the natural way of accomplishing this project. According to [FOLDOC1996].

“The phases a software product goes through between when it is conceived and when it is no longer available for use. The software life-cycle typically includes the following: requirements analysis, design, construction, testing (validation), installation, operation, maintenance, and retirement.”

Although retirement is part of the Software Life Cycle, the author tries to create a system with the least possibility of retirement. The reason behind is that a well designed and implemented system’s retireability should be very low wherein a “quick and dirty” system will retire and be replaced in no time.

The project also borrows ideas and principles from Rapid Application Development [WALT1997] method which are:

1. In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution.

2. In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied.

3. In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.

Out of all the materials gathered, a suitable application framework is selected to serve as the basis for developing the system. The following is a brief discussion of the design of the system.

The PostgreSQL Object Relational Database System [http://www.postgresql.org/] will be used due to its maturity and flexible license. The author has for years experience administering production environments with PostgreSQL as the backend database system. PostgreSQL interfaces to C, C++, Perl, JDBC, ODBC, Tcl, PHP, and possibly most other languages written in C. PostgreSQL is based on POSTGRES 4.2 which was developed at the University of California at Berkeley Computer Science Department. POSTGRES pionered many concepts that only became available in some commercial database systems later. It is the open-source descendant of the original Berkeley code and is supports SQL92 and SQL99 and offers many other features like: complex queries, foreign keys, triggers, views, transactional integrity, multiversion concurrency control. It can be extended by the user in many ways, for example by adding new: data types, functions, operators, aggregate functions, index methods, and procedural languages. PostgreSQL has a liberal license which means PostgreSQL can be used, modified, and distributed by everyone free of charge for any purpose, be it private, commercial, or academic.

The most recent version (as of writing) of PostgreSQL will be used in the project. It will be downloaded, compiled, installed, and fine-tuned to suit the particular purpose.

The Linux Operating system has been chosen because of its fast paced development, the variety of hardware it supports, the many software compatible with it, and the same flexible and liberal General Public License. The speed and support for thin-client setups is also critical to decision for Linux to be used. It will be used in development of the applications, as a thin-client terminal and as a terminal server. The most popular way of doing this thin-client setup is the Linux Terminal Server Project (LTSP). The LTSP setup makes use of etherboot, tftp, dhcp, nfs, telnet or ssh, and X-Windows to provide text-based and graphical thin clients. All these technologies are also freely available in the Internet.

Because the system is mission-critical and the risk of a system malfunction is not acceptable, the cafeteria management requested the system to be highly available. Therefore the Linux HA Project was used to ensure high reliability of the system. The Linux HA principle is to use a secondary backup server which has real-time data synchronization with the primary server. In the even the primary server fails the secondary server automatically takes over all services and IP addresses and optionally ensures that the primary server is powered off to avoid any interference of still-running service in the primary server.

The risk of unauthorized access to the system drove the writer to consider using OpenSSH in the transactional connection between the system used to load credits and the main cafeteria database server. This is very critical to the security of the systems because without SSH anybody could tap in a network sniffer and see bare SQL transactions in the campus backbone. With OpenSSH network sniffing, session hijacking, and falsification of network identity becomes inhumanly difficult if not impossible due to SSH’s use of host and user signatures, strong encryption, and compression of packets over the wire. SSH is used to redirect the database port between secure servers.

For designing the graphical User Interface, the Glade 2.0 UI Designer was chosen because it is under the General Public License. Glade is a GUI User Interface designer enables programmers to design forms and edit their properties. It generates C code which is compiled with the “callbacks” that the programmer wrote to take care of every event.

The Joe Editor will be used for editing source code, configuration files, and other text documents. This editor works similar to WordStar.

The GNU Compiler Collection (GCC) will be used to build the project applications. Also of significance is the use os the Gimp ToolKit (GTK) 1.2 interface libraries which code the Glade UI Designer generates.

For testing, one sample terminal and one server were acquired and setup in LTSP way. The terminal was to have dual monitors. This was possible by wiring two female VGA connectors to one male VGA connector effectively putting all the lines in parallel. This was tested in the laboratory and classroom lectures to see if any damage or malfunction will be caused to the monitors or the video cards. Luckily there have been none.

The risk of a harddisk crash made the author think of using RAID mirroring. But the features of Linux-HA has superseeded the benefits of RAID. Linux-HA takes care not only of harddisk failure but also of a failure of the whole machine. While expensive RAID hardware enables hot-swapping, the inexpensive Linux-HA solution enables automatic unattended machine swapping which is more desirable. RAID takes care of the harddisk only while Linux-HA takes care of any failure of the whole machine including the power supply, motherboard, LAN cards, and like RAID, the harddisk too.

Data gathering will be accomplished by the, almost daily, interviews of the cafeteria operators and supervisors, by observation, and reading they transaction and system logs which are kept in the server.

Documentation will be done primarily in StarOffice 5.1.