EPP/PEP Sugested task list

[Trent Shipley]

On Friday 2005-03-25 15:05, Bryan.ONeal@asu.edu wrote:

<snip contents=3D"all"/>

> Any thoughts, is this too complex?

NOPE.  Way Too Simple.

I have combined the previous post in this thread with another one by Derek.

I build the list in OpenOffice.org writer.  Let me know if you want the=20
original posted to my site.

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Event Software Integration Project Plan (Draft)

[NBB!  This plan, with contributions by Bryan, Derek, and Trent iterates ov=
er=20
customers or sub-projects rather than Joseph's preference for the outer=20
iteration loop over a master architectural plan.]

Phase 0: Foundations=20

 1 Recruit core volunteers
 1.1 Coders
 1.2 Para-Programmers

 2 Overarching project vision statement

 3 Initial project life cycle document


Phase I: PLUG Installfest Automation

 0 Pre-project
 0.1 Find preliminary project manager (Joseph)
 0.2 Recruit interested parties
 0.3 Find meeting space
 0.4 Schedule meetings
 0.4.1 As-needed versus regularly
 0.4.2 Manager responsible for agendas
 0.4.3 in person or virtual
 0.4.4 Stand up versus sit down if in person

 1 Scope
 1.1 Solicit User Input
Get a list of features from the "users" [PLUG/AZOTO stakeholders] to find o=
ut=20
what it is they need.  These do not need to be in great detail or exhaustiv=
e,=20
but general in nature. ([Derek] would limit this first pass to no more than=
=20
50 items.  He suggests Alan would be a good person to handle this.  Trent=20
thinks it must be Joseph's job.)
 1.2 Produce bullet list of features from above. =20
 1.3 Describe user requirements (Short story card)
Things like needing =E2=80=9CDate Record Input=E2=80=9D or =E2=80=9CDate La=
st Record Retrieval=E2=80=9D
 1.4 Project scope document (one paragraph to two pages)

 2 Shop versus Build (Shop is BETTER)
 2.1 Shop
 2.1.1 Look for FOSS projects with similar overall function
Review scope and search sourceforge, freshmeat, etc for projects with simil=
ar=20
functionality. Bring list including url and pertinent information back to=20
group.
 2.1.2 Look for FOSS projects that meet included functions
Review feature list and search sourceforge, freshmeat, etc for components t=
hat=20
meet specific requirements.
	For example if a requirement is a standing event calendar look for compone=
nts=20
that make creating calendars.

 2.2 Build (unless found by shopping)
 2.2.1 Pre-Build Decisions (Design)
 2.2.1.1 Determine license that will be used
 2.2.1.2 Determine who holds copyright
 2.2.1.3 Determine targeted/supported hardware platforms
 2.2.1.4 Determine targeted/supported logical architectural topologies
 2.2.1.4.1 Stand Alone,=20
 2.2.1.4.2 Static Shared
 2.2.1.4.3 Enterprise
 2.2.1.5 Abstract Data design (interacts with program design)
 2.2.1.5.1 Determine required data
 2.2.1.5.2 Determine desired stored procedures
 2.2.1.5.3 Design data schema
 2.2.1.6 Abstract Program design (interacts with data design)
 2.2.1.6.1 Determine basic functional blocks
 2.2.1.6.2 Describe internal interaction between blocks
 2.2.1.6.3 Class Diagram(s)
 2.2.1.6.4 API's (pseudo-code header files with comments)
 2.2.1.7 Determine development tools/framework
 2.2.1.7.1 Chose working language(s)
 2.2.1.7.2 Choose Database
 2.2.1.7.2.1 Close-coupled, dedicated
 2.2.1.7.2.2 Indirection layer
 2.2.1.7.2.3 Initially close-coupled, iterate to indirect.
 2.2.2 Building/Coding (yippee)
 2.2.2.1 Management
 2.2.2.1.1 Project =E2=80=9Cmanagement=E2=80=9D finds sutures in design.  A=
ssigns code to=20
coder roles (NOT individuals)
 2.2.2.1.2 If needed, manager (and anyone he can hoodwink) busk for MORE=20
coding volunteers.
 2.2.2.1.3 Coding tasks assigned (and sometimes re-assigned)
 2.2.2.1.4 Meet=20
 2.2.2.1.4.1 Track progress
 2.2.2.1.4.2 Code review
 2.2.2.2 Database Development=20
 2.2.2.2.1 Create data container objects (instantiate the data schema)
 2.2.2.2.2 Develop stored procedures (if any)
 2.2.2.2.3 Generate or write documentation for schema objects, the DBI and=
=20
storage (two lines to one page per  =E2=80=9Citem=E2=80=9D, depending on co=
mplexity)
 2.2.2.3 Program Development=20
 2.2.2.3.1 Deployment cycle
 2.2.2.3.1.1 Build cycle
 2.2.2.3.1.1.1 Unit Cycle
 2.2.2.3.1.1.1.1 Assign teams or pairs (is this possible?)
 2.2.2.3.1.1.1.2 Assign code
 2.2.2.3.1.1.1.3 Coding cycle
 2.2.2.3.1.1.1.3.1 code-document
 2.2.2.3.1.1.1.3.2 Unit test (with automation)
 2.2.2.3.1.1.1.3.3 Occasional code review
 2.2.2.3.1.2 Regularly scheduled frequent build
 2.2.2.3.1.2.1 compile
 2.2.2.3.1.2.2 link
 2.2.2.3.1.2.3 regression test
 2.2.2.3.1.2.4 pass|fail
 2.2.2.3.1.2.5 notify and publish
 2.2.2.3.2 Deploy or deliver to customer(s)=20
 2.2.2.3.2.1  Get customer feedback
 2.2.2.3.2.2  React to feedback appropriately
 2.2.2.3.2.2.1 Deny
 2.2.2.3.2.2.2 Extend
 2.2.2.3.2.2.3 Refactor
 2.2.2.3.2.2.4 Redesign


Pre-Phase II: ASULUG/PLUG plan and produce Mega-Installfest

 1 Preferably overlaps Event Software Integration Project Phase One.

 2 May include other elements
 2.1 Corporate sponsors with booths (exhibition)
 2.2 Short presentations or poster sessions (conference)
 2.3 Lectures (seminar)

 3 Mega-Installfest work must lead its automation.  (No itch, no scratch)
 3.1 Do a few Mega-Installfests then start automation project
 3.2 One Mega-Installfest, then start automation
 3.3 Shortly after starting work on first Mega-Installfest, start working o=
n=20
automation tools.
 3.4 Start working on automation tools in advance of Mega-Installfest (but=
=20
why?)


Phase II: Mega-Installfest automation

Note that the outline under =E2=80=9CPhase I=E2=80=9D is close to being a g=
eneric plan for a=20
software project.  Therefore, much detail in Phase II is left out with a=20
reference to =E2=80=9Csee Phase I=E2=80=9D.

 0 Pre-project: Assume continuity with Phase I.

 1 Scope (see Phase I)

 2 Extend, Shop or Build from Scratch
This is as Phase I, except that our list of =E2=80=9Coff the shelf=E2=80=9D=
 solutions now=20
includes the results from Phase I.  Also, extending the work of Phase I is=
=20
qualitatively different from shopping for approximate fits to Phase II need=
s.
 =20
 2.1 Extend and Shop compete for preference
 2.2 Either is better than Build from Scratch
 2.3 Extend or Shop
 2.3.1 Review updated needs and scope
 2.3.1.1 Shop SourceForge and Freshmeat. =20
 2.3.1.2 Review Phase I product.=20
 2.3.1.3 Extend or Shop Overall if either seems feasible
 2.3.1.3.1 Compatible scope
 2.3.1.3.2 Compatible features
 2.3.1.3.3 Acceptable
 2.3.1.3.3.1 License
 2.3.1.3.3.2 Software architecture
 2.3.1.3.3.3 Hardware
 2.3.1.3.3.4 Topology
 2.3.1.3.4 Use extension if it seems easier or comparable to results of=20
shopping
 2.3.1.3.5 Else use results of shopping
 2.3.1.4 Extend or shop for each contained function
 2.4 Build (unless extension or shopping seem feasible)
 2.4.1 Pre-Build Decisions (Design)
 2.2.2.4 Determine license that will be used (unlikely to change)
 2.2.2.5 Determine who holds copyright (unlikely to change)
 2.2.2.6 Determine targeted/supported hardware platforms (likely to stay th=
e=20
same or increase)
 2.2.2.7 Determine targeted/supported logical architectural topologies (lik=
ely=20
same or higher, see Phase I)
 2.2.2.8 Abstract Data design (see Phase I)
 2.2.2.9 Abstract Program design (see Phase I)
 2.2.2.10 Determine development tools/framework
 2.2.2.10.1 Chose working language(s)  (unlikely to change)
 2.2.2.10.2 Choose Database (unlikely to change, see Phase I)
 2.2.2.10.3 Building/Coding (yippee! see Phase I)