BA372 Syllabus

Spring 2006

Individual Initial AP Design

• Part 1:  Create a narrative (1 - 4 pages) describing the functions of the system. The system will need to record vendors, purchase orders, invoices, projects, and checks as per our class discussion. Your narrative should say who is involved, what they do, what triggering events move the process along, and what each step accomplishes. For example: When a PO is requested for a new payee, the payables clerk records the name, address, and phone number of the vendor but can not issue the PO until a manager approves the new account.
• Part 2:  Decompose the narrative into a set of events. For each event, list:
  • the internal agent responsible,
  • the triggering event,
  • and the individual activities which make up the event.
  Chart those events in a single overview UML activity diagram.

• Please review the instructions which request "The system will need to record vendors, purchase orders, invoices, projects, and checks as per our class discussion." Don't forget to include a way of "charging" invoices to an account or project.
• Make up a company and write as if you are describing the AP process in that particular company.
• Make sure the process you describe is for accounts payable.
• Event tables should include names for each event. Event names should always begin with a verb. No "ings" or "tions".
• All events from the table should appear in the UML diagram with exactly the same name. Additional events can be added to the diagrams.
• Diagrams should include events, documents, and an individual symbol for each master or transaction table used by the system.
• It is good to include some level of detail in the narrative such as a list of attributes recorded for an entity (e.g. vendor) or transaction (e.g. invoice).
• Think like a business person who needs to communicate with managers, clerks, and programmers. Don't think like a programmer and jump straight to the data design. In this exercise we begin by analyzing the process and then let our understanding of the process guide our design.
• Review the example we did in class with the narrative, the event table, and the UML diagrams. You systems will likely be more extensive than the class exercise but the format and methodology for narrative, table, and diagram should be similar.
• As in the example in the slides, your narrative should read like a story describing how the process is done. Format your narrative in this way:
  • Company Description: Briefly describe the company's activities. (1-2 paragraphs)
  • High-level Overview: The AP system at our company controls and supports the process of....
  • Include several paragraphs (probably with headings) that describe the process. You can do it a number of ways: By person, in time series, or some other way. But make sure it is organized in some sensible fashion.

Group Process Description and Data Design

• Choose from or reconcile the individual submissions from your group members’ Individual Initial AP Designs to create a group narrative (1 - 4 pages) and an overview UML activity diagram for an AP system. For each event in the overview diagram, list
  • the internal agent responsible,
  • the triggering event, and
  • the individual activities which make up the event.
• Create 2 - 4 detailed UML activity diagrams as needed.
• Construct a data design (tables, attributes, and primary keys) for your system. Include a data-oriented class diagram as well as a table listing.
• Be sure your documents are consistent.

• Your project needs to include a way of allocating expenditures to projects, accounts, or categories. This is a vital part of every AP system. This should show up in the narrative, the activities listed for events, and in the data design.
• Check over the requirements, look at the slides from class, and ask me questions. Some projects did not include the required components. Check over the details. Did you name all events with verbs? (a verb with a "ing" or "tion" counts as a noun). Don't forget to include the data types of the attributes in your tables.
• Don't worry about repeating things in different models. The narrative should include almost everything shown in the event table. The exact events listed in the event table should show up in the UML diagrams. Each master and transaction table shown on the UML diagram should appear in the data design. Some of you seem to have tried to describe the decisions being made in the narrative and the steps in the process in the tables and charts. That makes some sense because I asked you to think about the business instead of thinking like a programmer. But,the idea is to clearly model the system and steps so the users, managers, and developers can understand and verify the information.
• Overview diagrams should include annotations that refer the reader to the detail diagrams as on the slides presented in class.
• In the UML activity diagrams, when a computer is the agent for an event there should almost always be a solid line from a previous event which leads into the computer event. Often, but not always, events listed in the computer column would be better if the were shown in the column of the agent intiating the event.
• Junction tables usually include fields in addition to the foreign keys. For example a quantity is usually needed to link a product to a particular invoice (e.g., 3 Size A wigets on invoice #25).
• Make sure you decide if multiple invoices can be paid on a single check. If not, you probably need to explain why. Most companies don't want to send 5 checks to the same vendor at the same time. Also, be sure you account for checks in you project.
• Review my comments on your submission. I may not have understood what you were trying to do. If so, explain it either in the project or talk to me. These projects are complex and subjective. There is not a single correct answer.

Group Internal Controls

• Review your design to identify important controls needed in your system.
  • Workflow controls
  • Input controls
  • General controls
  • Logging and access controls
• Modify the data structures as needed to support a robust control environment for your application. At a minimum create:
  • a log structure for tracking changes,
  • a security structure to support authorization,
  • annotations describing the update rules for individual attributes, and
  • pseudo code for at least two transactions which might be used in your system.
  • Include your updated diagram and table listing.
• Create a set of test data to populate your structures. Include:
  • at least 5 rows for each table;
  • exemplary documents which show data from your test set: a PO, a Check, a vendor status report, a project activity listing, an edit report for verifying the system integrity of at least one junction table;
  • and, at least 10 "error entries" involving at least 5 processes or tables. These should include examples of realistic errors which ought to be addressed by the system controls. Presumably, these errors would all be used in the testing process for your application.

BEGIN TRANSACTION
     Reduce Account A by Amt
     Increase Account B by Amt
COMMIT

Group Architecture ** NO LONGER REQUIRED AS OF 5/22/2006 **

• Include more than one layer and define the functionality of each layer.
• Allow for security and logging facilities.
• You will make numerous assumptions along the way. Take a shot at justifying your decisions. The good news is that you can make up whatever environment you want to justify your choices!

Group Final Write-up

• Executive summary: 1 page max. An executive summary includes facts! A reader should get the main ideas without reading anything else.
• Table of contents
• Introduction: The introduction provides background, describes the motivation for the work, and introduces what is to come.
• Previous project parts:
  • Process description (narrative and UML activity diagram)
  • Data Design (Diagram and tables)
  • Internal Controls Write-up
  • Architecture ** NO LONGER REQUIRED AS OF 5/22/2006 **
• Governance (1-4 pages)
  • Describe the appropriate governance environment
    • How do we know if our system is working?
    • What delivery and deployment strategies should be used?
    • What general IT controls are needed?
• Conclusions (1-3 pages)
  • What did you learn while doing this project?
  • What general principles are demonstrated in your design?
  • How does the work you did tie into the course material?

• A business document as a whole, and each part separately, should be structured to help the reader gain the most in the least amount of time.
• Headings and paragraph topic sentences should accurately guide the reader.
• Tables and figures
  • should be presented in the body of the text not in an appendix,
  • should be referenced in the text, and
  • should have a descriptive caption as well as a name. Many readers only look at the pictures and captions. Make sure they get the main ideas.
• Include a title page. Every business project write up should tell who created it and who the work was done for.
• HAVE SOMEONE ELSE PROOF READ IT!
• Poor organization, typos, bad grammar, and unclear writing characterize unprofessional work. Unprofessional work cannot receive better than a C.
• FOLLOW THE DIRECTIONS. Business organizations like innovation but they do not tolerate work that does not cooperate with organizational protocol.

Late Deliverables

Group Member Evaluations:

• 1 - small or none
• 2 - less than expected
• 3 - acceptable contribution
• 4 - above average
• 5 - exceptional