How to start modelling a web application?

Question

I ask this, because tomorrow is my first meeting with the client, in which she tells me, what she is doing right now (by hand) and what it is, what the new web-application should do in the end.

I wondered, what I do during she shows me the steps of the process. Do I recognize use cases and model them directly? Do I describe the process in prosa? How do I describe/transcribe the process from real world to a modell which then is the basis for the code?

What is the best-practice to start with a new development for you? Any tips?

Answer 1

I don't think your client wants to talk to you about any of those things... I Bet she is going to show you some drawings on how the page should be organized and how she expect things to work.

You should just follow her presentation asking questions (always for the user point of view), so you can do your job as she expects. Leave the technical stuff for yourself ;)

Answer 2

Most developers don't take the time to do this, and jump right into modeling class diagrams and the system architecture, but more than anything I would say to write down every single feature she mentions. Don't worry about groupings, or how they all fit together. At the time, you just need to get from her every piece of functionality possible. When you leave, and begin to think about the application, it is then that you will start to draw correlations between pieces of functionality, which will end up eventually grouped into objects with properties and methods.

Answer 3

It's all about process and managing expectations and very little to do with the technical. The mistake (imho) most clients make--particularly with smaller consultancies--is that they go for a fixed price contract (possibly with support being billed T&M: time and materials). They do this as a risk management exercise so it's understandable.

The problem is that they are paying for that lower risk in three ways:

• You pay a premium for lower risk. This is a fundamental principle that is as true in software development as it is in financial markets;
• So much risk can be put on the developer(s) that the cost goes up astronomically, which benefits precisely noone (well, it benefits the developer until things go catastrophically wrong, which they nearly always do eventually); and
• You spend so much time developing a specification and formalizing the deliverables and acceptance criteria that you forget in doing so you've just spent $300k writing a 300 page Word document instead of, you know, coding something.

All of this serves to make the end result more expensive for the client, demotivating for the developer (who wants to write 300 page Word docs? Seriously!) and it delays the client actually getting anything (thus increasing the risk of scope creep, which is directly proportional to the length of the project).

Both parties would often be better served by taking the T&M approach combined with some form of rapid prototyping methodology with regular deliverables or demonstrations to the client no more than 4-6 weeks apart. This goes towards managing expectations. If the client can see something is happening it puts them at ease and lets you get on with the job (rather thans pending time in meetings going over GANTT charts).

So what you should do is try and voncince your client to go for a graduated approach (baby steps) where they can see what they're getting, how it's evolving and participate in the process. It gets results faster and is ultimately cheaper (with both parties sharing the risk burden).

One thing many developers also seem to forget is that they are like royal subjects in 15th century France. They may have privilege, even riches, and many perqs but they serve at the pleasure of the king (or queen), who can behead them on a whim. By this I mean that the client ultimately wields the power and you, as a developer, exist to make their life easier and not the other way around.

If the client wants a pink and green website developed in Cobol on Rails running on a virtual Vax/VMS server on the boss's iphone well that's what they get. Now you can use your expertise and experience to try and convince them that's not a good idea but ultimately if that's what they want you have two choices: give it to them or walk.

Too many developers fall into the trap of giving people what they think they should have, not what they ask for. BIG MISTAKE. Part of the process is to keep communication channels open with the client such that you don't go off on a tangent thinking they want something (or deciding they should have something) when they're expecting something completely different.

Even a small software development project can easily run into 6 figures. This is typically a large investment for whoever is paying for it. They have a right ot be nervous and you have a responsibility to make them happy.

Answer 4

Users are not interested in how its going to work. To them its all about the organization of the interface and the necessary steps to perform the operations. I agree with the above suggestions, write down functionality and interface requirements and them see how and if they can be modeled.

After the analysis talk to her again about what you can and cannot do and present solutions or improvements.

Answer 5

The client most likely told you what they want in the first 5 minutes you talked to them. Anything after that is just pillow talk.