JBoss Software Development Cycle

A project lifecycle consists of the following phases:

1. Identifying the next product version.

2. Requirements gathering period. (stakeholders: CTO Office, Product Management, Development Management, driver: Project Lead/Architect)

1. Selecting previously requested features and adding new requirements. (2 weeks)

2. Prioritizing requirements. (1 week)

3. Estimating approximate development time for each requirement (1 week)

4. Setting delivery deadline. Normally major versions are spaced at 3-6 months and intermediate versions at 1-2 months. (2 days)

5. Setting delivery dealines for intermediate versions and distributing requirements among them. (2 days]

6. Deferring overflowing requirements to a future version.  (1 day)

3. Writing functional specification. This document is a technical description of each feature and is the ultimate source driving coding tasks, QA test plan, user guides and training material. The initial draft is written by an architect and following updates are contributed by any of the core project developers. (1 week for initial draft). The following document is a good example for functional specification: tomcat functional spec.

4. Creating development tasks. Based on the initial draft of the functional specification, the architect creates a list of development tasks. A task is usually sized at 2-4 days. Along the way new finer grained coding tasks might be created by core developers, other architects or CTO.

5. Coding. (4-6 weeks, participants: core developers and external contributors, driver: Project Lead/Architect)

1. (for each development task)

2. Writing design document - includes Static and Interaction UML diagrams as well as algorithmic description using pseudo code or similar technique

3. Coding

4. Unit Testing

5. Updating Functional Specification if applicable

6. Peer review. Design documents should refer to the forum discussion where peers post  ed their feedback. Code check-in notes should refer to a peer reviewer name or email address.

6. QA phase (2-4 weeks, stakeholders: QA team, core developers, driver: designated QA manager]

1. Execute test plans. QA team executes automated test suites and manual scenarious when necessary to verify code quality. 0 failing unit tests is part of the quality acceptance crieria.

2. Benchmarking and performance tuning. QA team executes benchmarking procedure and either establishes a baseline or compares against a previously established one.

3. Bug fixing. During this step, bugs are open by QA team, developers and external contributors.

4. Update functional specification

5. Certify code quality

6. Build installers

7. Release phase (2-4 weeks; stakeholders: marketing, services, development; driver: product management)

1. QA Certification - Installation bundles are ready to be published.

2. Services Certification - End User documents and Training Material are ready.

3. Marketing Certification - white papers, press releases and other marketing material is prepared.

4. Note: Services and Marketing certifications are mandatory for stable product versions (e.g. 2.1 final) and optional for intermediate versions (e.g. 2.1 Beta).

5. Product launch