Software R Us is proud to announce the completion of a fully functional system, the Student Timetabling System (STS), for the Creative Futures Institute (CFI). We would like to express our sincere gratitude in working with CFI, in designing and developing the STS. Over the past three months, Software R Us has worked hard in delivering a professional software system, which met CFI’s functional requirements, changes, and requests. This was accomplished through several meetings with CFI, analyzing feedback given to us from CFI in regards to our documents, along with clarification via email. We are delighted that CFI has been receptive in regards our implementation of their comments and suggestions, as we have made the necessary changes they have requested.

As our final document, the purpose of this Project Evaluation document is to evaluate us as a group, Software R Us, over the past three months. We have five main sections of discussion in this document:

Project Specifications
Design Process
Time Schedule
Management Structure
Opinions and Lessons Learned

In the Project Specifications section, we will discuss what the essential requirements were of the STS. We will also discuss any additional or subtracted features from the STS.

In the Design Process section, we will discuss how we implemented stages of the design process, in order for the STS to become a reality. We summarize each document we produced, and our general views on how each document either benefited or hindered Software R Us in the design process.

In the Time Schedule section, we will discuss how we had planned to utilize our time during the design process for each of our documents, and contrast it how our time was actually utilized.

In the Management Structure section, we will discuss how we planned to be managed and structured as a group, and contrast it to how team management dynamically changed by the time the STS was completed.

Finally, in the Opinions and Lessons Learned section, each group member from Software R Us was asked to give their honest opinions and answers for the following three questions:

1. If this were a real project, how would you do it?

2. Changes you would make?

3. Lessons learnt?

2.0 PROJECT SPECIFICATIONS

2.1 Essential Requirements

CFI approached Software R Us for design and development of the STS because of their need to maintain an Internet based timetabling system for people affiliated with CFI.

They had defined four types of users for the STS: Student, Instructor, Registrar, and System Administrator, which we simply refer to as Administrator; who would be able to perform their tasks as listed below, respectively.

CFI required a software solution that would contain the following essential requirements, and user associated tasks, as they outlined in their initial proposal (Quoted for verbatim):

A student should be able to manage his/her classes through the system as well as print off a resulting timetable and fee invoice.

An instructor should be able to view enrolment in his/her classes as well as assign a grade to each student.

A registrar employee should be able to assist students in managing their classes as well as perform some rare functions such as overloading a class or waiving prerequisites for a class.

A system administrator should be able to manage classes and accounts as well as handle requests from each instructor to modify certain elements in their class. The system administrator should also be able to print off a list of fees owed by each student, which would be used to aid in the collection of student fees.

CFI was not concerned with the implementation of the system, as these decisions were meant for us, nor were they concerned about type of programming language(s) or additional software we used, in conjunction to our design and development of the STS. However, since the STS was intended to be software solution accessible on the Internet, the STS required security measures, both within the system and for the users, to prevent unauthorized access. This was accomplished by deciding the STS would use 128-bit encryption, along with unique usernames and passwords. Not only was every username unique, each password had to meet the security criteria in order to be considered a valid password.

2.2 Additional Features

As we designed and developed the STS, we realized that there would be a need for user error messages to appear if errors were to occur. Consequently, we have user error messages built into the STS for a wide range of possible user errors, based on user input.

Student User Section:

User error checking contained within entire section.

Instructor User Section:

User error checking contained within entire section.

Registrar User Section:

User error checking contained within entire section.

Administrator User Section:

User error checking contained within entire section.

2.3 Subtracted Features

While Software R Us is proud announce that almost all of the essential requirements were properly implemented in the STS, there were only three tasks that we have not been able to fully implement, at this time. However, from a working prototype perspective, the features for the following tasks have been accounted for, but from a fully functional perspective, they have yet to be fully implemented. We will ensure that all essential features will be fully functionally on any future release of the STS.

Student User Section:

Full functionality within this section.

Instructor User Section:

Full functionality within this section.

Registrar User Section:

The feature to view the capacity for a lecture or lab and how many students are actually registered is not fully implemented.

The feature to waive prerequisites for a student to register in a course, is not fully implemented.

Administrator User Section:

The feature to enter, remove and change the prerequisites and co-requisites of the courses offered, is not fully implemented.

As previously mentioned, we will ensure that these three missing features will be fully implemented on any future release of the STS.

3.0 DESIGN PROCESS

3.1 Overview

In this section, we will discuss how we implemented stages of the design process, in order for the STS to become a reality. We summarize each document we produced, and our general views on how each document either benefited or hindered Software R Us in the design process.

3.2 Functional Specification and Management Plan

This stage of the design process was paramount in terms of properly defining the functional specifications and management plan. Essentially, this was the basis of our project. We were required to quickly and efficiently investigate possible solutions for the STS. Furthermore, we had to make decisions as to how the STS would be designed and developed, at this initial level. Having the initial customer proposal was obviously an asset, as they systematically defined the general system requirements, which were further broken down into user tasks.

However, this was a difficult task in itself for sole reason being that thirteen students, whom some have never met each other before, were now required to work together. It was a given that over time, we would all get to know each other and become more comfortable with one another. However, at the time, this was a natural obstacle to overcome, as the only way a group can become more productive is over time. The overall benefit was that it became clear within this stage of the design process the areas of expertise each group member had, as they were naturally inclined to be involved in that area.

3.3 Conceptual Design Document

Upon receiving feedback from CFI from our Functional Specification and Management Plan document, we made the necessary changes and revisions in areas where we had. Consequently, we ourselves made our own changes and revisions, based on both CFI’s requests and because we had more as a group to collectively discuss how the STS should be designed and developed for the best results.

Our Conceptual Design Document was also our first document where we properly outlined our project management outline. This was subsequently revised and included within future documents, as we ensured CFI was fully aware of the progress we were making.

This document was also a very large document, as we conceptualized the STS from many perspectives, with the use of class diagrams, data flow diagrams, and graphical user interfaces. Not only was it beneficial to understand and visually see how the STS would be implemented, but also since we had included so much technical detail within this document, we in fact had done some of the work for the next document, which was the Technical Design Document.

3.4 Presentation

Our first presentation was also our first formal meeting with CFI. As a supplier, we had to sell our product, the STS, to CFI and make them feel confident that we were designing and developing the system they wanted, and that we would within the given time.

While it was beneficial for all of us to make a formal presentation, the idea of selling the product was rather skewed because we all knew that even if had not sold the idea of the STS to CFI, they still would pursued us to develop it for them anyways. In any case, this was still worthwhile presentation experience, as it exposed students to presentations who might not have been exposed to them before.

However, preparation for the presentation gave our group more opportunities to work together as a team. As a result, group dynamics began to improve, in the sense that we all felt more comfortable discussing ideas and being more open with one another.

3.5 Technical Design Document

Upon receiving feedback from our Conceptual Design Document, we made the necessary changes to our class diagrams, data flow diagrams, and graphical user interfaces. As previously mentioned, in addition to the revisions, we had already completed some to the work required for this stage in our previous document, so we had more time to properly ensure all the necessary changes were not only completed, but correct. At this stage, we also began to see how the STS would be coming together. We listed all of our methods to be used within the STS, along with a brief description, input, output, and the respective pseudo-code.

This was a rather tedious and cumbersome task, as we have been told to create documents that are easy to understand. From a customer’s viewpoint, we questioned whether CFI would be able to fully understand the roles each of our methods had, and how they interacted with one another. We felt the technical document gave too much of a behind the scenes look into the coding of the STS. Furthermore, not only would it have been difficult for CFI to make requests for changes or revisions to the code, even if they wanted to, but ultimately our coders would have still coded the STS accordingly to what was the optimal method to do so. In other words, the structure coding of the STS could evolve and changed even as the coders were developing the STS. Consequently, giving CFI a chance to make requests for changes or revisions to the code would have been unfair for our customer, since our coders were the ones with the final voice, strictly speaking in terms of coding.

One section where this document was beneficial was in the terms of outlining out testing for the STS. By outlining to CFI our testing methods and schedule for it, it proved to be an asset for us too, as there was a lot of testing to be done with our system. More so since we were actually designing and developing a fully functionally system, and not just a working prototype.

However, perhaps at this point we should have also realized the large scale of our system, and developed a better strategy for ourselves, in terms of completing the system in time, and allowing ample time for all of the testing we had described.

3.6 User’s Manual

The User Manual document was also an asset for both CFI and us. Not only did it outline step-by-step instructions for the STS, it was also an aid for further system testing and refinements. The User Manual was a very clear and concise document, with a decent mixture of graphical and textual instructions. Additionally, the Troubleshooting and Known Issues sections were beneficial for just those reasons. We felt overall this was definite document to include as part of the design process. It serves as both a User Manual and a final verification as for proper system functionality.

3.7 Test Report

The intent of the Test Report document was to report all testing at previously outlined in the Technical Design Document. While we had previously created a testing schedule, in conjunction with all of our testing methods, in all fairness the testing was not conducted this way. This was something which we had anticipated earlier on, which began to make us think as to why did we created a testing schedule which we knew earlier would be hard to follow. In any case, all testing as previously described was eventually conducted, but since we were pressed for time, we felt that not only was the testing rushed, it was obviously was not as systemic as we had described.

However, the obvious benefit of testing and creating the test report was that we were able to identify many parts of the system, which were not functioning as they supposed to. Accordingly, our coding team was able to make all the changes and revisions, based on our testing, and complete a fully functional STS in time for our system demonstration.

3.8 Demonstration

Upon receiving feedback from CFI from out User’s Manual, we made all required necessary changes to system functionality, as this would be CFI’s final chance before our system demonstration to request any changes. Most changes dealt with the cosmetics of the system, such as color and layout, which were not too time consuming for system demonstration preparation.

The demonstration being the last interaction with our customer, CFI, was a requirement. No project with a large-scale system completion, as ours, could have proper closure without a demonstration. The amount of time we had to do our system demonstration, along with time for anticipated questions and answers, was a realistic scenario of a customer-supplier demonstration in the “real world”.

4.0 TIME SCHEDULE

4.1 Overview

In this section, we will discuss how we had planned to utilize our time during the design process for each of our documents, and contrast it how our time was actually utilized.

4.2 Functional Specification and Management Plan

While we were able to compete our first document in time, we still felt that it was justified at this stage to have more time. The reason being that this was our first document as a group, and as previously mentioned, it does take some time for group members to become more comfortable. At the same time, by having time restraints the way we did, it also forced us to take the initiative to both attempt to work together as a team, and obviously, work on the document.

4.3 Conceptual Design Document

Upon completion of our first document, we all had a fairly good idea of everyone’s expertise in document design. As such, we accordingly divided the work to group members who felt they would be the best at getting the work done. Just as in the first document, we were also able to complete this document in time too. We had a lot more content in this document, such as class diagrams, data flow diagrams, and graphical user interfaces, which take time to accurately create. Since we had much more content, we also had clearly defined internal deadlines, in order to pass the completed content to the appropriate group members for either compiling or editing, for example.

4.4 Presentation

Our initial presentation required the same amount of time that any other type of presentation would require. Our only obstacle was that it was difficult at times to assemble all group members outside of scheduled lab time for meetings, or for practice sessions for the presentation. In any case, we soon realized that instead of trying to meet everyone’s personal schedule, it would be best if we were able to accommodate the a general schedule in which most group members could attend. While we would have liked to have always had everyone’s input on group decisions, sometimes this just cannot be done, and you have to make the best decision for the group’s best interests.

4.5 Technical Design Document

The Technical Design Document was a very large and detailed document, which covered many sections. However, as previously mentioned, we were able to complete our work in time, also because there was some overlap in content between this and the previous document. Also, the changes and revisions we had to make were minimal, which was a positive indication to us because it meant that we were on the right track for designing and developing the STS. Additionally, we saved time since all changes and revisions that had to be made were done by the group members who had done worked on those sections to begin with, so they already knew what they were doing.

4.6 User’s Manual

The User Manual was also a large document, due to the number of graphical user interfaces and steps involved in each one. We attempted to simplify the User Manual by placing the graphical user interfaces into either a generic user section, or a user defined section, such as Student, Instructor, Registrar, and Administrator. We felt that the breakdown of task for this document has handled well and consistently too. However, more time was allocated for editing and revisions since this was an elaborate document, in which correct details were crucial, and because we as a group felt more time should be spent on making our documents look more professional.

4.7 Test Report

Since the STS was behind schedule in development, testing was an issue. While some of us wanted to wait until we had a complete, fully functional system, some of us also felt we could start testing individual modules. While we are aware that proper system testing involves system testing before final completion, it was difficult at times for our group to do so since so many of our modules had a high level of interdependency. In any case, our testing was completed, and in time for our test report. However, this was one area where we were pressed for time, and where we felt taking more time would have been beneficial for all of us.

4.8 Demonstration

If we had been able to properly complete our STS on schedule, we would have had more time to properly prepare for our presentation. Inevitably, we were in fact rushed for time to put together our presentation, which created additional stress for our group. However, our group did pull thru, as we always do, and we were in fact able to properly present a professional demonstration.

Furthermore, special care and attention was given to our question and answer period, which we felt was handled exceptionally well. In spite of any obstacles our group has overcome, not only were we able to properly demonstrate a fully functional STS, but we were also able to prove that STS really did work. We felt our questions were answered flawlessly, and to the best of our ability, as we hope CFI felt so too.

In summary, a general comment that could be made by us, or any other group, is that we need more time. While we did not always feel that was case, we do feel that considering the time restraints we did have, we successfully managed ourselves as a group in order to deliver quality documentations, presentations, and the STS itself. The obvious lesson we all learned from this is that in the future, all aspects of the design process should not only start earlier, but be anticipated to finish later too. Another lesson we learned is that in certain stages, we can work in parallel, instead of working sequentially. If anything, our group was very good at not wasting valuable time. That is, as a group if we were together for meetings or group work sessions, we were focused on our tasks.

5.0 MANAGEMENT STRUCTURE

Our group consisted of a diverse group of thirteen students, with the assumption that we were supposed to be a group with members each having their own strengths and areas of expertise. Inevitably, each group member was expected to benefit the group as the whole, with their specific skills set. As such, we formed a team management when we first met.

Initially, we all introduced each other and exchanged names and contact information. Accordingly, we discussed our strengths and weaknesses as a group, and then began to decide who would lead the group. However, before we even selected our project manger, we also had group members who were eager to form their own coding hierarchy team.

Eventually, we selected our project manager, along with an assistant project manager too. We also selected our sole web-master, along with our two main document editors. It was assumed that the web-master and document editors would work in conjunction in order to produce professional documents that would be appropriate for our website. Furthermore, we also assigned three group members who were essentially our coding team.

With that being said, five of our group members had no title attached to their name. However, as you will find out, that did not mean their roles were not as important as others.

Our first two assignments included the involvement of everyone in the actual document creation. We broke up into subgroups, which met on their own outside of regularly scheduled lab time, and we came back to following lab with our results. This worked well for the most part, except that our documents took longer to compile, depending on how the editors were receiving material from other group members.

By our third assignment, the two main editors were solely responsible for editing only, the group felt the editing was not at the level it should have been. This was a result of internal deadlines not being met on time, along with additional roles the editors had taken on, such as formatting the document and writing up minor sections. In any case, this had a caused a delay in the past, which directly effected the web-master. It was not fair for our web-master to wait until almost the day before a document was due, to publish our documents. As we all know, any professional web-master requires time to effectively publish any document online.

Towards the remaining documents, group members who may not have been as involved before, because they perhaps were not directly assigned a role from the beginning, were now taking the initiative to become more involved. By now, we also had a shift of responsibilities that were previously defined. We were beginning to see overlap between roles and responsibilities as group members generally became more involved.

Additionally, it was around this time that our coding team was taken off from further document design so they could have both a head start design and develop the STS, with enough time for system testing too.

While our group had initially defined roles for group members, and most of them remained the same, all of us dynamically changed our roles to pull thru. The roles that our group members were assigned to from the beginning, were not the only roles they had within our group. For example, group members took an active role with populating our database and system testing, the project manager became more involved with coders, and the webmaster was involved in both the initial and final system demonstrations.

The reason why many other group members had to pull thru, along with our coding team, to properly design, develop, and test the STS, was because we challenged ourselves. We not only exceeded our customer group requirements, but course requirements too. We created a fully functional system, instead of just a working prototype for demonstration purposes. We have implemented a real-time database, courtesy of our coders. None of our data, nor outputs, have been hard-coded into our system. Consequently, this required additional time, which perhaps not only the coders, but also the entire group overlooked from the beginning. If we had initially realized just how much work was involved in creating and running a real database, maybe we would have found alternative solutions for our system.

In summary, under the leadership of both our project manager and assistant project manager, our group was always able to finish all documents on time, adequately prepare and practice our system demonstrations, and obviously, completely design and develop the STS.

6.0 OPINIONS AND LESSONS LEARNED

Since this is our final document, all group members of Software R Us were asked to state their opinions in regards to the following three questions:

1. If this were a real project, how would you do it?

2. Changes you would make?

3. Lessons learnt?

Their responses are presented in the following section:

6.1 Kathi Bradley

If this were a real project, how would you do it?

Since this is a school project we allow room for people to learn from their experiences and a chance to grow. If this were a real system, I would hope we would have put the most experienced people in positions they excelled in and had more defined roles for them. We allowed in having an inexperienced leader, even though there were still obstacles along the road, he did do good job. The coding team would have been well defined if they knew exactly what they were doing.

Changes you would make?

Hard deadlines would have been defined better. If this were a real job, and not a school project, people probably would have put all their effort into their work, and probably done a better job. Communication between the group was good and I was impressed with how cooperative everyone was. There were a few individuals that put extra work into the project and it showed, even though they were just as busy as everyone else.

Lessons learnt?

The team should have worked together more. If the coders should have worked on the system together, there may have been better organization. The writer would then been able to ask the coders questions. Thus, in the testing phase, the error could have been fixed as they were found.

6.2 Ken Chen

If this were a real project, how would you do it?

If this were a real project, I would first spend more time on the development phase to make sure that all the requirements are met. I would also have people start experimenting with some developmental implementation to see what the advantages and disadvantages would be.

Changes you would make?

Some of the changes that I would make would include more material that was taught in the lecture, and not deviate from it or teach us what is needed to do the assignment. I would also concentrate on one area of the process of the Software Engineering, and not all areas, as 3 months is not long enough to do what is expected. Also, expectations should be made clearer for the students.

Lessons learnt?

· Do not trust what people may say, only trust what they do.

· Always have a back up plan for even the most obscure problems that may happen.

· Start implementing earlier so there isn't too much work in the end.

6.3 Chad Clark

What I felt went well:

· We had excellent support from the whole team in putting together scripts to populate the database with reasonable content.

· We developed the system quickly under time constraints. We developed the system in about 2 weeks. We only had four people in charge of coding. The final system came out to over 10 thousand lines of code. That's 5000 LOC per person-month. I think that's pretty good considering two of our programmers were not familiar with PHP/HTML/SQL before starting and only one was familiar with Oracle.

What I felt did not go well:

· Database access was delayed and a bit limiting. Oracle required trigger code to be

written and sequences to be setup. In addition to our setup time we didn't have permission in the database. Only two of our coders had command line access to the database, and only one of them had experience with Oracle and databases. This meant we had to write PHP code just to view the contents of the tables.

· Sessions don't work properly on the CPSC web server. I am not sure if this is a result of the "safe mode" imposed on PHP or if there is some other problem but it took a while just to get a login page working.

· As far as I know Oracle documents are available only if you are willing to pay for them. I spent a lot of time just trying to join tables in a certain order and gave up resorting to using multiple queries instead.

What I felt was not effective:

· The documents did not describe the system. We created "class diagrams" because we

felt we were expected to. When we created the class diagrams we didn't plan on using classes in our programming. We specified "modules" in order to meet document requirements and originally didn't really believe in the breakdown. If this were a real project I would want to design the system the same way we plan on implementing it.

· We had inconsistencies in our documents. There should have been more checking across the documents and sections. We had GUIs that included personal information that the database did not allow for.

· We should have started the implementation earlier. The coding didn't really start until we had access to the database, which left very little time for development and testing. A bit of code was written earlier, but you can't really know how well it will work without seeing it in action.

· There were differing expectations for the final system. Some viewed the project as a prototype that would be thrown away in a few weeks. Some felt very strongly that the system should be a fully functional and usable system.

· The goals of this course were not made clear. I see this course as a time to learn the processes of developing software and gain experience working with other people on a team. This is not a programming course, and it should be made clearer.

6.4 Brandon Holtz

If this were a real project, how would you do it?

I think we should have taken more time to work on the actual system. Perhaps we could have included a few more people that understood what the coders were doing and could act as a liaison between the document writers and the coders. This would have cleared up more time for them to code the system, while still allowing the document to get done with the correct information.

Changes you would make?

Changes I would have made to the system would have been to exclude the extra functionality that we offered in the original documents, it appears, to me at least, that we may have promised too much when they were not looking for it. I also would have liked to be included more in the actual coding of the system.

Lessons learnt?

I think that the main lesson that we have learned is to make sure the system is started early in the semester. However I think for the most part we have done a fine job in the time given.

6.5 Manny Lavery

If this were a real project, how would you do it?

· Present only a horizontal or vertical prototype not both:

Since a lot of the project is similar this ensures that the user has early feedback on their ideas. With the reduced amount of work, the user is more likely to return feedback. If the user desires fundamental changes to how something looks or works it is easier to do so.

· Perform the project development in as a JAD up to when the process evolves from prototype to developing the release.

· Drastically increase enforcement of design patterns and object orientation to reduce large uncontrolled scripting that is difficult to change and debug.

Changes you would make?

· Redesign the database to reduce some of the data integrity complexities, and add additional columns in certain tables to reduce the need to multiple and nested queries.

Lessons learnt?

· PHP can be both a difficult and time-consuming language to use for HTML design, as it has a high learning curve.

· Database design is very time consuming work. Thus, the assistance of an expert for designing such a large, complex and complicated database would be more efficient and reduce errors in database

6.6 Yan Ma

If this were a real project, how would you do it?

· Team structure – if this a real project, every member of the team will be assigned to a specific roles which will eliminated the task of figuring out who is supposed to do what for each document. Also the roles of each team member are assigned according to their skill set. Every team will have a complete skill sets across members, and you can be sure that every member should be reliable.

· Smaller group sizes – a group of 13 people doesn’t necessary mean more productivity. Due to the huge amount of communication needed between members, it actually slows down the progress.

· Time – If this is a real project then every member will have the same schedule and be working more together with each other.

· Communicate with the customer – work more closely with the customer to limit the changes required.

· SQA team – have a separate SQA team to do the testing.

Changes you would make?

· Reduce the amount people in each team.

· Increase the lab time to 2 hours, since it’s hard to find a common time for every member to meet outside of the class.

Lessons learnt?

· Start early – so that if anything that needed to be change there’s still time and most task takes longer than you plan.

· Communication – good communication is the key to a successful team project. Even when work is divided into sub-group, part of project from each sub-group must flow with the other parts.

· Cooperation - It’s very difficult to communicate with 13 people since everyone has their own opinion. So it’s important to accept people’s differences and learn to work with them.

· Leadership – a good leader is very important on keep track of the progress of the team.

· Teamwork – Being able to work with other is essential for software developer.

· Software design – The important of design process in software development is shown through doing various design documents.

· Testing – Testing is very important to ensure a quality product is being produced.

6.7 Alan Maryniuk

If this were a real project, how would you do it?

I think if this were a real project, many of the group members would have specialties in certain areas. For example, we would have technical writers that specialize in editing and writing.

Changes you would make?

If I could make a change to the course it would be to make the groups smaller. That way, there would be less diversity in the group which would mean that everybody would have to play a bigger role in each part of the course. As it is now, groups are pretty much split into two sub-groups - people that have good writing skills, and those that don't. The people with the best writing skills often do the most work and the rest of the group just adds filler to the documents.

Lessons learnt?

I think in school everyone is still in the process of learning what they are good at, and I think too much time is spent in this course 'trying' to help people get a better feel for what they are good at. For the most part, it is just a course to get people to start communicating.

6.8 Aarti Punj

If this were a real project, how would you do it?

The project we created satisfied the original specifications fairly close. We added details as we went along but as our project is so well understood that we didn't run into many conceptualization issues. The design process was helpful to an extent since it would have been difficult to keep track of all the customer needs if we didn't properly document everything. The design of the system would be the area that ended up changing the most as the coders realized more details on what would be needed while actually coding the project. The test plan was not helpful at the stage it was done. Given a week or so more the testing would have made more sense for our group. If this were a real project, security concerns would have been focused on more. Beta testing would have also been done.

Changes you would make?

If doing the project again, I would have made sure there were people coding from the very beginning. There was really no need to wait until all the documentation was finished, even though that is proper design procedure. Given heavy time constraint, that would have been a better approach to the project.

Lessons learnt?

I learnt that coders should investigate if their goals are reachable within the time given, and even if the resources are available, they should ask themselves if the system is realistic. In other words, can a deliverable be produced within the given time?

6.9 Nitin Puri

If this were a real project, how would you do it?

If this were a real project, I would have had more interaction with our customer group. This could be accomplished by either having more regularly scheduled meetings with our customer group, or by appointing one person from both the customer and supplier groups to be liaisons with the other group, respectively. Better yet, just appoint one person between both groups to be the liaison. Furthermore, I would have reduced the number of design documents, as some of them were quite redundant in nature. Additionally, I would have ensured that the coders were designing the system right from the beginning, with the eventual goal of coding later on.

Changes you would make?

I would have monthly evaluations of the group, with the group. This would give all group members a fair chance to evaluate each other, and accept constructive criticism. I do not see how this could fail any group from producing a far superior system, perhaps even ahead of schedule, if this were done. Another change I would make is allowing students to choose their own groups. One side of the argument is that in the real world, you cannot choose your own group members. That is true. However, in the real world, group members who are not performing their duties, as they would be expected to, would be fired. In contrast, group members who not perform their duties should be dealt with more seriously. However, I feel a way to avoid this is to simply form your own groups. By picking and choosing your group members, I feel group dynamics would be much better.

Lessons learnt?

To begin with, I have learned that people with unsatisfactory work ethic and a negative attitude towards group work, somehow passed CPSC 333/SENG 311, the pre-requisite course. I also learned that even though this was a senior level CPSC course, some people still do not take their courses seriously. As a result of both lessons, the final lesson I learnt was that as an active group member, you should always make sure the rest of your group can deliver what they say they can. In other words, do not leave the onus upon only the project manager and/or assistant manager. It is simply not fair for one or two people to make up for incomplete work from other group members. As a group member, you must be remain active and be involved, at all times. This will ensure successful completion of any system within a given time period, if not earlier.

6.10 Michael Su

If this were a real project, how would you do it?

If this were a real project, I would follow the prototyping model discussed in class. One of the reasons for that is that the prototyping model moves the supplier and customer toward a quick implementation. After the meetings between supplier and customer that are conducted to determine overall system objectives and functional and performance requirements, the supplier can develop a quick design and build a working model of some elements of the system. Also, the customer can use the prototype to evaluate its functions and recommend changes to better meet their needs early in the designing phase.

Changes you would make?

One of the changes that I would make is to have the coders be involved in the meeting with the customer, which will determine the overall system objectives and functional requirements. The coders can then start building a prototype of the system early, instead of waiting to build the system until the entire design document is done. Also, by following this model, early adjustment of the system can be made and bugs can be found and fixed early in the stage. More importantly, the coders will have enough time building a complete system.

Lessons learnt?

The prototype of the system should be built or at least get started on, as soon as the customer requirement document is done. Initial problems that occur when building the system can be fixed, and coders will have enough time to build a more complete system instead of rushing everything just barely to make the requirements. This way we would have a better and more complete system.

6.11 Jamil Thobani

If this were a real project, how would you do it?

I would separate it into 3 groups:

Group 1 would be documentation specialists.
Group 2 would be designer specialists.
Group 3 would be coding specialists.

Group 1 would thoroughly go through design and produce documentation. Group 2 would design system completely, and send findings to documentation people. Group 3 would implement documents into a working program. Furthermore, Group 1 would also include one member from Group 2 and 3 as advisor, in case there was something to be cleared up. Likewise Group 2 would include one coder and one documentation specialist. Group 3 would have a document personnel incase they cannot translate something from the document. A designer would be necessary for Group 3 too.

Changes you would make?

Have more one-to-one meetings with the customer group. Do not have as many people in the group, a 13 people is too many, but 8-10 people is a good size. Also, have requirements for each document clearly stated on the course website or course outline, instead of us having to figure it on our own.

Lessons learnt?

· Working hard brings good results.

· Get to know everyone in the group right away.

· Try to have your final version ready at least two days in advance, because there are

always last minute changes to be made.

6.12 David Troung

If this were a real project, how would you do it?

I would say that if this were a real project we would have the coders start on the program much earlier, or at least have a mock program up like the other group had during the first demos. This would probably be more realistic because we could then find out which requirements are not feasible to code.

Changes you would make?

Changes that I would make would be cutting some of the documents short, either have fewer documents, or have them covering less because we repeat a lot of material, such

as the testing.

Lessons learnt?

A lesson learnt is to start on everything earlier as we did to have a couple of days of buffer time if anything else arises or if things take longer than expected.

6.13 Mark Velichka

If this were a real project, how would you do it?

If this were a real project, I think there would have been more communication between us and the customer. A lot of the requested changes that they were making in our documents could have been avoided had there been a constant stream of questions and answers back and forth, instead of just the replies to the documents. Either more meetings with the customer group, or more emails being sent would have helped a lot. Also, while everything worked out fine, I think stress could have been avoided if we pushed to have our work done before the due date. However, I think the way we split tasks up was good, and what we did was high quality.

Changes you would make?

I think the team was much too large. I know the whole point of the assignment is to see how well we can divide into smaller teams, and divide up tasks and all that, but I think that's kind of a moot point if in real life we're being placed in smaller teams anyway. I think I would also start coding sooner, and then base documents off of the code, instead of the other way around. Too often the documents are followed closely and then

it's discovered that they are incomplete, and it's difficult to pass that information to everybody.

Lessons learnt?

Currently, I've learned that if for some reason or another you are unable to do something, the rest of a good team will be willing to pick up the slack, assuming you don't make a regular practice out of it.

7.0 CONCLUSION

Once again, on behalf of the team at Software R Us, we would like sincerely thank Creative Futures Institute for allowing us to design and develop the Student Timetabling System. As your supplier, we were not aware of all of the intricate details that go into the design and development for such a demanding software solution. Consequently, we would like to thank Creative Futures Institute for their patience throughout the entire design process, in order for us to meet your functional requirements and implements changes, requests, and revisions along the way. Our product was a deliverable which we consider to be a professional software solution. We are delighted that we have been able to create a professional, working relationship with Creative Futures Institute, and as such, we look forward to working with you again in the future.