This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This is my first post in this forum. I've picked up on some core Java/J2EE technologies and am now ready to start putting them to practice in a full blown project.
Myself and my two partners have come up with an idea for a large scale web site which we would like to build on a J2EE platform.
Our site will mainly be based around our users. Something of a social networking site for a very niche group of individuals.
We have a lot of ideas but we're not sure how to start putting things together in an organized way. I have very little experience in RUP, XP, Agile, or the other methodologies since I have mostly been involved in the testing or deployment phases of projects in my professional career.
I know our first step should be defining our requirements, but I'm unsure of what document format we should use, diagrams/models necessary, etc. Also I want to follow the process most appropriate for a small team.
A few suggestions: 1. Keep your modeling efforts simple. See Agile Requirements Best Practices. 2. If you think you'll have a lot of pages, then you should consider a UI flow fiagram to "map out" what your site will look like. 3. I'd consider drawing UI screen sketches to design your pages. 4. Some sort of understanding of how people are going to use your system is critical to your success. Consider informal use cases for this. Many people get hung up on use cases because they go into bureaucratic documentation mode and create overly detailed formal use cases. 5. Implement your system in URL=http://www.agilemodeling.com/essays/changeManagement.htm]priority order[/URL]. 6. You don't need to identify all the details up front. Get the high level idea in the beginning and then model storm the details on an as needed basis.
Originally posted by Karthik Hariharan: I know our first step should be defining our requirements, but I'm unsure of what document format we should use, diagrams/models necessary, etc. Also I want to follow the process most appropriate for a small team.
I prefer the XP process, especially for small colocated teams. For requirements, you could try story cards - I like how dynamic and involving they are.
You could take a look at the book "Extreme Programming for Web Projects". I don't know how good it is, just sounds like it might be appropriate for your situation...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Aug 14, 2005
I like the idea of using the extreme programming methods to get started. We really want something with fast iterative development (since there's only three of us).
Do you have any sample user stories? I just want to have something to guide one of my partners so she knows what type of end result to produce.
If it is gonna be large scale(as you are expecting), it will sure need some thoughts into scalability in the future.
In the web world, scalability can not be delayed into a later release cycle; because of value proposition the usage or amount of traffic may spike if the idea clicks very fast. If the site is not able to serve those spikes, the value proposition will fade real fast(who ever putsup similar themed site with better scalability will win).
Example: Espn fantasy football in recent weeks. I have a feeling almost 50% of this years users will opt CBS because of the initial hiccups they faced in the first week of this year's football season.
Yes scalability is definitely an issue we are trying to keep in mind. That is one reason why I want to make sure we do everything right from the start.
Unfortunately, I have very little experience in the design phase of getting something like this started (most of my experience has been in the testing/performance analysis). This project is partially a way for me to fill in the gaps in my software lifecycle knowledge.
What books would someone recommend that outline the steps for taking on a project like ours where extreme programming/agile methology would be used?
Originally posted by Karthik Hariharan: Yes scalability is definitely an issue we are trying to keep in mind. That is one reason why I want to make sure we do everything right from the start.
Karthik, don't fantasize about getting everything "right" from the start. History has shown us that this just doesn't happen except on the most trivial software projects...
Originally posted by Karthik Hariharan: Unfortunately, I have very little experience in the design phase of getting something like this started. [...] What books would someone recommend that outline the steps for taking on a project like ours where extreme programming/agile methology would be used?
My first suggestion would be to not think about phases. The whole point about iterative and incremental development is to recognize the fact that waterfall doesn't work--we can't plan ahead for 12 months and still hit our target reliably. Instead, start small and reflect often.
In your case, with the scalability worries in mind, I'd suggest starting writing performance test scripts early on in the project so that you know as soon as possible if some parts of your web application exceed the performance targets they've been allocated. Otherwise, you'll be analysing your designs to death without really knowing what's good enough and what isn't.
This is not to say you shouldn't make some initial architecture decisions in the very beginning. Just don't try to come up with a "complete" design all at once.
Lasse is making an important point. The preferred way of handling risks in an Agile way is to defer decisions until the last responsible moment, by keeping options open as long as possible. The earlier you settle on a decision, the less information you have at hand, the greater the risk that it's the *wrong* decision. Especially feedback from running tested code is vitally important to assess what a good decision should look like.
So what you probably should do is exploring your options early, but don't decide on one but develop in the system in a way that allows you to switch between them should it become necessary. Start with a system that doesn't directly take scalability into account, but which won't make it to costly to add one of the solutions later. For this it often suffices to use a simple, but strongly decoupled design that can easily be refactored. A strong automated test suite is vital, too.
Joined: Jul 11, 2001
Originally posted by Karthik Hariharan: What books would someone recommend that outline the steps for taking on a project like ours where extreme programming/agile methology would be used?
If I understand correctly, you are mostly concerned about how to come up with a good design? In that case I would highly recommend Robert C. Martin's "Agile Software Development - Principles, Patterns and Practices".