|
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
|
|
|
|
|
PIEBALDconsult wrote: "My general rule is that design should be top-down, but implementation should be bottom-up."
I've ran into something similar in my own experience--I've come up with some pretty good solutions when the design specifications were done from the top down, and when the implementation was done from the bottom-up to meet those specifications. Generally, I don't introduce any patterns or any preconceived architecture until I can get the simplest prototype up and running (using standard structural programming techniques) and then refactor it and generalize it at various points until a design emerges.
It works for me in most cases, but the trade off in this case is that this approach assumes that you can pretty much refactor your way out of anything--and this might not be the best way to do things if you have a team that doesn't have much experience in refactoring. Without refactoring, the approach I mentioned above will quickly descend into a "Code & Fix" scenario, so overall, I would recommend it if you can guarantee that you can keep your code base relatively clean..
|
|
|
|
|
I don't know the meaning of "refactoring".
No, seriously, I have to find a definition of "refactoring".
Chances are, I do it, but I just don't know it.
|
|
|
|
|
|
Yes, I've come to the same conclusion over the years. In fact I've come to believe in a form a form of 'undirected' development sometimes known as z-programming. The concept is that you keep a proportion of your team busy all the time coding from the bottom up without any particular spec or goal, simply taking the existing set of low level facilities, be that APIs or COM objects or graphics primitives and combining in ways that seem like they might be useful, creating data structures and containers and algorithms that conform to best practices but don't have any particular application in mind. You do your design from the top down and create at least one empty shell style prototype which consists mostly of the UI of the product and any product specific novelties. Application development then becomes a process of filling in the functionality using the generic tools you've developed. One of the key things being no-one is allowed to reinvent for a specific app anything that's already available in the codebase for generic usage. You soon find if there's an area your z-programmers have been ignoring and they can be directed to concentrate on it. This does a number of things, it keeps programmer busy, it makes them write truly generic code, it allows them to concentrate on what they're good at and to be creative, it ensures that re-use ( a goal but seldom a reality ) actually happens.
This is all great for desktop application but if and how it might be applied to web based applications is still amystery to me 
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
