Faculty Contact Information:
The term begins November 3, 2003 and ends March 7, 2004. The winter break is from December 22, 2003 until January 18, 2004.
INSTRUCTOR: Edmund I. Deaton
e-mail: edeaton@faculty.ed.umuc.edu
phone: 0434 662 079 (h), 3387 389 270 (c).
|
|
Consultation:
|
The primary means of consultation will be our use of Web Tycho. Dr. Deaton is also available by e-mail and telephone.
|
|
Required Texts and Readings:
|
There is no text for this course.
|
|
Supplementary Readings:
The standard for papers in the graduate program is the APA style. All participants in this course and all graduate INSS, MGMT, PUAD, and ECON courses should have a copy of the style guide:
American Psychological Association. (2001). Publication Manual of the American Psychological Association, 5th Edition. Washington DC: Author.
For this course, a copy of the APA Crib Sheet will suffice. It is available from
URL: www.wooster.edu/psychology/apa-crib.html
All graduate students should be prepared to utilize the UMUC online library at http://www.umuc.edu/library/. The library contains a large number of full text academic journals that are free of charge and immediately available. The library homepage also contains a number of links related to improving students' research and writing skills.
|
|
Recommended Journals:
|
Publications of the various professional societies (such as ACM -- the Association for Computing Machinery, the IEEE Computing Society, and the various management professional societies) are strongly recommended. In addition, there are many trade journals (such as eWEEK) that MIS professionals should become familiar with, many of these being published both weekly and on-line.
|
|
Course Description:
|
3 semester hours credit. Prerequisites: INSS 540, INSS 550, INSS 620, and advancement to candidacy in the M.S. program. Provides the student with practical experience in analyzing, designing, implementing, and evaluating an information system in educational, industrial, governmental, or military environments. The student completes a systems development project in which all of the systems development cycles can be experienced. Students can be placed in practicum sites independently or in a team to acquire practical experience. This course is graded Pass (P) or Fail (F) and is normally conducted over two terms.
|
|
Course Goals:
|
1. Critical Thinking: Students should improve their ability to analyze information and develop appropriate summarizing and reporting techniques.
2. Writing Skills: Students should improve writing skills through development of the Project Proposal and project documentation.
3. Oral Presentation Skills: Students should improve their presentation skills through oral presentations and structured walkthroughs of the project in process.
4. Computer Skills: Students are expected to improve their computer skills implementing a systems analysis and design project. In addition, the conduct of the course will make extensive use of the webboard.
|
|
Course Objectives:
|
1. Directly apply the SDLC (systems development life cycle) methodology
2. Participate proactively in a structured walk-through of code
3. Evaluate critically (on a managerial level) a systems analysis, design, and implementation proposal
4. Identify, describe and model procedures for information systems projects
5. Demonstrate data reporting and analysis techniques
6. Demonstrate technical writing skills
7. Demonstrate oral reporting skills appropriate for a managerial environment
|
|
Grading Information:
During this 14 week distance education course, the student will be evaluated based on presentations of the project decided upon by group or individual and the course grade will be based on the final project to be presented in class. To obtain the grade "P", the student's performance has to be "B" or better. To obtain a grade of "B", the student must have an average of 80%. There are no letter grades in this course. This not a lecture type course. The instructor's responsibility will be to guide the student toward successful completion of the project.
|
|
Course Requirements:
Presentations - 4 totaling 60% of course grade (each presentation: content 60% presentation 25% visuals 15%)
Final Report 40% (Content 75%; Presentation, Quality of English 25%)
POSSIBLE TOPIC AREAS:
|
|
Description of Course Requirements:
Since the goal of the course is completion of the project, the bulk of the formal on line meeting times will be devoted to achieving this goal. This will be accomplished via formal status reports on the projects, beginning with the Project Proposal which will be presented the first week. Each participant in the course should have a formal presentation of the project proposal prepared for the first week. The group will evaluate the strength of each proposal and will recommend appropriate modifications (evaluating the strength of the proposal as well as recommending modifications to the scope.) The Project Proposal Form should have been drafted at that point. This will be the basis for the presentation.
Students are required to work singly or in pairs to solve a problem in some aspect of information system development. (The advantages and disadvantages of individual effort versus team co-operation should be considered carefully before choosing one or the other mode.) In the first week of the course, students will choose a problem they might like to solve. This could be a problem arising from their work experience, but it is preferred that it is not something they are doing as part of their daily work. The instructor will assist with the choice of project. See the Project Proposal Form and Suggestions as the end of the syllabus.
Students will be required to present their ideas and progress reports to the class for critical appraisal via class presentations each week (see Tentative Schedule). These presentations will detail work in progress and will take the form of a structured walkthrough (students are expected to develop their own walkthrough report) as would be used in professional systems development. Every student must make a full presentation of their (contribution to the) work and produce appropriate documentation (interim reports) for their review. Students should be prepared for a rigorous and detailed examination of their work. In addition to presenting their own work, all students will be expected to participate in the structured reviews of other students' work. These presentations and reviews will be assessed and will count towards the final grade (see grading criteria above). The Tentative Schedule suggests presentation timing; however, as part of the experience of the SDLC, students are expected to develop their own schedule for the deliverables, which will be monitored by both the student and the instructor.
At the end of the course, students will submit a final written report of their work. Where students work in pairs, the reports must show clearly which student was responsible for each section. (It is expected that joint projects will involve the same amount of effort per student as for a student working alone.) The final project report should show relevant sections of the solution process as described in courses INSS 540 Information Systems Analysis and Design and INSS 550 Database Management and Decision Systems and the phases should be clearly demarcated. It is impossible to prescribe the length of a report - each problem is unique. However, it is strongly recommended that students select a small problem, which they can complete in the set time in preference to one which is too large and which can be only partially solved within the time constraints.
Class Participation/Conferences--each student will be judged on the quality, not quantity, of participation in class discussions. For this class, class participation is contribution to Conferences. It is expected that each student will contribute substantially to weekly Conferences. There will be one conference for each student in the class. I would like for you to treat your conference as your workspace where you submit your work to the rest of your virtual company for review/comments. I would like for you to treat your peers’ Conferences as though they were members of your corporation and that together we are producing these products for our customers. In this way your comments on your peers’ work should be constructive and help their work be more efficient and responsive.
· ATTENDANCE POLICY: Regular class attendance is expected. You should plan on being connected to the course material at least twice a week. The most effective technique is to set aside one particular time to be "connected." If you are going to miss a particular week, I would like an e-mail message telling me when you will be gone and for what reason. For this Practicum, it really means that on a weekly basis, I would like for you to be submitting something for review, commenting on another student’s submissions, or asking for guidance. Please note that those students receiving tuition assistance from the Federal Government must not miss three consecutive class meetings without prior approval, or the education Services Officer (ESO) must be notified by the instructor.
POSSIBLE TOPIC AREAS:
· Automation of a small business
· University print shop charge back system
· Requirement determination and strategic selection for information systems for a particular company
· Automating accounting control procedures for a company
· Economic analysis of an automated identification card system
· Development of an automated order processing system for an office automation system
· Maintenance control system for a company
· Cost benefit of information system
· Personnel tracking system
· Inventory system
Project Proposal for Information Systems Practicum -- INSS 680
This course provides the student with practical experience in analyzing, designing, implementing and evaluating an information system in an industrial, government, or military environment. The student is assigned a systems development project in which all of the systems development cycles can be experienced. Students may be placed in practicum sites independently or in a team to acquire practical experience.
The following guidelines must be used when completing the Project Proposal:
1. If you have questions on completing this form, you may email the instructor (edeaton@faculty.ed.umuc.edu) prior to the beginning of the term.
2. All Project Proposals will provide the information specified in the Project Proposal Form attached. The form may be submitted as follows:
a. Complete the attached form by filling in the blanks. If you wish to add more, then do so at the end of the Project Proposal sheets.
b. Please keep the questions in the same order and answer all questions.
3. Consider the length of the term - really fourteen(14) weeks. Ensure that the project scope does not exceed this very real constraint.
4. The course description states that the student must "experience" the system-development cycles.
a. This does not require that the student implement all the steps in the cycle.
b. For example, a student or team could read/study previously created analysis and design documents, "do" the implementation and also prepare an evaluation plan to be completed by other students or teams.
c. Similarly, a student or team could "do" the analysis, "do" the design, and develop frameworks for implementation and evaluate phases to be completed by other students or teams.
5. Please note that an INSS 680 Project is not just a "let's do one paper" project. It is expected that the student or team will do several tasks or phases in the systems development cycle. While installing a LAN is a neat thing to "do", it does not in and of itself come close to meeting the letter or the spirit of the requirements for INSS 680
6. The proposal requires a definitive presentation of the tangible results expected from the project. These tangible results are hereinafter referred to as "deliverables".
a. For example, the document(s) that will be created and the scope and detail that the documents must meet are deliverables, or an operational database with ten (10) input screens and six (6) standard reports are deliverables.
b. The deliverables must be presented in concrete terms that can be evaluated by a disinterested party.
c. The following are presented as examples and as the beginning of a list of possible deliverables that a project may require. Remember a successful project will normally consist of several deliverables of this kind.
(1) A LAN User Manual.
(2) Analysis Documents that could include interviews, periodical research and other tasks associated with the analysis phase.
(3) A detailed Design Document
(4) A Programer's/System Administrator's Maintenance Manual for an implemented database system.
(5) A UNIX System Security Manual for System Administrators on AT&T 3B2 Computers.
(6) Documented installation of a LAN with two (2) file servers, three (3) printers, and fifteen (15) fully functional workstations.
(7) Documented installation of a relational database system.
(8) The creation of a new functional module for an existing database.
(9) The analysis, design, implementation, and evaluation of a reliable Client-Server file transfer system.
7. Any project that "does" an implementation (a deliverable) must also include the development of an evaluation document (a deliverable) that may be used to evaluate the implemented system.
8. Organizations that wish to sponsor a student or a team in the INSS 680 Practicum should be prepared to meet some of all of the following requirements:
a. Allow adequate access to software, systems, documentation, and other resources to allow students or teams to complete the project during the term
b. Sign a Release of Liability with the University of Maryland, Overseas Division.
c. Provide a specific Point of Contact (POC) for the development and implementation of the project. Additionally, the organization will perform a role in ensuring that the project remains on schedule. This will possibly include meeting with students during the first class so that organizations and students or teams can be matched up.
d. Organizations wishing to formally present their projects to students at the first class meeting to "drum up support/interest" are most welcome to do so. This is not a requirement, but an invitation, if you wish to sell your project.
9. Project Proposals are due to the instructor in draft form no later than the first class meeting. They are due in finalized form by email not later than one week after the first class meeting, i.e. 10 November, 2003.
INSS 680
PROJECT PROPOSAL
FORM
1. Proposal Name:
2. Project Description:
3. How much time/effort do you expect that this project will require?
4. Specific Deliverables:
5. Sponsoring Activity:
6. Sponsor Point of Contact (POC) Name and Telephone Number:
7. Special Requirements:
a. Security Clearance: Yes/No
b. Other:
8. What special skills must any student have who is assigned to this project?
9. Sponsor Support:
a. What days and times are available for the students to conduct work at your facilities?
b. What hardware and software will be available for the student or team to use for the project?
c. What documents, functional descriptions, requirements, etc., are available that will assist the student or team in defining this project?
|
|
Course Schedule:
Pre-class 1
WebTycho, Connectivity, and preparation for the Practicum ;
Connect to WebTycho, send an e-mail to the instructor, complete a Student Information Form, review the SDLC in the Whitten and Bentley text, and begin exploring potential projects
Class 1
Introduction to course, lecturer, and other class members; The Planning/Survey Phase;
Submit a brief biography to Who We Are; complete a Project Proposal Form; obtain instructor's approval for your project; may want to review the SDLC discussion on walkthroughs in Whitten and
Bentley, paying particular attention to the deliverables and tasks by Phase
Class 2
Analysis/Study Phase; Walkthroughs Review; User Definition Review ;
Review and comment on peers' Proposals; develop a walkthrough report for use by other students in analyzing your work; may want to review the discussion on walkthroughs in Whitten and Bentley
Class 3
Analysis/Study Phase and/or Definition Phase; Review of Budgeting and Scheduling ;
Submit for review: 1) User requirements, 2) A detailed analysis of the users, including their tasks, experience level, and other demographics, 3) A rough budget and schedule estimate; Comment
on peers' walkthrough report form; may want to review Modules A and B and the discussion on walkthroughs in Whitten and Bentley. End of first grading period.
Class 4
Design Phase ;
Comment on peers' project plans (1-3 above); Begin design work
Class 5
Design Phase ;
Submit preliminary design for walkthrough and develop a preliminary evaluation plan; Be an active participant in the walkthroughs (number dependent on number of students in class)
Class 6
Design Phase ;
Submit final design for walkthrough; Be an active participant in the walkthroughs (number dependent on number of students in class). End of second grading period.
Class 7
Construction Phase ;
Continue activities listed above and begin constructing the proposed project
Break 22 Dec, 2003 - 18 Jan, 2004
Class 8
Construction Phase ;
Provide either a status report or submit materials for walkthrough; Be an active participant in the walkthroughs (number dependent on number of students in class); continue work
Class 9
Construction Phase ;
Provide either a status report or submit materials for walkthrough; Be an active participant in the walkthroughs (number dependent on number of students in class); continue work
Class 10
Construction Phase ;
Provide either a status report or submit materials for walkthrough; Be an active participant in the walkthroughs (number dependent on number of students in class); continue work
Class 11
Construction Phase ;
First Draft of the Deliverables Due, including Implementation Plan. End of third grading period.
Class 12
Delivery Phase ;
Be an active participant in the walkthroughs on the deliverables (number dependent on number of students in class)
Class 13
Delivery Phase ;
Support Plan and Final Evaluation Plan Due. End of fourth grading period.
Class 14
Evaluation Phase ;
Final Project Due, including report on Lessons Learned and Actual vs. Budgeted schedule and resources
|
|
Academic Policies:
|
Please refer to the UMUC - Europe Graduate Catalog, available online at http://www.ed.umuc.edu/general_info/publications/catalogs/index.html or from your local Education Center, for information on the following:
Academic Integrity
Course Load
Exception to Policy
Grade Appeal Process
Make-up Examinations
|
|
Faculty Bio:
INSTRUCTOR: Edmund I. Deaton
Dr. Deaton received his Ph.D. in Mathematics from The University of Texas. He has been teaching and doing research in Computer Science since 1980. After many years at San Diego State University he retired in 1992. He was a visiting professor at Hope College, Holland, Michigan during 1993-1995. He spent two years at Oklahoma State University from 1980 to 1982 as a visiting professor and visited there again in 1992. He worked as a management consultant with a Southern California consulting firm for several years in the 1980's. He specialized in database design for governmental entities. He has been with the University of Maryland, European Division since 1995. He teaches in the graduate MIS program and also teaches undergraduate computer science courses. His academic specialty is data base design. His primary hobbies are hiking and Alpine climbing. Although based in Heidelberg, he calls Rota, Spain home and hopes to be assigned there for some time each year. He is currently living in Aviano, Italy and will be there until January, 2004. Phone (Aviano, Italy) +39 4034 662 079 (h), +39 3387 389 270
|
|