From an idea to a fully functional binary or DLL, a project passes through a varied range of activities and processes. The project life cycle refers to the different logical and physical stages that a project goes through from inception to completion. The life cycle starts with gathering the business requirements and ends when the final product is delivered after complete testing. The following are the major stages of a generic project life cycle:
1. Project Initiation
2. Planning and Prototyping
3. Project Construction
4. Project Transition and Release
These stages are more-or-less common through all projects. In this section, we will see some of the basic processes and understand the importance of each. Note that it is not necessary for each project to follow a standard life cycle strictly. Every project will have its own modified version of the life cycle, as well as its own duration for each stage.
This is the part where the project idea is discussed with the stakeholders. Here, we discuss the feasibility of the project, and decide if it is really worth moving forward with the project at all. A few things which might be discussed are:
Does the project's business model make sense?
Is the project feasible given the current technological platforms?
How big is the project going to be? Is it possible to complete the project within the business deadline?
Do we have the required technical talent available in the market to complete the project on time?
In this phase, the business analyst or the stakeholder(s) will create a high-level requirements document. This document will list the aim of the project and its fundamental business logic in business terms. One can also create RFQ (Request For Quotation) or RFI (Request For Information) documents to be sent to other firms who might be willing to bid for the development of the project, or to the internal development team for further development time and cost estimates.
So in this first stage, the stakeholders discuss and decide on the business feasibility of the project and prepare a document that captures most of the requirements at a very high level.
In this phase, we elaborate on the project requirements by capturing all business requirements in specially formatted documents called use cases, and then prepare a prototype as well as a project plan for the next stages of the project life cycle. Once the project initiation and inception stage is over and the project owners have selected a development team, the second phase starts, in which the architect or the development team leads and the project manager will work out a plan and a development cycle. In this phase, most of the major pre-development activities take place. These activities are described in more detail below:
The project manager will need to create a plan that will lay out all of the major tasks in the project life cycle, along with the resources and time required. Without a plan it would be very difficult to track and manage the progress of different stages of a project. The project plan at this stage might not be able to cover the actual development phase, because this will depend on the completion of the following tasks.
The architect/business analysts will first start this phase by creating use cases, which can be simple documents explaining the interaction between the application and the end user. A "use case" lists the interaction steps sequentially, along with other possible paths for a single interaction with the user. Each use case should capture a specific scenario from end-to-end. It should also list all pre-conditions as well as post-conditions for that scenario. Here is a sample use case:
|
UseCase 1.10 User Login | |
|
Description: |
Actor gains access to system. |
|
Actors: |
All roles. |
|
Trigger: |
Actor invokes the application. |
|
Pre-Conditions: |
Not applicable |
|
Post-Conditions: |
Actor is successfully logged in to system. |
|
Basic Flow: |
BF1: Log on to Client
|
|
Alternate Flows: |
AF1: Forgot Password The use case starts when the actor has not logged in and clicks Forgot Password link.
AF2: Change Password The use case starts when the My Account action is invoked. The actor is already logged in.
The use case ends when the System saves the new password. |
|
Exception Flows: |
none |
|
Special Requirements: |
None |
There are many ways of creating use cases; we can also create them diagrammatically. But to keep things simple, we can follow the above use case, which is easier to understand. After the major use cases are covered, we can move to the next step in this elaboration phase, which is, prototyping.
The Graphical User Interface (GUI) of any project is one of the most critical areas in terms of its overall presence and credibility. And many projects are delayed because of repeated changes in the GUI throughout the project life cycle, adding to the frustration of the programmers. For web projects, designing a working prototype in HTML before starting to work on any other activity can be very helpful, for project stakeholders as well as developers. A working prototype means that the different HTML pages would be linked to each other (based on the use cases we covered earlier), and can use dummy data to give a realistic impression of the actual project.
A GUI prototype is not only a part of the Proof of Concept(POC), but also forms an important extension of the project requirements specifications, in a graphical sense. Properly-linked HTML pages with some dummy data showing the important business process flows can be an indispensable tool, aiding in the visual understanding of the project, as well as answering all kinds of technical and business-related questions. That is why it is highly recommended to develop a prototype before starting the actual coding for a project.
The architect and the technical lead will create an object model of the system, highlighting all important entities and how they will interact. We will learn more about how to create an object model in the coming chapters of this book.
A database model would be created based on the class model described above. This data model, along with the object model and use cases, will help provide the development team with clear instructions, and paths to the targets and objectives. It is very common for a data model to be created before a class model. It's also very common for these two steps to be completed at the same time, as they are very closely related.
Based on the use cases, the prototype and the object/data models, the project manager, along with the architect and the team lead, will develop a project plan for the construction phase, in which the coding takes place. This plan will highlight the milestones as well as list all of the important deliverables of that phase.
When all of the primary documentation is complete, the actual development work starts. The technical team will study the use cases and the object and data models, and start planning the delivery cycles. Here, we can use one of the following famous development methodologies:
SCRUM Development
Waterfall Model
Agile Development/Extreme Programming (XP)
Iterative Development
You can find more information about each of these techniques online via the list of references I have provided. There is a lot of online as well as offline text available on these methodologies. I personally prefer SCRUM development, which is a Chaos Theory based approach. In SCRUM, we have sprint, which is an iteration with a certain number of days (for example, 30) at the end of which the development team covers a certain set of use cases and lets the stakeholders see and test the application. During the next iteration, they cover more features, which are prioritized accordingly. Each iteration passes through a full software development cycle: planning, requirements, design, coding, testing, and documentation. The goal is to have an available release (without bugs) at the end of each iteration.
A major goal to be achieved by using this process is to allow the client to take their new product to market before it is completed in its entirety. We are also minimizing risk by developing highly-focused components in a short period of time. This development process will continue throughout all phases, promoting the release of components to a beta phase in a live environment as the life cycles are completed. The following are the major benefits or principles of the SCRUM method:
Keeping things simple by chunking (or batching)
Customer satisfaction through rapid, continuous delivery of useful software they can get their hands on
Working software is delivered frequently (taking weeks rather than months)
Working software is the primary measure of progress
Late changes or additions in requirements are welcome and can be added to iterations with ease
Close, daily cooperation between clients and developers
Continuous attention to technical excellence and good design
Regular adaptation to changing circumstances
Because the stakeholders can see and review the current application at the end of each sprint, it gives them a valuable opportunity to change anything they don't like. Changes made at a later stage (such as when all use cases are covered) would take a longer time to absorb into the application, and can sometimes derail the project completely.
At the end of the last iteration, the project will be in alpha stage, which means that all of the main use cases are implemented. The alpha build of the software is the build delivered to the software testers, usually internal to the organization/community developing the software. Usually, no end users see this phase. Alpha stage software is never completely bug free, but functionally covers all use cases.
Once the alpha testing is over, the project moves to the beta phase, which means that external users/end users (outside the company or organization that developed the software) can now start checking the system and using it.
A beta version is the first version released outside of the organization or community that developed the software, for the purpose of evaluation or real-world testing. Beta level software generally includes all of the features, but may also include known issues and bugs of a less serious variety. Once the beta phase is over and all major bugs have been fixed, the project is in an RTM (Release To Manufacture) stage, or in the Gold Edition.
The following is a summary table showing all of the important project phases:
|
Project Stages |
Project Pitfalls |
|---|---|
|
1. Initiation: Understanding project needs from a very high-level perspective and conducting a small feasibility study |
A poor feasibility study can hinder or block project progress later on; it is very important to see what really can be achieved and what cannot, given the current technological offerings |
|
2(a) Planning: Understand the project needs comprehensively, develop business use cases, detailed project plan, high-level architecture, class diagrams, data model, sequence diagrams, prototype |
Detailed planning and project management is the key here; without a well laid out plan the project is doomed to fail. Wrong estimates or an improper choice of architecture can sound the death knell for the project's progress |
|
2(b) Development: Work iteratively on selected use cases, QA process follows |
Lack of unit tests, deviations in architecture, patching and short circuiting code to avoid missing deadlines |
|
3. Transition: Beta testing, release docs, deployment instructions, bug fixing |
Without proper usability and integration testing, success is not possible |
|
4. Support: Provide support after the Gold/RTM release |
Good support is very crucial |