Wednesday, December 05, 2007
Sunday, October 14, 2007
Tuesday, October 09, 2007
Wednesday, March 21, 2007
any single software development model would be perfect
but they are not. IMHO each and every software development has issues. Of course there is no such thing as a "fits all" model, but it would be nice to set up some kind of general guideline for how a modern software project should be run.
For starters, most of us know that the Waterfall model (look it up on Wikipedia) is flawd by design, but it has one great thing: the focus on the requirements specification. Let me explain what i mean: let's say i'm a contractor, I'm trying to set up the definition of what i need do deliver before the project is considered as finished, so I can get paid. A good requirements specification would do exactly that. Working with iterations on requirements as with some agile models doesn't allow you to know exactly when you're done. Imagine the customer being pissed off because he considers that you didn't fulfill your contractual obligations, he/she probably will stop all payments until the issues are resolved.
What I'm suggesting is just as programming, use concepts from different models, and create something new, a bit more generic, but with extension capabilities.
For instance i would choose to have some solid requirement specifications, with the possibility of having sets of requirements specifications, such as "base functionality" and "extra goodies".
After that It would be nice to do some design - also a concept "less agile" according to some people. In a presentation of TDD I've heard the phrase "We're doing 'just-in-time design'". Good for them, but I like to have a structure to work with, even if the need for redesign appears in a later stage. "Just-in-time" design might be good for people with tons of experience, because they already know what the application structure should look like, and what the pitfalls are.
Speaking of test driven development .. A very nice concept, only where do you stop when designing your tests ? The combinations could be endless, how much time do you spend on it? should you be designing strict tests for business logic, and less strict test - or no tests - for the rest of the application ?
Productivity and reliability often have less priority than cost, but where do you draw the line ?
... to be continued after lunch
Scrum seems to be having a try at this general method approach, and specifies some really good aspects, such as the backlog, and the burn-down chart, but having 3 types of backlogs brings the classical time vs cost issue to my attention. How much time is needed to maintain these 3 backlogs ? wouldn't a classical requirements document and a simple backlog be enough ? (or better) There is nothing about testing mentioned in Scrum.
http://en.wikipedia.org/wiki/Feature_Driven_Development is another method that attempts to combine "a number of industry-recognized best practices into a cohesive whole" as cited from Wikipedia, but I think it's a bit loosely specified.
to be continued
For starters, most of us know that the Waterfall model (look it up on Wikipedia) is flawd by design, but it has one great thing: the focus on the requirements specification. Let me explain what i mean: let's say i'm a contractor, I'm trying to set up the definition of what i need do deliver before the project is considered as finished, so I can get paid. A good requirements specification would do exactly that. Working with iterations on requirements as with some agile models doesn't allow you to know exactly when you're done. Imagine the customer being pissed off because he considers that you didn't fulfill your contractual obligations, he/she probably will stop all payments until the issues are resolved.
What I'm suggesting is just as programming, use concepts from different models, and create something new, a bit more generic, but with extension capabilities.
For instance i would choose to have some solid requirement specifications, with the possibility of having sets of requirements specifications, such as "base functionality" and "extra goodies".
After that It would be nice to do some design - also a concept "less agile" according to some people. In a presentation of TDD I've heard the phrase "We're doing 'just-in-time design'". Good for them, but I like to have a structure to work with, even if the need for redesign appears in a later stage. "Just-in-time" design might be good for people with tons of experience, because they already know what the application structure should look like, and what the pitfalls are.
Speaking of test driven development .. A very nice concept, only where do you stop when designing your tests ? The combinations could be endless, how much time do you spend on it? should you be designing strict tests for business logic, and less strict test - or no tests - for the rest of the application ?
Productivity and reliability often have less priority than cost, but where do you draw the line ?
... to be continued after lunch
Scrum seems to be having a try at this general method approach, and specifies some really good aspects, such as the backlog, and the burn-down chart, but having 3 types of backlogs brings the classical time vs cost issue to my attention. How much time is needed to maintain these 3 backlogs ? wouldn't a classical requirements document and a simple backlog be enough ? (or better) There is nothing about testing mentioned in Scrum.
http://en.wikipedia.org/wiki/Feature_Driven_Development is another method that attempts to combine "a number of industry-recognized best practices into a cohesive whole" as cited from Wikipedia, but I think it's a bit loosely specified.
to be continued
Subscribe to:
Posts (Atom)