|
A hints page has been added for the project.
Click here to read it.
You may wish to use Microsoft Visio to tackle some of the assignments,
particularly to prepare data flow diagrams, entity relationship diagrams, and
system architecture diagrams. I have prepared a sample Visio page holding the shapes you
will need. Download it
here.
The Concept:
During this project you will select and describe an organization in need of
help. Then you will propose and describe an information system you think would
meet it needs, then run through the different phases of the
system development life cycle as studied during the course. This will run from
the initial feasibility study and systems planning phase through the systems
analysis phase and the systems design phase. You will not be required to do any
actual implementation, but you will need to come up with a plan for the systems
implementation and systems operation and support phases.
The project will be carried out individually.
Selecting Your Project:
The organization you use for your project on should be real, or based on a
real one, and it will usually help if you pick one you know something about and
have some interest in. However, you do NOT have to remain entirely true to
reality. If the real-life version of the organization is too small to need a
computer system, you can pretend that it has expanded to five stores instead of
one and is having difficulty with its old methods. Don't bite off more than you
can chew -- trying to do the whole of a huge company like Wal-Mart or Ebay would
be too hard. If the real life version is
too big to work with, for example the PetCo chain, then you could pretend that
the branch of it you are studying is a single, independent pet store in need of
a system to track its products and customers. Do not be scared to make up
plausible seeming details in Phase I.
Examples:
- In a library: A computerized system to track the catalog of books, tapes
and other materials, together with the library patrons and their borrowing
activity.
- In a restaurant: A computerized system to track reservations, assign
seats to patrons, track food and beverage orders and produce bills. It might
also offer a "frequent diner" program.
If you have a job or internship, there will almost certainly be some kind of
real or hypothetical information system to study. It may be that the organization you are familiar with already has some kind
of computer system. In this case you have a choice. You could take yourself back
in time and pretend it didn't yet exist, so that you can design another system
to do the same basic job. That's OK as long as you don't just totally copy the
real system. Or, you could admit that it exists and either design a replacement
or a new system to work along side it. The situation you describe in your
project doesn't have to totally match reality, and in fact you will probably want to
simplify in some areas. But it does have to be consistent through all the phases
-- the system you design in phases II and III has to fit the organization and
requirements you describe in Phase I.
As you continue to work on later phases, you may discover problems or
omissions in your original analysis. For example, missing processes, outputs or
users. In this case, you will want to go back and revise the earlier stages
before submitting the final version. Due dates for each phase are shown on the
Schedule page.
Breakdown of Credit
| Phase |
Total Credit |
Credit for Draft |
Credit for Final |
| I |
15% |
10% |
5% |
| II |
35% |
15% |
20% |
| III |
30% |
15% |
15% |
| IV |
10% |
N/A |
10% |
| V |
10% |
N/A |
10% |
If group members do not agree that an even distribution of credit accurately
reflects the balance of effort within the group then credit will be
redistributed between individuals following the process described in the course
policy.
What to Produce
The term project requires you to supply the same kinds of reports and
diagrams you have been practicing with the weekly assignments.
More details on most of these items are available on the
project hints page. This gives you a good idea of
how to approach the harder parts of the exercise and what I will be looking for
when I grade them. Please read this carefully.
Phase 1: Systems Planning
- Organizational Background: Begin with a summary of the
organization you are using for your example. Discuss its origins, current
operations, future plans, strengths and weaknesses in a similar format to
that used in the case studies in Chapter I of the textbook. It's important to get a
sense for what the major activities of the organization are and who is
carrying them out.
- Mission Statement: Write a mission statement for the
organization. This can be fairly short (one or two paragraphs). Avoid making
it too specific or short term, but also try not to make it some totally
general thing that could fit any organization.
- SWOT Analysis: Carry out an analysis of the Strengths,
Weaknesses, Opportunities and Threats for the organization as a whole (not,
as in the textbook example, just for the IT part of it). List at least three things
in each category.
(The three items above give the background against which your proposed system
will be judged, so don't be afraid to present them in such a way as to make your
system seem like a really good idea, even if this means modifying or simplifying
reality.)
- Proposed System: Give a short (one paragraph) description of the
purpose of the proposed system, including the main tasks it will carry out.
Don't go into too much detail here, but it is vital to have a reasonably
clear idea of what the system will or will not include before moving on.
- Reasons for the Project (Business Case): Identify at least five different
potential organizational benefits of the project, from the categories given
on pages 54-55 of the textbook as "main reasons for systems projects."). Spend a couple of sentences of each, and
explain what they mean in the specific context of this system and this
organization. It should be clear from each one how it will help the
organization achieve its mission.
- Feasibility of the Project: Discuss the feasibility of the
proposed project, being sure to cover several considerations in each of
the four categories (economic, operational, technical and schedule) given
on page 61-64.
For each of the four kinds of feasibility, give at least two specific things
you would do to gather the additional data needed to make a well informed
decision (see the discussion preliminary interviews and data collection on
page 67-9 for some inspiration -- answers might include questions you'd ask
to specific people, documents you'd try to get hold of, etc).
- System Constraints: Identify at least ten constraints on the
project, including a mix of external and internal, and of present and
future. For each constraint, say where it falls on the table on page 69-70:
mandatory/desirable, internal/external and present/future.
Look carefully at the hints for this one -- the text book doesn't do a
good job of explaining the constraint concept and a lot of people get
confused and do a bad job on this section. Make sure your constraints are
really constraints and not just arbitrary design choices.
Phase II: Systems Analysis
We'll assume that the proposal presented in Phase I has been accepted by
the organization, and you are moving forward with the detailed design and
analysis for the system you proposed.
- System Requirements Checklist: Use the categories of Outputs,
Inputs, Processes, Performance and Controls given on pages 100-101 to
identify at least thirty requirements for the system. Try to make this
list as complete as you possibly can. (Note, the textbook glosses over
this in a couple of pages, but it is actually the most important part of
systems analysis).
- Analysis of Users: Identify at least four distinct groups
of system users. For each group, discuss their main interactions with the
system. Include a list of inputs, outputs, and responsibilities for each
group. Make sure that the inputs and outputs you mention fit with the System
Requirements Checklist.
- Fact Finding Plan: Outline a plan by which you would
investigate the system requirements. Include discussion of the documents
you would seek to collect, and what you would hope to learn from each.
Include a paragraph on each of the interviews you would conduct, and what
you would try to learn from it. Inclusion of a questionnaire is optional.
- Data Flow Diagrams: Prepare a Context DFD, a Level 0 DFD and
at least two Level 1 DFDs (pick the most complex processes).
- Process Descriptions: Produce a reasonably detailed, one
paragraph plain English description of what each of the top level
processes does (the ones in the Level 0 DFD). Then do the same for each of
the lower level processes on the Level 1 DFDs. Make sure that these
descriptions are arranged to give a good sense of how the system as a whole
does its work.
- Development Strategies -- Software Acquisition: Do a real life
web search, and identify a real-life package suitable for this
application. Summarize the system requirements you identified earlier and
give a critique of its apparent strengths and weaknesses of this package
against this summary. Also consider how well the package would fit with the
existing IT infrastructure and personnel of the organization, and what would
need to be added in terms of people or technology to support it. Many points will remain ambiguous, so prepare a list of questions
you would ask the sales representative for the company supplying the
software.
When you submit the draft of Phase II, you MUST submit the graded copy of
Phase I so I can see how the two relate.
Phase III: Systems Design
Note: Phase III requires you to do your own original design work. If the
sensible thing for you organization would be to do with a package then just
ignore the fact for this phase, and pretend you are designing one yourself to
meet the requirements.
- Entity Relationship Diagram: Draw an ERD
for the entire system. Show relationships and cardinality (for cardinality,
if you use the 1, M, N notation rather than the crow's feet one, be sure to
use the format "1..M", "0..1" etc. as explained in class to show if the
relationship has to include at least one record).
- Data Design: For each of the entities shown on your ERD,
prepare a set of data dictionary entries. These would be used to prepare
data base tables to store this data. Each one of these entities will have
multiple fields. For example, in many systems a "Customer" entity might
have fields including FirstName, LastName, CustomerNumber and PhoneNumber.
In the data dictionary entry for each of these fields, specify its name,
type, length/range and source. (This is similar, but not quite the same, as
the data element documentation discussed on pages 168-169). Use the same
format as the exercise here.
Remember you will need a separate table for each and every entity in the ERD.
- User Interface Design: Design at least three sample screens
for the system. One of these should be a main menu screen for the
application, giving top-level options for the system. One of the other
screens should allow data entry. Accompany the screens with a discussion of
the features used to reduce input errors and improve productivity as
presented in the textbook on pages 304-321 (things like
checks of different kinds, navigation features and so on). Many applications, including Access,
Word, Excel and FrontPage can be used to produce screen designs.
- Report Design: Produce one example report from the system,
including fake but plausible looking output data. Use as many of the
report features discussed in the textbook as possible (groups, headers,
totals and subtotals, etc).
- System Architecture: Devise a suitable architecture for the
system. This will involve making decisions about application platforms and
the use of web technologies. Justify your choices by writing a one page description
of the system architecture and explaining how you made your decisions. Prepare a diagram
showing the overall technical structure of the system, including users,
client computers (whether fat or thin) and any required file servers, database servers, application
servers, specialized hardware stations (such as card swipers or checkouts)
and network connections. An example diagram is available in
Visio 2003 format
and as a .pdf file
-- see the hints page for more details.
PLAGIARISM REMINDER: Many people choose to design systems for real-life
organizations similar to those they have personal experience with. This is
good. Some people choose to design systems to do similar work to those that
actually exist in these organizations. This is OK, but make sure that your
system is significantly different in some way. Copying actual screen or
report designs, however, is plagiarism and means that you fail the entire
course. Don't make me do it.
When you submit the draft of Phase III, you MUST submit the graded copies of
Phase I and II so I can see how they all relate.
Phase IV: Systems Implementation
- Implementation Plan: Develop a plan for the implementation
phase, including programming, testing, documentation, training, data conversion and
changeover strategy. Include at least a paragraph on each, with an
estimate of the person-days required and who would be responsible for
carrying it out. Produce a timeline showing start and
end dates for each activity.
Phase V: Systems Operation and Support
- Maintenance Plan: Identify a plan for dealing with
maintenance issues. Include some discussion of each of the four kinds of
maintenance tasks discussed on page 512-514 (Corrective, Adaptive,
Perfective, Preventative) and give at least one example of each kind of
task in the context of this system, how it would be resolved, and who
would be responsible for it.
- Phased Enhancements: The textbook doesn't talk much about
this, but no system is ever complete in its first version (or ever,
really). Identify at least three major enhancements that could be made to
the system over the weeks or months ahead, and write a paragraph or more
on each.
- Effectiveness Metrics: Back in Phase I you listed a number
of organizational benefits you thought would come from the project (aka as
"reasons for the project). Assuming the system is now in place, explain how
you would come up with a numerical measure of how effective it had been at
achieving one of them (you pick which one). This will involve comparing
"before" and "after" values for this metric to see if the system has altered
in in the desired manner.
When you submit the final version of the whole project, you MUST submit the
graded copy of Phase I, II and III so I can see how well you have addressed the
issues I raised in grading the drafts.
|
