• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Life Cycle

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure which forum this should be in, so I stuck it in here. Does anyone have a good guide as to the steps you should follow when developing new applications?

I know first is to gather requirements, but now that we've done so we aren't exactly sure what is next. Previously I've built out prototypes at this stage to kind of verify requirements and based on these built my database and then my presentation layer followed by any methods called from my presentation layer to access the database.

Anyone else have any good material or suggestions for how to progress after you've gathered requirements?

Thanks,
Scott
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I think you have illustrated the steps in brief.
I dont have any boklet on this. But few tips...

Think you should have identified the technology u want to go with.
Now concentrate on developing a POC (proof of concept) to ensure that U can develope the application based on the given requirements using the technlogy chosen. Simultaneously start working on database stuffs. This will be a critical stuff and will require good brain stroming sessions with co-workers. Finalise the database.
Start the design. Prepare a generic framework. Mostly common dynamic stuffs and common operations will be captured in framework. A good Design will take care of most things or rather hide most things from developer and expose only needed classes/objects. Hide and provide interfaces whereever possible.
Start working on the objects that you will use for each module.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many schools of thought on this. There are many prominent supporters of agile methods -- those development methods that emphasize iterative development, constant customer feedback, lots of developer testing, and deemphasize the notion of a "phase" and the notion of "Big Design Up Front" (BDUF). I'm an agilist myself, as are many of the Ranch's staff.

But as I said, there are many different schools of thought. I'm going to move this thread to our Process forum, where this question will be right at home.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally, I very much like XP - you can get a rough overview with links to more detailed explanations about the XP lifecycle from http://www.extremeprogramming.org/map/project.html

When following XP, you would next create a rough release plan, guided by perhaps some architectural prototyping to get better estimates for the risky parts. That probably shouldn't take longer than a few days.

Then you would start your development iterations. In my experience, the best iteration length is one week. In every iteration, you implement a handful of the highest priorities features for the system (for that you need to break down the features into rather small chunks, which is a Good Thing TM), end to end. You only build the parts of the architecture (framewors etc.) that are necessary to support those features.

The goal should be to have at the end of every iteration a running system that you can demonstrate to the Customer and shows him that the most important things (to him!) are working. If the Customer likes, he should be able to get a new system into production every couple of iterations.

How does that sound to you?
 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ilja, one week iteration length is too short for highest priority items(it may be complicated task).
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

one week iteration length is too short



Every single person says that the first time they hear it. Many are convinced otherwise in short order. The trick is to give yourself small tasks (stories) that can be built and tested. The "item" might not be complete in one iteration (and that may make you ask next about our definition of "iteration") but the part that is built and tested is positive progress.

If you try this style start with a longer iteration if you must, but look back after a few and see what's stopping you from going shorter.
[ April 24, 2006: Message edited by: Stan James ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by kri shan:
Hi Ilja, one week iteration length is too short for highest priority items(it may be complicated task).



If your highest priority items cannot be implemented in less than a week, I would strongly advise to break them down into smaller parts. There are at least two reasons to do this:

- big features are much harder (if not impossible) to estimate. If you don't break them down into smaller chunks to estimate, you can be quite sure that your estimate is *way* off.

- a big feature invariably consists of parts that are more important, and other parts that are less important. Breaking it down into small chunks allows you to schedule those parts seperately, and thereby providing more value to your customer earlier.

It takes some practice, but we've found that it's almost always possible. We are six developers working on a one million lines of code system now for years, and we find that any Story (how features are called in XP) larger than 16 person hours constitutes an increased risk.

http://xp123.com/xplor/xp0512/index.shtml might give you some ideas.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by kri shan:
one week iteration length is too short for highest priority items (it may be complicated task).


You do work 8 hours a day, don't you? And you do have lunch some time during the day, don't you? And you still get small things done every day, right?

The trick is, as Ilja and Stan mentioned already, to simply make sure that those tasks that you do complete within a one-week iteration are of production quality and, as far as possible, a cohesive piece of functionality that can be built upon or even used by the end users as it is (even if it's only a subset of the full feature).
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic