Click a link below to go to appropriate setion of project:

1. OVERVIEW

2. PROJECT SCOPE CONSIDERATIONS

3. DELIVERABLES

4. CURRENT SYSTEM DESCRIPTION (CSD)

5. USER REQUIREMENTS DOCUMENT (URD) (Reference Martin, p. 245)

7. PROTOTYPE MODEL (PRT)

8. TEAM PROJECT PRESENTATION (TPP)

9. PEER EVALUATION

10. HINTS FOR A SUCCESSFUL PROJECT

1. OVERVIEW    Return to top of page

You and your project team are contracted by a Sacramento-area client of your choice to perform the Analysis and Logical Design phases of the System Development Life Cycle (SDLC). You will conduct all activities and prepare all deliverable products associated with a Final Systems Study. You will use the specific templates, reports, and conventions included in the Visible Analyst WORKBENCH. At the conclusion of your study, you will prepare a comprehensive, high-quality project team report containing your results. You will also design and program a Level 1 prototype model of your system using the ACCESS programming language.

2. PROJECT SCOPE CONSIDERATIONS    Return to top of page

a. Locate a company or agency that is interested in either automating a manually-based information system or enhancing its current computer-based system.

b. Explain to your client that your project team is willing to help them define their requirements for a new system. They can use your study for either custom development or software package selection. Your consulting services could easily cost your client $5,000. You are willing to provide this service free in return for the client's cooperation for the project.

c. You may choose any type or size company or agency. If you choose a small company, cover a fairly wide range of business functions. If you choose a medium- to large-sized company, confine your scope to a more narrowly defined business application (e.g., customer billing and collection). It is better to have a deeper, more comprehensive analysis of a narrow-sized application scope.

d. The student version of the Visible Analyst WORKBENCH allows a maximum of 30 Data Flow Diagrams (DFDs) for any project. Discounting the upper-level control modules, this leaves only 20 to 25 DFDs at the primitive or programmable level. This gives you a natural constraint on the size of your project.

e. Do not choose a system with which any member of your team is currently working.

f. Your level -1 DFD must have at least four (4) meaningful processes.

3. DELIVERABLES   Return to top of page

a. General

All project deliverables (except the presentation) are to be (1) typed, (2) double spaced, (3) enclosed in a 2- or 3-ring folder, and (4) labeled. The outside label should include team number/name, project deliverable name, due date, and names of all team members. All deliverables must be turned in by the beginning of class on the day they are due. There will not be regrading of your deliverables.

Deliverable	Topic
PTC	Project Team Composition (3b)
PTP	Project Team Proposal (3c)
IPS	Initial Project Schedule (3d)
RPS	Revised Project Schedule (3e)
CSD	Current System Description (4)
URD	User Requirements Document (5)
FSS	Final System Study (6)*
PRT	Prototype Model (7)
IPP	Team Project Presentation (8)
PE	Peer Evaluation (9)

b. Project Team Composition (PTC)

Names, phone numbers, class schedules, and work schedules of team members. Include agreed upon weekly team meeting times.

c. Project Team Proposal (PTP)

(1) Name of client company or organization, line of business, company contact, indication of company size, transaction types and monthly volumes, and an organization chart for the part of the organization you are studying.

2) A discussion of the set of business functions or activities to be evaluated. It is presumed that you will not study all areas of the business. For example, you may study order processing but not payroll. The first level DFD must have at least four (4) meaningful processes.

(3) A preliminary Level 1 DFD. (See Figure 6.1-4, p. 192, of the Martin textbook.)

(4) See grading checklist on next page.

F When I review your proposal, I may require that you modify and resubmit it.

d. Initial Project Schedule (IPS)

(1) Narrative portion:

(a) Class life cycle stage (e.g., current system description).

(b) Tasks within stage (e.g., interviewing).

(c) Name of analyst responsible.

(d) Time allocated (e.g., 1 week).

(e) Completion date (e.g., end of 6th week).

(2) Gantt Chart. (See Figure 3-11, p. 106, of the Martin textbook.) Include stages and tasks as shown in d (1) (a) and (b)

e. Revised Project Schedules (RPS)

Same format as IPS.

5. USER REQUIREMENTS DOCUMENT (URD) (Reference Martin, p. 245)   Return to top of page

a. Conduct Of Analysis

(1) End-users contacted.

(2) Records, forms, and reports analyzed.

(3) Processes observed.

4) Analysis methods used (pp. 228-234).

(5) Problems encountered with data collection.

b. User Requirements

(1) Unconstrained system objectives.

(2) Report requirements by type, layout, and frequency.

(3) User training requirements.

(4) System constraints (summary) (Martin, pp. 243-245).

c. System Constraints (Detail)

(1) Description of time, funds, skills, technology, and external factors (Martin, pp. 243-245).

(2) Realistic system objectives (must be measurable).

d. Logical DFDs of Current System

Include a narrative description of how you changed your physical DFD into a Logical DFD, e.g., what processes did you eliminate (see Martin, p. 173).

e. Logical DFDs of Proposed System

Include a narrative description of how you changed the logical DFD of the current system.

f. Application Architecture Diagram

Design a diagram similar to that of Foundation Health Corporation as shown on the following page.

g. Problem Correction Alternatives

(1) Hardware (at least two different configurations).

(2) Software (including outsource, purchase, or in-house design).

(3) Processing (batch versus realtime and key-stroke versus scanning entry).

h. Documentation

(1) Data collection instruments.

(2) Synopsis of interviews.

 

6. FINAL SYSTEM STUDY (FSS)    Return to top of page

a. Submission Requirements

(1) Typed, double spaced.

(2) Submit two copies. I will keep one and return the second (corrected copy) to you.

(3) Comprised of:

(a) Transmittal letter addressed to your client.

(b) Body of report.

(c) Plastic disk holder pages containing VAW DFD/Data Dictionary disk and Level 1 prototype (ACCESS).

(d) Title page consisting of client name, team name, and names of all team members.

(4) One copy of the Final System Study (the 1 copy I will retain) should be bound.

(5) Each team member will be assigned the same number of report points, subject to peer evaluation adjustments.

b. Contents

(1) Executive Review:

(a) Description of problem(s).

(b) Proposed solution.

(c) Summary of cost/benefit of proposed solution (pp. 269-273).

(d) Implementation time frame of proposed solution.

(2) Proposed System Narrative

Use Level 1 DFD as a guide.

(3) Physical DFDs for Proposed System (in Appendix)

(a) Include narrative description of changes from logical DFD for proposed system.

(b) List of who will perform tasks, i.e., computer, clerk, etc.

(4) Hardware/Software Requirements

(5) Data Dictionary (in Appendix)

(a) Include structured English for all lowest-level processes.

(b) Sorted by entry type (i.e., processes, etc.).

(c) Multiple items per page.

(6) Screen, Form, and Report Designs (in Appendix)

(7) Cost/Benefit Analysis

(a) Use payback period model.

(b) Focus on out-of-pocket costs only.

(c) Complete Feasibility Matrix (example of Foundation Health shown on page 22).

(8) Schedule for Completing the Remainder of the Project in MIS 116B

(9) Appendices

(a) Corrected Current System Description.

(b) Corrected User Requirements Document

Note: All material contained in Appendices must be referenced in body of report. For example: "Data Dictionary," see Appendix G.

7. PROTOTYPE MODEL (PRT)   Return to top of page

A working Level-1 prototype of your system written in ACCESS. The model will include (a) Main Menu using Command buttons, (b) at least one file update menu, and (c) at least one report in print preview mode. All navigation, including ending the session, should be controlled through the Main Menu.

8. TEAM PROJECT PRESENTATION (TPP)    Return to top of page

Each team will make a short (15 to 20 minutes) project presentation during the last week of the semester. A slide printout (stapled) will be given to me prior to the presentation. The presentation will provide an overview of the project's scope, schedule, problems, and results. At least three (3) team members must actively participate in the presentation. All other nonactive team members must be available for questions. The presentation will be evaluated by the following criteria:

9. PEER EVALUATION   Return to top of page

In the MIS workplace, you will be asked to evaluate your subordinates, your peers, and even your managers. In this class you must complete two peer evaluation forms.

a. Peer Evaluation Form A

I will average the Percent Contribution over all forms submitted for each team member. This average will be used to allocate project points. For example, if an individual's team members feel (on the average) that he or she contributed 20% towards the team project (all deliverables), then that individual will receive 20% times the total team points awarded for the semester. If a team member fails to evaluate one or more of his/her peers, it will be assumed that the contribution was 100%.

b. Peer Evaluation Form B

PEER EVALUATION FORM A

Comments:

______________________________

Signature

PEER EVALUATION FORM B

Your constructive criticism enables your colleague to improve his/her skills for MIS 116B. Please check the statement that best describes the above name student. Don't put your name on this form.

Comments:

10. HINTS FOR A SUCCESSFUL PROJECT    Return to top of page

• Try to obtain a client that has a manual process that your team may automate. The proposed automated system should be designed for a PC rather than a mainframe.
  
• The sooner the "proposed" system's DFDs can be arrived at the better. Try not to delay too long on arriving at a proposed system lest you run out of time to complete the Data Dictionary specifications.
  
• Try not to spend an excess amount of time on the DFDs at the expense of not completing the Data Dictionary specifications.
  
• The sooner you can complete the information gathering phase of the analysis, the more time you will have to devote to the design phases of the project.
  
• The sooner a project schedule (Gantt Chart) can be put together the better.
  
• Realize that doing everything as a whole team is often slow and inefficient. Use whole-team meetings primarily for brainstorming and coordinating sessions. Break the team up into smaller units, and delegate specific tasks to each of these units. These smaller units of one or two members are more efficient in completing the project "milestones" than trying to do it as the whole team.
  
• One member should be designated as "quality control" person. She/he should scrutinize the Data Dictionary specifications for completeness. She/he should also check narrative pages using spell check and a grammar package (e.g., Grammartique).

(Note: These hints were provided by a former MIS 116A student.)