In the subsections to come we discuss different aspects of the implemented study planning system. At first we verify whether the system complies with the posed requirements (section 10.2.1). Thereupon, the chosen architecture of the system is discussed (section 10.2.2).
Furthermore, we question:
• Is the system configurable? (section 10.2.3)
• Is the system extensible? (section 10.2.4)
The performance of the system is finally discussed in section 10.2.5.
10.2.1 Fulfillment of Requirements
In this subsection we discuss whether the implemented study planning system fulfills the requirements posed in the requirements specification presented in chapter 4.
Data Requirements
A systematic examination of the database design (appendix E) and the implemented data tier (section 5.4, appendix A) will show that the system is in fact capable of storing data as required in section 4.1. Moreover, section 5.1, subsections 5.2.3 and 5.4.4 and chapter 6 substantiate that claim.
10.2 Implementation 117 Functional Requirements
Below we discuss whether the requirements posed with respect to functionality have been fulfilled.
• Principal Requirement
As required, the system can be used by a web browser (confer section 5.6 and chapter 8). Into the bargain, a user interface to other types of user clients can relatively easy be provided in that all business and data logic have been separated from the web browser interface.
• Elaboration of Study Plans
The system is indeed able to elaborate both correct as well as expedient study plans.
This issue is discussed in section 10.3.
• Various Management Functionality
As described in chapter 8, users are able to manage study plan criteria and view elab-orated study plans by the user interface.
• Restricted Admission&c.
As expound in section 6.7, admission to the system is restricted, precautions are taken against brute force attacks and a strict password policy is managed. The requirements posed in section 4.2.2 are thus fulfilled.
• Culture Versioning
Both the Danish and British cultures are supported by the current version of the system (confer subsections 5.2.5 and 5.4.4 and also chapter 8) and other European cultures can easily be added as exemplified in section 10.2.3.
In conclusion, the functional requirements have been fulfilled.
Quality Requirements
Below we discuss whether the requirements posed with respect to quality have been fulfilled.
• Capacity
On account of the time available we have not carried out scalability tests and only verified that a subset of the initial capacity can be handled.
• Performance
The system does indeed perform as required. The aspect of performance is discussed in section 10.2.5.
• Usability
The posed usability requirements are difficult to measure, however, it is most likely that users can use the system without prior instruction. Moreover, the system only demands information from the user if the information cannot be derived from existing information.
• Security:
– The system is not vulnerable to injections into the database as the data tier only interacts with the database using parameterized queries as explained in section 5.4.2.
– Hackers cannot attack or make the system break down by exploiting buffer over-runs as the system is based on the .NET Framework which offers a managed environment.
– Nor does the system have a weak spot when it comes to URL tampering, content suction and script injections as countermoves have been made in that respect (confer section 5.6).
– The transmission between the client and server isnot done via the https protocol as it depends on a so-called SSL certificate which is not free of charge. However, this security aspect can easily be added later on.
• Extensibility
The implemented system is indeed extensible. The aspect of extensibility is discussed in section 10.2.4.
In sum, except for the missing test of capacity, the implemented system can reasonably be said the meet all the posed quality requirements.
Other Requirements
Below we discuss whether the remaining requirements posed to the system have been fulfilled.
• Legal Requirements
Because of the time available we have not taken specific initiative towards making the system fulfill the requirements posed in section 4.4.1.
• User Interface Requirements
Referring to chapter 8 it is evident that the worked out user interface is in accordance with the requirements described in section 4.4.2.
• Technical Requirements
As expound in section 5.6 the system only forwards output to the client (web browser) in a format such that a client, which complies to the standards specified in section 4.4.3, can actually use the system.
• System Design and Programming
The system is based on a 3-tier architecture as expound in section 5.3 and object-oriented principles as it appears from e.g. sections 5.4-5.7. Consequently, the require-ments made on system design and programming in section 4.4.4 have been fulfilled.
Further discussion of the implemented architecture is given in section 10.2.2.
• Documentation
The documentation requirements in section 4.4.5 can reasonably be said to have been fulfilled.
In short, apart from the legal requirements, the requirements posed in section 4.4 have as well been fulfilled.
10.2 Implementation 119
10.2.2 Architecture
The various advantages of the chosen 3-tier architecture were enumerated in section 5.4.
In addition to this we have a few comments based on our experience working with the architecture.
Undoubtedly, we felt it somewhat cumbersome to implement the data tier. However, the ef-forts proved to be rewarded as the business tier in many cases was very efficient to implement.
Likewise, we found it a little incentive that the functionality of the system (e.g. elaborated study plans) were not visualized until late in the development process.
In addition the chosen approach concerning the one-to-one mapping between the table classes in the data tier and tables in the database, one could introduce a number of classes repre-senting a join between two or more tables2. The disadvantage of a such insertion would be that several classes depend on the structure of a table and thus more dependencies have to be taken into account. The advantage would be less iterations in the business tier and possibly a better performing system.
10.2.3 Configurability
In the implementation of the system emphasis has been on configurability. The system is highly configurable which means that many changes may be performed without changing a single line of code. For example all types in the system are stored in database tables instead of being hard coded into the system modules. Some of the types used in the system are:
• Study Type
• Project Type
• Period Type
• . . .
Adding a new study type to the system is thus merely a matter of inserting a few rows into theStudyTypeandStudyTypeVersiontables as well as other associated tables if applicable.
Representing course descriptions in a third language (besides Danish and English) such as German is as simple as inserting a new<culture>node in the XML string representing the course description (section 5.2.5).
If all the types had been hard coded into the system, development of the system might have been somewhat easier and quicker and the system would have worked just as well – maybe even faster since there would be less data to retrieve from the database. Using this approach, however, would have made the system quite static. Adding a new type would mean changing the code many places in the system with the possible risk of forgetting something.
Introducing a new language might even require extension of some database tables as well as code alterations depending on the implementation.
In a dynamic world the requirements to a system (including a study planning system) are likely to change. A static system which requires the involvement of developers for making a small alteration is not desirable for the customer who has to pay for every change.
The approach used in the study planning system does not eliminate the need for code and database changes in order to cope with new requirements, but being configurable the number
2Alternatively, one could introduce a view in the database.
of changes needed is significantly lower when compared to hard coding. Hence the mainte-nance cost of the system is lower and the time-to-market is improved.
Section 11.1 describes how the system could be made even more configurable especially from the student’s point of view.
10.2.4 Extensibility
We claim the system to be extensible and shall briefly exemplify how the system can be said to be so.
The utilized 3-tier architecture certainly conduces to the system being extensible. For in-stance, one can relatively easy support new types of user agents in that the new user interfaces can reuse the present logic in the business and data tiers. As another instance of flexibility, the system could bring new data sources into play (e.g. a web service) and the business tier would remain unaffected by this change in data strategy.
The fact that the system is implemented using an object-oriented programming language, namely C#, also makes the system extensible. As an example, existing classes can easily be extended with new methods and new classes can – without further ado – inherit from the present base classes.
In addition, the database design is made in a way such that data concerning distinct entities are stored in separate tables. Thereby, one can without exceptional difficulties alter data for an existing entity and introduce new entities.
10.2.5 Performance
Since study plans are to be elaborated online while the user is waiting, performance must be reasonable to an extent such that the user does not lose his patience. With the complexity of generating a study plan in mind most users will show understanding for the fact that the elaboration takes more than a few seconds.
Tests have shown that the elaboration of a study plan takes approximately 17 seconds on average3. Compared to the alternative of generating the study plans by an hourly running batch job, we find that a waiting time of 17 seconds is a small price to pay for an online generated result.
If the performance is not acceptable there are several possible ways of optimizing the perfor-mance of the study plan elaboration as described in the following.
Introducing Redundancy
Currently, the study plan elaboration algorithm uses some redundancy of data to improve performance. For example the elaborator often needs to know if a given course has already been scheduled when checking prerequisites and to prevent scheduling of the same course multiple times. This may be determined by performing a linear search through the preliminary study plan until the course has been found or the end of the study plan has been reached
3On an AMD Athlon XP 2000 with 256 MB RAM using Microsoft Internet Information Server 5.1, Microsoft SQL Server 2000 and version 1.1 of the .NET Framework
10.3 Test 121