|
I don't get it. Why are you so hung up on terminology? All of these terms get used for different things by different people, and the only thing that's consistent is that none of them are a panacea for producing a quality product on-time and under-budget. It's worth remembering that all of these concepts are applied upon tasks that are incredibly malleable, and can generally be accomplished in any number of ways by someone with skill and understanding.
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
you are not getting my point. I know it depends upon individual which method he wants to follow. I am just asking if i say incremental development, does it also refer to extreme programming or agile methodology. Or is it completely different.
Like i can say waterfall model and incremental model is completely different approach. And i know difference between them and here i just want to know the difference between incremental development and extreme programming(if there is any).
I hope you got my point.
thanks
|
|
|
|
|
Julia4u wrote: I know it depends upon individual which method he wants to follow.
That's not what i wrote.
Julia4u wrote: I am just asking if i say incremental development, does it also refer to extreme programming or agile methodology.
What makes you think there's a 1-to-1 mapping here? What if it's a component of both methodologies? And/or other completely separate methodologies? And things that aren't formal methodologies at all? "If i say 2x4, does that also refer to a house or a shed?"
Julia4u wrote: Like i can say waterfall model and incremental model is completely different approach.
You can say waterfall doesn't include incremental development. You might be wrong though. Nothing stops you from combining the two.
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
Let's say for instance, the development was done in modules. Each module was done seperately with different time scale n etc.and later they were combined together.
So after looking over the development method..can i can say this "I have used agile methodology, and xp is a type of agile methodolgy which includes incremental development. And this is what i followed"
Please comment on above.
Thank you very much dear shog 
|
|
|
|
|
Julia4u wrote: So after looking over the development method..can i can say this "I have used agile methodology, and xp is a type of agile methodolgy which includes incremental development. And this is what i followed"
You can say it. Depending on who you're talking to, they might believe you. But there's a lot more to agile than incremental development and orthogonal (modular) design. If you were talking to a gung-ho Agiler, they probably wouldn't buy it, pointing to things like trying to keep a working system available in all but the earliest stages of development, or the importance of bringing customers in early and often to collect feedback.
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
ok i got you shog.
You are a life saver.
Thank you very much shog. Where are you from ?
|
|
|
|
|
Shog9 wrote: If you were talking to a gung-ho Agiler
of course the real test is how many people notices the difference in the same paragraph between "agile" and "Agile".
I program agile, not Agile, because my business is agile; now I could have done Agile, but that wouldn't be as agile in an agile developement, because Agile isn't agile enough for truly agile environments. BTW, anyone feel free to quote me to your professor if you don't mind him assigning you extra revenge work. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
|
|
|
|
|
El Corazon wrote: I program agile
Do you do stretching exercises first?
Jon
Smith & Wesson: The original point and click interface
|
|
|
|
|
stretch for coffee... stretch for login to CP... yup!
|
|
|
|
|
Shog9 wrote: the only thing that's consistent is that none of them are a panacea for producing a quality product on-time and under-budget
Exactly. I think some of these terms were really geared to non-technical managers who have a clouded illusion that having a quality product and coming in under budget and on time is a possible feat.
In my 15+ years of programming/developing, I have never heard of a high quality product be on time and under budget together.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Basically, it boils down to this, Vista is the birth of a new version of Windows. Natal, as you may know, refers to a birth. Increment means go to the next. So Incremenatal Programming is done for Vista, while we continue to use XP for Windows XP. Good luck on the exam.
Jon
Smith & Wesson: The original point and click interface
|
|
|
|
|
Julia - I'm going to give you one piece of advice here. Stop thinking of methodologies as discrete items that actually mean much. Frequently, these methodologies are just subtle variations of another methodology, with new terminology thrown in to hide the fact that there's not much new in there at all. In my company, we don't practice methodologies. We design and develop software using the quickest methods we can that include full documentation and development consultation. Blind adherence to methodologies tends to get in the way of actually delivering software.
|
|
|
|
|
Dude 
Julia4u wrote: No google is not helping me out.
led mike
|
|
|
|
|
led mike wrote: Dude
Julia4u wrote:
No google is not helping me out.
It depends what she was putting in. If she wanted information about incremental versus iterative development and put in "nice red shoes" then she was never going to get help.
|
|
|
|
|
Pete O'Hanlon wrote: It depends what she was putting in
Yes, obviously she can't figure out to put in the same words she put into her post here. That was my point. 
It seems to me that anyone wanting to know anything about Agile and has not yet found Amblers site just isn't looking.
led mike
|
|
|
|
|
Hell - even Wikipedia has an article or two.
|
|
|
|
|
Hi Everyone,
So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design.
At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works.
So... what questions do you ask yourself when reviewing a design?
|
|
|
|
|
I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
|
|
|
|
|
Pete O'Hanlon wrote: I generally ask questions like:
What problem is this attempting to solve?
Does it solve it?
What other ways could this be done?
Are they easier or a better fit?
Is it necessary, or are we just adding fluff?
Is this maintainable?
And the questions to ask at the end:
What's missing?
How do we accept this (what are the acceptance criteria)?
And the question after the question at the end:
What's for lunch?
|
|
|
|
|
Along the lines of what Pete posted you can look at the Agile and RUP[^] analysis to see those and more considerations along with suggested timing of when questions need to be asked and asked again. Be sure to check out the links in that page, it's just a starting point.
led mike
|
|
|
|
|
Does it satisfy the requirements of a good user interface (assuming it ultimately leads to software someone uses and not a machine or other software).
I tend to think about the requirements and the user experience first, even mock up a UI on paper. Try to eliminate as much work or complexity on the part of the user as possible so that the user can focus on accomplishing *tasks* rather than manipulating data.
Once I have that decided the rest is easy because it simply has to meet the criteria of satisfying the task oriented design decisions.
If you start from the bottom up on the other hand then you are faced with uncertainty at every level and ultimately could end up with a very computer programmer oriented design but not a user friendly design. (i.e. the end user get's exposed too much to the inner workings of tables and databases and how the computer and software works instead of simply being able to view it as a machine that helps them accomplish the tasks they already know and understand).
This is the essential pivot point between what users percieve as "good" software and what users perceive as "bad" software.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying."
- David Ogilvy
|
|
|
|
|
I was just commenting on this[^] article, and said:
"My general rule is that design should be top-down, but implementation should be bottom-up."
Has anyone else come to this conclusion?
Or have reasons not to do it that way?
|
|
|
|
|
There is no cookie cutter rule or process or whatever that I can tell. The needs vary from project to project and even more so from company to company. If there is anything close to a cookie cutter map of project activities it would be this one.[^]
PIEBALDconsult wrote: My general rule is that design should be top-down
That doesn't really work with large systems having a relational database back end which is very common. Starting with the model and designing off of that for the different sub systems of the system is normally the way it works.
led mike
|
|
|
|
|
led mike wrote: Starting with the model and designing
That would seem to imply that you've already begun implementation -- creating the database.
Ideally, one of the last steps of design would be defining the database schema, then the first step of implementation would be creating the database and work up from there.
In many cases (including my current project), this can't really be achieved because the system accesses third-party databases, but there may still be the need to define views and such. This is true of any off-the-shelf product to which one must interface.
|
|
|
|
|
First I reiterate, my example is for a large business application. This means different project types could vary greatly from what I am saying.
PIEBALDconsult wrote: That would seem to imply that you've already begun implementation -- creating the database.
No, you start by modeling (design phase) the model. So..
PIEBALDconsult wrote: Ideally, one of the last steps of design would be defining the database schema,
Yes, I am saying from my experience one of the first things you do is model/design your model and part or all of that can end up being implemented in one or more database schemas.
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
