MIS 44048 Fall 2012 Steinberg
M&IS 44048 Software Integration Fall 2012
Dr. Geoffrey Steinberg / gsteinbe@kent.edu
Objective
This is a writing intensive course; as such you and your team will write documents and rewrite until the result is excellent. The primary objective of this course is to ensure that you are able to consistently produce high quality, clear, and to the point communication. All other objectivities and activities in this course are secondary to that objective.
You will perform the writing as a member of a project team. The team will be a consulting team and learn to produce high quality professional business results. Success will be largely determined by organization, engagement, determination, and perhaps most importantly, commitments to team work.
You will perform the writing as a member of a project team. The team will be a consulting team and learn to produce high quality professional business results. Success will be largely determined by organization, engagement, determination, and perhaps most importantly, commitments to team work.
Requirements
- Obtain a client with an information related need. The client and project must be approved by the instructor. Often the instructor has suggestions about prospective clients and projects. Check with the instructor.
- Work with the client to learn what their specific needs are and document what is learned in the form of a requirements specification.
- Once the client accepts the requirements specification and your proposed solution, translate the proposed solution into a technical design. The technical design will be like a blue print that specifically defines, in super detail, what the team is to build. The clarity of the technical design must be such that it could be given to a different team for implementation.
- After completion of the technical design the team will craft a system prototype. The specific technologies will likely include programming tools (PHP, VB, C-sharp, etc), web-site tools (HTML, XHTML, CSS, JavaScript, etc), and database tools (MySQL, Access, etc.). The selection and acquisition of the tools is the responsibility of the team. The team is also responsible for learning how to use the tools selected. Open source solutions are also acceptable as long as the client’s requirements are satisfied. It is quite likely that the selected solution will be an integration of open source and custom developed software.
- You will individually write several short papers during the course of the project. You will receive feedback from the instructor on each paper and be given the opportunity to rewrite. The final grades you receive for all individual papers will be averaged and becomes your "individual papers grade".
Textbook
None.
Course Grade
The course grade is composed on five parts that each weigh 20%:.
- Requirements Analysis
- Functional Design
- Technical Design
- Operating Prototype
- Individual Papers
You will be a member of a project team. All members receive the same grade for each of the first four components. Your grade for the last component is your's alone.
Note: A signature of approval from the client is required for items 1, 2, and 4.
Note: A signature of approval from the client is required for items 1, 2, and 4.
Due Dates
Due dates for each document or deliverable are a listed here. You should take advantage of the time to submit each document for review and critique before the due date enabling your team (and you) to review and correct. This is not a requirement but an opportunity to receive and react to feedback before the final submission of each document.
| Deliverable | Due |
| Requirements Analysis |
4th Class Meeting |
| Functional Design | 7th Class Meeting |
| Technical Design | 11th Class Meeting |
| Operating Prototype | Last Week of Semester |
| Individual Papers | As Announced |
Equity
This is a team project. It is up to the team to figure out how to work together. This means each person must know what exactly is expected of him/her and must also know what is expected of the other team members. To make this work each person must be trust worthy and get done what is expected, on line, and with quality results. It is not a good idea for one or two persons to “do all the work” even though “we feel that the others are not doing their part and we do not want our grade to suffer.” The point here is to learn to work effectively as a member of a team and not to take matters into your own hands.
Staff Meeting
Your team will meet with the instructor weekly. Students from other teams will not be present. At the meeting the following is expected:
- All members present.
- An agenda printed and presented at the meeting. See "Documents Section" below for details. All team members will have a copy of the agenda at each meeting.
- All participate.
- Present formally what your team has accomplished since last meeting. Compare to established goals and explain divergences if any (none are expected).
- Agree with instructor on goals for the next week.
If the instructor determines during the meeting that the team is not functioning properly (see above) the meeting may be terminated early at the instructor's discretion. Each meeting terminated early will result in each team member (present or not) having points deducted from the final course grade for the entire team.
Read This Important Note
Staff meeting attendance is mandatory. A casual attitude will result in points off (see above). If your team has one or more members not carrying their weight (including attendance AND/OR participation at staff meetings) your team should:
· Address the issue with the team member
· Address the issue with the instructor if it is not cleared up within the week
Until the issue is addressed your team will continue to lose points. If you attempt to address the issue and the team member does not change behavior you should discuss this with the instructor (during office hours). Until you clear up the problem points will continue to be deducted. If appropriate the instructor will "fire" the team member, however, if the instructor determines that the team is inappropriately ganging up on someone the team will suffer. It is best to clear team issues up without the instructor's intervention.
· Address the issue with the team member
· Address the issue with the instructor if it is not cleared up within the week
Until the issue is addressed your team will continue to lose points. If you attempt to address the issue and the team member does not change behavior you should discuss this with the instructor (during office hours). Until you clear up the problem points will continue to be deducted. If appropriate the instructor will "fire" the team member, however, if the instructor determines that the team is inappropriately ganging up on someone the team will suffer. It is best to clear team issues up without the instructor's intervention.
Documents
Here are some guidelines that will help you prepare documents required for this course. All documents will be printed. None are to be submitted electronically.
Weekly Agenda
Your team is expected to prepare an agenda for each meeting. Bring printed copies for all members and the instructor. The agenda will have these major parts with as much detail as needed for each part:
- Discussion items for the current meeting
- Accomplishments since last meeting
- Goals for next meeting
- Revised project schedule for remainder of project.
Requirements Analysis
This document reports all that you know about the client and the client's needs and issues. This document does not included anything about the future; meaning do not discuss a proposed system or what you will do for the client - that comes later. As with all documents your team prepares there is no standard formal format but do include these sections in the requirements analysis at a minimum:
- Client description.
- Description (brief) of industry the client operates in.
- Discussion of client's problem(s) including the business impact the problems cause.
- List (with description) of what the client wants. This is more than identification of the problem. The client has ideas of where they want to go with your help. What are those ideas?
- Constraints imposed by client including but not limited to: time, cost, technical.
- Begin with an executive summary
- Page numbering
- Table of contents
Functional Design
The functional design is a description of “what” the client will receive when a system is built and delivered. The technical design (the following document prepared by the consultant) is a description of “how” the system will be built. The client is interested in the functional design and not in the technical design.
Fundamentally a functional design is the tool the consultant uses to present a solution proposal to a client. When the client reads/views the functional design it must become clear to the client what exactly the consultant is proposing as a solution to the client’s requirements. If that does not happen the functional design is not adequate.
The functional design will reflect all requirements that are documented in the Requirements Analysis (that document is prepared first). The functional design should reference specific points in the Requirements Analysis. The functional design may also describe ideas of the consultant that extend beyond what the client requires (this is known as “value added”).
The functional design is prepared so that the client can understand it. Textual descriptions accompany screen layouts. A flow chart could be used to show the connection between different screens; in effect a “site layout”. Any special rules (such as access level permissions, backup procedures, data import or export, etc.) would be described in words. For example: the functional design would not simply say “the user will sign-in” but it must explain what the user types in order to sign-in and what validations of user input occur and that descriptive information must be linked to a screen shot of what the sign-in box looks like.
The functional design will give the client an understanding of what they will get if the proposed system is built. If the client cannot get the complete “picture” of what will be delivered the functional design is not complete. Consultants often “know” what they expect to deliver and run the risk of assuming that the client “knows” what they will receive. This is a setup for disaster. If something is not in the functional design it is not part of the design. Period! If something is not clearly presented it is not presented at all. Period! If something is not linked to the rest of the design it is not in the design. Period! The functional design is not a document to be casual about.
Stand back and ask yourself what would you need (if you were a client) to “get the picture” a consultant offers you? Make no assumptions here. If any aspect of the proposed system is not sufficiently presented in the functional design is not complete.
There is no formal standard format or outline for a functional design. As in any document begin with an “Executive Summary” and follow with a Table of Contents (TOC). What is found in the TOC is up to you. If you are unsure whether your design is complete ask someone apart from your project team to evaluate it for you. Ask the client to examine it for you while it is being prepared. If they “get it” you are on the right track. Otherwise fix it.
There are many purposes for functional design. One of the primary purposes on team projects is to achieve some form of team consensus on what the proposed system is to achieve before making the more time-consuming effort of writing and debugging code. Typically, such consensus is reached after several reviews by the stakeholders (client) on the project proposal.
A functional design does not define the inner workings of the proposed system (that is the”how” described in the technical design); it does not include the design of how the system function will be implemented (that is the”how” described in the technical design). Instead, it focuses on what the stakeholders using the system will experience when interacting with it. A typical functional design might state the following:
Fundamentally a functional design is the tool the consultant uses to present a solution proposal to a client. When the client reads/views the functional design it must become clear to the client what exactly the consultant is proposing as a solution to the client’s requirements. If that does not happen the functional design is not adequate.
The functional design will reflect all requirements that are documented in the Requirements Analysis (that document is prepared first). The functional design should reference specific points in the Requirements Analysis. The functional design may also describe ideas of the consultant that extend beyond what the client requires (this is known as “value added”).
The functional design is prepared so that the client can understand it. Textual descriptions accompany screen layouts. A flow chart could be used to show the connection between different screens; in effect a “site layout”. Any special rules (such as access level permissions, backup procedures, data import or export, etc.) would be described in words. For example: the functional design would not simply say “the user will sign-in” but it must explain what the user types in order to sign-in and what validations of user input occur and that descriptive information must be linked to a screen shot of what the sign-in box looks like.
The functional design will give the client an understanding of what they will get if the proposed system is built. If the client cannot get the complete “picture” of what will be delivered the functional design is not complete. Consultants often “know” what they expect to deliver and run the risk of assuming that the client “knows” what they will receive. This is a setup for disaster. If something is not in the functional design it is not part of the design. Period! If something is not clearly presented it is not presented at all. Period! If something is not linked to the rest of the design it is not in the design. Period! The functional design is not a document to be casual about.
Stand back and ask yourself what would you need (if you were a client) to “get the picture” a consultant offers you? Make no assumptions here. If any aspect of the proposed system is not sufficiently presented in the functional design is not complete.
There is no formal standard format or outline for a functional design. As in any document begin with an “Executive Summary” and follow with a Table of Contents (TOC). What is found in the TOC is up to you. If you are unsure whether your design is complete ask someone apart from your project team to evaluate it for you. Ask the client to examine it for you while it is being prepared. If they “get it” you are on the right track. Otherwise fix it.
There are many purposes for functional design. One of the primary purposes on team projects is to achieve some form of team consensus on what the proposed system is to achieve before making the more time-consuming effort of writing and debugging code. Typically, such consensus is reached after several reviews by the stakeholders (client) on the project proposal.
A functional design does not define the inner workings of the proposed system (that is the”how” described in the technical design); it does not include the design of how the system function will be implemented (that is the”how” described in the technical design). Instead, it focuses on what the stakeholders using the system will experience when interacting with it. A typical functional design might state the following:
| “When the user clicks the OK button, the dialog is closed and the focus is returned to the main window as it was before this dialog was displayed.” |
That description must accompany a screen shot of the dialog box and an indication in a flow chart (or other chart) that shows where that action falls in the overall flow of the system.
Such a requirement describes an interaction between an external agent (the user) and the software system. When the user provides input to the system by clicking the OK button, the program responds (or should respond) by closing the dialog window containing the OK button.
Final word: The functional design will contain many "pictures" or "screen shots". The client must be able to visualize what they are to receive before they can approve your proposal.
Technical Design
Consider this the "blueprint" that will guide developers as the prototype is constructed. Just as a contractor follows a blueprint while constructing a building developers follow a technical design while constructing an information system. What goes into a technical design? In a word: "detail", and lots of it.
This document provides construction information that describes how to build the system proposed in the functional design. Every page, user interface element, data source, and function described in the functional design is to be described here; and that is not a complete list. Every detail needed to implement the proposed system must be included in this document. Identification of required software is expected and so are instructions for software installation if needed. Sources of data the system will process are to be identified and so are procedures for importing data and converting it to the system's format. The systems data storage definition in the form of a data dictionary is to be included too.
A "quick start" is a good idea. Since the technical design document is likely to be quite lengthy it is smart to provide the reader (the developer) a quick start at the beginning of the document. Tell the reader how to get set up and get started. Give the reader the main steps to follow and from within the Quick Start reference the sections of the technical design where the supporting detail is found.
The technical design must be adequate to provide a remote development team with all it needs to build the project. Suppose your design were outsourced to a team you could not have contact with. Give them everything they would need to build the project successfully.
This document should also include sections on trouble shooting and future expansion. The former should be a guide for those who will maintain the system in the future; guidance for where or how to search for the causes of problems. The latter should provide guidance for how and where future developers might attach extended functionality to the system.
This document provides construction information that describes how to build the system proposed in the functional design. Every page, user interface element, data source, and function described in the functional design is to be described here; and that is not a complete list. Every detail needed to implement the proposed system must be included in this document. Identification of required software is expected and so are instructions for software installation if needed. Sources of data the system will process are to be identified and so are procedures for importing data and converting it to the system's format. The systems data storage definition in the form of a data dictionary is to be included too.
A "quick start" is a good idea. Since the technical design document is likely to be quite lengthy it is smart to provide the reader (the developer) a quick start at the beginning of the document. Tell the reader how to get set up and get started. Give the reader the main steps to follow and from within the Quick Start reference the sections of the technical design where the supporting detail is found.
The technical design must be adequate to provide a remote development team with all it needs to build the project. Suppose your design were outsourced to a team you could not have contact with. Give them everything they would need to build the project successfully.
This document should also include sections on trouble shooting and future expansion. The former should be a guide for those who will maintain the system in the future; guidance for where or how to search for the causes of problems. The latter should provide guidance for how and where future developers might attach extended functionality to the system.
Prototype
Although not a document here are the requirements: Prepare a working system that demonstrates the functionality of the prosed system. Provide the instructor with the information needed to access the finished prototype; this likely includes URL, id, and password. Also provide usage instructions, however, a good system requires no external usage documentation; the user interface should give the user all instruction needed.
The instructor will not review programming code so it is not required that it be submitted.
The instructor will not review programming code so it is not required that it be submitted.
Individual Papers
The topics for the individual papers will be announced; the first topic, however, is described below. The format for each is as follows:
- Maximum 1 page
- Font: Times New Roman
- Font Size: 12
- Margins: 1" (all sides)
- Your name on the top row
Topic for paper #1:
- Why I am an Information Systems major/minor.
- How the CIS curriculum prepared me for Software Integration. Be specific.
- What I expect from this course.
Paper #1 is due the second time the class meets.
