Systems Analysis Team Project

Goals

• Promote appreciation of good information gathering techniques,
• Apply analysis and modeling techniques learned in class to a moderate sized case,
• Learn to consolidate products of process and data modeling, and
• Experience group dynamics typically present in most reasonable sized systems development projects.

Deliverables

The project consists of two deliverables, a document review, and one in-class presentation. Detailed guidelines about the contents of

• Deliverable 1: draft system project , due APRIL 8
• Document review , due APRIL 29
• Deliverable 2: final system project, due APRIL 29 (last day of class) and
• format of the presentation, which will be conducted on APRIL 29.

As you work on the project with other members in the group, you will realize that it takes thoughtfulness and effort to become a good team and produce a good project. Look at what other groups have done in the past to become a good team.

Dividing the Work

Deliverable 1: Draft system Group Project

• Team Logo.
• World Wide Web Presence. Use System Architect's HTML report to display encyclopedia.
• Executive overview.
• Table of contents.
• Pre-interview and post-interview assessment for each interview.

(Summary, limit total to 1 page).
• Analysis of information gathered during the interviews.

(Summary, limit total 1/2 or 1 page of bulleted comments.)
• Analysis of Requirements, including documentation of dropped requirements.
  (List those requirements that were dropped, and why.)
• Problems with the current system, mentioned, noticed, and discovered.

(Summary, limit to 1 page.)
• Rationale (objectives) for the proposed system

(5 to 10 in total.)
• Requirements for the proposed system.

(10 to 20 in total.)
• Conceptual Model and Class Diagram.

(Conceptual model is a simplified, and earlier version, of the Class diagram.)
• Use Cases

(In the draft, do 2 * N, where N is the number of group members--this will provide an overview of the project.)
(In the final version, do N+1 and provide detailed collaboration diagrams.)
• Sequence and Collaboration Diagrams.

(In the draft, focus on sequence diagrams. In the final, drop the sequence diagrams, but expand their ideas in the collaboration diagrams.)
• Appropriate reports and Screen snapshots from the CASE tool that support your work.
• Definitions of all requirements, classes, and objects.
• (Unified) Rule check reports for all diagrams.

(Optional, running these reports may help you find minor errors in your work.)

Document Review

• Group fault check-list
• The documented review.

Deliverable 2

• Team Logo.
• World Wide Web Presence.
• Executive overview.
• Pre-interview and post-interview assessment for each interview.
  (Summary, limit total to 1 page).
• Analysis of information gathered during the interviews.
  (Summary, limit total 1/2 or 1 page of bulleted comments.)
• Analysis of Requirements, including documentation of dropped requirements.
  (List those requirements that were dropped, and why.)
• Problems with the current system, mentioned, noticed, and discovered.
  (Summary, limit to 1 page.)
• Rationale (objectives) for the proposed system
  (5 to 10 in total.)
• Requirements for the proposed system.
  (10 to 20 in total.)
• Conceptual Model and Class Diagram (with operations and Contracts).
  (Conceptual model is a simplified, and earlier version, of the Class diagram.)
• Use Cases
  (In the final version, do N+1 and provide detailed collaboration diagrams.)
• Sequence and Collaboration Diagrams.
  (In the draft, focus on sequence diagrams. In the final, drop the sequence diagrams, but expand their ideas in the collaboration diagrams.)
• Appropriate reports and Screen snapshots from the CASE tool that support your work.
• Definitions of all requirements, classes, and objects.
• A copy of your Document Review.
• Responses to points raised by the Document Review.
  (A summary of the changes you have made (or have not) in response to the document review.)

Final Presentation

• Teamwork (1 minute)

Introduce your team and members. Demonstrate or indicate how all team members were involved in the project. Briefly describe their contributions.
• Problems with the Current System (2 mins)
  We know why your team was hired. Get to it the point! Bullet the problems you discovered - while reading the case, while doing the interviews or while creating system models. State each problem(s) in a single phrase or sentence, and explain the reason(s) in terms of shortcomings of the current system. State the evidence you found to make this claim.
• Broad-Brush Outline of the Proposed System (2-3 mins)
  Explain the focus of your modeling efforts. Show the conceptual model and use cases along with the rationale and requirements. Explain why you chose this to be the scope for your system, and why you excluded what you excluded. Relate your decision directly to "Problems with the Current System".
• Proposed System Model (5- 8 mins) Generally, its best to show at least one vertical "slice" of the system: from business objective, trace to collaboration diagram, then show the relevant classes. Consider also showing other aspects in more detail if you have time. Show the class diagram. Briefly explain the careful steps you took to make sure that your model is correct - for example, state which reports and checks you conducted using the CASE tool. Clearly explain why and how your proposed model is better than the current business operations in dealing with this problem.
• Conclusion (1-2 mins) State that you have addressed other problems in a similar manner. Also, state the problems you did not address since they were outside the scope of your system. You have presented the results of your 'Analysis'. Finally, try to answer the questions that the executives of this company will have: What Now? Why should the 'Systems Design' for this project be awarded to your firm (and not the other teams)?
• Open Floor
  Finally, the presenting team will respond to questions from the class. Your instructor will moderate the time remaining.

CASE Tool

What should the Executive Overview contain?

The executive overview is where you should sell your project to your instructor. It should be not more than 2 pages. It should tell the instructor what the project is all about, and must (1) talk about problems you faced while completing this deliverable and how you overcame them, (2) brag about the nifty things you discovered or did, and (3) the problems that still remain unsolved.

What are the Appropriate Reports and Screen Snapshots ?

There is a reason why people create and print reports. For each report you decide to include in the deliverable, you must have a title page that clearly states the name of the report, why you decided to run the report, and what you expect the reader to gather from reading the report. Sometimes, running a report (such as a Report of Errors) may result in an empty report. In that case, you may choose to print the screen snapshot from the CASE tool to show that no errors were found.

Examples of what other teams have done in the past for those Extra Efforts:

• Use of animation during the final presentation.
• Design of new reports using System Architect.
• Insightful and well-written extensions to the Executive Overview.
• Comprehensive interview schedules and agendas.
• Insightful analysis of interviews.
• Clarifying and classifying requirements using various schemes.
• Insightful or novel analysis of Rationale or Requirements.
• Use of schema generation facility.
• Use of menu generation facility.
• Use of screen prototyping facility.
• Use of 4GL prototyping facility.
• Creation of simple running prototype.
• Use of presentation graphics facility.

As you work on the project, you will notice your own unique talents and ways to extend the mundane list of requirements to final products you will be proud of. Pay attention to what the other group members are good at, and show your appreciation so you can motivate them to put in those extra efforts. Also, listen to what others in your group say about your work. You will discover things that only you are great at, and you will be able to get those extra effort points.

What is TeamWork?

The following excerpts were taken from the one page Overviews of Project Deliverables turned in by the group: Intelligent Designs Incorporated during Spring 1995. Write an insightful overview, and you will be represented in these pages.

"In preparing this deliverable for our project, our team has spent a great deal of time. Indeed we have spent a considerable amount of time since the beginning of this project. Our team meets every day before class for an hour and a half and on weekends as much as eight hours at one time. We have also met in smaller groups on several occasions to work out details with particular areas of the project.... ... One of the major problems we have encountered is working as a group. Our team consists of six people with very different personalities, which led to many areas of disagreement. We originally could not agree how to approach the group project and the various tasks involved. Some members wanted to work on everything together to ensure continuity and group concurrence. Others wanted to divide the project tasks among group members to avoid duplication of efforts and wasted time. This led to the compromise of dividing the project, working individually on each person's assigned part, and then coming together again as a group to look at everyone's effort. Unfortunately, we then tried to scrutinize everybody's work and struggled to make the "perfect" system. We now feel we spent too much time in this area. Once we realized that we would just have to trust each other and their talent, things went much smoother. We also realized that you can't please everyone and we have each had to compromise in one way or another for the good of the group. This has been a difficult lesson but one well worth learning. Other problems relating to group dynamics was the clash of personalities. As with any group, some personalities are more dominant than others. This has caused some communication problems and hurt feelings among group members. We are continuing to strive to overcome these problems. Realizing they exist is half the battle. Our team members are extremely talented and hard-working and given more time, we believe we could effectively meld into a 'true' team."

"The most difficult thing we encountered in the completion of our project had to do with group dynamics. Our team consisted of six members, each of whom had a different level of knowledge, understanding and perspective to bring to the group. In addition, we had a wide mix of personalities who took on many different roles including all of the standard group task roles: initiator, information seeker, information giver, orientor, evaluator/critic; the social and maintenance roles: encourager, compromiser, group observer, gatekeeper/expediter; and individual roles: aggressor, blocker and dominator. We fell right into one of the major disadvantages of group work: GroupThink. We fit the classic textbook description of GroupThink: over-reliance on the group decision process as lead by some of the more dominant role players lead to bad decisions as a result of failure to critically assess ideas and seek out minority ideas. We found ourselves making more extreme decisions than we would have done on an individual basis.

There were some good things that we were able to do with our group. At the first meeting an attempt was made to get everyone to agree to take on a specific role in the project. Some of the group members were reticent to entrust parts of the project to others. As time passed, however, we found ourselves falling into specific roles: project manager, case tool expert, methodology expert, report writer, and technical writer. It is well established that groups are more effective with use of division of labor. We still need to improve on spreading out the role-specific tasks among the group members, but we have a start. Another advantage of groups is the phenomenon of synergy where the ideas are better because one idea plays upon another to grow and develop superior ideas. It became apparent to us, however, that there is a file line between synergy and groupthink. After looking at both the good and bad things about the work on this project so far, it is clear that with the addition of some effective time management and resource/talent management, and a little more trust and respect for the time and talents of each other, we would make the last portion of this project a much more pleasant experience. We have learned so much about both the 'content' and the 'context' of our group project, and there will be much more to learn."

"This class has given us the most realistic view of 'life in the real world'. We were given a situation that closely resembled what we will be facing in the business environment. No only were we forced to deal with clients, their personalities, and their way of doing business, we also had to deal with our team members and their differences. It was quite challenging. We have all had to work on group projects before, but none so comprehensive and at times, so overwhelming. As much as some of us like to work independently, it was a pleasure to experience this. Where we once saw problems, we now see opportunity. And animosity has dissolved into respect for the talents and hard work of other team members. We will take away a first rate education in team work, which, in the end, may be more important than the class itself"