Full life cyle of of an application

Recently I got an interview question like this:
Please describe conceptually what an application life cycle looks like.
My answer is:
1) Gather user��s requirement 2) Explore, analysis and design system architecture, select tools. 3) Software Architecture Design. 4) Finish coding 5) Unit Testing and performance tuning 6) Support customer.

Apprently it is not good enough, can somebody cast some light on
how to detailize the answer.
Thx
Pat

Well, this is just a guess, but so-called "iterative processes," such as the Unified Process or XP (extreme programming) are pretty much de rigeur in software today. The approach you described is closer to the traditional "waterfall" method, where requirements are set in stone at the beginning, and then simply implemented. By contrast UP, RUP and other iterative processes emphasize that development should be broken down into a series of short mini-projects called "iterations." Each iteration results in tested, working code that is a subset of the system's eventual functionality. Users are given an opportunity to react to a working (albeit incomplete) system early on, and requirements are continually revised based on their feedback. The point of this is that iterative processes allow developers to gradually "home in" on the the system that the end user needs rather than going through a full development life-cycle only to find in the end that the system is all wrong!
If you're interested in finding out more about this, I would check out JavaRanch's "Process: UP, RUP, DRUP, XP, etc." forum or the excellent book "Applying UML & Patterns" by Craig Larman.
Buzz
[This message has been edited by Buzz Andersen (edited October 26, 2001).]
[This message has been edited by Buzz Andersen (edited October 26, 2001).]

I think that you answered the question perfectly fine. Buzz has good input, but I don't think that your answer was wrong. From your post it sounds like your answer to the question was wrong in some big way, which I can't see. Maybe someone was trying to find fault with you and just used this question as the excuse.

This may be splitting hairs, but I think "technically" the answer is wrong; that is, I would interpret the question differently.
In my mind [i]application[/] lifecycle is how an application is used. Typically this includes such things as: startup, initialization, login, pause/resume, sleep states, cleanup, and shutdown. It can be further refined depending on the complexity of the system and level of detail. Examples of application lifecycles include applet lifecycle, servlet lifecycle, and EJB lifecycle.
The answer you gave was a development process, or development lifecycle.
Well, that's how I would intepret the quesiton, anyway.

--Mark

Christopher: I agree with you--I don't necessarily think Patrick's answer was wrong. I was just elucidating what I thought *they* might have felt was wrong with it.
Mark: That's a really good point. It never even occurred to me that they didn't say "application development cycle!" I guess that's the cardinal rule of interviews: listen!
Buzz

Originally posted by Patrick Wang:

My answer is:
1) Gather user��s requirement 2) Explore, analysis and design system architecture, select tools. 3) Software Architecture Design. 4) Finish coding 5) Unit Testing and performance tuning 6) Support customer.

Also adding to Buzz's comments about XP. Now a days I have seen quite a few people writing unit tests before coding. I am trying to get used to that.
Of course, most probably it was a trick question testing ur listening ability rather than testing ur SW Engg knowledge. They have so many to reject ... and if u clear all such trick questions there are always thoes quizes/puzzles ...

Originally posted by shashank bapat:
Of course, most probably it was a trick question testing ur listening ability rather than testing ur SW Engg knowledge. They have so many to reject ... and if u clear all such trick questions there are always thoes quizes/puzzles ...

I've got to disagree here. Assuming my theory is right as to what was actually meant, I don't think it was a trick question. Usually if they are going to ask you such a trick question, it would be about some programming trick, not about process. Chances are, he probably figured you didn't know to what he was referring, and simply took a guess. Personally, I would have repeated the question and made what I was asking for, clearer.

--Mark