You are here: UK Essays » Essays » Information Technology » System Cti Students

Cookie Information

Privacy Information

System CTI Students

To complete this project I have chosen to design and implement a fully functioning system, the details of which I will outline below.

CTI Bedfordview has recently experienced a major increase in the number of students taking the International Diploma and International Advanced Diploma courses. As a higher education provider, the campus requires an up to date well managed library. Great advances have been made in achieving this, such as the recent hiring of a dedicated librarian and the purchase of many reference books; however the current system used for managing resources has become inadequate due to the volume of students using them. Additionally new forms of resources need to be introduced. These include digital resources such as lecture notes, past papers, instructional videos, etc Because of the very nature of these resources it is very difficult to monitor, maintain and distribute them.

Currently books are monitored using an access database with no front-end. This is obviously not an optimal way of managing a library. Students have to ask the librarian for books as there is no reference system. Additionally lecturers have to distribute electronic media themselves. This results in a number of problems, such as students disrupting lectures to get notes, students not receiving notes because they are un-able to see a lecturer etc.

I propose to design, build and implement a system that will address the issues that are interfering with the smooth running of our library. The system will include 2 distinct parts. The first of these will be the database backend. This will be a relational SQL database. The second component will be an “administration” front-end to be used by the librarian and a “student” front-end that will run as a server side active web page.

Chapter 1: Introduction

What is software development? A loose definition could be that it is the process of changing a requirement into a functioning software system. Unfortunately this definition does not even begin to hint at the complicated set of processes that are required to achieve this. Although I have studied many facets of information technology over the past few years, I have not yet experienced actual software development. Through this project I will be exposed to the various steps involved in creating a useful system and by the end hope to understand how all the techniques I have learned fit into the bigger picture of software creation. Along the way I will have to make various informed choices as to how to complete this task. I will outline these decisions and the reasons for my making them in this project report.

Chapter 2: Lifecycle Methodology

2.1 Introduction

A software system is a large and complicated thing, this makes creating them a very complicated process. The more complicated a process is the higher the chance of errors occurring during the course of that process [1]. For this reason it is necessary to have a structured, preferably documented approach to the development of the system. Having an ordered, well defined methodology increases the likelihood of the system being successful.

2.2 Selecting a lifecycle methodology

The NATIONAL INSTITUTE OF OPEN SCHOOLING notes that there are a number of accepted methodologies currently in use [2]. Each of these is suited to different kinds of systems (). This means that I will have to examine each methodology in order to select one that is suitable for this project. I will be considering the following 3 methodologies:

• The waterfall/classic model

• The spiral model

• Rapid Application Development (RAD)

Before I begin my comparison I must first draw up a list of criteria that I will use to evaluate the methodologies. The most important criterion is that the model allows me to easily set milestones. This is crucial due to the fact that I have a very limited timeframe in which to complete this project. The second criterion that I will be looking for is defined output from each of the phases. This is important because it will make compiling the final project document easier and also allow me to evaluate my work as I progress through the phases of the lifecycle. Lastly the methodology must not be too complex as I have not had any industry level experience of software development. The requirements for this project are unlikely to change during the duration of its development therefore I will not need a methodology that allows adaptation of the specifications.

2.2.1 The Waterfall Model

The waterfall or classic model uses a sequential approach to development whereby each phase is seen as a step that, once completed, flows down to the next [3]. The phases include:

• Requirements Analysis

• Design

• Implementation

• Testing

• Maintenance

As can be seen, the phases are well defined and this means that each phase can be planned for and will have a defined output.

Additionally MCCONNEL notes that the waterfall methodology is best used when dealing with technically weak or inexperienced team members [4]. SOMMERVILLE noted that the waterfall model is best used when dealing with a well defined project specification that is unlikely to change [5].

2.2.2 The Spiral Model

PRESSMAN defines the spiral model as a methodology that allows for the rapid development of incremental versions of a system [6]. Using the spiral model, the project is started on a small scale and more features are added until it is a complete system. At the beginning of each of the increments a risk analysis is completed. This is followed by the creation of a prototype and the subsequent testing of that prototype. Finally planning is done for the next iteration. I feel that it will be difficult to plan each phase due to the fact that the program will undergo an unknown number of iterations.

The spiral model is more suited to large complicated projects [7] where the customer would need to be consulted throughout the development process.

2.2.3 Rapid Application Development

BALDWIN describes the Rapid Application Development (RAD) model as follows “Building and modifying a model system in response to user feedback until the user likes the system” [8]. This implies that the duration of the project will be difficult to gauge because there is no way of telling how many times the user will change the system. However the goal of RAD is to complete a system in as little time as possible. Although this is tempting BALDWIN notes that there is often a tendency not to document the system [8]. This is not desirable because, as stated above, I need to present the output from the development to support my project. RICHARDSON recommends that a small team be used when using this model, which suits my situation, however he goes on to state that the members of the team should be experienced [9].

2.3 Conclusion

Through my research I have identified that the most appropriate methodology to use would be the waterfall model. In addition to meeting my criteria it has a number of other benefits. Most notably it is easier to pick up problems at each phase of the model and this in turn will help to avoid wasted time later in the project [3].

Chapter 3: Requirements Analysis

3.1 Introduction

The requirements analysis phase is necessary to discover what the actual requirements of the new system will be. It involves a study of the current system and results in a Requirement Specification document being produced [10]. In order to achieve this I must examine who will be using the system, for what purpose and what their expectations of the system are. This information must then be summarised in a “written statement of what the software will do” [11] or Requirements Document.

3.2 Fact Finding

In order to accurately document the current system it is necessary to undergo some sort of fact finding task. After all, it would be impossible to create a useful system without first understanding the current system and its inadequacies. Furthermore, in order to create a system that will be useful, it is essential to understand who the target audience are and what their abilities are as far as computer use is concerned.

3.2.1 Fact Finding Methods

There are a number of fact finding methods available, these include

• Site visits

• Interviews and questionnaires

• Observation of the work environment

• Taking samples of existing documents

I will be making use of all of the above mentioned techniques in my investigation. To assist me in analysing the data collected I will use graphs, diagrams and summaries. These can be found in the Workbook submitted with this report.

3.3.2 Fact Finding Plan

During the software development process it is important to approach any task with a full plan. Haphazardly attacking problems can only lead to the ultimate failure of the project. For this reason I will compile a fact finding plan in order to ensure maximum success.

The most obvious aspect of fact finding is the creation of the questionnaires and interview questions that I will be using to gather information from prospective users of the system. Secondly I will need to plan the site visits, interviews, collection of sample documents and distribution of questionnaires. Finally I will have to consolidate all the collected data into a report that can be reviewed by the various parties involved so that they can correct any misunderstandings I may have had. This report, once corrected and approved, will be the requirement specification.

3.3.2.1 Questionnaire and Interview Question Preparation

I have decided that the interview process will be broken into two parts. The first part will consist of open-ended questions. SOMMERVILLE states that by using open questions “the requirements engineering team explores a range of issues with system stakeholders and hence develops a better understanding of their needs” [5]. The use of open ended questions will provide me with a broad overview of the system which will need to be elaborated on in order to highlight the various processes involved. This elaboration can be achieved by using the answers supplied for the first set of interviews to draw up more specific or closed questions. During the second round of questioning I will ask the interviewee for any documents, forms etc that they are currently using. These documents will be analysed and filed for reference purposes.

I will also need to investigate how computer literate the users of this system are in order to decide how best so structure my program. A program with an advanced interface would be a failure if the target audience was unable to operate it. After careful consideration I have decided that I will use a short questionnaire with simple yes/no or multiple choice type questions. I have decided this because this will guarantee accurate, useful responses that can be easily captured and measured. I have a good idea of the data that I need therefore closed questions will cover all the areas that I need to investigate.

3.3.2.2 Interview and Site Visit Preparation

In order to gain the most from my site visits I feel that it would be wise to ensure that the persons involved are given adequate notice as to what is required of them. To do this I will be sending memos out to them at least two days, but not more than a week, in advance. I feel that two days gives the interviewee ample time to prepare but notifying them too far in advance could result in them forgetting the meeting.

The memos that I send will all be written from the same template to ensure consistency. By doing this I hope to display a certain level of professionalism as well as helping them to understand the importance of the system and that it is in their best interest to be as accurate as possible with their information. A copy of the memo template can be found in the workbook.

The memo will include:

• A brief description of the new system

• A description of how the interview/site visit will be conducted

• The time and date of the interview/site visit

• The location of the interview/site visit

• A request for any documents that the person may currently be using

The inclusion of the above listed information should help the interviewee prepare fully and thus assist me in successfully completing my task.

3.3.2.3 Questionnaire Distribution

The questionnaire that I have drafted is an excel spreadsheet that I can load on a set of computers and have the students complete electronically. I will then use the information by copying their responses into a single spreadsheet to create graphs. I have organised that 5 students be selected randomly from each of the four course groups (IDB, IDCS, IADB, and IADCS) to fill out a questionnaire. I will set up the research centre computers with the spreadsheet and have the students complete their questionnaires in one sitting all at the same time. The completed questionnaires and my report of the collected data can be found in the project workbook.

I have chosen to only give the questionnaire to students because they will make up approximately 95% of the prospective users of the system. Being a computer institute I am fairly certain that members of staff are able to use a computer fairly effectively.

3.3.3 Analysis of the Collected Data

By reviewing the questionnaire distributed to the students I have been able to draw the following conclusions.

3.3.3.1 User Interface

Most prospective users are confident in their abilities. This can be seen in the graph of their responses to the question “How would you rate your computer proficiency?”

This leads me to conclude that the system can make use of an intermediate level interface but should not be too complicated in order to avoid alienating the less computer literate students.

Most of the students are frequent users of the internet and word processing programs as can be seen in their response to what applications they most use.

Fig. 2 - Typical activities performed by the students

Thus I have concluded that using a web interface would probably be the most efficient way of presenting the system to these users.

3.3.3.2 Usage Patterns

Most of the responses I received indicate that the students make use of a computer fairly often. Most of the students make use of a computer daily or every other day. The students that use a computer most often seem to prefer using their home computers but a large majority do use the college's computers.

A large majority of students have an internet connection at home.

This data supports my decision to use a web interface because it clearly shows that although the students are will use college's computers they also make use of their home computers a great deal. In the event that they are unable to use the college's computers, they will be able to access the system from home. This should increase the likelihood of the system succeeding because it will be more suited to the user's habits and needs.

3.3.3.3 Users

Using the interviews I conducted I have identified that there will be 4 types of user. They are:

• Administrators

• Lecturers

• Librarians

• Students

There exists the possibility that more types of user could be needed so I will need to make provision for later changes.

3.3.3.4 System Functions

By reviewing the interviews I had with the staff I have isolated three major categories of system functions. These are library functions, personal information functions, and the notice functions. These are all discussed in detail in the system requirement document (included in the project workbook) so I will not go into detail here.

3.3.4 System Requirement Document Format

The system requirement document serves two purposes. The first is to demonstrate that I have understood the needs of the intended users and the second is as an input to the design phase of the system lifecycle. As a result it has to be written in a style that the stakeholders will understand but without excluding any necessary technical information.

I have devised the following structure using SOMMERVILLE's prescribed outline for a system document [5].

I will use diagrams and examples as much as possible in order to ensure that whoever reads the document will understand it.

Note: The System Requirement Document is included in the project workbook.

Chapter 4: Design

4.1 Introduction

The design of a system is “the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements” [12].

Through the design process I will specify how the software and hardware components of the system will be built in order to accomplish the goals of this project.

4.2 The Software Components

I have chosen to focus on the software components first because by doing so I will be able to most accurately define the hardware elements of the system. The first aspect that I will focus on is the architecture of the software.

4.2.1 Software Architecture

The first part of my software system will be a relational database. I have decided to use a relational database over other data storage methods because:

• Relational databases avoid redundancy. Redundant data can cause unexpected results when using the data for reports, etc. and can clutter up and slow down a system. Avoiding redundancy is very important and having the database automatically do this saves me from having to manually implement redundancy checking.

• Relational databases management systems provide all Create, Read, Update, and Delete functionality [13]. This has the benefit of freeing me from having to handle all of these functions myself. I will therefore be able to focus on what needs doing instead of having to figure out how I'm going to do it.

• The relational data model is useful for applications that need flexibility in the data structures [14]. My application will need to generate a number of reports so rigid data structures would be inappropriate.

• Databases allow you to store all your data in a single place [14]. By doing so the risk of having incorrect or incomplete data is eliminated.

• Relational databases are simpler and more flexible than some other database systems [14].

• Relational databases are faster that other database systems.

• “Relational databases also have excellent security” [15]. This is vital because of the sensitive nature of the personal information that I will need to store.

• Databases can easily be designed using ER modelling techniques.

The ER-diagram and Normalisation for the database can be found in the project workbook.

Unfortunately most computer users have no direct experience with databases. Many have used them without even realising it. This is because developers typically create a front-end to hide the underlying database and its functionality. My front-end will be created in two sections. The first is the data manipulation and retrieval unit (DMRU). This section of the program will primarily be concerned with fetching and writing information to and from the database. There will be no display functionality in the DMRU.

The DMRU will be a collection of object oriented classes that will sit in between the database and a web-based front-end. The main advantage of using classes is that it creates a modular structure that can easily be added to and modified. The design for the DMRU is a class diagram that can be found in the project workbook.

The web based front-end will be created using a server side scripting language and will be the only contact point between the user and the system. I have created samples of what the front-end should look like. I based my design on the layout of CTI's main web page. I have done this because most of the students have had contact with the page (it is set as the homepage on all the computers at college) and I want to keep continuity between the pages. This will hopefully add a professional feel to the page and help the users feel more comfortable using it.

Using this levelled approach I will be able to change any part of the system in future with little or no effect on the rest of the system. Building a system too rigidly may mean that it is rendered useless if procedures change in any way. By avoiding this I hope to create a system that will have a much longer life.

An added benefit of the levelled approach is that it will also hide the inner workings of the program from the user and thus make for a more user-friendly and secure system. This is demonstrated in the diagram that follows:

Web based Front-end

Data Manipulation and Retrieval Unit

Database Backend

User

As you can see each part of the system is isolated from the next and messages are simply passed between them.

4.3 The Hardware Components

Being a web-based system the software will need to be housed on a server. The server will have to have an operating system, a database management system and software to serve the pages to client computers. Because different pieces of software have different minimum requirements the specifics of the hardware required will be impossible to work out at this stage. For this reason I can only give an overview of what will be required at this stage. The architecture I am discussing is only for hosting the web-page on the campus. At this stage it is too early to consider making it available externally as the system would have to be extensively tested and permission for it to be used would have to be granted by upper management of the company.

4.3.1 Hardware Architecture

The server needed to host the web page does not need to be an expensive one. From speaking to our network administrator I have found out that there are a few broken computers that parts could be salvaged from in order to build the server. The following will be required to do so:

• Keyboard

• Mouse

• Screen

• Network Interface Card

• A hard disk drive

• A CPU capable of running a modern operating system

• Enough ram to run the operating system and software

• A CD-ROM drive

• A motherboard preferably with USB support

Once the server has been built it would need to be connected to the network so that the client computers could connect to it. No software other than a web browser is needed on the client's computer. This is a big advantage because it will mean that any changes to the system need only be done on the server and there will be no need to install any software onto the client computers. Effectively every computer on the network will be able to access the system. I have created the following diagram to illustrate the hardware architecture.

Fig. 5 - How information is sent over the system

Chapter 5: Implementation

5.1 Introduction

The implementation phase of the waterfall model is when the system is created. In this case that involves creating the software and setting up the hardware as described above. The name of this phase can be confusing as people think that the word implementation means the installing of the system.

There are a number of things to consider when implementing the system these include:

• What operating system should be used

• What language to use

• Conventions for writing of code

• What off the shelf software needs to be used

I will examine these choices and more in this chapter.

5.2 Software and Hardware Considerations

The first choice that I need to make concerning the software is which programming language I am going to use to write the custom software. Then, based on this I will select the web page hosting software, the database management system and the operating system.

5.2.1 Choosing a Programming Language

In order to avoid confusion I would like to use similar or the same languages to write the front-end and data manipulation and retrieval unit. I have decided this because it will be a lot less confusing when working with both parts if I only have one language. It will also mean that I will only need to acquire one IDE to write the program in.

There are a number of server-side scripting programs but I have selected two possibilities that meet my criteria. They are ASP.net and JSP.

5.2.1.1 ASP.Net

ASP.Net is Microsoft's server-side scripting tool and is part of the .NET platform [16]. ASP.Net has a number of advantages. The most important of which are:

• It has powerful database-driven functionality [17]. This is very important because my design relies heavily on accessing a database.

• It has multiple language support [17]. This gives me the opportunity to select a language that I am comfortable with and that I can use to write the data manipulation and retrieval unit.

• ASP.Net is a Microsoft product which means that it is well documented and supported.

• It has improved run-time error handling techniques [16]. This is important because it means that I can build a much more user friendly application which will make the program easier to use for people with less computing experience.

• ASP.Net includes “an extensive set of controls and class libraries allows the rapid building of applications” [16].

• ASP.Net has better memory leak protection [16,17].

• ASP.Net runs faster than most other scripting tools [16,17]. If a user has to wait a long time for a page they might get irritated and give up. So the faster I can get the page to them the better.

• ASP.Net supports the C# language which I have had experience with. I would be able to write both sections of the program using C#.Net and ASP.Net using a very similar style and language.

• I have access to Microsoft Visual Studio.Net 2005 which can create both C# and ASP.Net programs so I will only need 1 tool to create the program.

There are a few disadvantages to using ASP.Net. The ones that concern me most are:

• ASP.Net can sometimes accidentally log a person out [16]. This could irritate or confuse users causing them to stop using the system.

• ASP.Net has to be hosted on a Microsoft server (i.e. one running windows) [17]. This ties my hands as far as operating system selection goes.

5.2.2.2 JSP

JSP was created by Sun Microsystems and allows Java code to be embedded into static web pages [18].

Advantages of JSP include:

• Platform independence. I would not be tied to an operating system.

• There are a large number of Java and JSP developers so getting support is fairly easy.

• It's free

The disadvantages of JSP are:

• JSP can only be used properly is you have Java experience. I do not. This would mean that I would have to teach myself Java before even thinking about coding. This is a major hurdle.

• Simple tasks can be quite complicated when using JSP [19]. Again this would probably slow me down quite considerably due to my complete lack of experience with it.

• JSP has a tendency to give error messages that are not very helpful [19]. Once again my lack of experience would mean spending a large amount of time trying to understand what was wrong with my program.

• JSP can be quite slow because it is an interpreted language rather that a compiled one. As I mentioned before the speed at which pages are served is very important.

5.2.2.2 ASP.Net or JSP?

I have come to the conclusion that ASP.Net will be the better choice for my application. The benefits of JSP are far outweighed by the disadvantages. The disadvantages of ASP.Net are not too severe, for example the fact that the server must be running a Microsoft operating system has no effect on the end user. They are free to use any operating system that they wish.

5.2.2 Choosing an Operating System

Because of my decision to use ASP.Net I have no choice but to use a Microsoft operating system. After discussing this with our network administrator I have decided that I will use the 2003 version of Windows. We have licensing for the operating system and it comes with version 6 of Internet Information Server which is needed to host web applications.

5.2.2 Choosing a Database Management System

For this project I will be using an Access database. Although Access lacks the features of more complex database systems such as Microsoft SQL Server or Oracle it does have its advantages. The reasons I have chosen it are:

• Because an Access database is contained in a single file it is far more portable than a larger system. It also does not require the installation of any additional software.

• Access can have problems when being accessed by more than a few people, however this problem is resolved when using a front-end as the only access to the database is thorough it. This means that there is, in theory, only ever 1 connection to the database.

• Creating databases in Access is very quick and easy because of its simple interface and wizards that guide you as you work.

• Access databases can be opened with Microsoft Office and the records inside them can easily be viewed. This will be an advantage when testing the system because records can be checked even if the front-end system is not yet working.

As I have noted before the database can be changed at a later sage so if usage volume increases to a level where the database can't cope a new one can be created using a different database management system and put in the old ones place. L Chung of Microsoft notes that Access is fine for use on an intranet web-site but not on and internet web page [20]. If the system is ever taken externally, the database will have to be changed.

5.2.3 Choosing the Hardware

Earlier in this report I stated that I could not specify what hardware was needed because I hadn't decided on the software. Now that I have I can recommend the following hardware for the server computer:

• 20 GB Hard Disk Drive

• Pentium 4 2.5Ghz or equivalent processor

• 1 GB RAM

• 52x CDROM Drive

• VGA Adaptor

• 1 x 100/10 Ethernet Card

5.3 Coding Standards and Documentation

Before I start coding I must first decide on what standards to use. Coding standards dictate how code should be written so that other programmers can read it easily. Documentation standards are in place so that comments in code, etc are in a readable and useful format.

Standards are not to be confused with syntax. If a syntax rule is broken the program will not run. If a standard is broken the compiler will not pick up on the mistake. This means that I will have to be extra careful when writing the code and double check to make sure I have not broken a rule.

5.3.1 Coding Standards

Using the guidelines set out by

5.3.1.1 Code layout

Visual studio automatically lays code out in a standardised format. I will use this to my advantage by allowing it to structure my code and by doing so conform to the standards as laid out by Microsoft.

5.3.1.2 Naming standards

The way that variables, classes, methods, etc. are named is very important. When reading code the style that a name is written in is used to determine what it is. Using Peter Browns list of industry accepted standards [21] I have compiled the following list of standards that I will be using.

• Class Names - Start with a capital letter

• Class Names - May not begin with an ‘I' if the letter following it is not capitalised. This prevents it being confused with namespaces.

• Class Properties - Begin with an uppercase letter.

• Class Properties - May not contain underscores.

• Class Level Variables - Begin with an underscore followed by a lowercase letter.

• Method Names - Must begin with a capital letter.

• Method Names - Must not contain underscores unless they are event handlers.

• Method Parameters - Start with a lowercase letter.

• Method Level Variables - begin with a lowercase letter

• Controls On User Interface - All controls to have the prefix ux followed by a name. The name must start with a capital letter

• All names must be descriptive

• Avoid using names that are too long

• If two words are to be used they must be joined together and the first letter of the second word must be capitalised.

5.3.2 Code Documenting Standards

When documenting my code I will follow these standards:

• All classes and methods are to be commented using xml style comments. This will, if need be, allow the automated creation of help files so that other programmers developing the system in the future will be able to make use of the classes that have been created.

• Class and method comments are to explain the use of the item being discussed as well as ,in the case of methods, any parameters or return values that the user can expect.

• Code within methods is to be commented using standard comments.

• Block comments are to be avoided within methods as it makes the code harder to read.

• Comments within methods must explain what the code does not how it does it.

Chapter 6: Testing

6.1 Introduction

Testing is an important part of the lifecycle because it is the process of finding any forgotten or misunderstood features (validation) and errors in the code or processing (verification) [1].

6.2 Planning the Tests

To check that the code is working I will compile a list of actions to be done with the expected output of each. I can then write and run the program and follow the steps to test each of the features are giving the correct results.

I will create a checklist that I can work through to make sure that everything discussed in the System Requirement Document has been included in the program. I will then sit with the person who requested that feature and demonstrate it to them. If it is correct I will tick it off my list.

6.3 User Interface

When testing the program I must review the interface to make sure that it is clear and understandable. This includes checking that users are given a good indication of what is expected of them and making sure that adequate error messages are given.

Chapter 7: Maintenance

7.1 Introduction

Maintenance is an ongoing process that carries on for years after the initial development of the system. Because of the time restraints of this project I will only be able to touch on this phase of the lifecycle.

7.2 Manuals

Because of the different categories of people that work will work on the system I have decided to create 3 different manuals. The first will be a short installation guide for the administrator so that he can set the system up. The second will be a manual describing all the procedures that staff would need. Finally I will create a manual for the students.

I have chosen to separate the manuals instead of creating one for two reasons. Firstly I do not want students to see all the functionality because this could create a security risk. They won't be tempted to fiddle with something if they don't know it's there. Secondly the majority of people do not need to know how to work the “hidden” functions so including descriptions of them will make the manual cluttered for no reason.

When writing the manuals I must bare in mind that my target audience is not as experienced as I am. I must write in a style that they will understand and explain in greater detail concepts which might be difficult for them. I also plan on using screen shots wherever needed to clarify concepts. However I must not write the document in a way that is too simple for them. This could frustrate them and result in them not using the manual or worse the system.

7.3 Training

To help the students get accustomed to the system I will hold training workshops that they can attend. I will use the lab at the college so that I can give them a “walkthrough” of the system using the projector. They can then try the system out for themselves and ask me any questions or give me feedback.

I will do a similar workshop with the staff but instead of showing them the system first I will guide them through the various functions while they try the system.

At the beginning of each year I will do the workshop over with any new students that have enrolled.

7.4 User Support

User support will be provided in the form of the manuals which will be printed and kept in the library. I will also make them available through the web-page by posting them on the site. Any queries that are not covered by the manuals can be directed through me. I will make a note of this in the manual.

Chapter 8: Critical Appraisal of the Project

8.1 Introduction

Through the completion of my project I have experienced several shortcomings of both my methods and the methodology that I chose. I will discuss each of these in the following chapter.

8.2 Lifecycle Methodology

The Waterfall Methodology Was A Bad Choice! When I chose the waterfall approach I believed that very little would change as I worked on the project. In hindsight this was rather naïve. As I discovered even a fairly simple system specification like this one will invariably change at some point. I found that by the time I had completed the system many people had thought of new functions that they would have liked.

Once in the maintenance phase of the waterfall model it is not clear what the procedure for updating or adding to the system are. I assume that one would end up using a new waterfall methodology every time a new function was added.

In conclusion I should have done more in-depth investigation (possibly reviewing cases where the methodologies where used) into the different methodologies before I made a decision.

8.3 Requirements Analysis

When I conducted the investigation with the student's I did not use accurate enough scales of measurement for the questionnaire. For example instead of using only “Poor” and “Excellent” to describe the rating scale I should have given each number a description. I found that many of the students who were completing the questionnaire were confused by this and I had to explain to them what I was looking for. Luckily I was able to do this but if I had not been the system could have been a complete failure.

I also feel that I should have used a wider cross-section of students. I initially thought of using 20% of the students to complete the questionnaire but then changed my mind and used 10%. Using a higher number of students would have given me far more accurate measurements. However I was lucky this time as the measurements I got were not too far off the average.

8.4 Systems Requirement Document

When compiling the Systems Requirement document I found that I needed information from both the analysis and design phases. I concluded that the waterfall model does not indicate this overlap and deduced that this is another shortcoming of the methodology.

The requirements specification document that I distributed was approved by all the people who received it. However once the system was completed many of the people who had read it complained that there were functions missing from the system. On reviewing the document with them the functions they were looking for were not in the specification. This leads me to believe that they a) did not read the document, or b) did not understand it. Either way I should have made certain that they were actually happy with the specification by having meetings with them concerning it and using far simpler explanations in the document.

My second mistake with the systems requirement document was not making the people who reviewed it sign a document stating that they were happy with it. Had this been a large project with many resources involved and the system had been a failure I would have been solely responsible because people could have denied seeing and approving the document. This is one mistake I will not be making again!

Lastly by including the “System Evolution” section in the document I was able to convince people that this was a worthwhile project but I seem to have inadvertently implied that these items would be part of the system. This lead to some disappointment with the system and as a result I will now have to go back and add many of these features. In future I will be sure to word any possible system growth far more carefully

8.5 Too Much Rush, Too Little Design

When I was designing the program I thought I could save time by doing a minimal design. This mistake probable cost me more time than it saved me. I found myself having to check code over and over and re-write large sections of it. Having skimped on this I can not confidently say that my program is as well written as it should be.

8.6 Using Access

Using Access may be fine for now but ultimately I will have to change the database when the system gets bigger. This means extra work later on which could have been avoided. Although having said that, I have had no problems with the database up to now with about 300 people using the system in total with up to 45 concurrently.

8.7 ASP.Net Using .Net 2

On some computers the program crashes with strange error messages. This is, as I discovered after many hours of sifting through code, not a mistake on my behalf but rather a problem with the .Net framework itself. It seems that the framework does not work well when certain other programs are running in memory. An example is Avast Antivirus which just happens to be the antivirus I use.

8.8 Testing the System Myself

When I was testing the system I found that it was very easy to forget myself and just fix problems as I found them. As a result of this many of the errors went undocumented and this means that anybody who works on the system may inadvertently re-introduce the bugs that I removed.

I also was unable to do interface testing objectively because, having written the program, I knew exactly how to use it. This could have resulted in people not being able to use the system as this is the only contact point they would have with it.

8.9 Not Integrating the Help System

I have found that simply attaching the manual as a notice on the web page was not sufficient. Part of the problem lies in the fact that if users don't know how to log in they can't get to the file.

Having the manual available in the library was only partially successful because the students found it easier to come and ask me for help (instead of looking for the answer on their own). This is not ideal because if I am not available they cannot get help and it creates a lot of extra work for me.

In hindsight I think that I probably should have made an html version of the help system and added links to the appropriate section on each page.

Chapter 9: Conclusions

When I started out on this “adventure” in system design I was in no way aware of just how much goes into creating even a small system such as this. Although my system may not be 100% I still feel that I have gained a lot of experience from this project. The most valuable lessons I have learned have not necessarily been from my successes but also from my failures. I have also learned that although a procedure may be perfect in theory, its practical implementation is not always as sparkling a success as you would expect.

As I worked through the project I became more and more aware of the importance of documentation and communication with the system stakeholders. It is impossible to build a system that is successful without conveying what you are doing and ensuring that any person that is involved in the project understands exactly what is happening and why.

Through this experience I have learned the value of practical experience and developed a new insight into systems development. For these reasons I feel that my project was a success.

Reference List

• M RICHARDS (2001), Systems Development, NCC Education

• National Institute of Open Schooling n.d., System Development Methodologies,Retrieved October 19 2007, from http://www.nos.org/htm/sad4.htm

• Wikipedia, The Waterfall Model, Retrieved October 19 2007, from http://en.wikipedia.org/wiki/Waterfall_model

• S MCCONNEL, Rapid Development, Microsoft Press

• I SOMMERVILLE (2004), Software Engineering 7th Edition, Pearson Addison Wesley

• R. S PRESSMAN (2001), Software Engineering: A Practitioner's Approach 5^th Edition, McGraw-Hill

• Whatis.com, Spiral Model, Retrieved October 20 2007, from http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755347,00.html

• D BALDWIN, Systems Development Approaches, Retrieved October 20 2007, from http://oldweb.uwp.edu/academic/mis/baldwin/sysdelec.htm

• L RICHARDSON (2005), Rapid Application Development, Automated Architecture Inc

• S JORWEKAR, Waterfall - Software Development Model, Retrieved October 20 2007, from http://www.buzzle.com/editorials/3-13-2005-67039.asp

• T BEREZIN, Writing A Requirements Document, 1999, Retrieved October 20 2007 from http://www2.sims.berkeley.edu/courses/is208/s02/ReqsDoc.pdf

• Wikipedia, Systems Design, Retrieved October 28 2007, from http://en.wikipedia.org/wiki/Systems_design

• S W AMBLER, Relational Databases 101 - Looking at the whole picture, retrieved October 28 2007 from http://www.agiledata.org/essays/relationalDatabases.html

• Business Collaborator Ltd, Introduction to the relational database tool, retrieved October 28 from http://dev-odbc.groupbc.com/bchelp/sec-8-0.html

• A AWERITY, Relational Databases, retrieved October 28 from http://awtrey.com/tutorials/dbeweb/database.php

• Wikipedia, ASP.Net, retrieved October 28 from http://en.wikipedia.org/wiki/ASP.net

• L McDONALD, Advantages of Using ASP.Net , retrieved 28 October from http://www.brillianceweb.com/betterwebdesign/tips_52.aspx

• Wikipedia, JavaServer Pages, retrieved October 28 from http://en.wikipedia.org/wiki/JavaServer_Pages

• J HUNTER, The Problems with JSP, retrieved October 29 from http://www.servlets.com/soapbox/problems-jsp.html

• L CHUNG, Microsoft Access or Microsoft SQL Server: What's Right in Your Organization?, retrieved October 29 from http://download.microsoft.com/download/5/d/0/5d026b60-e4be-42fc-a250-2d75c49172bc/Access_Whats_Right.doc

• P BROWN, .NET Programming Standards and Naming Conventions, retrieved November October 29 from http://www.irritatedvowel.com/Programming/Standards.aspx

Sign up and be the first to receive our latest offers: