Waterfall Methodology

Overview:

The first concept of the Waterfall method was introduced by W.W. Royce in 1970. Royce then went on to redesign his 1st method arguing that it was flawed. In his next redesign of the Waterfall method he introduced that the initial model could be developed into an iterative model, with feedback from each phase influencing subsequent phases. His criticism of the 1st model was largely ignored and thus resulted in the current Waterfall methods of today. Most modern Systems Analysts do not like or use the Waterfall method because of its non-iterative and inflexible design process. The way the waterfall method works is that each phase must be completed perfectly for the next phase to begin. There is no overlap or moving backward in phases.

The Process steps

Requirements: they set in stone the requirements of the system.

Design:The system in question is designed and a "blueprint" is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given.

Implementation: When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, system components produced by different teams are integrated.

Verification or Testing: After the implementation and integration phases are complete, the system is tested and debugged; any faults introduced in earlier phases are removed here.

Installation & Maintenance: The system components have all been integrated. The system is installed within the company and training for the system begins.

Pros:

  • Time spent early on in software production can save a company hundreds of thousands of dollars. Its shown that problems found too late in the life cycle of systems development can end up costing 50 to 200 times the amount that it would have cost to fix if it were found during that particular faze.
  • It places more emphasis on documentation than some other models. If someone from the team were to leave, than any new person brought aboard would be able to easily catch up because each step in the Waterfall model is designed before it is implemented, and nothing changes after the implementation of each step.

Cons:

  • It is almost impossible to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. Feedback from following phases is needed to complete satisfactory preceding phases.
  • Requirements are locked in too early, even after business conditions have changed. With no user feedback many of the new user requirements will not be implemented.
  • There is so much emphasis placed on design deadlines and completion that the system may not match the user needs. This could lead to extensive maintenance and much unnecessary rework that could be very expensive.

eXtreme Programming (XP)

Overview:

Extreme Programming was invented about 8 years ago by a man name Kent Beck. XP is successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customer needs when it is needed. XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.XP was created to improve software projects in four essential ways; communication, simplicity,feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.

The Process steps (Once a project is started these go in no particular order)

Planning: During the planning process user stories are first collected from the customer. User Stories are written by the customers as things that the system needs to do for them. Feedback is given to the customer to help better understand the requirements.

Designing: During the design phase the primary focus is on keeping the design simple. Constant communication with the customer is used to design and redesign over and over again until they have reached an acceptable solution.

Coding: The coding process is a very iterative process in XP. It is usually done in teams of 2 programmers so they can constantly feed off of each others ideas. While coding the customers feedback is constantly used in order to meet design requirements. Testing is immediately done when the code is finished to achieve optimum functionality.

Testing: Testing is consistently done after each portion of code is written. This is to insure that there will be no bugs in the system, and if a bug is found the code is immediately reworked and retested.

Pros:

  • Code will be developed, tested, and implemented into the system within a few hours after it has been written.
  • XP is governed by very simple rules and practices.
  • The pair programming used in XP produce more and better communication amound developers, higher levels of produmtivity, higher quality code, and reinforcement of the other practices in XP, such as the code-and-test discipline.

Cons:

  • Really there are no cons to XP besides the fact that it may not be applicable to every project.

Rational Unified Process

Overview:

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation(a division of IBM since 2003) around 1998.

Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. According to Rational, RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. The RUP uses six key principles

  1. Adapt the process : Decide on the right size project and budget for the organization.
  2. Balance stakeholder priorities: Determines business goals and stakeholder needs
  3. Collaborate across teams: With a broad variety of stakeholders, all voices need to be heard. Everyone within the project shares information, opinions, and ideas.
  4. Demonstrate value iteratively: Projects are delivered, even though often only internally, in an incrementaland iterative fashion. This encourages feedback from stakeholders and allows projects to adjust to changed requirements based on customer feedback
  5. Elevate the level of abstraction: Motivates the reuse of software or Framework already created.
  6. Focus continuously on quality: Encourages quality checks through testing not only at the end but during the creation of the projects.

The RUP consists of 4 phases:

Inception: Analysts define the scope, determine the feasibility of the project, understand user requirements, and prepare a software development plan. Usually entails a single iteration. It is short and the least resource intensive.

Elaboration: Analysts detail user requirements and develop a baseline architecture. Analysis and design activities constitute the bulk of the elaboration phase. May have one or two Iterations and is considered the most critical of the 4 phases. In this phase an executable demonstration of the critical pieces will be developed. It is long and has the 3rd most resource consumption.

Construction: The software is actually coded, tested, and documented. At the end of this phase a beta version of the project is released that should have operational capabilities. Itis the longest and most resource intensive phase.

Transition: The system is deployed, problems are corrected, and the users are trained and supported. Once acceptable criteria are met the product can then be scheduled for release.

Pros:

  • Establishes a better understanding and communication channel between business engineering and software engineering.
  • Provides pre-configured process templates for small, medium and large projects, which can be used for easier adoption.
  • Allows for constant feedback from the business as well as the stakeholders.
  • Encourages the use of reusable assets such as software pattern, 4GL or Framework which in turn prevents software engineers from having to make custom software.

Cons:

  • If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process.
  • Requires an RUP process expert, the project's overall success is highly dependent on the abilities of this one person.
  • May not be applicable to all situations.