[PsychoCoder]

Came across this article on Twitter today. Good read for anyone wanting to properly develop a web application:

Quote

Developing a web application it's a hard work which requires much time you have to spend doing a myriad of things. If you don't use a methodic approach, especially in case of a complex project, you run the risk of losing sight of the project, not respecting times of delivery and wast your time for nothing.

You can read the full article here. Should make for a great discussion amongst the web people here on Dream.In.Code

[c0mrade]

Eh, don't really agree with a few things

Quote

An application map contains just meaningful and essential information about the structure of your application: pages (represented with some blocks) and main relationships between them.

Uh, what? I've heard of site maps. I've heard of use cases. But "application map"? Really? Sounds like the classic web developer trying to sound like a real software developer.

Quote

Ok, now it's time to design application database. A simple way to do that it's using a entities-relationships (ER) model. In general you can follow this order: define first tables, than attributes and relationships between tables.

Wrong. An ER diagram defines entities and relationships between those entities. It does not define attributes. An ER diagram should be formulated at a stage where it is still to early to be defining attributes.


Other comments:

The article does not mention prototyping at all. I have found that this is almost always necessary. If your working for a client then they will likely not have a clear idea what they want/need (not always the same thing). If your working on an internal project then business people will likely need to see something physical to make business decisions. And lastly, if your working for yourself, a prototype is still helpful because it allows you to gather feedback before too much time is invested.

Lastly, the article takes quite a closed minded approach to developing a "web application". In reality (at least my reality), applications will rarely be best implemented as simple web to db programs. You might want a PHP web module which makes SOAP requests to a Java manager application, which then delegates to other modules using a standard messaging platform.

[danny_kay1710]

c0mrade, on 20 Apr, 2009 - 05:06 PM, said:

The article does not mention prototyping at all. I have found that this is almost always necessary. If your working for a client then they will likely not have a clear idea what they want/need (not always the same thing). If your working on an internal project then business people will likely need to see something physical to make business decisions. And lastly, if your working for yourself, a prototype is still helpful because it allows you to gather feedback before too much time is invested.

This is why a good analysis is required (Requirements Definition as the article describes it). I believe that this is one of the most overlooked aspects of system design by many people who want to learn and become a programmer (and some more experienced as well) simply because many people think a project can be defined by it's title.

To use a popular university project I want an airline seat reservation program. Any programmer could make that but that does not mean it is what the client wants. Inevitably it is what they need in some form but will not cover their needs. In a good well managed structured system design, every field (and I mean this literally) should have set out a field length, validation required and the appropriate testing (test plans etc) before I believe you should even start to code. You should have your main screen layouts all set, fonts decided, colours decided (I have seen projects where even aesthetics like this need to be tested thoroughly). It is also important to be careful to not get caught up in the how you will do it - that's design.

And sometimes it is down the client for the lack of data. Some clients can't or won't answer your questions then wonder why it isn't what they expected. University projects are similar. I believe they are generally vague and lack detail and then mark you down when you aren't detailed enough.

Considering it talked about ER diagrams (although didn't perhaps explain them correctly) I am surprised that data or information flow diagrams where not mentioned.

An ER diagram explains relationships between objects in your system. E.g. a plane can have many seats. a booking can be for one place, a booking can be for many customers. It is generally concerned with what type of relationship you are dealing with one-to-many, many-to-many, one-to-one. It will then HELP you decide your table structure - Many-to-many is not possible without an assignment table in the middle.

[c0mrade]

Ironic choice of example, airline reservations systems is what I do at work

So your explanation of the system seems overly simplistic.

[danny_kay1710]

I wasn't trying to go into great detail, it was just to get my opinion across.

And really it only highlights my point - You have worked in making this system and know of the vast amount of detail that goes into it. I and I think most other outsiders don't realise the detail that does go into it.

A good analysis of the requirements should make us outsiders aware of all of that detail.

[c0mrade]

Sorry I wasn't arguing or anything, I was just pointing out that it was ironic

[c0mrade]

The real life software development process:

[danny_kay1710]

You will never get a better explanation of that than that.

Note the difference between the way the customer explained it and what they needed. Clients need to be specific and have a clear understanding of what they want and in many cases this is just isn't the case at all.

And to be honest that's not saying there is no flaws often present in the other sections but you cannot get the correct output without the correct input. And the first fault occurs with the communication between the client and the project leader in this case.

EDIT: This is why I especially hate it when people say can you make this simple xy system and the proceed to be extremely vague in everything they say.

This post has been edited by danny_kay1710: 21 April 2009 - 07:56 AM

[mikeblas]

c0mrade, on 21 Apr, 2009 - 05:32 AM, said:

The real life software development process:

This doesn't describe a process; it describes results and perception.

[c0mrade]

mikeblas, on 22 Apr, 2009 - 03:56 PM, said:

c0mrade, on 21 Apr, 2009 - 05:32 AM, said:

The real life software development process:

This doesn't describe a process; it describes results and perception.

Hmm, maybe I meant "the reality of software development processes" then.

Anyway, I'm sure you get the gist of it...

[doWhileSomething]

Quote

This is why a good analysis is required (Requirements Definition as the article describes it). I believe that this is one of the most overlooked aspects of system design by many people who want to learn and become a programmer (and some more experienced as well) simply because many people think a project can be defined by it's title.

I know it's lose terminology, but there is a huge difference between a "programmer" and a "developer". Maybe not so much to an HR manager, but to a project lead or an information technology director, they are distinct and separate roles.

A programmer is typically assigned tasks to build pieces or components of an application (web or otherwise). Conversely, a developer has a wider range of responsibilities and capabilities and usually act as a liaison to the application architect or analyst and helps shape and model the end result.

cOmrade,
I think there might be a slight language barrier (the person wrote the article in english, but does not have full command of english). He does say "first, then...
So, while I see and agree with your point, I interpreted his meaning by defining entities first (tables) then work from there, as opposed to how he displayed it, everything at once.

Last comment on the "application map" - he is using PHP as his web language. You know, 54 includes to make one page, that language.

I'm not trying to argue with anyone either, it is a fairly good example especially for a programmer starting out. I remember when I first started out writing stuff, I would do the home page first (or the first screen), then a few other things, then think about the DB, then a few funtions sprinkled in, then..... Obviously, and completely the wrong approach, but that's how I started my first few apps. So, for someone just starting out and even those with a few years under their belt, it's a decent article.

[c0mrade]

I agree it's a decent article for beginners. I probably didn't make that clear.

That's the reason I pointed the things out. The article is well written and it sounds like he knows what he's talking about. Beginners shouldn't take the article as gospel. His terminology and detailed descriptions hint that he is no expert in the subject he is writing about.

[doWhileSomething]

Again, I agree with that as well. It almost appears he was writing the article based on something he was reading and wanted to illustrate and share. Having a "decent" direction or "some" insight is better than nothing at all.

[danny_kay1710]

doWhileSomething, on 22 Apr, 2009 - 06:05 PM, said:

Quote

This is why a good analysis is required (Requirements Definition as the article describes it). I believe that this is one of the most overlooked aspects of system design by many people who want to learn and become a programmer (and some more experienced as well) simply because many people think a project can be defined by it's title.

I know it's lose terminology, but there is a huge difference between a "programmer" and a "developer". Maybe not so much to an HR manager, but to a project lead or an information technology director, they are distinct and separate roles.

A programmer is typically assigned tasks to build pieces or components of an application (web or otherwise). Conversely, a developer has a wider range of responsibilities and capabilities and usually act as a liaison to the application architect or analyst and helps shape and model the end result.

I would tend to agree with you, but my point was simply to say, that many people overlook the need for good planning and preparation and sadly that is often neglected by people who start to program or develop IMO.

The articles was great and I have no doubt it will make people aware of how they should be programming and planning.

I simply voiced my points because I had exam style answers drummed into me during class. If I had even remotely suggested ER models had any representation to tables then it marked was wrong. In many occasions there are more tables than there are entities. Two words that have pretty much identical meanings but one could be wrong the other right. An example of how pedantic it could be:

Validation - is checking that the data complies to set rules
Verification - Ensuring that entered data is correct.

If you used correct, right or valid (there was a few more but I can't remember them) in the definition of validation in any context it was wrong.

I am also willing to accept that there are different interpretations of many things, for instance, a virtual machine by my exam terms was "software designed to hide the complexity of the hardware from the end user" - however many people in today's terms would relate virtual machine to something like VMWare (and if you described this you would not get the mark). The exam answer becomes clearer when you think of things like Java which is ran from a Java Virtual Machine (http://en.wikipedia.org/wiki/Java_Virtual_Machine)

IMHO a beginner to programming is normally at some point going to have to face exams where they will mark you down for one or two misplaced words. Again it's just loose terminology but these things do make a difference. When I first starting studying I lost an entire grade (about 13 marks out of 65) due to slight wording differences - ridiculously irritating but in many cases the marking scheme said no mark if they use these words

This post has been edited by danny_kay1710: 23 April 2009 - 09:16 AM