doc

desertdysfunctionalInternet and Web Development

Dec 4, 2013 (3 years and 8 months ago)

76 views

1


Project Description


(revised
April 3
, 2011
)


1.0

Summary


You will produce a website using Joomla for some domain/application that interests you. You will document
your approach using a standard iterative design process using principles from Information Archi
tecture.


2.0

Overview


For your project, you will proceed, iteratively, as needed through the steps shown below. This is referred to as
an iterative or sp
iral development approach.
You will produce a single document with the following sections:


1.

Needs Stateme
nt

2.

Domain Analysis

3.

Analysis

4.

Design

5.

Implementation

6.

Testing

7.

Post
-
Mortem


You should use the template that follows for your document.
1.

You should use c
learly marked sections and
subsections that utilize a number scheme (e.g. 1.1 or 1.A, etc.)


-------------
--------

Template for Project Document Follow
s
---------------------



2









Project Name

PADM 7190


Content Management Systems
, Project

Group Member Name(s)

Date



3



1.0

Needs Statement


Often a software project and/or website project begins with a
Needs
S
tatement

which is a document that is
provided by the customer and given to the developers. It is a succinct statement describing what functionality
the software or website should have from the user’s point of view and the role that it plays in the larger c
ontext.
So, usually, you (the developer) would be provided this statement. It marks the beginning of the project. It
doesn’t bombard the reader with a lot of detail nor nuances; those are fleshed out and discovered in
subsequent steps: domain analysis and
analysis. In this case,
you

wil
l write your own
.

Below is a Needs
Statement I provided

(Fall 2010)

to students in my software engineering class

where t
hey were developing a
software system. You are developing a website, so yours will be a bit different. Ho
wever, the intent in the
statement below captures the spirit of what you are to do, provide a good feel for the proposed
system/website, without getting lost in the details. I suspect yours will be a bit longer than the sample below.


Controlled airspaces
(Sectors) are utilized over large cities and other areas in order to ensure safety of
aircraft passing through this sector. A sector is an imaginary box that sits above a city. Any aircraft that
will travel through the sector must register their flight pla
n with the managing air traffic controller (ATC).
A flight plan must be approved before an aircraft can fly through a sector. For a flight plan to be
approved it must satisfy a number of conditions such how close the aircraft is to other aircraft in the
se
ctor. The system you will develop, Sector Management System (SMS) will allow pilots to submit and
review flight plans and air traffic controllers to issue queries about planes in a sector.


2.0

Domain Analysis


Do some background research on the domain you are

interested in (
e.g.
city government website). One of your
homework

s (IA
-
4?) can be used here.

The idea is you want to see how other organizations are providing a
similar website. You could/should be a bit more comprehensive than the homework mentioned pr
eviously. For
instance, if you were developing a website for a smaller city (
e.g.
Valdosta), you might look at similar sized cities
primarily, but also look at a step or two up (
e.g.
Savannah, Tallahassee, and maybe even another step up). In
short
anything

here that helps you see the possibilities, their strengths and weaknesses.


3.0

Analysis


The idea with
A
nalysis

is documenting “what” is desired. This is in contrast to the next document,
Design
, where
we are concerned with “how” to implement it. Warning: th
e line between Analysis and Design can get blurry!

The focus is on what the different audiences are and what things members of each
can
do. In some cases, this
may involve describing background, implications, dependencies,
etc.
In some cases
an
Analysis

is

followed by a
Requirements Specification which
is a formal
(numbered and sub
-
numbered)
list of requirements that the
website should have w
here all details are explained. This document can be as informal or formal as you desire.
You should try to use any i
deas from information architecture here that you see as applicable. For instance, you
might document an implicit information architecture that already exists.


4



4.0

Design


The idea with design is documenting “how” you will implement the requirements. This ma
y involve overhauling
or inventing an information architecture using any techniques from our text. A design document usually includes
a prototype. A prototype is a mock
-
up of the actual website/system, it shows the functionality, the flow of tasks,
etc
. Fo
r large systems, the prototype is actually done in

a
graphics package (
e.g.
Photoshop)

with narrative
explaining everything. Then, this is handed off to developers who implement the design. I want you to do a
prototype. How? Your choice. It doesn’t need to

be fancy, just to convey how it is to be implemented. The text
may suggest some techniques. Or, invent your own. You could even use text to make your prototype. Or, you
might do something quick with XHTML and provide screen shots. Narrative to explain flo
w is important. The
overall idea of a design is that it is a blueprint for implementation. In theory, a design could be implemented in
different ways depending on the technology that is ultimately used. For instance, a website could be
implemented from scr
atch using XHTML and custom server
-
side programming. Or, as in our case, the
implementation will be done within the confines of Joomla.



5.0

Implementation


This is the system you will develop.

Simply provide a link to your site and provide any additional inf
ormation as
necessary here.


6.0

Testing


This section can be as short or as long as you like. The important idea here is that websites/systems should be
formally tested. Testing is a well defined discipline and is beyond the scope of this course. Here, we wil
l adopt a
more informal approach. You could describe different scenarios for
different
audience members to
use the site.
For instance, a city resident wants to obtain a copy of the rules for reserving a park for a cookout. Then you
could ask a friend (not
the best test strategy!) to read the description of the goal and then do it on the website.
You could observe them and take not
e

of how successful they were, any problems or confusion, etc. You would
document all this in this document: who is the audience
member, what is their goal/task, results, etc. You
should do something like this for several scenarios. Exhaustive testing is generally impossible for real systems.


7.0

Post Mortem


A write
-
up (1
-
2 pages) detailing how the project ended up, what you did good,

what you could do better, what
you would do differently now that you know what you know.

If working in a group, there should be a general
statement made by the “group” as well as individual statements made by each member.