|
|
|
|
|
|
|
|
 |
|
 |
|
Slashdot's Menu
|
The reality is that the project management methodologies available to a project manager are often decided on long before a project starts. In many cases the decision is based on nothing more than "this is what we've always done". At other times, the decision is based on an enterprise-wide initiative to adopt a particular process like the Rational Unified Process. Regardless, it is important to know the various project management methodologies if for no other reason than to be aware of the where their strengths lie and where they fall short.
This section (see menu to the left) describes project management and software development methodologies that I've used or have read about over the years. Some are fairly mature in that they've been around for quite some time. Others are relatively new and have been developed to recognize the challenges that are inherent with many modern software development initiatives. All are worth reading about.
Methodologies
Top
Adaptive Project Framework
The fundamental concept underlying the adaptive project framework (APF) is that scope is variable, and within specified time and cost constraints, APF maximizes business value by adjusting scope at each iteration. It does this by making the client the central figure in deciding what constitutes that maximum business value. At the completion of an iteration, the client has an opportunity to change the direction of the project based on what was learned from all previous iterations. This constant adjustment means that an APF project's course is constantly corrected to ensure the delivery of maximum business value.
The core values of the APF approach are:
- Client-focused
- Client-driven
- Incremental results early and often
- Continuous question and introspection
- Change is progress to a better solution
- Don't speculate on the future
|
Top
Agile Software Development
Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies e.g. Crystal Methods, Dynamic Systems Development Model (DSDM), and Scrum
Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.
Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface designers, technical writers, and management.
Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods.
|
Top
Crystal Methods Methodology
Alistair Cockburn developed the Crystal Methods approach. His focus is on the people, interaction, community, skills, talents, and communications with the belief that these are what have the first-order effect on performance. Process, he says, is important, but secondary.
Cockburn's philosophy translate into a recognition that since ach team of people has a different set of talents and skills which means that each team should use a process uniquely tailored to it. And it means that the process should be minimized -- barely significant.
The use of the word "crystal" refers to the various facets of a gemstone -- each a different face on an underlying core. The underlying core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and standards. Cockburn also differentiates between methodology, techniques, and policies. A methodology is a set of elements (practices, tools); techniques are skill areas such as developing use cases; and policies dictate organizational "musts
|
Top
Dynamic Systems Development Model (DSDM) Methodology
The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the agile software development techniques, at least in Europe. DSDM favors the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavor.
The nine principles of DSDM are:
- Active user involvement.
- Empowered teams that the authority to can make decisions.
- A focus on frequent delivery of products.
- Using fitness for business purpose as the essential criterion for acceptance of deliverables.
- Iterative and incremental development to ensure convergence on an accurate business solution.
- Reversible changes during development.
- Requirements that are baselined at a high level.
- Integrated testing throughout the life cycle.
- Collaboration and cooperation between all stakeholders.
|
Top
Systems Development Life Cycle (SDLC)
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize.
Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows these steps:
- If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and consulting with support personnel.
- The new system requirements are defined including addressing any deficiencies in the existing system with specific proposals for improvement.
- The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and security issues.
- The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
- The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
- Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
|
Top
Extreme Programming (XP)
Not available
Not available
Not available
Not available
|
Top
Feature Driven Development (FDD)
Not available
Not available
Not available
Not available
|
Top
Joint Application Development (JAD)
The Joint Application Development (JAD) methodology aims to involve the client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and Tony Crawford, developed the JAD methodology in the late 1970s and began teaching the approach in to the 1980s.
In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client satisfaction, both of which stem from the constant involvement of the client throughout the development process. On the other hand, with the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews.
Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components.
|
-
Top
Lean Development(LD)
Not available
Not available
Not available
Not available
|
Top
Prince2
Not available
Not available
Not available
Not available
|
Top
Rapid Application Development (RAD) Methodology
RAD (rapid application development) proposes that products can be developed faster and of higher quality by:
- Using workshops or focus groups to gather requirements.
- Prototyping and user testing of designs.
- Re-using software components.
- Following a schedule that defers design improvements to the next product version.
- Keeping review meetings and other team communication informal.
There are commercial products that include requirements gathering tools, prototyping tools, software development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.
|
Top
Rational Unified Process (RUP) Methodology
The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.
By contrast, RUP represents an iterative approach that is superior for a number of reasons:
-
It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
- Integration is not one "big bang" at the end; instead, elements are integrated progressively.
- Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
- Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
- Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
- When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
- Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
- The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.
|
Top
Scrum Methodology
Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralysed by heavier, process-laden methodologies. Its intended use is for management of software development projects as well as a wrapper to other software development methodologies such as Extreme Programming.
Scrum is characterised by:
- A living backlog of prioritised work to be done.
- Completion of a largely fixed set of backlog items in a series of short iterations or sprints.
- A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and obstacles are raised.
- A brief planning session in which the backlog items for the sprint will be defined.
- A brief heartbeat retrospective, at which all team members reflect about the past sprint.
Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The scrum master is not the leader of the team (as they are self-organising) but acts as a productivity buffer between the team and any destabilising influences.
Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional "process control" manner. As such, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, focusing instead on maximising the team's ability to respond in an agile manner to emerging challenges.
|
Top
Spiral Methodology
The spiral methodology extends the waterfall model by introducing prototyping. It is generally chosen over the waterfall approach for large, expensive, and complicated projects.
At a high-level, the steps in the spiral model are as follows:
-
The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
-
A preliminary design is created for the new system.
- A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
- A second prototype is evolved using four steps:
-
Evaluate the first prototype and identify its strengths, weaknesses, and risks.
-
Define the requirements of the second prototype.
- Plan and design the second prototype.
- Construct and test the second prototype.
- At the project sponsor's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could result in a less-than-satisfactory final product.
- The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
- The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
-
The final system is constructed, based on the refined prototype.
-
The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
|
Top
Systems Development Life Cycle (SDLC)
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize.
Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows these steps:
-
If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and consulting with support personnel.
-
The new system requirements are defined including addressing any deficiencies in the existing system with specific proposals for improvement.
-
The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and security issues.
The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
-
The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
-
Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
|
Top
TenStep Project Management Process
I used to have a description of the TenStep Project Management Process on this page having found the information I read from a book about the process to be interesting and useful. However, I've since learned that a description of how I used the process was in violation of the licensing terms from TenStep Inc. To be in accordance with the licensing terms I would need to pay a fee (no idea how much).
This to me is an unusual business model as I would've thought that what I learned from a book I paid for would be mine to use as I see fit. But the process and content aren't mine, so I'll let the owners decide what is and isn't fair use.
So I'm retracting my endorsement of the TenStep Project Management Process as it is no longer a good fit for how I prefer to operate. And in compliance with their terms, I will not use the process with any of my projects. Instead, I recommend that you review some of the other methodologies below all of which I believe are open to use by the public (although you may need to buy the vendor's software to get the full benefit).
|
Top
Waterfall (a.k.a. Traditional) Methodology
The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is rigid and linear. Waterfall development has distinct goals for each phase of development where each phase is completed for the next one is started and there is no turning back.
The perceived advantages of the waterfall process is that it allows for departmentalization and managerial control. A schedule is typically set with deadlines for each stage of development and a product can proceed through the development process. In theory, this process leads to the project being delivered on time because each phase has been planned in detail.
In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes and revisions that become necessary with most projects. Once an application is in the testing stage, it is very difficult to go back and change something that was not thought of in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.
|
|
|
|
.
|
|