corelinux-public

Re: [Corelinux-public] Oops

[<t.r...@at...>]

I agree with your sense of heaviness.  In an ideal world 
the requirement originator would be the one to determine 
if a design/implementation fufills the requirements, 
however once the requirement is fully analyzed and 
specified any developer should be capable of designing 
and implementing to meet the specifications.

Tom
--
----------
			
> I was re-reading the documentation and I noticed that I wrote something
> along the lines of "A requirement is owned through to implementation."
> 
> Is this to heavy? I mean, I have received e-mails from people with a
> range of interest and experience but not necessarily across the board.
> Should I change this to be a more modular effort?
> 
> I know there are times when I feel up to Analysis and/or Design, and
> other times I want to follow the recipe and just put out some code.
> 
> ---
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> 
> 
> 
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public

Re: [Corelinux-public] Oops

[Frank V. C. <fr...@co...>]

> I agree with your sense of heaviness.  In an ideal world 
> the requirement originator would be the one to determine 
> if a design/implementation fufills the requirements, 
> however once the requirement is fully analyzed and 
> specified any developer should be capable of designing 
> and implementing to meet the specifications.
> 
> Tom
> --

I meant a more granular approach:

Someone does the requirement
Someone does the analysis based on the requirement
Someone does the design
Someone implements the design

Or one person can do analysis AND design, or...

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Oops

[Jim K. <jrk...@cs...>]

"Frank V. Castellucci" wrote:

> > I agree with your sense of heaviness.  In an ideal world
> > the requirement originator would be the one to determine
> > if a design/implementation fufills the requirements,
> > however once the requirement is fully analyzed and
> > specified any developer should be capable of designing
> > and implementing to meet the specifications.
> >
> > Tom
> > --
>
> I meant a more granular approach:
>
> Someone does the requirement
> Someone does the analysis based on the requirement
> Someone does the design
> Someone implements the design
>
> Or one person can do analysis AND design, or...
>

I like the granular approach myself, depending on the volume of work, it
might be nice to be able to delegate Requirements, Analysis, Design or
implementation to someone else.  This also allows flexibility in
accomodating different skill sets (as has already been mentioned).

-- Jim

Re: [Corelinux-public] Oops

[Frank V. C. <fr...@co...>]

----- Original Message -----
From: Jim Koontz <jrk...@cs...>
To: <cor...@li...>
Sent: Friday, January 14, 2000 1:04 AM
Subject: Re: [Corelinux-public] Oops


> "Frank V. Castellucci" wrote:
>
> > > I agree with your sense of heaviness.  In an ideal world
> > > the requirement originator would be the one to determine
> > > if a design/implementation fufills the requirements,
> > > however once the requirement is fully analyzed and
> > > specified any developer should be capable of designing
> > > and implementing to meet the specifications.
> > >
> > > Tom
> > > --
> >
> > I meant a more granular approach:
> >
> > Someone does the requirement
> > Someone does the analysis based on the requirement
> > Someone does the design
> > Someone implements the design
> >
> > Or one person can do analysis AND design, or...
> >
>
> I like the granular approach myself, depending on the volume of work,
it
> might be nice to be able to delegate Requirements, Analysis, Design or
> implementation to someone else.  This also allows flexibility in
> accomodating different skill sets (as has already been mentioned).
>
> -- Jim
>

Yeah. I won't be able to update the process document today, but I think
it is fine that anyone reading the mailing list understands that your no
longer tied to the "soup to nuts" time debt.

Here is a list of who is working on what, so we don't collide:

Jim - String
Frank - Remaining Structural Patterns

Anyone can check the Bug Tracking and Analysis/Design/Implementation
task lists to see who is working on what.

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux