Forcasting PEP consumers [was]: [snip] Event Planner Project [was]Re: Event Planning Project

[plug-devel@lists.PLUG.phoenix.az.us]

I confess, this will be my first Open Source project...  But how do you manage
without at least UML arch and class diagrams...  I can see how good API docs,
with good class diagrams could replace sequence diagrams, but true XP and RDP
seemed like prototyping only sort of things...  Perhaps I am too affected by
getting a business degree in computers ;)

I will defiantly look at the links you provided, this should prove to be quite
the leaning experience :)

We used to do a lot of rapid development where I worked (Yes as a tech ;)  but
it only seemed to lead to apps that were so poorly documented that it was easier
to rewrite a module then alter it to fit a new parameter. . .  But I promised to
be more well informed by the end of the weekend :)


Thanks again for the links :)




Quoting Joseph Sinclair <plug-development@stcaz.net>:

> Bryan,
>     We most certainly will not be doing any of the first 18 things in 
> your list, and the remainder will be considerably smaller than you're 
> thinking.  The reason being that it turns out they aren't a good idea in
> 
> many cases, including, I think, this one.  For a LOT of information 
> regarding what is wrong with heavyweight methodologies (What you have 
> here is a list of the artifacts produced by heavyweight methodologies,
> 
> mostly large-scale RUP) take a look at www.xprogramming.com, 
> www.extremeprogramming.org, agilemanifesto.org, and 
> alistair.cockburn.us/crystal/crystal.html for a small sample of 
> information on lightweight methodologies.
> Take a look at the Apache projects, or Eclipse or Debian, or a host of
> 
> other open source projects, you will be very hard pressed to find much,
> 
> if any, of the artifacts in your list, and (nearly)all of those projects
> 
> may be considered highly successful in the open source community.  Open
> 
> source doesn't work well with heavyweight methodologies, so it's 
> extremely rare to see them put together.  I'm hoping to see a 
> lightweight/agile approach used here, as it provides the disciplined 
> framework needed for successful results, while avoiding the heavy 
> overhead that would kill the project.
> 
> Bryan.ONeal@asu.edu wrote:
> 
> ><<SNIP>>
> >
> >
> >As for a real project does that mean we will be doing:
> >
> >Executive Summary	
> >Project Description
> >Project Objectives
> >Project Scope
> >Project Deliverables
> >Project Schedule
> >Business Analyses	
> >System Architect
> >Use Case Diagram
> >Class Diagrams
> >Class Relationship Diagrams
> >Sequence Diagrams
> >Database Table Designs
> >Package Diagrams
> >Network Model Diagrams
> >Test Plan and Test Results (On each phase)
> >Post Mortem Review (on each phase)
> >Required Support
> >Project Documentation
> >System Documentation
> >User Manuals
> >Training Manuals
> >Maintenance Documentation
> >System Implementation	
> >Application Installation Instructions
> >Etc. ?
> >
> >And all the other goodies that make both a project both successful and
> a PITA :)
> >If So I believe we could really do something good and that will be
> very
> >successful :)  If not it could still be interesting, but I would have
> far less
> >faith in its survival.
> >
> ><<SNIP>>
> >
> >  
> >
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>