Module 1 FOUNDATION FOR SYSTEMS

DEVELOPMENT

Lesson 3: SYSTEM DEVELOPMENT METHODOLOGIES

A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps

and deliverables). There are many different systems development methodologies, and each one
is unique, based on the order and focus it places on each SDLC phase. Some methodologies are
formal standards used by government agencies, whereas others have been developed by
consulting firms to sell to clients. Many organizations have internal methodologies that have been
honed over the years, and they explain exactly how each phase of the SDLC is to be performed
in that company.

Categories of Methodologies

A process-centered methodology emphasizes process models as the core of the system

concept. In Figure 1-7, for example, process-centered methodologies would focus first on
defining the processes (e.g., assemble sandwich ingredients). Data-centered methodologies
emphasize data models as the core of the system concept. In Figure 1-7, data-centered
methodologies would focus first on defining the contents of the storage areas (e.g., refrigerator)
and how the contents were organized. By contrast, object-oriented methodologies attempt to
balance the focus between process and data by incorporating both into one model. In Figure 1-7,
these methodologies would focus first on defining the major elements of the system (e.g.,
sandwiches, lunches) and look at the processes and data involved with each element.

1
 Figure 1-7. A simple Behavioral Model for Making a Simple Lunch (Dennis, Wixon, & Tergaden, 2015)

Another important factor in categorizing methodologies is the sequencing of the SDLC

phases and the amount of time and eff ort devoted to each. In the early days of computing,
programmers did not understand the need for formal and well-planned life-cycle methodologies.

They tended to move directly from a very simple planning phase right into the construction
step of the implementation phase—in other words, from a very fuzzy, not-well thought- out system
request into writing code. This is the same approach that you sometimes use when writing
programs for a programming class. It can work for small programs that require only one
programmer, but if the requirements are complex or unclear, you might miss important aspects of
the problem and have to start all over again, throwing away part of the program (and the time and
effort spent writing it). This approach also makes teamwork difficult because members have little
idea about what needs to be accomplished and how to work together to produce a final product.

Different Classes of Methodologies

Structured Design. These methodologies became dominant in the 1980s, replacing the previous
ad hoc and undisciplined approach. Structured design methodologies adopt a formal step-by-step

2
approach to the SDLC that moves logically from one phase to the next. Numerous process-
centered and data-centered methodologies follow the basic approach of the two structured design
categories outlined next.
• Waterfall Development. The original structured design methodology (still used today) is
waterfall development. With waterfall development-based methodologies, the analysts
and users proceed in sequence from one phase to the next (see Figure 1.8). The key
deliverables for each phase are typically very long (often hundreds of pages in length) and
are presented to the project sponsor for approval as the project moves from phase to
phase. Once the sponsor approves the work that was conducted for a phase, the phase
ends and the next one begins. This methodology is referred to as waterfall development
because it moves forward from phase to phase in the same manner as a waterfall.
Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it
is extremely difficult (imagine yourself as a salmon trying to swim upstream against a
waterfall, as shown in Figure 1-8).

Figure 1-8. A Waterfall Developmental-Based Methodology (Dennis, Wixon, & Tergaden, 2015)

The two key advantages of the structured design waterfall approach are that it identifies
system requirements long before programming begins and it minimizes changes to the
requirements as the project proceeds. The two key disadvantages are that the design
must be completely specified before programming begins and that a long time elapses
between the completion of the system proposal in the analysis phase and the delivery of
the system (usually many months or years). If the project team misses important
requirements, expensive post-implementation programming may be needed (imagine
yourself trying to design a car on paper; how likely would you be to remember interior
lights that come on when the doors

3
 open or to specify the right number of valves on the engine?). A system can also require
significant rework because the business environment has changed from the time when
the analysis phase occurred.
• Parallel Development. Parallel development methodology attempts to address the
problem of long delays between the analysis phase and the delivery of the system. Instead
of doing design and implementation in sequence, it performs a general design for the
whole system and then divides the project into a series of distinct subprojects that can be
designed and implemented in parallel. Once all subprojects are complete, the separate
pieces are integrated and the system is delivered (see Figure 1-9).

Figure 1-9. A Parallel Development-Based Methodology

The primary advantage of this methodology is that it can reduce the time to deliver a
system; thus, there is less chance of changes in the business environment causing
rework. However, sometimes the subprojects are not completely independent; design
decisions made in one subproject can affect another, and the end of the project can require
significant integration eff orts.

Rapid Application Development (RAD). These are a newer class of systems development
methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both
weaknesses of structured design methodologies by adjusting the SDLC phases to get some part
of the system developed quickly and into the hands of the users. In this way, the users can better
understand the system and suggest revisions that bring the system closer to what is needed.

• Phase Development-based Methodology. A phased development-based methodology

breaks an overall system into a series of versions that are developed sequentially. The
analysis phase identifies the overall system concept, and the project team, users, and

4
 system sponsor then categorize the requirements into a series of versions. The most
important and fundamental requirements are bundled into the first version of the system.
The analysis phase then leads into design and implementation—but only with the set of
requirements identified for version 1 (see Figure 1-10). Once version 1 is implemented,
work begins on version 2. Additional analysis is performed based on the previously
identified requirements and combined with new ideas and issues that arose from the
users’ experience with version 1. Version 2 then is designed and implemented, and work
immediately begins on the next version. This process continues until the system is
complete or is no longer in use.

Figure 1-10. A Phased Development-Based Methodology

• Prototyping. A prototyping-based methodology performs the analysis, design, and

implementation phases concurrently, and all three phases are performed repeatedly in a
cycle until the system is completed. With these methodologies, the basics of analysis and
design are performed, and work immediately begins on a system prototype, a quick-and-
dirty program that provides a minimal amount of features. The first prototype is usually the
first part of the system that is used. This is shown to the users and the project sponsor,
who provide comments. These comments are used to reanalyze, redesign, and re-
implement a second prototype, which provides a few more features. This process
continues in a cycle until the analysts, users, and sponsor agree that the prototype
provides enough functionality to be installed and used in the organization. After the
prototype (now called the “system”) is installed, refinement occurs until it is accepted as
the new system (see Figure 1-11).

5
 Figure 1-11. A Prototyping-Based Methodology

The key advantage of a prototyping-based methodology is that it very quickly provides a

system with which the users can interact, even if it is not ready for widespread
organizational use at first. Prototyping reassures the users that the project team is working
on the system (there are no long delays in which the users see little progress), and
prototyping helps to more quickly refine real requirements. The major problem with
prototyping is that its fast-paced system releases challenge attempts to conduct careful,
methodical analysis. Often the prototype undergoes such significant changes that many
initial design decisions become poor ones. This can cause problems in the development
of complex systems because fundamental issues and problems are not recognized until
well into the development process. Imagine building a car and discovering late in the
prototyping process that you have to take the whole engine out to change the oil (because
no one thought about the need to change the oil until aft er it had been driven 10,000
miles).
• Throwaway Prototyping. Throwaway prototyping-based methodologies are similar to
prototyping-based methodologies in that they include the development of prototypes;
however, throwaway prototypes are done at a different point in the SDLC. These
prototypes are used for a very different purpose than previously discussed, and they have
a very different appearance (see Figure 1-12).

6
 Figure 1-12. A Throwaway Prototyping-Based Methodology

A system developed using this type of methodology relies on several design prototypes
during the analysis and design phases. Each of the prototypes is used to minimize the risk
associated with the system by confirming that important issues are understood before the
real system is built. Once the issues are resolved, the project moves into design and
implementation. At this point, the design prototypes are thrown away, which is an
important difference between these methodologies and prototyping methodologies, in
which the prototypes evolve into the final system.

Agile Development. All agile development methodologies are based on the agile manifesto and
a set of 12 principles. The emphasis of the manifesto is to focus the developers on the working
conditions of the developers, the working software, the customers, and addressing changing
requirements instead of focusing on detailed systems development processes, tools, all-inclusive
documentation, legal contracts, and detailed plans. These programming-centric methodologies
have few rules and practices, all of which are fairly easy to follow. These methodologies are
typically based only on the twelve principles of agile soft are. These principles include the
following:
1. Software is delivered early and continuously through the development process, satisfying
the customer.
2. Changing requirements are embraced regardless of when they occur in the development
process.
3. Working software is delivered frequently to the customer.
4. Customers and developers work together to solve the business problem.
5. Motivated individuals create solutions; provide them the tools and environment they need,
and trust them to deliver.

7
 6. Face-to-face communication within the development team is the most efficient and
effective method of gathering requirements.
7. The primary measure of progress is working, executing software.
8. Both customers and developers should work at a pace that is sustainable. That is, the
level of work could be maintained indefinitely without any worker burnout.
9. Agility is heightened through attention to both technical excellence and good design.
10. Simplicity, the avoidance of unnecessary work, is essential.
11. Self-organizing teams develop the best architectures, requirements, and designs.
12. Development teams regularly reflect on how to improve their development processes.

Figure 1-13. Typical Agile Development Methodology

Based on these principles, agile methodologies focus on streamlining the system-development

process by eliminating much of the modeling and documentation overhead and the time spent on
those tasks. Instead, projects emphasize simple, iterative application development. All agile
development methodologies follow a simple cycle through the traditional phases of the systems
development process (see Figure 1-13). Virtually all agile methodologies are used in conjunction
with object-oriented technologies.

• Extreme Programming. Extreme programming (XP) is founded on four core values:

communication, simplicity, feedback, and courage. These four values provide a foundation
that XP developers use to create any system. First, the developers must provide rapid
feedback to the end users on a continuous basis. Second, XP requires developers to
follow the KISS principle. Third, developers must make incremental changes to grow the

8
system, and they must not only accept change, they must embrace change. Fourth,
developers must have a quality-first mentality. XP also supports team members in
developing their own skills. Three of the key principles that XP uses to create successful
systems are continuous testing, simple coding performed by pairs of developers, and
close interactions with end users to build systems very quickly.

Testing and efficient coding practices are the core of XP. Code is tested each day and is
placed into an integrative testing environment. If bugs exist, the code is backed out until it
is completely free of errors. An XP project begins with user stories that describe what the
system needs to do. Then, programmers code in small, simple modules and test to meet
those needs. Users are required to be available to clear up questions and issues as they
arise. Standards are very important to minimize confusion, so XP teams use a common
set of names, descriptions, and coding practices. XP projects deliver results sooner than
even the RAD approaches, and they rarely get bogged down in gathering requirements
for the system.

XP adherents claim many strengths associated with developing software using XP.
Programmers work closely with all stakeholders, and communication among all
stakeholders is improved. Continuous testing of the evolving system is encouraged. The
system is developed in an evolutionary and incremental manner, which allows the
requirements to evolve as the stakeholders understand the potential that the technology
has in providing a solution to their problem. Estimation is task driven and is performed by
the programmer who will implement the solution for the task under consideration. Because
all programming is done in pairs, a shared responsibility for each software component
develops among the programmers. Finally, the quality of the final product increases during
each iteration.

9
 Figure 1-14. Extreme Programming Methodology

• Scrum. Scrum is a term that is well known to rugby fans. In rugby, a scrum is used to
restart a game. In a nutshell, the creators of the Scrum method believe that no matter how
much you plan, as soon as the software begins to be developed, chaos breaks out and
the plans go out the window. The best you can do is to react to where the proverbial rugby
ball squirts out. You then sprint with the ball until the next scrum. In the case of the Scrum
methodology, a sprint lasts 30 working days. At the end of the sprint, a system is delivered
to the customer.

Of all systems development approaches, on the surface, Scrum is the most chaotic. To
control some of the innate chaos, Scrum development focuses on a few key practices.
Teams are self-organized and self-directed. Unlike other approaches, Scrum teams do
not have a designated team leader. Instead, teams organize themselves in a symbiotic
manner and set their own goals for each sprint (iteration). Once a sprint has begun, Scrum
teams do not consider any additional requirements. Any new requirements that are
uncovered are placed on a backlog of requirements that still need to be addressed. At the
beginning of every workday, a Scrum meeting takes place. At the end of each sprint, the
team demonstrates the software to the client. Based on the results of the sprint, a new
plan is begun for the next sprint.

Scrum meetings are one of the most interesting aspects of the Scrum development
process. The team members attend the meetings, but anyone can attend. However, with

10
 very few exceptions, only team members may speak. One prominent exception is
management providing feedback on the business relevance of the work being performed
by the specific team. In this meeting, all team members stand in a circle and report on
what they accomplished during the previous day, state what they plan to do today, and
describe anything that blocked progress the previous day. To enable continuous progress,
any block identified is dealt with within one hour. From a Scrum point of view, it is better
to make a “bad” decision about a block at this point in development than to not make a
decision. Because the meetings take place each day, a bad decision can easily be
undone. Larman suggests that each team member should report any additional
requirements that have been uncovered during the sprint and anything that the team
member learned that could be useful for other team members to know.

Figure 1-15. Scrum Methodology

Selecting the Appropriate Development Methodology

Because there are many methodologies, the first challenge faced by analysts is selecting
which methodology to use. Choosing a methodology is not simple, because no one methodology
is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards
and policies to guide the choice of methodology. You will find that organizations range from having
one “approved” methodology to having several methodology options to having no formal policies
at all.
Figure 1-16 summarizes some important criteria for selecting a methodology. One
important item not discussed in this figure is the degree of experience of the analyst team. Many

11
of the RAD-based methodologies require the use of new tools and techniques that have a
significant learning curve. Often these tools and techniques increase the complexity of the project
and require extra time for learning. However, once they are adopted and the team becomes
experienced, the tools and techniques can significantly increase the speed at which the
methodology can deliver a final system.

Figure 1-16. Criteria for Selecting Methodology

• Clarity of User Requirements. When the user requirements for a system are unclear, it
is difficult to understand them by talking about them and explaining them with written
reports. Users normally need to interact with technology to really understand what a new
system can do and how to best apply it to their needs. RAD and agile methodologies are
usually more appropriate when user requirements are unclear.
• Familiarity with Technology. When the system will use new technology with which the
analysts and programmers are not familiar, early application of the new technology in the
methodology will improve the chance of success. If the system is designed without some
familiarity with the base technology, risks increase because the tools might not be capable
of doing what is needed. Throwaway prototyping-based methodologies are particularly
appropriate if users lack familiarity with technology because they explicitly encourage the
developers to develop design prototypes for areas with high risks. Phased development-
based methodologies create opportunities to investigate the technology in some depth
before the design is complete. Also, owing to the programming-centric nature of agile
methodologies, both XP and Scrum are appropriate.
• System Complexity. Complex systems require careful and detailed analysis and design.
Throwaway prototyping-based methodologies are particularly well suited to such detailed
analysis and design, but prototyping-based methodologies are not. The traditional
structured design-based methodologies can handle complex systems, but without the

12
 ability to get the system or prototypes into the users’ hands early on, some key issues may
be overlooked. Although phased development-based methodologies enable users to
interact with the system early in the process, we have observed that project teams who
follow these tend to devote less attention to the analysis of the complete problem domain
than they might using other methodologies. Finally, agile methodologies are a mixed bag
when it comes to system complexity. If the system is going to be a large one, agile
methodologies will perform poorly. However, if the system is small to medium size, then
agile approaches will be excellent.
• System Reliability. System reliability is usually an important factor in system
development; after all, who wants an unreliable system? However, reliability is just one
factor among several. For some applications, reliability is truly critical (e.g., medical
equipment, missile-control systems), whereas for other applications (e.g., games, Internet
video) it is merely important. Because throwaway prototyping methodologies combine
detailed analysis and design phases with the ability for the project team to test many
different approaches through design prototypes before completing the design, they are
appropriate when system reliability is a high priority. Prototyping methodologies are
generally not a good choice when reliability is critical because it lacks the careful analysis
and design phases that are essential for dependable systems. However, owing to the
heavy focus on testing, evolutionary and incremental identification of requirements, and
iterative and incremental development, agile methods may be the best overall approach.
• Short Time Schedules. RAD-based and agile methodologies are excellent choices when
timelines are short because they best enable the project team to adjust the functionality in
the system based on a specific delivery date, and if the project schedule starts to slip, it
can be readjusted by removing functionality from the version or prototype under
development. Waterfall-based methodologies are the worst choice when time is at a
premium because they do not allow easy schedule changes.
• Schedule Visibility. One of the greatest challenges in systems development is
determining whether a project is on schedule. This is particularly true of the structured
design methodologies because design and implementation occur at the end of the project.
The RAD-based methodologies move many of the critical design decisions earlier in the
project to help project managers recognize and address risk factors and keep expectations
in check. However, given the daily progress meetings associated with Agile approaches,
schedule visibility is always on the proverbial front burner.

13