November 26, 2007 at 11:34 am
WANT MORE FEATURES!!!!
Sorry, couldn't resist. @=)
The Scope Creep discussion reminds me of a moment at one job where the developers worked their butts off designing a website solution (tied to a database, of course) based off of BU requirements. They got it knocked together, thought it was perfect and took it to the Big Kahuna for a demo.
Said BK immediately told them to go back to the drawing board. Why? Because there were too many layers in the website. You had to click 5 links to get to point A, 6 links to get to point B, another 6 links to get to point C....
Site was done By The Requirements, but the requirements didn't take into account visual layout or how things would be ordered. Weeks worth of work (maybe up to 2 months, I don't remember) down the drain because of one little tidbit that no one, not even the business unit, thought of during the design or development phases. My opinion is that you can have requirements out the ying-yang, but you'll never catch everything no matter how hard you try.
Also, things like this (the above example and Steve's scenario) are a good argument for agile programming. You ask as many questions as you can think of up front, then part-way through the process give the users a sneak-peek. Annoying as it is, better they raise a fuss before all the work's been done then after. Less grief on our end, at least.
Speaking of Agile Programming.. Please tell me someone has seen today's Dilbert. (11/26/2007 cartoon). Two weeks after my workplace makes a project an "agile project", this comes out. ROTFLOL!!!
November 26, 2007 at 12:01 pm
I totally agree! I'm a big proponent of prototypes. It always helps to see something to realize what you are missing, or what sounded good on paper. No matter who was involved in creating the requirements, there will always be something that was overlooked.
November 26, 2007 at 12:39 pm
As far as I know, I do not do agile programming. However, I do use prototypes extensively. In fact, my users never see or have to approve a list of requirements. I consider that a waste of everyone's time. Instead, I start projects by asking my users (the real users, not management) a bunch of questions about what they think they want, including all the stuff they haven't thought of. Then I decide what they really need and design a prototype. The users review and approve the prototype. This system has worked a million times better than when I used to make my users review every decision and create all the rules/requirements up-front.
My belief is that a written list of requirements requires a kind of mental gymnastics to interpret which most people simply can't do. (Because you can't read someone else's mind. What assumptions is that requirements document making concerning how the application itself would flow?) Users make bad decisions when pressed to do it this way.
I doubt I could make much sense of most requirements documents, and I create apps for a living. Perhaps a requirements document WOULD be usable if the document included screen prints. Then, maybe if I spent a lot of time studying the document and thinking about the requirements document and I had nothing better to do... Prototyping instead gives users an instant moving picture (worth a million words) to grasp the proposal. Aside from helping the user, the process of developing a prototype results in better thought-out screens than simply designing on paper. And it is also ultimately faster because you [can] skip that formal step of creating a requirements document that no one else reads or understands.
Another great benefit is that prototypes make designing the database easier. I can easily see and figure out what fields I will need when I can see the screens, functionality and reports that are needed. Let's relate this discussion back to the article in question: Maybe instead of creating the database/tables as the first step after vaguely describing the project, Steve should have created the screens/prototypes for us to see. Having to think through those screens would have made it easier for us to find holes in the database design. This works for some types of holes anyway. Put another way: I can't imagine creating an application to fit a data model. It makes more sense to me to create a data model to fit an application.
One more thought: I doubt my development process would work in environments with teams of developers. (I'm a one person shop.) Prototypes could still be used, but I would guess that they would have to be accompanied by written detailed screen descriptions so that everyone is on the same page. My (unoriginal) thought is this: The optimal process for designing a good database might not only depend on the project, but also on a number of other environmental factors, such as numbers of developers, types of users, management expectations, etc. These are all things for the beginning data modeler to take into account. I.E.: It depends.
November 26, 2007 at 1:29 pm
JJ B,
Excellent points and I think I'll actually move into 2 parts from here. One on getting/deciding on requirements and another on the modeling.
Steve
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 27, 2007 at 2:30 am
JJ B (11/26/2007)...Let's relate this discussion back to the article in question: Maybe instead of creating the database/tables as the first step after vaguely describing the project, Steve should have created the screens/prototypes for us to see. Having to think through those screens would have made it easier for us to find holes in the database design. ....
Hi - I think we should follow the very unoriginal ideas of standard requirements capturing:
* Have the analyst (whoever that is - you, the customer, some designated intermediary) draw an entity model (or some sort of it) of the world as she/he sees it; UML class diagrams are the modern choice, but every other notation will do.
* Draw screen sketches(!) when and where they appear to be (might be) important.
* Describe operational sequences (a) from the users' standpoint ("after X, we want to be able to do Y or Z"; (b) where (somewhat..very) complex decision chains are to be run through "internally" ("after K, it should compute L if K is less than ...; otherwise M") (again: UML has diagrams for this; but simple lines and arrows, or - of course - text often captures enough of what users want).
It is NOT enough just to draw screens/pages: In almost all cases, people have an underlying model of the world - a book has one or many authors, it has an ISBN, it has zero or some reviews ... independently of the screens! So all of the above is necessary!
Regards
Harald M.
November 27, 2007 at 7:11 am
Some great points about prototypes and Entity Relationship models / UML, but I'd like to add a point on "application databases".
I believe the data should be modelled as a database that the application can use, rather than building a database to service the one application. Too often do I see databases are designed to service one particular application. Tables are used to store the contents of the screen / page in a way that suits the presentation rather than the logical structure of the data. As soon as another application / report / data feed is required from this database, the flaws in the design become apparent. Usually the tables are not normalised sufficiently.
This is because the database was created as a data storage area for the application by an application developer, not modelled by a database designer. This approach yields much quicker application production, which is great in the short term; however when the company grows a very painful migration to a logical data structure to suit multiple users / departments is usually the long term result.
So I agree with prototyping the application (which may temporarily use a denormalised database to demo the prototype), but model the database and data flows for the longevity of the database design and the integity of the data.
December 5, 2007 at 5:53 pm
Lots of great reading here.... another suggestion (way back to the table design)... At least for me if I can remember the author's last name that's doing great. This could be searchable if split out into the usual components (first, mid, last) maybe composite index (last, first, mid)
Viewing 7 posts - 91 through 96 (of 96 total)
You must be logged in to reply to this topic. Login to reply