CSC 453 Term Project

enjoy… yow, bill

Here are some of the parameters (basically, the ones I can think of right now):

• Teams: You'll work in a team. Each team will probably have 3 members.
• Framework: We'll follow the five systems analysis steps describe in Chapter 5 of our textbook.
• Repository: I will setup k: drive folders for each team. All team members will have read/write access to the folder. Please use the k: drive as your official document repository. If you don't want to use the k: drive for everyday sharing (it's tough to play with over the Internet), that's fine, but please use it for your team's grading milestones.
• Professionalism: I expect professionalism in your team's reports and presentations. I especially expect professional dress and manners in any interaction you have with your customer.
• My role: I will play the part of “system owner” or “executroid” (as Prof. Bill would say). This means that those milestone meetings at the end of each step will be with me. I'll give you the thumbs up or down on proceeding to the next step.
• Grading: I expect that all members of the team will receive the same grade. If you think this is inaccurate in your team, please read the next bullet.
• Apathy, Antipathy: And finally, we have a really good group, I think. However, if you're having problems with an individual team member that you can't resolve in-house, then please see me in person (no email or whatever), and I'll help to discretely fix it.

Have fun, put in the time, and grab your “A” off the tree.

Postscript… our teams are:

canary thanks… yow, bill

Our four teams are:

• NBI - Phil T, Laura C
• Delta Force Consulting - Kelsey W, Andrew B, Chris F
• Yow! Design Group - Joy C, Dave J, Brannon H
• Drumlin Consulting - Chris C, Adam R, Lei F

go team sparrow… yow, bill

As I said, I'm the system owner. Each of the five system analysis steps ends with communicating your progress to the terrible executroids above. So, it shall be with out little simulation. You will present your documents and findings to me. Here's a tentative schedule, with the points to accompany each step:

• Phases 0 & 1 are due end of week 7, by Sunday October 28… 5 points
• Phases 2 & 3 are due end of week 8, by Sunday November 4… 10 points
• Phase 4 is due end of week 9, by Sunday November 11… 5 points
• Phase 5 is due end of week 10, by Saturday November 17… 20 points

Change: phase 4 to 5 points, from 10… phase 5 to 20 points, from 15.

The 15 points allocated to phase 5 includes my grade/analysis of your final report, your week 10 presentation, and how the whole project went in general.

Please email me at each due date with the location of your deliverables. If you have to deliver hand-written documents or diagrams, that's fine… just let me know.

As system owner, I may ask your team to present your findings at any step for myself and a number of my closest consultant buddies… basically, present for the class. This is “code” for I'd like each team to present at least once for the class… we'll see how our schedule goes.

quoth the raven… yow, bill

1. Your interview preparation work. For help, consult our textbook, pages 222-228.
2. I need to talk to your customer to ask them how the interview went.

BTW, here are the project choices for each team:

• Yow! Design Group is doing a church e-commerce system.
• Drumlin Consulting is analyzing a campus-wide recycling program right here at North Central College.
• Delta Force Consulting is creating an online order-taking system for the Casey's Market in Western Springs.
• NBI is studying online tools for information-sharing among students.

Excellent!

The purpose of this phase is to select a problem and customer combination, so that we can start our little simulation here.

The deliverables of this phase include:

• Your interview preparation: categories and questions
• Your interview notes/wrap-up… what important things did you learn in your interview?
• A copy of the “thank you” letter that you sent to your interviewee/customer.
• REQUEST FOR SYSTEM SERVICES is a fancy way of saying, “describe your problem in one page or less.” Start with the books example [page 170] and strip the unnecessary stuff.

The due date for this phase is Sunday October 28.

grilled puffin yum… yow, bill

The purpose of this phase is to accomplish two primary things:

1. Answers the question: “Is this project worth looking at?”, and
2. Establishes a baseline size and boundaries for the project.

The deliverables of this phase include:

• Preliminary Problem Statement - Break your project down into problem statements as shown in the example [page 171]. Please fudge the “annual benefits” estimate and other columns that we won't really know.
• Statement of Work - Follow the book's outline [page 131]. Please include at least one Gantt chart as part of your scheduling. Please use Microsoft Project or something similar for this. Yes, I know that your scheduling estimates are very, um, hypothetical. There are schedule examples in the text. [page 127, 128, 134]
• PROJECT CHARTER - Unfortunately, there is no example of this document in the text. It should be brief. As the book states, it should “define the project in terms of participants, problems, opportunities, and directives; scope; methodology; statement of work to be completed; deliverables; quality standards; schedule; and budget.” [page 167, page 174]

Reality Check - Remember that the schedule and budget projections are for the project development, not the analysis you are doing. Make sense? So, your schedule may stretch into 2008 or beyond. I know that phase contains a lot of hand-waving for our class. Please use your creativity and have fun with it. There will be no presentation at the end of this phase.

The due date for this phase is Sunday October 28. Email me so that I know where to find all your work. bald eagle… yow, bill

The purpose of this phase is to, well, let me quote the book… “The goal of the problem analysis phase is to study and understand the problem domain well enough to thoroughly analyze its problems, opportunities, and constraints.”

Sounds good enough. Understanding the “problem domain” also includes understanding the current system that address the problem being studied. We run into two problems doing this within the confines of our little simulation:

1. Some of our projects don't really have existing systems to study, and our access to users is limited.
2. We don't have the time to do this thoroughly.

So, you will see a lot of shortcuts in this phase, and it shouldn't take much time to complete. We'll spend our money in the next phase where we start describing our solution(s) to the problem at hand.

The deliverables include:

• Context Diagram - This is a one-page diagram of the current system/process. There's a good example in the book. [page 179] Your context diagram should include three things:
  1. The current system as a black box,
  2. Actors (people, organizations, or other systems) that interact with the system, and
  3. Input/output interaction between system and actors drawn as arrows. These I/O arrows should be noun phrases.
• System Improvement Objectives - list the objectives of your system and constraints. [pages 182-183] Notice the four categories of constraints listed here. This document should be short.
• Cause-Effect Analysis - This is optional. If you think it's important or appropriate for your project, then go ahead, otherwise skip it. [pages 180-181]

Reality Check - I do not need two things that the book emphasizes:

1. The book talks about doing process models and data models detailing how the current system works. You don't have to do this.
2. You don't need to do a compilation report for this phase, as shown in the book. [page 184] I'll review/grade the deliverables you create on their own.

The due date for this phase is Sunday November 4. dodo bird… yow, bill

The purpose of this phase is to describe your use cases. OK, it's more than that, but that's the biggie. As we know, your use cases will be used as a basis for future data models and process models to describe your system in detail.

Officially, the requirements phase answers the question: What do the users want and need from a new system?

The deliverables for this phase include:

• Data dictionary - This is an extra that I've added. Please list all the terms, acronyms and jargon that will be used throughout your project in your data dictionary. This is where you decide things like, are we going to call people “customers” or “patients”, and “let's use RN for nurse.” The important thing is that you are consistent throughout your project and that your terms are documented here in your data dictionary.
• Draft Functional and Nonfunctional Requirements - This is where your use cases go. You should have a lot of these and be as detailed as you can be at this point. I'd review Chapter 7 from our text before you get started. This document should include:
  • Use case glossary
  • Use case diagram
  • Use case narratives - the most important part, remember?!

Reality Check - Spend you time and money on your use cases. Have I said that enough? For example, I shouldn't look at your use cases and see obvious additional scenarios that you guys haven't flushed out. This is one place in our simulation that you can really be thorough, and it's also important for you to do so. Another example of a bad thing to do… have a bunch of terms that I can't understand and can't find in your data dictionary.

The due date is Sunday November 4, 2007. soaring hawk… yow, bill

For us, the purpose of Phase 4 is to construct our system models. These models describe in detail our proposed system.

The deliverables for this phase include:

• System Models - Go into as much detail as you can. I can't (won't?) go into all the detail that we have covered over a number of lectures on these topics. Bring your questions to class, if you have them. The system models are covered in Chapter 8 “Data Models” and Chapter 9 “Process Models”. You should at least have:
  • Data models, or Entity-Relationship Diagrams
  • Process models, or Data Flow Diagrams… follow the strategy detailed in the book. [pages 338-353]
  • Linkage between your use cases and the contents of your system models
  • Synchronization between E-R diagrams and DFDs [page 359]
  • Some text accompanying your diagrams, explaining each model and your overall organization
• Prototypes - This is optional. A prototype may be as simple as a series of sketches of what screens and user interaction may look like, to a couple web pages to a working prototype. The key is to add value to your system description, and I anticipate that most projects will have some sort of visual aid to describe their system in action.

Reality Check - Of course, this phase is tremendously important and is the cornerstone of your project. Spend your money here, guys. In this phase, it is also key to distribute your work across members of your team. Please draw your diagrams by hand, review them in your team, and then finally use CASE tools to produce your final, polished diagrams.

The due date is Sunday November 11.

macaw macaw… yow, bill

Phase 5 will put a nice bow on all your project work.

The primary deliverable for phase 5 is your SYSTEM PROPOSAL. Our SYSTEM PROPOSAL will be different from that shown in our text. We'll be focusing more on the technical aspects, rather than the feasibility, alternative solutions, etc approach. We brainstormed a candidate outline on the board in Monday's lecture. It's still worth reading the textbook's discussion of this stuff [pages 431-433]. There's some good general advice in there.

Once you've got your SYSTEM PROPOSAL done, you've got to do a few things with it:

1. Place a copy of all your stuff in your team's “phase5” folder on the k: drive, so I can play with it.
2. Print out one copy of your SYSTEM PROPOSAL and have it bound or put in a binder or something “nice”.
3. Place a copy of your SYSTEM PROPOSAL on the web site of one team member. Your web page can be simple, but not completely bare. Also, you can break your SYSTEM PROPOSAL up into pieces with links to each. For example, the Yow! team's approach on this here wiki would be fine. If you have any questions on how to use your w: drive to do this, please email me.
4. Write a 1-2 page EXECUTIVE SUMMARY of your project. In your summary, highlight that all the details for your system proposal are available at the web site from the previous step. Readers of your summary can then access your details over the web, without printing a cumbersome report.
5. Write a cover letter and send it along with your EXECUTIVE SUMMARY to your customer.
6. Finally, meet with old Prof Bill. Bring your bound SYSTEM PROPOSAL and walk me through all the highlights in 15 minutes or so. I'll check each of the deliverables for this phase.

The drop-dead due date for phase 5 is Saturday Nov 17 at noon. I cannot extend this deadline as the end of the term is near.

holy robin batman… yow, bill