Evaluation of the ATICS project

Satisfying the original specifications

In general, ATICS satisfies the original functional specifications outlined by the customer, and detailed by the supplier. Users can define plane types, add flights, add bookings, and issue boarding passes, which covers the basic functionality.

The major requirements are listed below, with a brief description of how well ATICS satisfies them.

Login:

ATICS provides a 'login' procedure which satisfies the requirements. The management of the booking agents and their passwords can be improved, but the specification was left open for us to do as we pleased.

System Administration

The system administration component satisfies the specifications fairly well, allowing easy addition, modification, and deletion of planes, flights, and booking agents. More input checking should be added and a usability study should be performed to fine tune the user interface.

Planes:

Flights:

Flights can be added, modified, and deleted easily. When adding a flight, the serial number should be selected from the list of plane types. More input checking between the plane types and flight definitions, such as number of rows, should be performed.

Booking Agents:

Booking agents can be added, modified, and delete easily. The password security provided satisfies the specifications, but apparently does not satisfy the customer's unstated concept of password security.

Booking Agent

The booking agent component, does not satisfy the requirements as well as the system administration component due to the more detailed user interface. The process of adding a booking should be examined, to see what order the booking agents prefer to add information.

Adding a booking:

The user can add a booking, storing the passengers seat preference, class of passage, special requirements, name, address, and phone number.

Selecting a seat for the passenger does not meet the requirement of choosing from a plane layout picture. The user must enter a specific seat.

The amount paid for the flight is not shown on the screen. Also, overbooking is not implemented.

The user can cancel a booking, but the process is not easy. We did not have time to implement the designed process.

Issuing boarding passes works well, allowing the user to enter a different seat for the passenger and print the boarding pass directly.

ATICS does not provide a facility for refunds since we did not have time to implement it. There was also a concern over the requirement for cheque printing. We believe a message should be sent to the accounting department, though the customer's expected ATICS to print cheques. Who has cheque signing authority? This should have been cleared up before, and is a minor point.

Querying flights:

Flights can be queried by flight number, date, and destination. The list of passengers, ticket numbers, and seating capacity are displayed. A map of the seats is not displayed.

Querying passengers:

Passengers can be queried by ticket number, but not by name nor phone number. Passenger information and flights the passenger is booked on are displayed.

A Real Project

A "real" project involves a company providing services to people, and has employees with specific job tasks. This company will then be able to identify employees that will be using the finished product. The company will pay a software contractor that has experience and is knowledgable to produce the product in question.

The software contractor should provide a small 'management group' consisting of approximately 3 people. These 3 people will collectively have excellent technical writing skills, communication skills, experience in the industry in question (eg: air line travel), and 'hold the vision'. They do not have to be computer scientists, and will not be coding the product.

The management group will interact with the client to discuss needs and basic functionality. Also, the management group will perform research into other products already on the market that provide similar functionality, to determine if they can be used, and to gain design ideas.

Then the management group will sub-contract out to experts in the following fields: communications, security, database, and user interface design to help create the product.

The sub-contractors will provide 1 or 2 experts with at least 5 year experience to help design the product. The client will also provide 1 or 2 employee representatives. The management group will manage the experts, keep them on track, and provide the vision.

The management group will set up a work area for the sub-contractors. The sub-contractors will provide enough people to code and test their portion of the product. The sub-contractor experts will be in contact with each other to discuss integration issues.

The management group will set up a test plan, training, and support details. Finally, they will oversee the delivery of the product to the client.

Lessons Learned

We learned many lessons in this project. Here is a brief discussion on some of them.

It's important to have the right tools to help put documents on the web, and to help improve the document quality. It was very difficult finding the right resources, and using them properly.

We found that smaller groups were most effective. Whenever possible, a task should be partitioned off to small groups, rather than a large collection of tasks being completed by a single large group.

More expertise and more training is important in satisfying the requirements of the customers, and of the course. As it was, we didn't have the skills or tools to grow, learn and achieve as much as we'd have liked.

More contact with the customers is preferable, and very beneficial. As it was, the only contact was through lengthy, and cryptic documents. It was too restrictive a medium, and no substitute for meetings, and more hands-on contact with the customer group.

We found that it was important to keep the motivationally challenged people separate. Left alone, the hard-working people tend to go together, leaving those that are hard to motivate in another group. One portion of the project will be well done, the other will leave something to be desired. A more balanced approach would probably be better.

We learned that 4th generation languages made development very rapid. We used Access, and it was very easy to learn. It made completing the project much easier to do.

It's important not to promise too much. It's tempting to agree to more work than the amount of people we have are capable of, in the fixed period of time. But it's important to be realistic in the expectations.

We felt that coding should have started much earlier in the process, especially in terms of interface. As is, so much time was spent on documents, that the coding wasn't begun until much later.

When assembling a group for coding, it's important to have more people at the start, so you can add less later. Adding more people to the project near the end is problematic. Coding is a large task, that requires several people, time, and organisation. It should begin as early as possible.

It's also important to ensure that everyone has access to the appropriate software. Too much time was spent scrambling so that everyone could work, and that the resources were available.

On that note, it's also important that there's a stable computing environment. A reliable place that everyone can work. Such places are remarkably hard to find on campus, yet it would be too expensive a proposition to do it any other way.

Better specifications. It's important to keep better specifications, and to use them. This is especially true in sections that are changed often.

Awareness of requirements and deadlines for everyone in the group is important. It's important to know what everyone is up to, and to be aware of precise requirements and deadlines.

Finally, the testing plan should be followed. Designing a good test plan is important to spend time on, but the group must also allow time and manpower to see that it's followed.

Management Plan

Our management plan stayed very consistent throughout the project.

It consisted of one main leader, Alvin Schur. He was the final link in every step of the process. He was like a central command. He kept the focus of the project. He also performed much of the liaison with other groups, and made many of the design decisions.

The project was divided into two general sub-groups, the system administrator group, and the booking agent group. For the most part, everyone worked on either one or the other.

Within each sub-group, there was a sub-structure. In both cases, there was usually a leader, and a co-leader. The co-leader was often the maintainer of the web page as well.

The leader of the Booking Agent group was Jamie Kromrey, and the co-leader was Ernest Domshy. The leader of the System Administrator group was Rob Vollman, and the co-leader was Andrew Taylor.

Most of the decisions and organisation for a sub-group was done by the leader(s), but everyone was in charge of some portion of the project. The leaders also served as a liaison to the other sub-group's leader, and the president (Alvin) himself.

Briefly we had an interface group, consisting of Andrew MacNeil and Michael Downey. They were concerned with the interface for both portions of the project.

Within the sub-groups, work was normally partitioned into smaller parts, and would be done by one person (sometimes 2, though). For example, in the system administrator portion, the work would be divided such that one person would be working on one of the three fields: aircraft, flights, or agents.

Within the sub-group, the work would be assembled. Then the leader would take the assembled sub-group material, and blend it into one.

This was a very effective use of manpower, and it worked quite effectively. It was a good communication system. Most importantly, it enabled people to focus on one portion of the project, without getting bogged down with the details of others.

The communication was the key part. By having certain people responsible, the communication responsibilities became easier - fewer people had to be contacted by each person. Quite an interesting web of links between people were made.

Also, when the coding came about, the groups were divided again, within the sub-group structure, to the two parts.

We found the management structure to have been very consistent throughout the project. The organised structure was of great benefit to our group. And, what's more, it was done is such a way to enable everyone to still be creative, within a basic framework.

Usefulness Of The Design Process

The design process for this project was for the most part dictated by the deadline requirements. In general, ATICS found this design process to be satisfactory.

Functional Specification And Management Plan

We found that the functional specification allowed us to arrive at a reasonable project to implement. The high degree of interaction between the customer group and the supplier group ensured our expectations matched. We believe that this document was an important part of the design process and that particular attention must be payed in order to avoid bugs and design flaws in the stage of the design.

The management plan was important in laying out the group structure. The group structure is important when a such a large group is working together on a project. We feel it allowed us to manage the group work and communication throughout the project.

In general, we feel not enough time was spent on this part of the design process. This was in part because both the customer group and the supplier group still did not have a clear idea of what was needed.

The Overall Design Document

The initial revision of the design document was quite different from what we eventually ended up with. Both the document and our understanding of the problem benefited from the iterative process of revision and review by the customer group. However we feel the size of the document reduced the usefulness by discouraging a careful review.

We feel the design process would have gone smoother if the number of people handling the interaction between the customer group and the supplier group was reduced. A smaller number of people would be able to communicate more effectively. We also feel more scheduled interaction, particularly in the later stages of the design would ensure that the product evolves according to their wishes.

It was at this point in the project that both the customer group and the supplier group had a clear idea of what the final product would look like.

This part of the design process took the most time.

The Coding and Implementation

The coding portion of the project was significantly easier with the materials from the design process. Our design document laid out the coding structure which sped coding, and also provided us with test cases to ensure that the product met the requirements.

The extensive design materials also meant the coding could process at a fast rate. The testing process was streamlined because the test cases were handled in the design document.

Recommended Process Changes:

After coming to an end with CPSC451 there are a few things that could be done differently to maximize the time and effort of the Supplier Groups. Overall, Supplier Group 6 proved to be a very capable and bright team with excellent interpersonal dynamics and work ethic. It is felt that the group did "gel" and turned out to be a very positive experience for everyone involved. Since this is the first major software development project most of the group has worked on there was to be expected a few flaws in the way in which we met the course objectives.

The first major process change that is recommended is minimize the unnecessary use of meetings. Productive meetings are fundamental to the successful implementation of a software project, however, most of the groups were just meeting for the sake of meeting. This of course is a waste of everyone's time, especially that late in the day.

In most cases agenda's were never clearly setup in advance so the meetings never really had a clear purpose. Often 13 group members would collect themselves after class to discuss the project when only two people really had anything of relevance to talk about or clarify. This could have been easily dealt with through e-mail. If it were something the entire group had to beware of then a group mail could have followed or a note placed on the web page.

Second, it was obvious that not everyone knew what was required and when it was due. Group members had to be briefed on what was coming up in the next week and what they could do to contribute to it. It is felt that since all this information was available to everyone on the web, group members should had made themselves aware of what was coming up and understand what possible contributions they could make towards it.

The use of sub-groups is a "double edge sword". It is obviously the most effective way to specialize in a task or requirement and meet deadlines effectively. However, it turned out to be an "us against them" type atmosphere. This was especially true in cases where one's work was the foundation of another's work. However, in most cases people were willing to help out other sub-groups when it came down to the crunch of meeting a deadline.

Furthermore, deadlines should be clearly set and followed. Again, this is especially true when one's work is the foundation of another's. This problem occurred more than once during the course of the project. Deadlines were clearly defined and iterated to everyone involved and group members would blatantly ignore them. This caused unnecessary tension and frustration.

The final suggestion that can be made at this time is that the coders should be familiar with the software package before they start programming. Everyone just assumed that MS Access would be easy to figure out but some difficulties were discovered during the development phase of the project. Also, as a group you cannot underestimate how long it takes to develop a fairly extensive software package.