|
|
 |
|
88-275: Information Systems Applications
Carnegie Mellon University -- Fall 1999
Professors Randy Weinberg & Larry Heimann
Course Nature and Goals: Student teams will design, build and implement an information system for
a client. The client may be a small or large business, a non-profit or charitable organization,
or a business unit of the university. The clients have real problems or functions they wish to
address and are seeking your assistance. Each team's relationship with the client will be similar
to the relationship that consulting and/or development firms have with their clients. At the end of
this semester, each team will provide its client with a complete, usable, and tested system as well as
necessary documentation and training.
One goal of ISA is to provide students with an opportunity to synthesize and apply what they
have learned in the classroom about structured analysis and design, data structures, analytical and
empirical methods, and organizational procedures. A second goal in this course is to give students
practical experience working together in teams and with clients on complex projects. Fulfilling these
goals will prepare students for the realities of the information systems business they are seeking to
enter after graduation.
Grades: Grades in this course will be largely determined by the client at the end of the semester.
As in any consulting situation, the first priority is a happy, satisfied client. However, the IDS
faculty will also review and evaluate all ISA projects, as well as project milestones and other work products,
and issue an independent grade on the team's work. Team grades are calculated from the results of the client's
grade (80%) and the faculty's grade (20%).
Individual team members can expect that some adjustment -- positive or negative -- will be made to their grade based
on midterm and final peer evaluations which reflect their contribution to the team effort.
After the team grade has been set, individual grades may be adjusted based on the midterm peer
evaluation (33%) and the final peer evaluation (66%). Because of the importance of the peer evaluation process, any student who turns in any peer evaluations late will lose one percentage point per day late.
This means that students on "A" teams who fail to turn in peer evaluations on time may potentially drop in grade.
Your integrity in the peer evaluation process is related to the teamwork goal stated earlier and should be handled by the students as a professional
obligation.
Attendance of weekly team meetings and project presentations is mandatory for all team members. However, students are allowed to miss up to two meetings (unexcused) without grade penalty. Excused absences will only be granted for verified medical reasons. Unexcused absences from weekly team meetings cost students
one percentage point for each absence. Likewise, students missing a project presentation to clients or faculty without excuse will be docked 4 percentage points.
Teams that produce non-working or otherwise substantially incomplete systems can receive
a grade no higher than a "C." To be considered a complete project, the system must be working, delivered to and
usable by the client, have documentation (user and technical), and meet whatever special requirements teams and
clients have agreed upon their contract.
Contract With Clients: After discussing and settling upon system requirements, each team will develop a contract
that is mutually acceptable with its client. This contract will spell out the responsibilities of both the team and
the client and establish a timetable for delivery. This is an important milestone for the team and agreements should not be entered into lightly.
Additional contractual issues to be negotiated may include agreements regarding proprietary materials and/or licensing. With regard to intellectual property,
the university's General Counsel has stated that:
"A student's work product created during an undergraduate class as a
requirement for the class is typically owned by the student, per the
Intellectual Property Policy of Carnegie Mellon University. In this class,
you will have the opportunity to participate in a project which may have a
'live client', typically a non-profit organization. If the sponsor
requests ownership of the material created during the project, you will be
required to relinquish your ownership of the work. If you do not want to
be in a situation where you would be required to relinquish ownership, you
must advise the professor at the start of this course and you will not be
assigned to such a project. You will be provided alternative options for
completing the course requirements without prejudice."
All teams are to have signed contracts no later than October 8, 1999. All contracts must be reviewed by the supervising faculty member prior to presentation to the clients.
Delivery Date: Final delivery of the system to the client should be no later than December 3, 1999. This date coincides with the project demonstration fair which all teams are required to participate in. Furthermore, faculty will evaluate all systems from November 28 - 30, 1999. Teams are required to schedule with faculty a time for system evaluation during this period. All systems should be functional at the time of the faculty evaluation; systems which are not operational at that time will be docked accordingly.
Other Milestones: During the course of the semester, students must develop the following documents and presentations for the benefit of the team, the faculty, and where appropriate, the client. For all cases, teams are
responsible for making copies of all documents and distributing this material to the appropriate parties in advance of any meeting which they are being discussed. With the exception of the project proposal and presentation, client
involvement in these milestones is at the discretion of the client.
• Task & User Analysis
Teams will prepare a set of task and user analysis materials to include:
-- a description of the users and their jobs;
-- a description of user's goals and tasks;
-- client's current system and technical infrastructure;
-- a brief problem description statement;
-- a brief statement of project scope and system boundaries;
-- a brief statement of short- and long-term project objectives;
-- a list of assumptions (by team and client) relating to the project;
-- a list of risk factors and a preliminary analysis of these risks;
-- a set of primary use cases;
-- a list of nonfunctional requirements.
This milestone is to be completed no later than September 17, 1999.
• Logical Model
As appropriate, each team will provide documents related to the system's logical model and/or any other work products designated by the team and its advisor.
This milestone is to be completed no later than October 8, 1999.
• Project Proposal & Presentation
By midterm time, teams will create a project proposal in conjunction with the contract that will incorporate what has been learned in the analysis phase. Each team will provide clients with a clear, nontechnical presentation which discusses client needs and goals, functional requirements of the new system, and a review of factors (such as maintainence) which will
contribute to the short- and long-term success of the system. On the week the team is designated to present its findings, all team members are required to attend. Students who arrive more than five minutes late or leave early will be docked three percentage points.
Contracts are to be signed and turned in no later than October 8, 1999.
Even-numbered teams will present on October 1, 1999.
Odd-numbered teams will present on October 15, 1999.
• Documentation Outline -- A preliminary plan for documentation should be turned in advance for review by the faculty and, as desired, the client. This outline should describe:
-- the user manual you are preparing;
-- provide a table of contents;
-- how you will index the manual;
-- how you will deal with user problems and troubleshooting;
-- how you will deal with "handoff" to the client for maintainence.
It is advisable to also prepare formatting guidelines so that the documentation ends up as professional documents with consistent font, margins, etc.
This milestone is to be completed no later than November 5, 1999.
Role of Faculty: Faculty (and assistants) are assigned to supervise teams, but not to be members of the team. Faculty review and evaluate team progress, provide appropriate technical guidance as needed, and endeavor to solve problems which may arise within the team or with clients. Teams will meet with faculty on a weekly basis and attendance at these meetings is mandatory for all
team members. Team managers will be responsible for setting the agenda for each weekly meeting and distributing that agenda to faculty at least 12 hours before the meeting time; failure to adequately prepare for weekly meetings may result in a team grade reduction.
Below is contact information for the faculty advisors:
Two Words of Advice:
1. Given the semester time limits, it is advantageous for teams to be able to assess client needs and requirements and from this settle on a contract as quickly
as possible; this allows for more time on design, development, and testing. But haste in this phase can be a double-edged sword: teams that move through this initial phase too quickly may not accurately
assess what is needed and build a useless system which either addresses the wrong issue or misses key requirements. (Warning: this has happened before!) Hence,
teams should not delay in getting a contract established, but also should not settle on a contract until they are confident that
they understand all the needs and circumstances of the client. Learning how to walk this fine line is part of the educational experience
of ISA.
2. For a team to work effectively, members must subordinate their own agendas to the team's goals. Problems in teamwork can stem from personality
conflicts that leave one or more team members -- or in at least one past class, a client -- alienated and unproductive. These conflicts lower the
quality of the team's output and reflect badly on all involved. Despite our best efforts to create teams with good "chemistry" it is still quite likely
that you will find yourself working for or with someone that you neither respect professionally nor like personally. Successful people manage in such
situations to minimize personal strife and to be productive. Subordinate your egos and act in a professional and mature fashion throughout the project.
This does not mean you should ignore your and/or others' feelings. A personality conflict sometimes disguises itself as a technical problem or client
difficulty. If you believe you are having trouble making progress in your group, please talk with a faculty member immediately.
These pages are relevant for the Fall 1999 semester.
Any questions or problems with these pages
should be sent to Professor H.
|
