Pages Menu
Chitu Okoli chitu.okoli.org

DESC 495 Project

DESC 495: Information Systems Design and Implementation
Project description

 

Project stage Details Weight
Project proposal This preliminary step indicates that you have formed a group and have a confirmed project for this course. In one page only, provide the following information:

  • Group members’ names
  • Name and brief description (one paragraph maximum) of the organization and/or department whose business process you will design and implement for the project
  • Brief description (one or two paragraphs) of the business process you will be designing and implementing (business function—management/HR/accounting/SCM/etc.; general purpose of purpose; kinds of users; etc.)
  • Name of the authorizing person who has permitted you to analyze the organization’s business process
  • Name of organizational contact who will freely answer your technical and business questions
0%
Milestone 1: Project selection and planning This step involves the general description of the project, and the presentation of the detailed system analysis, as resulting from DESC 481, Information Systems Analysis. It does not involve much new work, but rather formalizes the specification of the system. The deliverables are:

  • Description of organization
    • The organization (This is the entire organization—its products/services, clients/customers, organizational structure, etc.)
    • The organizational unit, if you are only covering one department or branch of a larger organization. Describe the role of this specific unit within the larger organization.
    • Purpose of process (one- or two-page explanation of the steps involved in the business processes that you will be modeling and implementing)
  • Process model
    • Detailed logical DFD for the process you will be implementing. This might be taken directly or adapted from a DESC 481 project.
    • Note that you must correct the final DESC 481 project model before submission. In particular, verify that outputs from each and every process have sufficient inputs to produce them.
  • Group work schedule
    • Gantt chart describing your schedule for completing the project tasks
5%
Milestone 2: Application architecture modeling This important step involves the physical design of the business process and data aspects of the system. The deliverables are:

  • Physical DFD
    • Use the corrected logical DFD from Milestone 1 to create a physical DFD for the final approved process. Include both manual and computerized parts of the business processes. I have prepared a sample physical DFD to illustrate what it looks like.
  • Data dictionary
    • You need to submit a fully specified data dictionary. I have prepared a detailed sample, based on the physical DFD sample referred to above. All data flows in the physical DFD must be explicitly specified in the data dictionary, with exactly the same name. For details, refer to the course textbook, pages 330 to 333. However, there are a few typos in the specification in the textbook. Thus, please follow the format in the attached specification page (compliments of IIT Kharagpur; full document is available online).
  • Database schema (physical ERD)
    • This is basically the logical ERD with data types displayed (compare Figures 14-7 and 14-9 in the textbook). I have prepared a sample physical ERD associated with the sample physical DFD and data dictionary referred to above. In Visio 2007, instructions on how to display data types are available online; in Visio 2010, it is similar: to invoke the right dialog window, just go to Database | Display Options.
  • Updated Gantt chart
    • This Gantt chart is an updated version of your Milestone 1 chart, with any date corrections indicated.
25%
Milestone 3: Input and output design This step involves prototyping the system in order to represent the initial specification (non-functional prototypes) for the input, output, and human-computer interaction aspects of the system. The deliverables are:

  • State transition diagram
    • Although there are more formal specifications of state transition diagrams, for this project, all you will need to present is the complete sequence of all GUI screens in your new system, following the simple format described on pages 635 and 636 of the textbook.
    • In Microsoft Visio, you can create these by creating a blank page (no template or stencils), then drawing simple rectangles and connectors (not lines) on the screen. For arrows on the connectors, edit the connector’s line property and add the desired arrow.
    • In the submissions below, you will need to include a screenshot of a prototype of every single screen represented in your state transition diagram.
  • Input and menu screenshots
    • Submit screenshots of non-functional prototypes of the main and menu screens (e.g. Figure 17-17 on page 637 or 17-6 on page  625) and input screens (e.g. Figure 16-8 on page 601 or 17-18 and 17-19 on page 638).
  • Source documents, if any
    • When applicable, include copies of source documents (usually paper or e-mails) from which data is then entered into the system; the copies should be filled out with real or sample data. (A possible example is Figure 5-7 on page 170.) If such documents already exist in a real system, submit a copy of a real sample. If they do not yet exist but are required for your new system (or existing documents need to be modified), then design the new document and submit a copy with sample data.
  • Output screenshots
    • Submit screenshots of non-functional prototypes of the output report screens (e.g. Figure 15-2a-c on pages 552 and 553).
  • Printed outputs
    • Include copies of output reports (paper, e-mail, etc.) that are generated by the system; the copies should include sample data (e.g. Figure 15-3 and 15-4 on pages 554 and 555. For this Milestone, you may prototype the reports as a Microsoft Word document. Do not invent new reports or outputs that were not specified in Milestone 2; only implement the outputs that were already specified.
  • Test plan and test cases
    • Software testing is a very detailed and formalized discipline, but for this project, you will only follow a simple procedure. The main point here is that you will conduct better testing if you plan ahead of time what you expect to test. For this project, your test plan will only cover unit (GUI screen) and system (process) testing.
    • For all test cases, use the Test Case Format provided by Jason Robbins. For specific tests to conduct based on input data type, he also provides detailed examples in “Choosing Test Data“.
    • Specific deliverables:
      • For unit testing, for each GUI screen in your State Transition Diagram above, submit one Test Case that tests every input possibility.
      • For system testing, for each Level 1 process in your physical DFD, submit one Test Case that tests a complete typical usage scenario, involving multiple screens.
20%
Milestone 4: Final project due This is the delivery of the completed, functional system:

  • Fully functional software
    • You must submit both the complete source code files and the compiled executable file, including the necessary database files. Make sure to test the installation and execution of the entire system on a computer that was not used for development. You must fully document the installation of the system step-by-step in your user manual.
  • Partially populated database
    • Your database should be pre-populated with realistic sample data. It must have sufficient data to generate a variety of realistic-looking reports.
  • Results of testing
    • You should conduct all your test cases to make sure that all the GUIs are working properly. However, you should submit printouts only for the system testing.
    • Specifically, first revise the system testing test cases for each Level 1 process in your physical DFD (e.g. 1,0, 2.0, 3.0). Then, submit all the screen shots involved with sample data involved in going through each Level 1 process with one sample, correct case. (I will test the invalid data on your live software; you do not need to submit anything for invalid data.) Also submit the reports generated from the data that you have entered in your test cases. If your users will print black-and-white reports, then do not submit colour reports.
  • User manual
    • Create a detailed user manual that explains every option of every screen. You are free to use any reasonable format; you can use Figure 19-4 in the textbook as a rough guide. However, your manual must include the following items:
      • Full system narrative from DESC 481, updated to reflect any changes and clarifications that you have made in the system. This is a text narrative only; you do not need to submit an updated DFD.Step-by-step installation instructions for installing the software and database. Make sure that these instructions are based on testing your system on a computer that was not used for development.
      • Section for new users: Step through the same steps that you follow in the system-level testing described above. In this section, only give a general description of the input controls involved.
      • Reference section (for experienced users): Explain every menu item and every button in detail. You should also explain every single input control, though you can group related controls (e.g. name and address fields) and explain them in one sentence. Note that there should be a lot of overlapping coverage between the section for new users and the reference section; however, the reference section should be much more detailed.
      • Troubleshooting section: Document any problems that you have faced in your testing that you find users might face during normal operations. Note that these errors are not bugs (you must fix all bugs); they refer to possible problems with the user’s system (e.g. files not installed in the correct location that you specified). You do not need to add anything beyond what you encountered in your normal testing of the system.
  • Submit a one-page final report with the team members’ names, and one or two paragraphs explaining your group’s shared experience on the project. In this explanation, be sure to state whether or not the system will actually be implemented by the organization or not, with a brief explanation of the next steps towards implementation.

  • Specific deliverables
    • Submit a CD with:
      • The compiled executable (Windows) file
      • Full source code of the project
      • Database files
      • Any other software needed for your system to be installed and run on any Windows computer
      • PDF file of testing results
      • PDF versions of the paper printouts required below.
    • Submit paper printouts of:
      • Any reports produced by your system
      • User manual
      • Final report

50%

 

I sincerely thank Dr. Rustam Vahidov for his kind assistance and provision of source materials that I have adapted and adopted in designing this project specification.

Miscellaneous tips

Post a Reply

Your email address will not be published. Required fields are marked *