Re: Full life cycle development

Responding to Rof...

Can someone please explain this term? I know it means requiremsnts
gathering, design, development and testing, but is there a specific
methodology/tool, like UML or PRINCE, or is it just the latest buzzword
that recruiters are using to mean "every stage of the design and
development process" - which any analyst/programmer worth his/her salt
has been fully aware of for years?

Basically I agree with Phlip (except for the Waterfall part) that this is most common view. Essentially it is a marketing term to describe some of the more egalitarian team-based shops.

When you hire a lot of superstars you get enormous productivity and high quality software. The problem is that there aren't any coolies to do the grunt work. [The classic Brooks Model (Mythical Man Month) of one System Architect thinking Grand Thoughts and directing ten minions doing the actual software.] Worse, maintenance is really where you need the superstars because it requires more effort to do right, but the superstars regard that as boring (i.e., they want to move on to New Things).

The solution is an egalitarian team-oriented shop where everyone does everything in roughly equal measure and the team as a whole owns the product throughout its life. The fallacy is that the maintenance cycle tends to be much longer than the original development cycle so the superstars are stuck doing the boring stuff too long and they go away anyway.

[There is a way around that, though it is rarely practiced. If one starts a second team on developing the next generation of the application just when the first team releases the product, one has fixed term obsolescence so that each team "owns" the maintenance cycle only until the other team releases its new generation of the product. This is actually a very attractive solution to the Legacy Problem, but it has a high startup cost.]

I should point out that, like many software terms in software development, it has multiple meanings. Another interpretation is that in the original development one "designs in" things like testability, maintainability, and extensibility. In theory, then, subsequent phases of the product life cycle (e.g., test, maintenance, and extension) will be easier to do.

Specializing that view a bit, the term can also be interpreted in a purely marketing sense of a Product Line Architecture (PLA). A PLA defines a planned sequence for introducing related products that are major variants on the original. In that context the development of each product is done with full expectation (i.e., designed-in extensibility) of the subsequent variants, hence the term.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Surprise in array concatenation
    ... >> Enumerated types, as presently designed, are not extensible. ... Ada types should not be a consideration during design. ... byte code, as is the case with Java, extensibility would stillbe at ...
    (comp.lang.ada)
  • Re: Why no one operating system is wrtten in an object language...!!!
    ... "The XO 2 Real Time System and Framework XO 2 is an object oriented, ... extensibility and abstraction." ... Active Objects are ... "The Active Object System Design and Multiprocessor Implementation" ...
    (comp.object)
  • Re: Comparison and criteria of design quality
    ... extensibility requirements - which is something not immediatly associated ... must also list the ways in which that design explicitly allows for future ... Obviously designing the first in a remote context is wrong, ... understanding and *documenting* the intended usage context rather than ...
    (comp.object)
  • Re: defmethod with multiple parameters
    ... Thomas A. Russ wrote: ... > And this then also gives you a better design for future ...
    (comp.lang.lisp)