Welcome to TechnologyProfessional.Org

Advance the profession. Advance your career.

Login now!

Member Login

Lost your password?

Application Development: Methodology Tools

December 8, 2008

Where Does a Developer Start?

As I thought about topics for this article and the myriad tools and techniques available to software developers, I tried to answer these two questions:

  1. What is the tool that every developer needs?
  2. What is the first thing a new developer needs to learn?

However, those two questions led me to more questions: Where does a developer start? What does a developer do first? What roadmap is most suitable? What determines methodology?

To help answer these questions, let’s review common methodologies and discuss how methodologies provide roadmaps for projects. Because software design is a creative process, some developers might be apprehensive about a methodological approach. However, a methodology can be very useful to organize tasks in the proper order, manage team members efficiently and effectively and provide a timeline with deadlines and milestones.

What Is Methodology?

As applied to this article, methodology is an organized, documented set of procedures or guidelines for the software lifecycle. Below, I provide an overview of waterfall, incremental, spiral and agile methodologies. Not all methodologies are alike, but nearly all share common traits. Methodologies simplify a complex undertaking by dividing it into manageable phases and tasks that can be clearly defined in these terms:

  • Objectives
  • Inputs
  • Activities (Roles/Procedures)
  • Outputs (Deliverables/Artifacts)

How Are Methodologies Selected?

Waterfall Methodology

My first experience with methodology was SDM-70—a proprietary systems development methodology developed by Atlantic Software, Inc. SDM-70 consisted of 20 volumes bound in three-ring binders. Each binder held skeleton project plans and phase, task, and role descriptions needed to execute the plans. Each binder included paper forms to document the requirements, designs, plans and status of each step in the development process. This was in the 1970s and before personal computers became common in corporate America. The forms were completed manually (handwritten or typed) and collected in additional binders that became repositories of project artifacts.

Although SDM-70 contained different templates for various types of projects (new development vs. system enhancement vs. purchased package implementation), it was fundamentally a “waterfall” methodology. Like many methodologies that were popular at the time, SDM-70 was divided into a set of phases that progressed sequentially from the beginning of a project idea through its implementation. In figure 1, you can see that SDM-70 was like a series of waterfalls with each phase built on the output of its predecessor.

Fig. 1. Waterfall methodology

Waterfall methodologies evolved from engineering and architecture disciplines where ideas developed from a rough concept into a finished structure through carefully planned steps with each step building on its predecessor. It is still the best the best approach for projects where, like a building, the result must stand on its own. Each component must function with minimal maintenance like the Mars rover.

Waterfall methodologies assume the following: 1) a substantial number of requirements are known, 2) they can be described with mathematical precision and 3) they are expected to remain relatively stable over time. Many business projects fail because the initial goal is no longer valid by the time the project is implemented.

Incremental Methodology

Incremental methodologies attempt to overcome potential scope creep issues by breaking the entire project into bite size chunks that can be designed and implemented in a relatively short period.

Fig. 2. Incremental methodology

Incremental methodologies use a combination of mini-waterfalls and iterative prototypes to build the final system (see fig. 2). They have the advantage of delivering portions of the system to the end users quickly, which allows the users to see progress and correct the course as necessary.

A shortcoming of the iterative process is that difficult problems tend to be deferred to later iterations to achieve early successes and solutions to these problems often have ripple effects through large parts of the system.

Spiral Methodology

Barry Boehm defined spiral methodology in “A Spiral Model of Software Development and Enhancement,” which appeared in the IEEE journal Computer in 1988. In spiral methodology, you plan the overall system first. Then, spiral systems are built as successive prototypes through a defined series of steps. The main objective of each prototype is to reduce risk by learning what works and what does not and apply that knowledge to the next iteration.

Fig. 3. Spiral model

Fig. 3. Spiral model

Each iteration follows the same basic steps (see Fig. 3):

  1. 1. Determine objectives (requirements and planning)
  2. 2. Identify alternatives and assess risks
  3. 3. Develop and test a prototype
  4. 4. Plan the next iteration

Because the main goal of spiral methods is the reduction of risk, the methodology works well for building real-time, safety-critical systems like air traffic control. Spiral methodology is less successful in situations with tight time and budget constraints because each cycle tends to generate additional work for subsequent iterations.

Agile Methodologies

Agile methodologies are based on a set of principles defined in the Agile Manifesto, which was created in 2001 by a group of software developers. These principles are as follows:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Other methodologies focus on predictability in the development process; agile methodologies focus on adaptability. Agile helps teams respond to the unpredictability of building software through incremental, iterative work cadences known as sprints. Sprints are timebox development iterations designed to create a usable set of functions that meet the user’s most pressing needs. Each iteration selects the highest priority items from a backlog of features and works through the development cycle in a fashion that emphasizes collaboration over written documentation. Teams meet daily to discuss progress, identify problems and plan the day’s activities with the goal being to produce working software as quickly as possible.

Agile methodologies differ from other iterative methodologies. They generally measure iterations in weeks rather than in months and follow a timebox more strictly. Examples of agile methodologies include the following:

  • Extreme Programming (XP)
  • Crystal Clear
  • Adaptive Software Development
  • Feature Driven Development
  • Dynamic Systems Development Method (DSDM)
  • Scrum

Agile methods tend to produce “usable” versions of applications earlier than other methodologies. Because users remain engaged in the process by continuously defining requirements and validating results, they have a greater sense of ownership in the system.


I hope this sampling of methodologies presents developers with a few options for selecting a roadmap. How to do the job is as important as deciding what to do and why. This goes for developers working alone or as part of a team.

Remember, code, implement, test, analyze and design is a methodology. However, it’s not one that will often succeed.


Leave a Reply