How do you manage development of your web based application projects?

Answer 1

For me the conceptional separation of Structure, Presentation, Behaviour in both the front -end (HTML - Structure, CSS - Presentation, Javascript - Behaviour.) and the backend (RDBMS- Structure, REST - Presentation, REST to HTML and other code - Behaviour) is more important then the actual choice of technology.

With this separation in place it's always easier to extend and support more output documents, presentations, functionality.

As for development lifecycle quite often i don't get to code before the project is fully documented. In my last project i started coding in the beginning of 2008 the first draft of the project functional description was started beginning of 2006!

In a nutshell this is our development life cycle at work.

1. functional design - what are the needs?
2. technical design - how are we going to implement the needs?
3. Cost assessment. - make an offer based on the FD and TD.
4. prototype. - Implement feauture in basic form to see if its viable.
5. develop. - fill out all the details.
6. test - done troughout development but too always double check.
7. release - release feature.

Interesting to see how others do it, nice q!

Answer 2

Manageing web based projects is no different from managing any other development project.

Get a sponsor.

Define Scope.

Identifiy Stakeholders.

Agree Requiirments (functional and non functional).

Define the architecture (including technoilgies and tooling).

Iterate over: Define detailed design. Develop. Test. User Test. Until sponsor is satisfied.

Deploy Appliction.

Appart from the tooling it should not be any different for a Web Based application.

Answer 3

When you think about it developing Web applications doesn't differ too much from developing Platform specific applications. The common ground I'm trying to point out here is that there is the following:

• Development Team
• Management

There are more roles in a development and in selling the software, but these are the only two important at the start.

What you want to focus on, depending on the size of the project, is the documentation. If the project is as big as let's say StackOverflow you might want to put 1 - 2 months pure documentation planning before you even concider starting the development.

There should in my opinion be three documents: Analysis, Requirements and Design. These three form a very nice triangle and are important for the further work.

Meanwhile the documents are formed the management team needs to take on some resposabillity too, the forming of the documents aren't only made by coders and uml folks, the management team needs to sit down with the customer, users and other parties that might be interesting to find common interests which should weight more in this documentation.

Which development process you have selected to work with is in this stage not important, this only becomes relevant when the development starts, this is my opinion anyways, since i like to work with Scrum and that doesnt really work on the documentation part because there are far to many variables to count the time on each sprint.

Now, you got your documentation, the coders need to select a language, these are the important parts to take in mind:

• What is the Deployment System Specifications?
• What languages are possible to use?
• Which language does the customer require, if none, which does the developers preffer?

Once the language is selected you can start the development process. I won't go through a complete development process because they are very different. But set up good points, on date X function Y needs to be finished and have at least Z unit tests to provide solid information about when it fails, why it fails and when it succeeds and why.

The management team in this stage is "only" there for supporting developers, giving them what they need to be comfortable in their work space. When the development comes to the stage when it's ready to deploy or tested, the management team needs to find a user base to test it and set up the appropriet methods for it.

Good luck with your project.

Answer 4

It would be easy to get bogged down in XP vs. BDUF arguments; here's a bullet list of issues to be addressed either way.

1. Define the goals: What is this application (or added/changed set of features) going to accomplish for the user?
2. Quantify the goals: Asses the value of those accomplishments, from the perspective of the user.
3. Clarify the goals: Write use cases, user stories, ... that clearly describe the individual interactions the user has with the product.
4. Prioritize the goals: Order the cases with heavy participation by the user based on delivered value and logical dependencies.
5. Attack the goals: Pick and implement the smallest set of cases that:
   • can be built and delivered with user-visible value,
   • keep the entire team engaged (or else let some parts of the team work on something else),
6. Reconcile the goals: Make sure that any inconsistencies, re-thinking, "oh no!"s, etc, from step 5 are cleanly folded into (reconciled with) the entire code base before proceeding. The codebase should always look as if "it was intended to be that way" by the end of the iteration.
7. Reassess the goals: Based on accomplishments to date, start the next iteration:
   • If you're trying to be "agile", start the next iteration as close to point 1 as possible.
   • If you're contract-driven or BDUF-oriented, start the next iteration at point 5.

That's the "meta-process"; the technical process requires brutally aggressive separation of model from business logic from presentation, both for maximum flexibility and for immediate testability throughout development. Use of TDD (again, independent of where you are on the XP-vs-BDUF scale) supports high quality and confidence throughout, as well as more accurate assessment of progress.

Constant open communication and feedback throughout the project, among all developers and other stakeholders is crucial! I've seen more project drama due to mismatched components, unmet expectations, unrealistic deadlines, off-target effort, etc. than other causes; I lump these together because, at root, they are all about poor (or subverted) communication.

Answer 5

How we're working -- focused on your topic list.

• Software engineering practices.

  • We use "mostly SCRUM" approach. We have daily stand-ups (via chat, since we work in different locations). We have a burndown chart which is our "todo list". Partially the todo list is user requests, some of it is bug fixes and enhancements, some of it is a list of ":todo:" comments in the code.

  • We're mostly TDD. Almost every method of almost every class has a pretty complete suite of tests. Not every logic path. Not every method of every class. Some things can be "tested by inspection" -- the code is so simple that we don't spend a lot of time on it. However, when we do maintenance and bug fixes, we tend to add a fair number of tests.

• Modeling. We use Python/Django, which includes an ORM layer. For our persistence layer, model comes first -- almost purely OO, but with a few nods to the ORM layer and the relational model that implements it. For other OO components (view functions and the supporting libraries, it's purely OO design in Python.)

• Architecture. Apache handles static requests and routing to Django for dynamic requests. Django/Python implements the app. MySQL is the database. Note that we will have scalability issues and will have to introduce Squid and Wackamole to handle the peak request load.

• Security. We have a few public web pages. Most of our application is secured via SSL and a VPN (sounds like overkill, but they address different threats). Additionally, all pages with interesting data require authentication and specific authorization against the data elements. The Web Services requests use password digests.

• Technologies. Python, Django, JSON, XML, Web Services, SQL.

• Web Services. Yes. Most requests have two forms: Web Services and HTML. The HTML side has a bunch of additional requests to handle navigation and convenient presentation. The WS side has just the core resources. We use REST with the payloads in JSON.

• Testing. TDD.