> To go along with the psudo-survey on what other modules are
> being used in
> Web application development and Jesse's request on SOAP usage, I was
> curious about how these apps are being developed in the
> design phase. UML?
> Extream programming, story board, in-house methodoligy? You
> get the idea.
> I am finding my app is getting to the point that real
> planning is needed
> or I will be crushed under it.
The most important thing is that you do SOME planning in advance. Specific
methodologies are not as significant as making sure that before you take a
step forward that you know what you're trying to go.
That said, at Vanguard Media we have an established methodology for software
development. Before we build an application we always build a specification
for that application. Our general software development methodologies are a
collection of ideas gathered from our experience, and the experience of
industry professionals who have committed their ideas to paper. One of my
favorite authors in the area of software development practices is Steve
McConnell. I encourage everybody to read his book "Software Project
Survival Guide".
As far as specific techniques, we produce five discrete documents as part of
our specification:
1. Textual descriptions
2. User Interface Wire frames
3. Data Schema Diagrams
4. State Transition Diagrams
5. Schedule and Budget estimates
The textual descriptions are a summary, in prose, of what each application
does.
The UI wire frames are usually static HTML documents which are somewhat
navigable to illustrate the functionality of the application. It is
important to note that our UI wire frames are explicitly void of any
creative/art direction. We purposely avoid putting anything in wire frames
other than fields, buttons and essential navigation. The Wire frames are
also as minimal and illustrative as possible. We avoid going so far as to
do anything which even gets close to a functional application. Keep is
abstract, or you'll find yourself developing your software during
specification!
Data Schema and State Transitions are done as UML diagrams. These documents
are most useful for the developers (particularly the Data diagram), but not
of much use to non-techies (clients, etc). As a general rule, State
Transition diagrams are made at the level of screens -- e.g.: one state in
the diagram represents one screen of the application. (Good UI wire frames
sometimes obviate the need for State Transition diagrams.) If you focus at
this level then the state transitions usually map nicely into
CGI::Application run-modes.
Schedule and Budget estimates should be made before you start the
specification, and revised when you complete the specification. During the
course of the project, if these estimates change, these documents should be
updated.
As a general rule, specifications may take anywhere from 20% to 50% (Avg:
1/3rd) of the total project time. The variance depends on the size of the
project, the criticality of the project and the complexity of the project.
This is a VERY brief overview of how we, at Vanguard Media, specify a
project. It's surely not the only way of specifying a project, but it works
for us.
TTYL,
-Jesse-
----
Jesse Erlbaum, CTO
Vanguard Media
212.242.5317 x115
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
