How much should I worry about modeling/analyzing a web application?

Question

I'm developing kind of a modern web application - scalable, robust and fast.

I need to develop it as fast as I can.

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

Answer 1

If you're under heavy time limitations then, first of all, build something that works. Draw anything you need to make a working system and ship something the client can use. Then, if needed, you can focus on improvements, optimization and polishing.

Answer 2

If time is an important constraint, if I were you, I would rather search for an alternative which requires less or no development.

For example, if you are asked by a customer to build an ordinary website which has nothing extra special, and do it in a week, while in better circumstances, you need at least three weeks, then what about the services like SquareSpace?

If it is not a solution and you still need to write code, try spending less time doing "other things", in particular by reusing things you've or somebody else have already done:

• Use frameworks. For example in .NET, don't write your own database queries, but let Entity Framework or NHibernate do the job. Another example: in PHP, don't reinvent MVC pattern every time: there are plenty of frameworks that will do lots of work for you.

• Reuse what you've already done. It also means that if you have a lot of similar projects to do quickly, spend a lot of time doing the common trunk.

• Pick the fastest customer relations technique. If you know that if you stay agile, the customer will disturb you a lot during the development process, gather the requirements, then keep everything secret during development, and only then show the result to the customer.

• Use project management techniques which help you to finish the development faster. For example, enforce the zero bugs policy (see point 5 of Joel test), since the later you fix the bug, the longer it will take to fix it later.

If you still don't have time to do the analysis phase, think if you need it:

• If you're creating a quick and dirty prototype, chances are that you don't need analysis at all, since in all cases, you will throw away the source code later.

• If you're about to build a large scale website which will be maintained by other people for at least five years, spend time doing things in a clean way, even if the original delivery will be delayed: it's better to be late the first time than to have to rewrite everything from scratch two years later, after wasting hundreds of thousands of dollars on maintenance.

Answer 3

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

Analysis of requirements is very important to get acceptance of the final product. Not understanding requirements or understanding vague requirements does not lead to faster applications. Instead, this generally leads to delivering the wrong product fast. Look at this inequality:

Cost(Analysis + Implementation + Testing) ? Cost(Analysis + Implementation + Testing) + Cost(Analysis + Implementation + Testing) +...

I argue that the "?" is "<". Even if you replace the Cost with "Quality" or "Customer Confidence". This is based on my own experience.

Some people understand iterative development as deliver something and fix it later, but this does not work well in general. This is especially true with the complex software engineering cycle that today's software has to go through.

The idea behind UML and ER diagrams in general are mainly:

1-To make you think deeply about the problem without too much syntax, code, etc.

2-To make you document what you think precisely.

3-To make others understand precisely what you think, so that knowledge is shared.

4-To produce code when possible from the diagrams.

5-Get/Give a feel of the application complexity, so that project/cycle planning can be accurate.

If you have not practiced use case diagrams, class diagrams, ER diagrams, etc. you will be surprised how many questions will arise when you try to model. Some of these questions should be answered by the customers or the users of the application and if you don't ask those there is a good chance that you will deliver less than a perfect product. The other set of questions will turn into design decisions that you will make in a code-less environment.

One of the classical funny, yet close to reality, diagrams that shows the value of requirements is here.

In summary, diagrams (and requirements specifications in general) are not just pretty pictures and in most cases, they are not a waste of time. In most cases, customers may not think high of you if you deliver the wrong product. If your application is not trivial, consider modeling as a serious activity.

As for the 2nd part of your question, the order of producing diagrams depends on whether you are going to use Pure OO approach or Mixed OO and Relational approach where a class represents a physical table. In a design leaning towards an OO approach a Class diagram is required. In the later case, you can build an ER diagram, and depending on your toolset, derive the Class Diagram from the database and possible generate the ORM code.

Answer 4

It depends on the scale of the system, the size of the development team, and the revenue / resource ratio. You state that it needs to be scalable, robust, and fast. Those are 3 features that benefit from a bit of planning. Does that mean that you need UML and ER diagrams? Not necessarily, but if you need to communicate to a development team or need a record of decisions for your client they can be useful tools.

The question I often ask myself is, if you don't have time to do it right... do you have time to do it twice?

Sometimes simple and quick are better if it the purpose doesn't justify a more elaborate approach. But, if you haven't decomposed the problem well you may run into issues with performance or robustness. As you try to add features it may require a lot of refactoring which can cost time and if not supported by tests could lead to regression defects.

How much is poor design or lack of design altogether going to cost you over time as you try to maintain and extend it?

If at all possible, I would use an iterative approach releasing new functionality in a series of limited scope releases. Avoid unnecessary features in early releases and maximize the return on investment by delivering the most critical features first.

Leverage well tested frameworks and component libraries where you can to avoid reinventing the wheel.

UPDATED - per OP comment feedback elsewhere Only you know the circumstances around your situation. Is there a significant potential for legal implications if there are design or implementation problems? Will mistakes or design problems directly cost you money. (ie. is it a sales or investment tool) Will you experience indirect financial consequences (ie. will paying customers turn elsewhere or will opportunities be missed by downtime?)

Design as much as you need to be comfortable with your choices. Document that design only as much as you need to know what you are doing. The complexity of the system and your ability to visualized the solution are your limiting factors.

Answer 5

A couple of recent examples in my life:

1. We homeschool the kids. First year of homeschooling, and the log/portfolio process was being done on paper -- bad. I spent 3 days whipping together a activity tracking web application, and at the end of the school year, another 2 days on the WYSIWYG layout program and .PDF rendering software. I was ultra-focused on getting something working, so I did not do anything but think of end result, write UI's, and make them work.

2. A client with a tight budget needed a comprehensive web app. So I proposed that they allocate $1000 for me to work on the UI. So with record-setting speed, I spent 10 hours burning through dozens of UI pages with no focus on graphics, etc... Then a 6 more hours spent (by someone else) polishing my work, and had a complete application mocked up. The client can see the requirements are met, and provide comments accordingly, all for 2 days of work.

Your answer depends on if you actually know the requirements by heart or not. But in any event, I suggest you start with the UI (valid HTML+CSS), and go from there. Don't waste time on abstract design if you don't have to.

If it is a bigger project, then you need to document a lot up front, and think it through, because that will save you time.

Answer 6

As i said in a comment.. Dont worry about any of that. Even if you have created the best application in the world that does not guarantee its success... first, you need to put your time into developing your application, and then you need to finish it, hopefully with quantifiable and thorough tests. Whether you use a test framework or not doesnt really matter.. you need to get your product out there in a PROOF OF CONCEPT sort of fasion.

No matter how much time you put into it making it's foundation "solid", you're probably going to have to rewrite it anyhow.. in fact, if you need to rewrite it later on than that would imply that you successfully proved that you have a working and successful platform (if you write it and it doesnt work, that's a problem)..

so finish the product, get it out there and cross your fingers that it takes off.. there's a lot of great music out there that never was heard.. and there's a lot of great products that we dont know about..

so again.. build it fast and cross your fingers..

Answer 7

Draw the base design of your application. Next jot down all the things that you are going to put into your application.Forget about he UML's,ERD's if you are going to work alone that can be done at spare time. But important is Data Flow diagram (you need to make sure how the data flow is going to be).

Database design is going to change if you want to make it scalable,so just develop a basic working model.Don't bother much about the UI since your additional functionality will definitely going to change it.

Please do not change your mind on things that you have planned. Most of the time is lost when you start to realize that What if I do it this way. Once you are done get feedback from your client(users). Enhance your project with whatever needful. No matter how much you think your project is the best ultimately its up to the client(user) to decide it.

Answer 8

This is all a bit abstract because I don't know anything other of your requirements than scalable, robust and fast.

That said, I think you should take the time to identify potential performance bottlenecks and design intricacies that don't fall into the typical patterns.

An example of this would be if you think you need to perform some real time operation, do some quick figuring about the request rate you need to accomodate now and where it would likely go in the near future.

This might help you avoid needing to do a complete re-write for a relatively low up front investment.

Answer 9

I would not make diagrams for the upper layers of the application (views, controllers) since their are probably going to change a lot, especially in the initial, prototyping phase. Furthermore, there are dozens of frameworks for different programming languages that allow to implement these layers in a structured way.

On the other hand, in order to have a solid foundation for your application, I would advise you to at least sketch a class model or an ER model of the business domain and produce a database schema based on it.

IMO having a pretty clear understanding of the structure and operations of your application domain can make your whole development a lot more robust.

Answer 10

I think one important question is how fast is your application going to grow. If the application is going to grow slowly, I think you can spend some time thinking about future plans for scalability. If you expect that your scale will dramatically change (at least in theory), then you should carefully think about what would be the next steps require to scale the application.

Take into account that my advise is more focused on having kind of a contingency plan than actually implementing it. As others said, before spending time on scalability issues at full detail, you should have a minimum product for your clients. Also take into account, that the expected scale determines the possible steps. Some solution may be optimal for small-medium size application and may be impractical for large scale.

Answer 11

When I'm tackling these sorts of things, I tend to start from the User's perspective. What does the user want to do and how is the best way to let them do it. You will hear a lot of people say stick to the MVC paradigm, that's because it has been proven time and time again to be easier to maintain. Try fixing an issue where the same functionality is in dozens of files...

Getting back to the point though:

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

You should probably start drawing the user journey. This will tell you what pages are useful and perhaps where you make things easier for the user with simple tricks such as shortcuts. From this you should be able to ascertain the entities you need and persistence between pages versus any tasks that could be asynchronous (which will help with scalability).

Once you have the entities you can start programming. Hopefully, by this point you have a model that can be implemented incrementally in an agile manner. For (a very simple) example, Users, Blogs, Employment Positions, Companies. You can see that you must have a User before you can have User's blogs, employment positions etc. Then referring back to your user journeys, you can see that the most common task (and hence the first task) should be to create Users, then add Blog posts. Then you can add Companies and finally Employment positions to link them.

One last advantage to this approach is that your logic should be in small chunks (as you add it incrementally), aiding maintenance.

Answer 12

Spend your time on the thing that will contribute the most to your project's success and continuation. You already have a lot of conflicting goals: scalable vs robust, fast development vs robust, fast development vs high performance.

If you're developing this for a prepaying customer who is driving requirements, then keep them happy because nothing matters if the client stops funding your project or won't buy it at the end. I would use prototypes to get requirements and workflow nailed down before you really start doing anything. Those prototypes don't have to be robust or scalable, just demonstrations. Be sure to manage customer expectations while doing so.

Also, how many people are going to use your site? If it is unreasonable for joe public to use this tool and workload for the problem isn't tremendous, then scalability doesn't matter.

If you're developing this as a startup, then focus on what your application does and who your customers are. Something that isn't wanted will not get popular enough for scalability to matter either.

Answer 13

As per my understanding you are going through the initial level of designing and according to me this is the right time to govern your application's performance it doesn't matter which language you are going to use but you have to analyze lots of key things right now. As you said you want your application Scalable, Robust and Fast... that simply means that you need a very strong Design Pattern and i will rec-amend you to use MVC(Model View Controller) Design Pattern because as per me this Design Pattern will make your application Most Scalable and Robustness... This Model will let you segregate your Different layers from each other and easy to Handle them.. like Presentation Layer(for forms,VOs,Actions, requests), Service Layer, DAO Layer etc.. As we are talking about Web Application So, You must have a perfect arcitecture + Development Skills because when we are talking about web apps then look and fields like JSP or HTML or CSS can be modified very easily or I can Say Presentation can be Modified, Enhanced or Enriched easily but the most important thing is its Business Layer or View which is going to handle each and every request and may access Database as well requirement so Your Business Layer is the Key Layer which will enhance you application's execution time in simple words the difference between the request time and response time is completely dependent on how efficiently you have designed its Handler or Business Logic. So, deeply analyze the workflow of you web application and plan accordingly because this is the right time... and avoid using heavy or bulky images because they exhibits some delay during low bandwidth or network conjunction....

Thanks

Few Reference Links are as.. 1) FOR more about DESIGN PATTERNS : http://en.wikipedia.org/wiki/Design_Patterns

2) FOR more about MVC : http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns#Model-View-Controller_Pattern