Table Of Contents
Purpose
next
previous
top
WinterSoft is a learning company; we do not want to make the same mistakes
over and over again, and hence this "postmortem". We have set out to evaluate
"Project Atlantis", to determine how we can streamline our processes in the
future, and to avoid potential pitfalls.
To ensure that this evaluation is as complete as possible, we were given
a number of questions by our Consulting Coordinator, Raul Nemes. These questions
should cover all aspects of our project, and they gave our team something specific
to respond to. We had small teams brainstorm as many answers as possible to
the questions, and then those teams asked the rest group for additional input.
This should ensure that our postmortem includes complete input from the entire
group. Finally, the brainstorming teams wrote up answers to the questions based
on their own input, and the input from the rest of the WinterSoft group.
This document is the final result of the evaluation process discussed above.
It is WinterSoft's sincere hope that this document represents all of its members'
opinions, and that this document will provide a useful "road map" for future
software engineering projects we undertake.
If you Took the Course Again, What Would you do Differently?
next
previous
top
Being a large group with many different individual personalities, it was
no surprise that there was a wide range of answers to this question. Most of
the issues brought up could be categorized into a few key topics: Organization,
communication and comprehension.
Organization
next
previous
top
We generally felt that strong organization was imperative to the smooth operation
of group activities. It was expressed by many members of the group that they
would try to find methods to increase the group's organization. One such method
is to hold frequent meetings. It is believed that by holding frequent meetings,
the group as a whole would be more informed with the overall intricacies of
the project. The meetings would give subgroups an opportunity to keep the others
informed with their progress as well as raise any questions or concerns.
Another idea was to use an agenda for each meeting. An agenda could prove
to be a powerful tool to increase productivity during meetings. With a concrete
agenda in place, the group would have a systematic approach to meeting goals
and performing necessary tasks.
Communication
next
previous
top
It is needless to say that strong communication is vital to the success of
any organization. Many group members thought that there needed to be more communication
not just within the group, but between the customers and suppliers as well.
It was thought that the more open communication was between the group the better.
In particular, it would prevent a few people from dominating all of the decisions.
By having more people express their views and opinions, the whole group would
benefit from the wide range of input.
Some suggestions of ways to encourage open dialogue within the group were
more frequent meetings (as mentioned above) and asking everyone to provide
feedback on their work. It might be worth noting, however, that some group
members did ask for feedback on their work, and found that little was offered.
One of the more interesting ideas was that each meeting should be facilitated
by a different person. Giving everybody a chance to lead a meeting is a good
way for people to overcome reservations about speaking aloud within the group.
It is also a good way to ensure that everybody gets to know each other.
Comprehension
next
previous
top
Before anyone starts an assignment or attends a group meeting, it is a good
idea to do your homework first. Some people said that it would have been beneficial
for them if they had just taken the time to understand the documents before
they started to work on them. One suggestion was to simply "go to class".
By having a strong understanding of the work you are supposed to be doing,
you avoid making many foolish mistakes. This way when you or your subgroup
completes an assigned task early, it might be possible to help other group
members if they run into any problems.
If This Were a Real Situation, What Would you do Differently?
next
previous
top
Although this course has given us much insight into a supplier's role in
the project development cycle, we realize that this was in a simulated environment
and that in the real world, the stakes are much higher. There are many things
that we would do differently if this was a real life situation. Nearly everyone
in the group agreed that the number of documents to be produced was too many,
or the documents themselves were too long. Often we felt that there was a lot
of redundancy in our documents because of the sheer quantity of material they
presented. Also, customers probably would not want to read through the large
documents that we produced every other week; we assume that the customers would
be very busy people. One of our members thought that the number of documents
to produce was good because it gave several chances for feedback from the customers,
but they should be shorter.
Another thing that we would do differently is cut out some of the design
processes and replace them with more useful processes. Most of us thought the
pseudocode in the functional design document was not very useful at all. In
the end we did not usually follow the pseudocode for the actual coding of the
project. Writing pseudocode for programming languages with heavy graphical
user interfaces such as Visual Basic was difficult, often we didn't know how
to go by doing it. We found that the cons of writing pseudocode by far out
weigh the pros.
We would probably also change the diagrams that we used in our documents.
They were too complex for a real customer to understand - we ourselves did
not even understand them totally. They should be replaced with more simplified
diagrams. For example, the scope of the ERD's would be out of the customers'
knowledge, we don't think that that they would want to learn something that
applies so little to them. In a real life situation, adding more prototyping
sessions with the customers would probably help us a great deal. The fact is,
the customers don't usually care about the structure of modules or how the
database will be designed, they want to know how the system will work for them.
Prototyping gives the customers a chance to provide more feedback regarding
the system, which will result in a system that better fits their needs.
In a real life situation, resources available to us would be more planned
out, whether it be time, hardware/software tools, or team members. We were
on a tight time schedule throughout the whole course. If we would change anything
at all with the time line, we would have given ourselves more time to code
the project. With so little time and documents due around the corner, we rushed
through the coding of the project, and in the real world this phase should
not be rushed. If we were not on such a tight schedule, more time could be
allocated to the coding phase so better code could be produced as opposed to
a quick and dirty hack job. Technical constraints were a real problem for us.
For example, we were not aware that CGI access was prohibited to us so we had
to change our plans many times before settling on Visual Basic. In the real
world, we would be working in an environment where we should know what sort
of hardware/software tools are available to us.
We also think that managing the group might be a lot easier to do in a real
situation. We would be working in a real working environment and that means
that we would get paid for our services, so more interest and effort will be
put into the work. Free loaders or slackers can be handled easier by by firing
them if they don't smarten up, and it should be simpler to coordinate meetings
with other team members.
How Well did the Project Satisfy Requirements?
next
previous
top
We believe that we followed the original customer requirements as closely
as possible, satisfying the key requirements specified by the customer. We
clearly and effectively covered both Administrator and Student "modes"
for the Registration System.
Some of the system requirements include:
- Allowing administrators and instructors to modify course information
- Allowing administrators and instructors to input grades for each student
in each course
- Allowing administrators and instructors to modify student information
- Maintaining class lists that are updated as a student registers in or drops
a course
- Allowing students to add, change, and drop courses
- Allowing students to check their schedule and marks
- Taking into account prerequisites and co-requisites for courses
- Allowing administrators to overload courses and override requirements
- Allowing students to access calendar information by course name
- Including a waiting list for students who want to get in to a full course
One requirement which we were unable to satisfy is the requirement that the
system be web-based. Due to the environment we were in, it was not possible
to properly implement the system because we were not authorized to use CGI
scripting. This security issue for the CPSC servers was a major hurdle which
our coding group was forced to overcome to build the final system.
Additions and Subtractions
next
previous
top
There were many functionalities that we felt should be added and others that
we felt should be removed. We felt that it was simple and necessary to include
the students' names in the system. This allowed the administrator of the system
to modify a student (or administrator) based on that individual's ID number
or name, hence increasing the efficiency and ease of use of the system. Also,
we allowed the administrators have control over assigning class rooms to lectures
instead of the "system". Another minor requirement that we removed from the
system was the automatic enrollment of a student in a course waiting list when
the course becomes available. Instead, we changed this functionality to prompt
the user on the waiting list when the course becomes available.
We believed that the adding and removing of the requirements discussed above
helped in the creation of a robust and effective registration system.
Bargaining
next
previous
top
During the bargaining session with the customer, we decided that it was necessary
to remove and clarify some requirements. One example is the customer's requirement
to implement a student waiting list. We felt this requirement would be difficult
to implement and nonessential to the final system. We tried to get this functionality
removed. But when talking with the customers, they believed this functionality
was extremely important for the student portion of the system, so we implemented
a simplified version of it in the system. We were also able to get the requirement
of backing up the system information removed, because we believed it was not
our responsibility but the customer's to back up this information from the
servers running the system. The most important requirement that we were able
to negotiate about removing was the requirement that the system must be web-based.
Due to the constraints mentioned earlier, we were not able to implement the
system this way, and we were successful in getting this requirement removed.
All of the requirements that we tried to get removed were based on the time
constraints that we were dealing with; if given more time we believe we could
have completed all of the requirements that the customers gave to us.
How Useful was the Design Process?
next
previous
top
If there is one thing the group liked about the design process, it was that
it forced us to consider the project carefully, and ensure that it was done
right. The design process caused us to look carefully at the customer's requirements,
and kept us from building the system the way we envisioned it. Instead
we were forced to concentrate on the way they envisioned it. In particular,
creating prototypes of the system forced us to think about the best way of
building it, and allowed the customer to give us feedback on how the system
was progressing.
This reveals the basic flaw that most team members identified in the design
process: It was great for the customer, but perhaps not quite as important
for us. One member of the team wondered how useful some of our diagrams were
to the customers. The ERDs and DFDs are simple compared to some other technical
diagrams, but they're still rather complicated, and probably didn't give the
customers much useful information (unless they were planning to build their
own registration system). They were somewhat useful to us, as they allowed
us to conceptualize the system, but we could have done without some of them.
Pseudocode is another issue. While this was helpful in ironing out major
logic flaws, we have to wonder if it was any better than just writing the code.
The editors had to spend a lot of time making sure that the pseudocode was
consistent, and while some of it may have been useful, it probably would have
been more efficient for people to design their own code, using pseudocode if
they felt it was a useful tool for them. Perhaps pseudocode would be useful
for complex, logic-based algorithms, but this system did not have very many
of those.
All in all, our opinion seems to be that the design process was useful in
some respects, especially in ensuring that requirements were met, and the customers
got the system they wanted. But there was too much work put into certain parts
of the documents, and not enough time to do them properly. Less emphasis on
length requirements might have helped to rectify the situation, and a less
formal process in general would probably please the team, although we can't
say whether or not it would work better, since we haven't tried it.
How Useful was the Test Plan?
next
previous
top
From our lectures we have learned that testing is one of the most important
phases in software engineering. As such, we put careful consideration into
the design of our test plan. The answers to this question varied greatly within
our group. Some of us believed that the test plan we used proved vital to the
successful development of Project Atlantis. Some stated that it offered a pragmatic
approach to the testing process, which leaves less room for error. On the other
hand, other members believed that the test plan did not play a major role at
all.
Effect on the Final Product
next
previous
top
One of the benefits of the test plan was that, by following it, we ensured
that the minimal system requirements were met. This way the customers were
guaranteed to receive software that met all of their needs. Several members
said the test plan provided a systematic approach to finding bugs within our
system. Once the problem areas were found they could be dealt with accordingly.
It was also good to have a test plan in use because it allowed members who
were not directly involved in the coding a chance to test the system.
One of the problems we found with the test plan was that it was pretty tough
to get people to stick to the plan. It was found that an informal method of
testing was preferred by a majority of the group. Some found the rigidity of
the test plan to be tedious and very time consuming. Another problem is that
people who were not involved with the actual coding sometimes did not realize
when they had stumbled upon a bug.
Would we Want This as a Job?
next
previous
top
The tedious nature of testing just didn't appeal to the hearts of many group
members. Like Dave Maulsby said in class, "It's difficult to get people
interested once the coding is viewed as complete." Many thought that the
testing was too time consuming and allowed no room for creative expression.
However, some members stated that they wouldn't mind being a professional
tester. They thought that by becoming good testers they would grow in many
different areas. They would improve their debugging techniques, they would
become better programmers, and they would have a better overall understanding
of the systems they were working on.
Others believed that the success of the design an implementation phase can
be gauged on how well the testing phase went.
How Were the Group Dynamics?
next
previous
top
The group started out with a semi-formally chosen leader, and later added
a second leader. There was some room left for "emergent leaders",
which is good, although in some cases this caused power struggles.
An interesting trend emerges when one looks at the opinions of the "management",
and the "workers". Some of the management team felt that the workers
were disinterested, and had to be dictated to in order to get the job done.
On the other hand, some of the workers felt their opinions were undervalued,
and they weren't given respect for their hard work.
A likely source of this problem was the size of the team. It is difficult
for everyone to get together in a team as large as this, so few formal meetings
were held. The members didn't get to know each other as well as they could
have because of this, and communication was not as good as it could have been.
The managers found that few people would volunteer for jobs, so the easiest
way to get their managing done was to dictate roles to the group. They had
to be specific in the jobs being given out, because it was the most efficient
way to make sure jobs got done "right" the first time. The workers, on the
other hand, were being dictated, and had little room for input.
In the end, things worked out anyway. This is probably because of the quality
of the team's individuals - just about everyone ignored their differences and
pitched in when things were rough, and some in particular gave up a lot of
personal time to ensure the job was done well. There was a lot of skill and
hard work displayed by many members of the group.
A potential solution to our communication problems? Create smaller groups
in the future, and work hard to ensure the whole group meets and discusses
the project regularly. These aren't necessarily mutually exclusive, either;
holding more meetings is easier with smaller groups, and communication in general
is less complicated. It might also encourage a greater amount of personal respect
among group members, although there is the opposite possibility: it could merely
allow members with clashing personalities to get on each other's nerves.
Timeline - Did Everything Happen as Planned?
next
previous
top
Our group followed the timeline fairly closely, all of our documents and reports
met the deadlines that were specified by the course. We felt that most things
were done according plan and we even found that we got ahead of schedule and
some tasks were completed before the deadline. This was due to well a organized
team, with leaders guiding us along the way. Hard work among most of the group,
and the reliability of group members bothed played a big role in completing
tasks on time.
Nothing can happen exactly as planned due to human factors and environment.
The coding of our system seemed to have been done well ahead of schedule. This
led us to finish some of the assignments ahead of time too. For example, our
informal testing was completed before the Test Report, and the User Manual
also was completed ahead of schedule. We were glad that our coding team made
such a big effort to complete the system, it gave us plenty of time to good
job on these other jobs.
Unfortunately, there was one unexpected occurrence that happened which made
us miss a deadline. During the publishing of the "Functional Design Document"
the testing team found they were doing the wrong type of testing shortly before
the deadline, we reassembled as a group and completed the testing document.
The testing document however, did meet the extended deadline with no problems.
Although we didn't follow the timeline that closely, we got things completed
anyways. The timeline would have been more useful in a "real" situation,
because in this class all of the deadlines were set for us. We did finish some
things ahead of time, but that was mostly due to hard work, rather than using
timelines.
What is your Overall Impression of the Course and Project?
next
previous
top
Perhaps this course is not the most technically challenging course, but the
adversities that a student must overcome are not any less difficult. Throughout
the semester students learn many things about themselves and other people in
their group. New friendships are made and some old friendships are broken.
By the end of the semester everybody has developed strong opinions on the course.
As usual the opinions within are varied.
The Course
next
previous
top
On a positive note, many people thought the course was a valuable learning
experience. This class gave us an insightful outlook on how software programs
are produced in the real world. We learned a variety of skills relating to
not only the software engineering cycle, but also non-technical skills such
as time management, organization, people skills, and patience. Some members
expressed how much they enjoyed the lectures for the course. They stated how
they found them entertaining and informative, "a real break from regular
lectures". Certain members thought that the feedback for the assignments
was helpful and informative.
For the negative comments, most people thought the course load was a little
extreme. There was a definite problem with not only the number of documents
we had to produce but with the size of each document. The deadlines were constant
and we were often pressed for time. Certain members felt as though they were
putting too much time in on documents that were not even being thoroughly read.
Often the large size of the documents caused a lot of redundancy. One suggestion
to fix this problem was to either reduce the number of documents or reduce
the size of each document. Another issue that arose was that some members felt
as though there were not enough TA's for the course. At the beginning of the
course, there was often a lot of wasted time waiting for the TA to appear.
Sometimes, due to the sheer size of the assignments the TA would take considerable
time to grade and give feedback for assignments. Many feel as though the future
students CPSC 451 would benefit by having more than one TA per lecture.
The Project
next
previous
top
The overall impression is that the project itself was good. Most people thought
the project posed many interesting challenges and learning opportunities. Here
are some of the comments: "It was a great change to design a system that
somebody might actually use …", "It was exciting to watch the
project develop from an idea to something tangible.", and "It's nice
to program something that isn't just a simulation …". As we can see
from the comments, one of the main attractions to the project was the fact
that our group had the opportunity to develop a "real life" system.
There were however some problems that group members had with the project.
Some people thought that the inconsistency between the difficulty levels between
projects was unfair. It was felt that some projects were much more complex
and required more time than others. Most members thought it was unfair that
our project had to be Internet based even though the security issues on the
computer science server made it very difficult to implement. We thought that
the professors should have been aware of this fact and should have warned us
about it.
What was our Relationship With the Customer Like?
next
previous
top
The relationship with our customer group can best be summed-up as a paper
relationship with minimal crossover between the few members of our group that
were friends with those in the customer group prior to this project. In a real
life situation there would be more substance to the relationship because the
customers would be more passionate about their role in the project.
Although there was not much of a relationship between our group and the customers,
they were crucial in the development of the system. They provided us with the
requirements on which to build their system, but there was a problem of response
time when it came to questions of clarification. We believe this has a direct
relationship to the frequency of customer meetings. It is difficult to get
the customer groups to meet when they are busy with supplier documents. In
some cases, this resulted in us having to dictate the answers to our own questions
if we were to complete our assignments on time.
We all agree that this was a much better situation than CPSC 333 where the
customers were the professors of the class. Professors are too busy to effectively
play this role and they do not have the time to keep up with all projects.
In certain situations, this prevents them from being as sympathetic to supplier
issues. Having students as customers made it easier to have requirements waived
or changed.
At the same time, the customer group tended to be very picky when dissecting
our documents. This applies to all groups and we feel there is less of a concentration
on the major ideas because we are forced to find all errors, regardless of
importance, in order to fill the size requirement for the customer documents.
Our group generally ignored this nit-picking and it did not affect the relationship.
We knew why they were making those comments because of our own experience as
customers.
This project would have been more difficult if there had not been a few members
in our group that had friends in the customer group. This allowed us to communicate
as humans as opposed to business associates. This direct contact aided in the
development of the relationship and was crucial in the development of the final
product.
We are thankful that the customer group understood our problems because this
course offers enough work without the added problem of having a strict customer
group. They understood that our major issue, the online requirement, was beyond
our control and they were willing not to call us on it. When they agreed to
waive this requirement we made an effort to include other things they had asked
for. Two examples of this are the student name and the professors being able
to select a room for a class, as opposed to the system selecting the room.
We felt that we owed them at least that, and I think that best displays our
relationship with the customer group.
What Lessons Did we Learn?
next
previous
top
During the course of our software engineering project we learned a great
deal of lessons pertaining to both interpersonal relationships, and the software
engineering cycle itself. In the following section we will discuss the lessons
that we learned from this software engineering course in terms of individual
and group perspectives.
Individual Lessons
next
previous
top
What many of us discovered, quite surprisingly, was the importance that communicating
and relating with the other members played a role in the success and experience
of not only individuals, but also the group as a whole. Whenever a large group
of people comes together to collaborate or discuss certain issues it is always
the case that conflicts will occur. In our group there were a wide array of
personalities, resulting in an interesting group dynamic. Each of us learned
to achieve (to some degree) a better understanding of the personalities and
motives backing the other individuals within the group. The biggest setback
to the success of the group was the size itself. What we found was that we
didn't have much opportunity to work with every member to a degree that would
facilitate strong relationships.
Another aspect of the group project that we were able to learn from was that
of time management. We all agree that the workload of this course was considerably
higher than most other courses. It was something that many of us were unprepared
for especially when our time was divided amongst other courses. In the beginning
we were able to set up meetings with large groups of members to discuss issues
and work on the early phases of our project. This approach we learned was quite
beneficial as it allowed us to help each other out and understand the project
itself to a greater degree. As the project progressed, the assignments became
more separated to the point that individuals would be given a deadline to finish
one part of the assignment. Communication at this point was based mainly on
e-mails between members of the group. Whether it was the nature of the assignments,
individual responsibilities, or a basic breakdown in group relations, the result
was less than positive.
Group Lessons
next
previous
top
One of the biggest concerns we had with the group itself was with the issue
of respect for other's work and/or effort. We learned that for all types of
individuals, offering positive comments or criticism only furthers their need
to do a better job the next time around. This in no way means that a person
should not express their honest opinions, but should strive to express them
in a constructive manner.
On the technical side we discovered some deficiencies of the Visual Basic
language itself. Not to say that Visual Basic is a bad language as it has the
major advantage of being a rapid software prototyping tool. The issues that
did arise however, introduced many problems that were beyond our control.
Another major aspect of a group's success deals with the amount of preparation
that they are able to perform before starting an assignment. What we discovered
was that the preparation that we were able to perform really helped us to understand
the requirements of the system.
Summary
next
previous
top
Once again, the purpose of this document was to learn about the project,
and to determine how it might be done "better" in the future.
To that end, here are a few key points:
- Because of the size of the group, communication was an issue. It is important to communicate
with the whole group, and this would likely be easier to accomplish with a smaller group.
- We ran into trouble with the online requirement. In future projects, it
would be a good idea to find out what technical constraints we are working
with earlier in the project.
- We had some established links with the customer group. If this had
not been the case, it would have been wise to establish those links during the
early part of the project.
- The design process is useful for getting feedback from the customer,
and conceptualizing the system, but it's important to decide how much of
it is of use to anyone. We found some of our documents (or some parts of our documents) seemed
to be wasted effort, and much of the work could have been done in a less formal manner.
This has been an interesting learning experience for WinterSoft,
and we hope that it will help to ensure the success of our future
projects.
[EXECUTIVE SUMMARY]
[MAIN]
[DOCUMENTS]
[CONTACTS]
| 