MIS674 - DePaul University



MIS674

System Analysis and Design

Group Project and Individual HW Assignment

Individual HW Assignments

Create an Activity diagram, a Detailed Use Case Diagram, and a Class diagram for the gym business process described below. Refer to the class schedule for delivery dates. This is Exercise O from the back of chapter 4, but I have rewritten the business process to make it more transparent. This is equivalent to undertaking additional rounds of user interviews to improve upon the business process narrative. Diagrams must be done in Visio, consistent with the rules outlined in the syllabus. Feel free to contact me if you have questions regarding ambiguity. Please note: we will assume that all of the business activities could be fully or partially automated. This is relevant to the Use Case Diagram.

Gym Business Process

When members join the gym, they pay a membership fee for a certain length of time and entitles the member to attend any gym. A regular membership is for one year, but some are as short as a couple of months. Throughout the year, the gym offers a variety of discounts on regular membership prices. It is common for members to pay different membership fees for the same length of time. Only the manager has the authority to override a member contract pricing. Therefore, membership fees may reflect a member discount. There are two types of membership discounts, but a member can only receive one type of discount from the clerk. The two types of discounts are a 10% regular member discount, and heavy user discount of 15%. A membership fee depends on the regular membership price with no discount, or the regular member price minus a 10% member discount, or the regular member price minus a heavy user discount. Members can pay their bills (or invoices) with credit/debit cards and cash which updates their account. Some members get angry when asked to renew at a much higher membership rate so the club wants to track member contract pricing. The manager can override any contract pricing structure whenever he chooses with special pricing. This is considered a manager’s discount, bringing the number of member discounts to three. Therefore, there are four types of membership, i.e., three discounted and one regular membership with no discount. The system keeps track of these new manager pricing discounts so that renewals can be processed accurately. The industry has a high membership turnover rate, as 50% do not renew. This is a problem because gyms spend lot of money on advertising to attract new members. The manager wants the system to track each time a member attends the gym. The system identifies heavy users and generate a heavy user report so the manager can ask them to renew their memberships early, offering them a reduced rate (i.e., heavy user discount of 15%) for early renewal. To help with renewals, the gym mails out reminder letters to members a month before membership expires, reminding them to renew. Likewise the system identifies members who have not visited the gym in more than a month (infrequent members), so the manager can call them and interest them in the gym. If the infrequent member is interested, he/she will be reinstated.

Business Rules:

A contract is entitled to only one type discount and that type may be applied to several contracts. If a manager overrides a previous discount, this becomes the final discount (ie, manager’s discount).

A member is entitled to attend several gyms, and a gym has several members.

A member payment is used to update an account, and an account is updated by one or more payments. However, a member makes one or more payments.

Members are sent receipts when they pay their bill.

Employees track many advertising, and advertising may be tracked by many employees.

An employee can track several attendance and an attendance is tracked by only one employee.

Some members receive one or many ph calls and a ph call is associated with one member.

A member has several contracts over his/her membership life. But a contract is associated with one member.

A member may receive zero one or many reminder letters and a letter is sent to each employee.

Group Project

Project Overview and Deliverables

Since the best way to learn the process of system analysis is to actually perform a system analysis, every student will be involved in a project over the course of the quarter. Each group will work on this own project, to be selected by the group with my approval. There is a final project deadline (see syllabus). Late submissions get zero grade. No exceptions! I strongly recommend that each student be intimately involved with all aspects of the project.

Project consists of 8 parts:

1. Project Selection

2. Narrative

3. Feasibility Study

4. Functional Requirements

5. Activity Diag

6. Use Case Diag

7. Class Diag

8. Windows Navigation Diagram (i.e. wireframe)

9. GUI’s

Group Information

Since you will be working in groups much of your professional career, the project will be assigned as group projects. The groups will be determined by the instructor. Keep in mind that as you develop the analysis, there will be a large number of assumptions that will have to be made. In a "real" system analysis and design, the analysts will have the business users available to provide detailed requirements and assist in creating the business justification. Since you will be developing the project essentially in a vacuum, your group will have to do research to determine the generic requirements for the system to be developed. This is another reason to pick a project that aligns with your career goals so you can gain more value from your research. It is up to each group to determine how work is allocated. It is highly recommended that each student be involved with all aspects of the project. Students can use the project for internships and job interviews.

Oral Presentation

One oral presentation from each group will be required at the end of the quarter. You are presenting to senior management in your own organization about the system you are developing. Therefore your presentation should focus on the topics that senior management would be interested in. As you put together your presentation, think about each slide that you create and ask, what the purpose of showing this slide to stakeholders is. Keep in mind that part of the purpose of the presentation is to ensure that senior management is convinced that your group knows what they are doing and the money on the project is well spent. You should be able to discuss your technical work in non-technical terms.

The oral presentation should be roughly twenty minutes per group. While a "short" presentation sounds easier than a longer presentation, the time limit means that your group will need to concentrate on the crucial information that must be presented to management in the time provided. The short time also means that your group must be completely prepared for the presentation because there is no "spare" time to waste fumbling around. One of the aspects on which you will be graded is how well I feel you identify what is crucial and how well the information is presented. All members should participate in the presentation and must be present. For grading purposes, please turn in a printed copy of your presentation before you present.

In general, the presentation should focus on the following items:

Discuss the organizational unit where the problem resides and how it relates to the rest of the company. Describe the problem and the motivation for the solution? Discuss the scope of the problem and how it impacts other stake holders in or out of the company. Discus the cost, benefits, and risk of undertaking the project. Discuss some of the technical solutions employed to address the problem, such as the role of activity, use case, class diagrams, WND and GUI’s. Don’t takes us step by step through the diagrams but speak in general terms how they address the problem. For example, the As-Is and To-Be could be used to explain the before and after business process and how they differ. Discuss any challenges in implementing the solution and assess the success or failure of the project. Discuss how was the success of the project was determined. Discuss lessons learned in undertaking the project and recommendations for the future. Discuss anything else you deem important!

Project Selection

Describe the type of project, how it fits into the larger organization, why it was chosen, the project scope, the problem, how the problem may affect other parts of the organization, team members, and the team project lead, and the project’s ability to be completed in 10 weeks. This is more or less a one page document.

.

Narrative

The narrative is unambiguous description of the business process related of the project. It describes in detail how the business process works. It should be detailed enough so that anyone who knows how to model business process should be able to create one that is clear and concise. When such a narrative is presented to team members unfamiliar with the project, they should be able to create Activity, Use case, and Class diagrams from the narrative. Therefore a business process narrative and an Activity diagram are mirror images of each other. One is in words the other in the form of a diagram. They both tell the story of how the process works.

Narratives have a beginning and an end. They are logical, unambiguous, step-by-step description of the business process. They describe each and every activity of the business process along with the inputs and outputs of each activity. They are business process which represent a continuous logically flow of the business activities. They should also explain the rationale behind why certain activities are performed and when they may be performed. They are essays made up of one or more paragraphs. They are not a random collection of sentences, or a bulleted list of items. The length of a narrative depends on the size and the complexity of the business process. A very small process could be described in a single paragraph as indicated in the practice exercises at the back of the chapter on functional modeling. Real life projects are often much more involved, lengthy, and complicated requiring several paragraphs, headings and/or subheadings.

• A well written narrative should be clearly understood by a lay person. It should be easy and straight forward for a skilled analyst to create an activity diagram from the narrative. If a skilled analyst struggles to create the activity diagram from the narrative, this is evidence that the narrative is poorly explained and described.

• The level of detail is determined by the audience (users and project team).It should be detailed enough so that users and team members clearly understand the business process.

• The undergraduate students are required to read three chapters on business processes (refer to link on business processes (PDF) located on the undergraduate section of the Systems Analysis and Design page). There you will find three chapters that describe core business processes (revenue collection, chap 11; procurement (i.e., purchase-to-pay) chap 12, and chap 10). These are good examples of business process narratives that are more involved than the exercises in the back of the text book chapter. Start by looking at the billing process narrative in chapter 11, then proceed to chap 12 .Chap 12 is the most complicated; to address complexity, headings and subheadings are used. This style is best reflected in Chap 12, pg 438-439. The chapters include more than narratives; they also include data flow diagrams, sample form, and figures.

• You have lots of examples to guide you. Those from the back of the text book chapter on functional modeling and the three PDF chapters.

Some comments:

The narrative is often from the user or customer perspective. If the narrative is poorly written, the team will struggle tremendously to create the activity diagram. A clear process description lends itself to an easy transition to the activity diagram. You may start with the draft narrative in bullet format then massage it into an essay or story that describes the business process. Use a top down approach to gather more detail as you describe the process.

All forms (input) and reports (output) should list exactly what is on the document, in other words, everything!

o Try to use the following guidelines when writing the narrative:

o Keep the sentences simple, try to use "subject-verb-object" wherever possible.

o It should be clear who or what initiates an activity.

o Write the narrative from the perspective of an independent observer.

o As you write the narrative, make sure it makes sense to the reader.

Feasibility Study

Follow the template and recommendations in the book for creating the study. Another example is posted on the class website. Make sure to provide references for sources of data used in the project. Example, if you use average salary figures for systems analysts, you need to provide the source where the figures came from. If you choose an annual interest rate in your calculation, justify its use.

Requirements Determination (Functional and Non-functional requirements)

Develop requirements document for the project. Requirements are one of two types Functional and Non-Functional, listed under their appropriate sections.

Business and Functional Modeling

Activity Diagrams

Develop an activity diagram that covers the activities of the system. It is effectively a logical flow of the business activities, inputs and outputs. It provides an unambiguous logical flow of the business process. It focusses on the business activities.

Use Case Diagrams

Develop two use case diagrams, an Overview and Detailed. Each group will create a detailed use case diagram that represents the activities described in the activity diagram (assume all activities will be automated, unless it is not possible or highly unlikely). Make sure to include all use cases in the use case diagram.

Class Diagrams

Develop a class diagram for the project. This represents the database structure for the new system. Make sure the various parts of each class is well represented. Example of violations are missing attributes, methods, etc. Make sure that every class is connected to at least one other class, if not, it’s a violation of the rules. Make sure to include multiplicity values because they are important. For example, assume two organizations have the same class diagram, they may not have the same multiplicity values. At one office, a doctor may have a maximum of 10 patients, at the other, 20 patients. This exercise is related to

The chapter on Data Management Layer Design. Please show your primary keys for each class and resolve any many to many relationship.

WND and GUI (i.e, wireframe)

Develop a WND for the project and the GUI’s shown on the diagram. This could be a time consuming effort, so if time becomes a problem, focus on the quality of the GUI’s not the quantity. It is the quality that is most important to me. Twenty poorly designed GUI’s is not worth as much as ten well designed GUI’s. Keep in mind that a team with twenty quality GUI’s will earn a better grade than a team with ten quality GUI’s, all other things being equal. The connection between the WND and the GUI’s should be very clear to the reader. He should be able to move very easily between WND and GUI’s. For example, the first item on the WND should correspond to the first GUI the reader sees. Moving down the WND page from left to right should dictate the layout of the corresponding GUI’s. The name of each item on the WND should be exactly identical to the name of the corresponding GUI. When these rules are not followed, the mapping between WND and GUI’s becomes very confusing to the reader, and results in the loss of project points.

You may choose to use any technology including Visio, PowerPoint, or any graphic related application to create your GUI’s. They just can’t be created by hand.

NOTE: We have one day on the class schedule allocated to addressing any project related issue. By this time, I assume that each team would have the project completed or near completion, and putting the final touches on it. This is the last time to finalize changes before submission. I strongly suggest that you bring up issues as we go along and not wait until last minute. If you have project related questions, raise them in class for the benefit of everyone. If you run in a potential problem, seek my advice and input very early!!! Late projects are not accepted.

Project Grading

Project Points

• Chapter 2 -Narrative …………………………………………………… 7

• Chapter 3 – Feasibility …………………………… 7

• Chapter 5 – Function/non-functional requirements …………………… 7

• Chapter 6 -Activity Diagrams…………………………………………… 8

• Chapter 6 -Use Case Diagram……………………………………………… 8

• Chapter 7 -Class Diagram………………………………………………………… 8

• Chapters 10 – WND and GUI’s ……………………………………. 16

• Oral Presentation…………………………………………………………… 5

• Total …………………………………………………………………………… 66

Individual Assignments

• Activity Diag…………………………………………………………………….… 8

• Use Case Diag …………………………………………………………………… 8

• Class Diag ……………………………………………………………………… 8

• Total………………………………………………………………………… 24

• Total…………………………………………………………………………… 90*

*Remember that the grade you receive will be the grade your group receives times the average peer evaluation score you receive from your group members.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download