For a project to succeed, it requires structure and flow. Structure is needed so that the project can be broken down into the necessary pieces required. Such a breaking down allow seach piece to be identified, tuned, given a start and an end and allows for it to be fitted together with all the other pieces, creating a total whole, the project plan. Structure gives us the static plan,
Flow is the actualisation of that plan. Flow requires resources (capital, people, tools etc.)but it also requires energy. As with all things, it is the energy that causes the plan to come to life. For KOSH, that energy manifests itself in many ways, excitement, determination, want and desire. We do not have the luxury (but also the curse) of the energy that is bought with money (peoples' time). This makes the harnessing and sustaining of the project's motivational energy all the more important.
Where most plans have a function that provides for such energy (budget and financial), KOSH will require a similar function, but its job will be to collect, maintain and amplify our energy. This can be done through constant updates, involvement, debate and, most importantly concrete progress and commitment.
There are many project methodologies following many paradigms. All have their pros and their cons. The one that we intend to use for KOSH is a RAD (Rapid Application Development) core team parallel flow model. In summary, the project is broken down into pieces, with each piece being assigned a core team/working group, a small group (7 or less) that is tasked with achieving its deliverable in any way it can within its life time. A flow matrix is created, identifying parallelism and dependencies. Ordinarily, a monitoring function is performed, either by a project management or a scheduler, or sometimes through a process called procession, where working groups with input dependencies pressure the working groups responsible to finish their deliverables.
The nature of KOSH however allows us to utilise and extend what is called the open audience model. Since KOSH is a community, the community members are going to be intently watching and participating in the observer mailing lists attached to each working group. This, coupled with a project mananger and scheduler, should provide more than enough motivation, progress monitoring and early warning alerts.
The rise of Quality Management and Workflow over the last ten years has led to a very structured approach that walks a fine line between trying to provide a formal structure whilst trying not to stifle creativity or requirements particular to a unique case. Every "piece" tends to have a script describing how the piece is defined, its scope, duration, structure, responsibility, review and signoff, all tied together in a document management and control system. This can be frustrating, until you consider the alternatives.......
The project life cycle model that we will use is a pretty basic one, and most people will recognise it, even if some of the words are different or some stages overlap or merge. It breaks out as follows;
The concept document usually consists of a short description of the concept itself, a list of shortcomings in the environment that led to the creation of the concept, and a section refering to the potential future of the concept, in terms of sales, concept development and how it enhances the parent entity.
The concept document is then given either a single, staged or consensual review depending on the structure of the entity to which it has been proposed. Whatever, the final result is either that no, the concept will not be pursued, the concept has merit but needs further development as a concept (which could lead to multiple iterations and input from other entities), or yes, the concept is a valid one and should progress to the nextstage.
The requirements definition phase creates two documents as output, the requirements baseline, and the plan. The requirements baseline, a comprehensive list of all requirements required to take the concept though the design, implementation and into the maintenance phase. Input into this phase tends to include Institutional requirements (general directives from the entity itself), the concept document from the previous phase, the formal development environment (the general plan, standards, QAmanual etc) and a sponsor/manager (if the entity requires it).
The structure of the requirements baseline document is often dictated by the structure of the entity or is adopted from a formal development lifecycle model. In general though, the requirements definition document would have the following sections.
As should be obvious from the above, the requirements baseline is a contract between all those who are mentioned within it. It stipulates requirements, resourcing, relationships and responsibilites (the 4 R's). Any changes require a large effort put into reviewing the document and, as such, serves as a disincentive to the rampant feature creep seen in many projects. "Fix what you want and then build it" is the motto here.
The plan is a description of how to get from the concept phase to the maintenance phase using the requirements baseline. It is often used as the dreaded "document of competency", for the entity to decide whether the project team know what they are doing. It is a "living document", in that it can change as time passes, adapting to new circumstances and events as they occur. It is also a progressive document. As time passes, the team passes along the plan, priorities change, resources need reallocating. It really is the story of the project.
The plan explains the why, how, who and what of the project. It contains another summary of the concept, the vision and goal of the project, the project team structure, its methodology and model (documentation, resource control etc), and QA and risk directives and of course, the project schedule.
The schedule is what we talked about earlier. The actual work broken down into atomic pieces, specified, resourced, deadlined, and connected together (dependency, inputs and outputs). The schedule lists all deliverables, all milestones, all critical paths and process it during the course of the project is akin to riding a surf board whilst juggling. The scheduler, or the project manager is responsible for keeping an eye on all progress, identifying slow downs or speed ups, redirecting resources and even splicing the schedule if it is required. (S)he becomes the most hated person in the project because it is their responsibility to keep the project moving and on schedule. Estimated or planned is mapped against actual, providing feedback that allows the estimated or planned itself to be constantly updated. A good project manager always knows the state of the plan.
Once the requirements baseline and plan has been created, they can be activated. Design is typically the first formal stage of a schedule. More than any other phase of the development lifecycle, design is unique to each entity. Typically though it is divided into 2, the logical design stage and the technical/physical design stage.
If we apply a top design process, then the logical design can be refined into logical 1, logical 2, logical 3 and so on. Into logical 1 is feed the requirements definition document and a high level, standalone, blackbox design is created, detailing the blackboxes, their interfaces and the communications between them. This is only done on a single level or pass, which allows for a consistent and level architectural design. Logical 1 is reviewed until it provides a total solution to the requirements definition.
There then follows an iterative process as the black boxes themselves are opened up and a single pass design is performed. A single black box at logical 1 may undergo several passes down to logical (n) before a fully descriptive logical model has been constructed.
For our project, the end result of the logical design should be a complete list of objects (or libraries and functions), described completely in an implementation independent format such as CORBA IDL. Remember, the purpose of the logical design phase is a specification, NOT an implementation.
The full logical specification is then feed into the technical design phase, the final deliverables of which are a million technical/physical specifications. A good logical specification can map almost transparently to a technical specification which, details the structures, the objects, the naming conventions etc of how the object, library, function or whatever should be coded. It is the technical specifications that are handed to the programmers, artists, musicians, engineers, package creators etc, allowing them to move ahead and actually implement the concept that started it all so long ago.
It is important to realise that the design phase is probably the most important phase of any lifecycle. Mistakes made early on tend to snowball, sometimes to the size where the whole project is endangered. When I started as a developer, an old lag told me that software was 40% design, 20% write, and 40% test or, as he putit the "think, work, worry" stages.
Peer review is a critical part of the design phase. Contrary to popular belief, peer review isn't about showing up other members of the team. It is about a person putting their ideas, or design, or code forwards and then having others analyse it along with that person. The purpose of it is to identify, correct and document errors in all parts of the development lifecycle. It is a learning and enriching experience. Of course, egos, bad moods and general gnarliness can turn a peer review into the Spanish Inquisition, but this would be the fault of the facilitator of the peer review. PEER REVIEWS ARE GOOD!!!
Of course, a point I almost forgot is that the design phase isn't just about software or hardware. The test plan for the lifecycle must also be designed and implemented, including test environments, test suites, tools and scripts. All the artwork, music, packaging and all the other non code deliverables identifed in the requirements baseline should also be designed and ready to implement.
Out of the design phase should come a vastly more accurate and detailed schedule and the full set of instructions for building and testing the product/service being constructed in a total quality environment.
Implementation is where the outside world finally starts to see the product/service enter the real world. Whilst the technical design phase may have seen some prototype code, layouts, engines, artwork and sound, the purpose of such prototypes would have been to more fully fleshout the technical specifications. With the implementation phase, we start building for real.
Whilst implementation phases can vary tremendously, they all share the same iterative process of construct, test, refine. This 3 stage cycle forms the basic implementation "cell" which is slotted into a set of defined levels. For instance, a standard corporate set would be unit, system (or integration) and user. For a software product being sold to the public, it could be function, integration, alpha, internal beta and external beta. Whatever the levels, the basic premise is the same. Build the individual pieces and test them, stick them together and test them (these 2 levels done by the developer and to the formal test plan), then release them to controlled and/or uncontrolled testing by person or persons not directly connected with the project. Remember the old adage, never test yourself because you already know the answer!!! In the implementation phase, the focus shifts from raw construction to fine finishing. After all, with the end of this phase, the product or service moves into the perilous outside world and people start to use it (and complain loudly if it doesn't work).
A contentious point during the late design and implementation phases are so called"feature creep". Some managers fix a logical specification and NEVER allow anything to beadded to it, saving new features to the first maintenance release. Some feel so pressured, especially when by superiors, that they are constantly adding new features as requested. Both are extremes and both have their consequences. It is often a matter of either personal preference, other factors, politics or directive.
At this stage, the concept is now a product or service and is out in the real world being used. The maintenance stage depends upon the nature of the product or service. For an OS that is constantly being used, maintenance is extremely important and time consuming. For a game, maintenance can last as little as six months, through the initial rush of buying and playing, until it becomes yesterday's game and everyone moves on to the next best thing.
Typically, a maintenance phase will see a formalisation of all the deliverables, documentations, plans, tools, test suites and results etc. These will be placed in a secure place and then stored, for whatever reason. Part of this process can include a PIR or Post Implementation Review, where members of the project team get together with others not associated with the project and they talk about what they did right, what they did wrong, ways to improve and lessons learnt. This information is then diseminated throughout the entity and its development lifecycle should become richer as a result.
For a product such as KOSH, maintenance is a full time phase. Bug reports and suggestions/recommendations for improvements come in all the time and have to been processed. Does the bug get fixed, is it called a feature and left or does it get rolled into a review of a whole structural area for the next release....when it all starts all over again.
Deliverables and phases
The above is a very general discussion of one type of development lifecycle. When I get the time, or if someone else gets the time, a table will be put below showing the phases, inputs, outputs and deliverables.