The software development plan is the explanation of the process framework that is used to build the software. It's audience is both management and devopers, and evolves as the project goes on.
The software is going to go through a number of iterations, where each iteration has a set of workflows described in the modern process overview. The goal is to release a workable version of the code during the Deployment workflow at the end of each iteration.
Version numbers will relate the iteration number. peppy follows the Python standard of version numbers for modules: major.minor.patchlevel[subrelease]. From the distutils docs:
The major number is 0 for initial, experimental releases of software. It is incremented for releases that represent major milestones in a package. The minor number is incremented when important new features are added to the package. The patch number increments when bug-fix releases are made. Additional trailing version information is sometimes used to indicate sub-releases. These are "a1,a2,...,aN" (for alpha releases, where functionality and API may change), "b1,b2,...,bN" (for beta releases, which only fix bugs)Until the project has reached Initial Operations Capability, the minor number will be the iteration number and the patchlevel number will remain at zero. No patch releases will be made between iterations; only checkpoint releases at the end of the next iteration.
Once the project has reached Initial Operations Capability, the version number will be renamed to 1.0.0. Iterations will still correspond to minor releases, but will increment the minor version number starting from zero. Patchlevel releases may be made.
There are four major milestones in the modern process: Objectives, Architecture Lifecycle, Initial Operations Capability, and the Product Release milestones. These are described in the modern process overview, but here's how they relate to versions:
Corresponds to version 0.1 and the end of the Inception phase. This means that the basic objectives of the project have been approved by the stakeholders.
Planned to reach the milestone by the end of iteration 5 or 6, which signals the end of the Elaboration phase and the Engineering stage, and the entrance to the Production stage. To reach this point, the stakeholders must agree that the architecture satisfies the driving requirements and is likely to satisify future requirements as they are spiraled in during further iterations.
There could be anywhere from 4 to 10 iterations before IOC is reached, at which time the version will be incremented to 1.0.0. This signals the end of the Construction phase, meaning that the code will be ready for early adopters and testers. The critical use cases must be satisfied in order to reach this milestone.
The version number will be incremented to 2.0.0 at product release and signals the end of the Transition phase and the Production stage. The code must pass acceptance testing before this milestone is passed. Once the milestone is reaced, the code would be transferred to the support organization (if there were one).
There will be five checkpoints for each iteration: Requirements completed, Design completed, Implementation completed, Assessment completed, and Deployed.
This indicates that no new features will be added, but development will continue on all currently open features.
Any major architecture designs should be complete at this checkpoint, further changes that are deemed to be major, i.e. that affect more than one source file, are required to be delayed until the next iteration.
This checkpoint indicaties that all required features have been implemented and acceptance testing for the release may begin. Code that fixes bugs is the only code that is allowed to be checked in. New documentation may be checked in at any time, however.
This indicates the date of deployment of this version, and no further new development is allowed against that version. Bug fixing may still take place on a branch identified by that version, but a new minor version will have to be created if the code is to be released again based on that version.
A release of the code will be available at the deployed checkpoint. Before passing that checkpoint, however, the following must take place:
Unit testing will be accomplished using the nose testing framework.
Looking into the PyCheesecake project for automated metrics gathering.
i.e. risk identification, tracking, resolution
In general, I'm following ESR's guide to good distribution practices where I can.
i.e. org, staffing plan, training plan