 |
 |
 |
 |
404.0 LifecycleStep Overview
|
All projects build one or more deliverables, and the processes used to build the deliverables are the project lifecycle. LifecycleStep contains a number of different IT Development lifecycle models. The one that is described in the most detail is the waterfall model, since it provides the basic thinking that can be used for most other lifecycle models as well. |
The high-level description of the waterfall lifecycle is as follows:
 |
Analysis
|
Analysis
The Analysis Phase is where the project lifecycle begins. The only exception is a situation where you have broken a large project down into smaller components. In that case, you may have an entire project that is only focused on the Analysis Phase, while the next project may start at the Design Phase.
The Analysis Phase is where you break down the high-level Project Charter into the more detailed business requirements. The Analysis Phase is also the part of the project where you identify the overall direction that the project will take through the creation of the project strategy documents.
Gathering requirements is the main attraction of the Analysis Phase. The process of gathering requirements is usually more than simply asking the users what they need and writing their answers down. Depending on the complexity of the application, the process for gathering requirements has a clearly defined process of its own. This process consists of a group of repeatable processes that utilize certain techniques to capture, document, communicate, and manage requirements.
Design
The project team should have a nice set of requirements to work from, a set of direction-setting strategies and a Conceptual Systems Design. There might be some on the project team that would say that this is enough to start the Construct Phase. However, it is not. The design process comes next. Even if the project was small and the requirements were simple, there is still a mental design process that occurs in between understanding the requirements and starting to construct. Design becomes more and more important as the project becomes larger, more complex and impacts more and more people. Once you complete the requirements, you will typically see a myriad of alternatives for construction. These alternatives include the tools and technology you will you utilize, the scalability of the solution, and the structure of the components you will build. In essence, the Design Phase is where you look at the many potential solutions and narrow down the choices to determine the most effective and efficient way to construct the solution. The Design Phase answers the questions about "how" you will build the best solution for your organization and your environment.
At the end of the Design Phase, you will have a logical solution defined. The solution is "logical" because it exists on paper or in a design tool. This logical solution is then passed to the Construct Phase, where the logical solution is turned into a physical solution. However, the people that specialize in constructing the solution will not have to worry about the myriad of possibilities. That guidance will be provided to them through the work in the Design Phase. The people working to construct the solution can use their talents to build the solution based on the deliverables produced during the Design Phase.
Construct
The Construct Phase is where the "rubber meets the road". This is the point in the project when we actually start to construct the solution. In an IT development project this is the time to start writing program code. If you followed the LifecycleStep process so far, your construct team has a lot of guidance. They have a complete set of design specifications showing how the application should be structured and organized. They have design specifications for all screens, reports and programs. At this point, then, the project manager should be able to start handing out the various design specifications and the construct team can start to build the solution.
The Construct Phase is also where we will create support documentation such as a Disaster Recovery Manual and User's Manual. In essence these documents are also being "constructed" and so the logical place to create them is the Construction Phase. Depending on the type of document, the support material can also be tested in the Test Phase and then executed or implemented in the Implementation Phase.
Test
We test our work for two main reasons. First, we want to ensure that the solution meets the business requirements. For instance, if a specific business transaction follows a logical path from A -> B -> C -> D, we want our testing to prove that this, in fact, happens. Second, we test to catch errors and defects. These may be programming errors, or errors that were introduced earlier in the development lifecycle. In other words, we need to prove that our solution is correct, while at the same time proving that there are no errors or defects. You may not catch many errors, but you still need to prove that the solution meets the business requirements.
Regardless of the type of project you are on, you want to catch as many errors as early in the lifecycle as possible. There are projects that purposely blast through the analysis, design and coding phases with a philosophy that they will fix all the problems in testing. This is usually disastrous. It is much more time-consuming and expensive to fix errors as they are caught later and later in the lifecycle. It’s not so bad, for instance, to correct programming errors that you discover in your testing. It is much more difficult when your testing uncovers a design error that resulted in information missing from your database. It is even harder if your testing points out that your analysis missed an entire business process.
Even with the best tools, it is impossible to test every logic path of every program. Therefore, you cannot ever be sure that your code is bug-free. There are times when software that has been stable for ten years suddenly breaks through an unlikely combination of circumstances that never occurred before. (These are “subtle” bugs.)
Implement
Implementation refers to the final process of moving the solution from development status to production status. Depending on your project, this process is often called deployment, go-live, rollout and installation. For the purpose of LifecycleStep, all of these terms are synonymous with "implementation".
There is no single way to implement an application. It depends on the characteristics of your project and the solution. Some implementations are as easy as saying “we are now live.” This type of implementation can work when the solution is brand new and you are developing and testing in what will become the production environment. In these cases, implementation is just a state of mind. One day the solution is in development and the next day it is in production. What could be easier?
When we think about implementation, we should always start by understanding the level of complexity involved. If the implementation is relatively straightforward, then there is no reason for elaborate implementation processes. However, most projects have a number of implementation events to plan for and execute successfully.
Other Lifecycle Models
In addition to the classic waterfall model described above, LifecycleStep also describes other popular lifecycle models, including iterative development, enhancements, Agile and more. Although the waterfall model can be used on all projects, other models may be more effective given the nature of the project and your organizational environment.
Percentage of Project Time per Phase
Many people ask how much time should be spent in each phase of a project. The answer is – it depends. It depends on the type of project you are executing, the lifecycle model you are using, the tools you are using, etc.
However, just for the sake of generalization, you could consider a “typical” project using a “typical” waterfall lifecycle. You could generalize the percentage of project time for each phase to be something like the following.
-
Project management: 15%
-
Analysis: 20%
-
Design: 15%
-
Construct: 25%
-
Test: 20%
-
Implementation: 5%
What is important to recognize is that a substantial portion of the project takes place before the coding begins. This is counter to many project teams that want to spend just a small portion of the time planning and thinking – preferring to jump into the coding as soon as possible. If you take that approach (code first) you will find that you are still doing a substantial amount of analysis and design work. Unfortunately, this work will be done while you are also trying to write code and test the solution, making it much more difficult to create a comprehensive and flexible solution.
[Previous - 403.0 Caveats] [Next - 405.0 Principles]
Product info: project management, project lifecycle, analysis phase, , design phase, lifecycle design, construct phase, test phase, implementation phase, project lifecycle consulting, project lifecycle methodology, Agile
