Hi Stephen,
Stephen Adams wrote, On 11/8/2006 5:22 AM:
Hi,
I'm thinking about how I go about designing an application from
scratch. I've got a wireframe diagram of how the system should look,
all the pages and what they will contain, but I trying to think what
to do next. Do I:
* Create the database
* Create UML diagram
* List the features of the system
I'm building this system with a Flex front end so its got to be very
OO orientated, but where to start. Does anyone have any ideas,
thoughts, what do other do?
As Hal mentioned, I would start from the UI design as well (...
almost...). However, I wouldn't go very in depth on it.
I would start by prioritizing the features by what the customer finds
most important - and start mocking them up so we could come to an
understanding of what is needed - as Hal said, it is not too unlikely
that what you might build without doing so would completely miss the
point - and in my own experience, the customers aren't sure what they
need or even what is possible without seeing something from you.
Frequent feedback, in my experience, is extremely valuable for a
successful project. I may even simply start with sketches, rather than
an HTML mockup, but unlike Hal, I wouldn't build the real flex front-end
(but I don't know how fast/easy it is to build). The idea here is to
commit to doing the least work possible at this point, since your
understanding of the system is the most incomplete it will be.
So, what I might to is this:
1) List the features. After all, if you don't know what the features
are, how do you know what to build?
2) Put a "cost" on each feature. It doesn't have to be a real cost - a
relative degree of difficulty, I would think, will do.
3) Prioritize the features according to what the customer finds most
valuable, given the knowledge of cost. But, if some feature has to be
implemented before another one can be started, obviously you should let
the customer know that.
4) Prototype a UI for the most important features that you could get
done in a week or two, and get feedback from the client.
5) Work on those features for a short time (the week or two I mentioned
above). Keep track of how much in "cost" you get done during the
iteration. That will be your guide as to how much "cost" the customer
can choose for the next one.
6) Show the features to the client, to get their feedback. Fix what
needs to be fixed and let the customer add new features or reprioritize
existing ones. Wash, rinse, repeat.
Be sure to let the customer choose the most important features - this
ensures they get the most valuable product in the shortest amount of
time, and they could start using it as soon as possible as well.
I see little value in prototyping the entire system in the beginning, as
you may very well never end up building the whole system as it was
initially envisioned. The key, in my estimation, is to produce the most
valuable features in order, and go from there.
I also see little value in producing UML diagrams for the whole system.
If classes relate to each other in ways it is easy to understand, there
is no point in diagramming them. I would only diagram them when they
aid understanding.
With all that said, if you want to have a /working/ prototype, there
are tools/products out there that can look at your database table, and
get your model, view, and controller for simple things up and going, so
you can focus on business logic. This could give a crude html
implementation that you can use to get feedback, and potentially build
the system out of them as well. In particular, I might take a look at
cf on wheels, or Transfer ORM, as they may be ready for production (but
still haven't reached version 1, to my knowledge). Things like this
would allow you to start with the database and effectively give you the
front end you want to get feedback from your client.
From what I've seen, cf on wheels is almost an entire CF implementation
of Ruby on Rails, but the docs make it sound like it only works on
apache, so I haven't tried it. I also heard about Transfer ORM just
this morning, so I don't know much about it, except that it appears a
lot more mature and requires some more configuration than what I've been
working on - cfrails, which you can find at
http://cfrails.riaforge.org. As I said, mine isn't as mature as these
other two, and in fact I don't know that I'd even call it useful yet,
but it is an alternative if you have CFMX 6.1 and MSSQL Server, and
allows you to produce working prototypes extremely quickly (there are
some glaringly missing features, such as ability to easily change the
default form fields to what you what, not working with mysql, no
aggregation of foreign key rows, no client-side auto-validation (there
is server side though), no "run this method before this action", etc.
For reference, Transfer ORM is also at riaforge:
http://transfer.riaforge.org and CF on Wheels is at http://cfwheels.com/
-Sam
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
