BA371 — Class Project
Preamble: discretion is assumed
Although most if not all information associated with City of Portland's Bureau of Human Resources (BHR) is public, we ask that you will exercise care and
discretion when storing, presenting and sharing project information.
The City of Portland maintains a sizeable set of Administrative Rules which govern employee rights, obligations and procedures.
Annually, city employees —as well as contractors and union representatives— are invited to comment on and propose changes to these rules.
The invitation to submit proposals (RFP) for changes typically occurs early in the (calendar) year by means of an email sent to all who are eligible to suggest changes.
The city receives about 100 proposals for change per year.
Following the RFP, the change proposals are first reviewed by BHR staff. Proposals which 'pass' this review may be amended after which they are moved on for
further review by the BHR Director and the City Attorney. Proposals which 'pass' this second review may again be amended after which they are made public
and eligible employees are invited to comment on the newly proposed rules and regulations (RFC).
Once comments have been processed by the BHR and Chief Administrator's Office (CAO), the change proposals which are still 'alive'
may be amended after which they are either passed on to City Council
for a vote or —if a vote is not required— are posted as the new rules and regulations.
Although this process is currently effective, the flow of information and activities is manually facilitated with emails and document files stored on the city's file system. Similarly,
the process itself is entirely manually controlled and executed by BHR staff.
BHR has asked us to assess its current process, to suggest improvements, and to design an information architecture and to prototype some applications which
can support this improved process and increase its efficiency and possibly its effectiveness.
We will address this challenge in two phases; one executed in this course (BA371) and one addressed in our follow-up course (BA372).
In this course we will analyze and model the existing process and design a relational database structure for it. We will do this under the assumption
that the process structure and flow will not change. In BA372 we will address the process structure itself, propose improvements and research and prototype IS solutions.
In BA371, teams of five people conduct the following activities and report three times (two reports and one class demonstration) on
- Delivery 1: Introduction, Impact study plan, Process models. This contains:
- Chapter 1: Introduction of the case study. This is a short write-up that introduces the case study. It contains a description of the
problem/opportunity the sponsor has asked us to address.
- Chapter 2: Write-up and modeling of the current business processes. This includes:
- Delivery 2: Database design, Architecture design, User interface design. This includes:
- Clean-up and corrections made to Chapters 1 and 2.
- Chapter 3: Design, documentation and SQL script implementation of a relational data model in third normal form to hold the data. This includes:
- Specification of all database tables and their fields, data types and nullability, including an explanation of the choices you made.
- Specification of all primary and all foreign keys.
- SQL creation and drop scripts that can be run against a blank Ms Access database using the SQL interpreter for Access
that you programmed in Assignment 1.
- An Ms Access (entity) relationship diagram (ERD) resulting from running the SQL creation script against it.
- Delivery 3: In-class demonstration of two (working) programs written in C#:
- Program 1: a Windows Forms user interface through which Administrative Rules proposals can be submitted. These will be
programatically stored the database designed as part of Delivery 2.
- Program 2: a Windows Forms program through which the data inserted using Program 1 can be queried and displayed.
- Your report must be professionally structured and formatted. This implies such things as
proper page numbering, title page has no number, Table of Content (ToC) pages have either no numbers or have roman numerals as numbers,
chapters start on a right-hand odd-numbered page, etc.
- Your report must follow some common rules for technical writing:
- Start chapters (except Chapter 1) with a short introduction, informing your readers what to expect in the chapter.
- Respect your readers' limited time available to read your report. Do not give your readers a puzzle to solve.
Always(!!) ask if your writing/formatting /presentation of information is to the advantage of the reader.
- Break your text into logical blocks and sections. Delineate major sections with section headers. Delineate minor sections with paragraph separators.
- Help your readers with reading sentences containing proper names; e.g., sentences containing the names of database tables and table columns,
by printing those names in italics. For example:
- The primary key of table table is foo.
is much easier to read than
- The primary key of table table is foo.
- Please avoid clumsy writing such as when mixing singular and plural in a sentence: e.g.,
"When the user clicks the button, their request is emailed." Singular/plural mixing is one of the most common errors in today's writing.
In almost all instances it can be entirely avoided by writing in plural. Writing in plural also avoids clumsy gender-specific
writing. (much nicer to write "When users click the button, their request is emailed." than
"When the user clicks the button his/her request is emailed." (Of course, both singular/plural and gender-specificity
can be avoided altogether by rephrasing: "Clicking the button emails the request.")
- Take a look at the MIT Basic Technical Writing slides.
- As a team, do your very best to catch obvious errors (Peer review!!!). When you give your readers
a text with bad errors such as bad spelling and/or grammar errors, your readers will likely interpret this as a lack of care and respect, you
being incompetent, or both.
- A note for foreign-language speakers. As a foreign-language speaker himself, your instructor very much appreciates the difficulty you may
have writing in English. However, you are part of an English-speaking and English-writing community and as such it is your responsibility to
turn in properly written materials, both to your English-speaking team members and to your instructor. Fortunately, OSU provides writing assistance
through its writing center. You are !!!STRONGLY!!! advised to run your materials by the writing
center BEFORE handing them to your fellow team members or to your instructor.
- A note to native English speakers. The previous note to foreign-language speakers does not imply that you are without sin. Most of you are not yet good
writers and there is plenty of room for improvement. So for you too, the writing center
and your colleagues can be of great help.
- A sample outline:
- Title page:
- Project title.
- Author names (!!!in (last name) alphabetical order!!!).
- Course and instructor.
- Table of Content (TOC)
- Chapter 1: Project Introduction.
- Chapter 2: Process Modeling
- Chapter 3: Database Design
- References (if applicable)
Suggested format (APA):
Smith, T.J. (2001) An Overview of Systems Design. Hammersmith Publ. Ottawa, Ontario.
Smith, T.J., Jones, P. (2001) System Design Methods. Journal of System Design, 12, 551-561.
Smith, T.J. (2001) Systems Design; New Developments. Available: http://www.wherever.com/smith/hereitis.pdf.
- Appendix 1: Revision Log
- Appendix 2: SQL Script for Schema Generation and Deletion
- Document !!!checklist/quality control!!!:
- Check the simple stuff. Pages missing? Figures, tables or whole sections missing?
- Pages numbered? (title page has no number. First page with content has page number 1).
- Table of Contents (TOC) matches the page numbers in the report?
- Chapters start on a right-hand, odd-numbered page?
- Chapters (except Chapter 1) start with a (short) intro informing readers what they will find in the chapter?
- Figures and tables integrated in the text? Do not add
them as an appendix in the back of the report. (The only exception are the SQL script and source codes).
- Properly numbered and captioned ALL(!!) figures and tables (use Microsoft
Word support for this)?
- Used cross-references to refer to figures and tables. DO NOT HAND-TYPE THE FIGURE AND TABLE REFERENCES.
- Spell checked? (both automatically and manually?).
- Checked for plural/singular mixing? Example: "When a user clicks the button they see a list." Fix these!! (write in plural).
- Grammar checked?
- Revision log?
- Peer reviewed? Before submitting your report, carefully
(!!) read what you and your colleagues wrote. Make it English, clean up ambiguities,
break up long and awkward sentences into shorter, more elegant ones. In
other words: show that you care.