Вы находитесь на странице: 1из 25

Software Development Lifecycle

Each phase in the life cycle has its own process and deliverables that feed into the next
phase.  There are typically 5 phases starting with the analysis and requirements
gathering and ending with the implementation.  Let’s look in greater detail at each
phase:

Requirements Gathering/Analysis

This phase is critical to the success of the project.  Expectations (whether of a client or
your team) need to be fleshed out in great detail and documented.  This is an iterative
process with much communication taking place between stakeholders, end users and
the project team.  The following techniques can be used to gather requirements:

 Identify and capture stakeholder requirements using customer interviews and


surveys.
 Build multiple use cases to describe each action that a user will take in the new
system.
 Prototypes can be built to show the client what the end product will look like. 
Tools like Omnigraffle, HotGloo and Balsalmiq are great for this part of the process.
In a corporate setting, this means taking a look at your customers, figuring out what
they want, and then designing what a successful outcome would look like in a new bit of
software.

Design 

Technical design requirements are prepared in this phase by lead development staff that
can include architects and lead developers.  The Business Requirements are used to
define how the application will be written.  Technical requirements will detail database
tables to be added, new transactions to be defined, security processes and hardware
and system requirements.

Let’s look in more detail at some of the activities involved in this stage:

Risk analysis 

 Threats and vulnerabilities which may arise from interactions with other systems.
 External or legacy code needs to be analyzed to determine if there are security
vulnerabilities.
 High-risk privacy projects could require review with a legal department. This
review should consider what personal data to collect, how to collect it, and
permissions/authorizations to make changes. This type of review is especially necessary
with corporate projects.

Functional Specifications 

 Includes a description of interface requirements such as definition of data entry


fields (allow numeric or alpha only, can it be left blank?)
 Important details, like: can date entered be before current date? What timezone
will user logins default to?
 Workflow – after clicking approve button, which screen appears next?
 Audit trail for every update on the database. This is where error monitoring and
logging tools can be useful.

Non-Functional Specifications

 Extensibility of the system – will current system easily allow new enhancements or
features with the next rollout? This is critical for any application that you’ll be adding
new features and updating often.
 Has the current or future capacity been analyzed for database requirements? Will
the current build plan result in capacity issues shortly after you finish building?
 Performance and response time – Has the expected response time been
determined?
 Resource Constraints – Are there constraints that need to be taken into
consideration in this phase? Common ones include disk space, bandwidth, etc.

Coding 

This phase is the actual coding and unit testing of the process by the development
team.  After each stage, the developer may demonstrate the work accomplished to the
Business Analysts and tweaks and enhancements may be required.  It’s important in this
phase for developers to be open-minded and flexible if any changes are introduced. 
This is normally the longest phase of the SDLC.  The finished product here is input to the
Testing phase.

Testing

Once the application is migrated to a test environment, different types of testing will be
performed including integration and system testing.  User acceptance testing is the last
part of testing and is performed by the end users to ensure the system meets their
expectations.  At this point, defects may be found and more work may be required in
the analysis, design or coding.  Once sign-off is obtained by all relevant parties,
implementation and deployment can begin.

Implementation/Deployment

The size of the project will determine the complexity of the deployment.  Training may
be required for end users, operations and on-call IT staff.  Roll-out of the system may be
performed in stages starting with one branch then slowly adding all locations or it could
be a full blown implementation.

One of two methods can be followed in a SDLC process.  Waterfall is the more
traditional model and has a well-structured plan and requirements to be followed.  This
method works well for large projects that may take many months to develop.  The Agile
Methodology is more flexible in the requirements, design and coding process and is
very iterative.  This process works best for smaller projects and expectations of
continuous improvement to the application.  Whether you use one over the other will
also depend to a large extent on the corporation and skills of the IT dept.
Waterfall Method
First introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall
model is a software development process. The waterfall model emphasizes that a logical
progression of steps be taken throughout the software development life cycle (SDLC),
much like the cascading steps down an incremental waterfall. While the popularity of
the waterfall model has waned over recent years in favor of more agile methodologies,
the logical nature of the sequential process used in the waterfall method cannot be
denied, and it remains a common design process in the industry.

Throughout this article we’ll examine what specific stages make up the core of the
waterfall model, when and where it is best implemented, and scenarios where it might
be avoided in favor of other design philosophies.

The Six Stages of Falling Water

Actually implementing a waterfall model within a new software project is a rather


straightforward process, thanks in large part due to the step-by-step nature of the
method itself. There are minor differences in the numbers and descriptions of the steps
involved in a waterfall method, depending on the developer you ask (and even the year
during which you ask him or her). Regardless, the concepts are all the same and
encompass the broad scope of what it takes to start with an idea and develop a full-
scale, live application.
 Requirements: During this initial phase, the potential requirements of the application
are methodically analyzed and written down in a specification document that serves as the basis
for all future development. The result is typically a requirements document that
defines what the application should do, but not how it should do it.
 Analysis: During this second stage, the system is analyzed in order to properly generate
the models and business logic that will be used in the application.
 Design: This stage largely covers technical design requirements, such as programming
language, data layers, services, etc. A design specification will typically be created that outlines
how exactly the business logic covered in analysis will be technically implemented.
 Coding: The actual source code is finally written in this fourth stage, implementing all
models, business logic, and service integrations that were specified in the prior stages.
 Testing: During this stage, QA, beta testers, and all other testers systematically discover
and report issues within the application that need to be resolved. It is not uncommon for this
phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to
be properly squashed.
 Operations: Finally, the application is ready for deployment to a live environment.
The operations stage entails not just the deployment of the application, but also subsequent
support and maintenance that may be required to keep it functional and up-to-date.

The Advantages of the Waterfall Model

While the waterfall model has seen a slow phasing out in recent years in favor of
more agile methods, it can still provide a number of benefits, particularly for larger
projects and organizations that require the stringent stages and deadlines available
within these cool, cascading waters.

 Adapts to Shifting Teams: While not necessarily specific to the waterfall model only,
using a waterfall method does allow the project as a whole to maintain a more detailed, robust
scope and design structure due to all the upfront planning and documentation stages. This is
particularly well suited to large teams that may see members come and go throughout the life
cycle of the project, allowing the burden of design to be placed on the core documentation and
less on any individual team member.
 Forces Structured Organization: While some may argue this is a burden rather than a
benefit, the fact remains that the waterfall model forces the project, and even the organization
building said project, to be extraordinarily disciplined in its design and structure. Most sizable
projects will, by necessity, include detailed procedures to manage every aspect of the project,
from design and development to testing and implementation.
 Allows for Early Design Changes: While it can be difficult to make design changes later
in the process, the waterfall approach lends itself well to alterations early in the life cycle. This is
great when fleshing out the specification documents in the first couple stages with the
development team and clients, as alterations can be made immediately and with minimal effort,
since no coding or implementation has actually taken place up to that point.
 Suited for Milestone-Focused Development: Due to the inherent linear structure of a
waterfall project, such applications are always well-suited for organizations or teams that work
well under a milestone- and date-focused paradigm. With clear, concrete, and well understood
stages that everyone on the team can understand and prepare for, it is relatively simple to
develop a time line for the entire process and assign particular markers and milestones for each
stage and even completion. This isn’t to suggest software development isn’t often rife with
delays (since it is), but waterfall is befitting the kind of project that needs deadlines.

The Disadvantages of the Waterfall Model

While some things in software development never really change, many others often fall
by the wayside. While Dr. Royce’s initial proposal of what is now known as the waterfall
model was groundbreaking when first published back in 1970, over four decades later, a
number of cracks are showing in the armor of this once heralded model.

 Non-adaptive Design Constraints: While arguably a whole book could be written on


this topic alone, the most damning aspect of the waterfall model is its inherent lack of
adaptability across all stages of the development life cycle. When a test in stage five reveals a
fundamental flaw in the design of the system, it not only requires a dramatic leap backward in
stages of the process, but in some cases, can be often lead to a devastating realization
regarding the legitimacy of the entire system. While most experienced teams and developers
would (rightfully) argue that such revelations shouldn’t occur if the system was properly
designed in the first place, not every possibility can be accounted for, especially when stages are
so often delayed until the end of the process.
 Ignores Mid-Process User/Client Feedback: Due to the strict step-by-step process that
the waterfall model enforces, another particularly difficult issue to get around is that user or
client feedback that is provided late into the development cycle can often be too little, too late.
While project managers can obviously enforce a process to step back to a previous stage due to
an unforeseen requirement or change coming from a client, it will be both costly and time-
consuming, for both the development team and the client.
 Delayed Testing Period: While most of the more modern SDLC models attempt to
integrate testing as a fundamental and always-present process throughout development, the
waterfall model largely shies away from testing until quite late into the life cycle. This not only
means that most bugs or even design issues won’t be discovered until very late into the process,
but it also encourages lackadaisical coding practices since testing is only an afterthought.

In spite of going through an explicit testing phase during implementation of


a waterfall model project, as discussed above, this testing is often too little, too
late. In addition to the normal testing phase, you and your team should strongly
consider introducing an effective error management tool into the development life cycle
of your project. Airbrake’s error monitoring software provides real-time error monitoring
and automatic exception reporting for all your development projects. Airbrake’s state of
the art web dashboard ensures you receive round-the-clock status updates on your
application’s health and error rates. No matter what you’re working on, Airbrake easily
integrates with all the most popular languages and frameworks. Plus, Airbrake makes it
easy to customize exception parameters, while giving you complete control of the active
error filter system, so you only gather the errors that matter most.

Rapid Application Development (RAD)


Rapid application development (RAD) describes a method of software development which
heavily emphasizes rapid prototyping and iterative delivery. The RAD model is, therefore, a
sharp alternative to the typical waterfall development model, which often focuses largely on
planning and sequential design practices. First introduced in 1991 in James Martin’s book by the
same name, rapid application development has become one of the most popular and powerful
development methods, which falls under the parental category of agile development
techniques.

Perhaps the biggest advantage of rapid application development is its inherent synergy
with the requirements of the medium itself: software. Whereas other forms of creation,
such as a towering skyscraper or a sleek new automobile, require meticulous planning
and logical development, the very essence of software is both malleable and in constant
evolution. Since code itself — and by extension, the software which is powered by said
code — can be morphed quickly and easily during development, software is inherently
adaptable, lending itself well to iteration and experimentation.

By utilizing a rapid application development method, designers and developers can


aggressively utilize knowledge and discoveries gleaned during the development process
itself to shape the design and or alter the software direction entirely.

Below we’ll explore a few of the primary uses of rapid application development, in both
historical and theoretical scenarios, as well as analyze both the pros and cons of this
attractive method of software creation.

A Few RADical Steps

Getting started with rapid application development generally follows a cyclical process
that includes four basic steps:
1. Planning Requirements: During this initial stage designers, developers, and users come
to a rough agreement on project scope and application requirements, so that future stages with
prototyping can begin.
2. User Design: User feedback is gathered with heavy emphasis on determining the system
architecture. This allows initial modeling and prototypes to be created. This step is repeated as
often as necessary as the project evolves.
3. Rapid Construction: Once basic user and system design has begun, the construction
phase is where most of the actual application coding, testing, and integration takes place. Along
with User Design, the Rapid Construction phase is repeated as often as necessary, as new
components are required or alterations are made to meet the needs of the project.
4. Cutover: The final Cutover (or Transition) stage allows the development team time to
move components to a live production environment, where any necessary full-scale testing or
team training can take place.

User Interfacing, Early and Often

In the slow, methodical software development methods of olde, receiving useful and
concrete user feedback has been inherently difficult, costly, and time consuming. Long
meetings and phone calls, and even longer design docs, were a necessary evil to lay out
even the most basic concrete plans of proper software design. With typical waterfall
methods, rudimentary user feedback was often many months if not years in the future,
after all planning and most development had taken place.

In stark contrast, one of the biggest benefits to rapid application development is the
ability to both easily and frequently receive feedback from users who are directly
interfacing with the application during development and prototyping. While this
advantage is most readily visible within the UI/UX components of the system, iterative
design intrinsically means user feedback can be at the forefront of the process.

A Prototype of Prototyping

While various forms of RAD emphasize slightly different concepts and design
methodologies, a common inclusion in most RAD systems is the heavy use
of prototyping. As an alternative to heavy-handed design specifications, the use of
prototypes throughout the development cycle provides for a number of unique benefits:

 User Involvement: Unlike a traditional waterfall model, which requires the design team to
discuss with users what features or implementations might be required and plan specifications
around those ideas, a rapid prototype allows users to actually use the software and provide
feedback on a live system, rather than attempting to provide abstract evaluations of a design
document.
 Feasibility: Prototyping allows the development team to quickly evaluate the feasibility of
a particularly complex or risky component right out of the gate. By recognizing and working on
complicated systems early in the development lifecycle, the software will be more robust, less
error-prone, and better structured for future design additions.
 Error Reduction & Debugging: With rapid prototype releases during a project, it is far
more likely that errors will be both discovered (and subsequently squashed) far earlier in the
development cycle than with a typical waterfall approach.

Pros of Rapid Application Development

While there are a number of benefits to using a rapid application development method,
we’ve highlighted a handful of the most crucial when considering whether RAD is the
right choice for your next project.

 Measurable Progress: With frequent iterations, components, and prototypes coming


down the pipe, progress on the overall project, as well as lesser segments, can be easily
measured and evaluated to maintain schedules and budgets.
 Quickly Generate Productive Code: As a larger percentage of active software developers
move into multi-discipline roles (i.e. full-stack developers), a RAD methodology allows skilled
team members to quickly produce prototypes and working code to illustrate examples that
might otherwise take weeks or months to see the light of day using a slower development
technique.
 Compartmentalization of System Components: Much in the same way that object-
oriented programming practices keep objects and components quarantined from one another,
RAD inherently has the same beneficial impact on the components generated during
development. By forcing designers and developers to create components that are functional and
independent on their own, to be used in an iterative release or prototype, each element within
the overall software system is compartmentalized and therefore easily modified as the needs of
the software evolve.
 Rapid, Constant User Feedback: As discussed above, obtaining relevant user feedback
during development is invaluable. RAD methodologies allow for near-constant user interfacing
and feedback through frequent iterations and prototype releases, giving the entire team
priceless evaluation and criticism when it’s needed most.
 Early Systems Integration: While most waterfall method software projects must, by their
very nature, wait until the tail end of the lifecycle to begin integrations with other systems or
services, a rapidly developed application becomes integrated almost immediately. By requiring
early integrations within a prototype, a RAD system quickly identifies any errors or complications
within integrations and forces immediate resolutions.
 Simple Adaptability: During development, software is a fairly malleable form. Since code
can be changed that dramatically alters the entire system or generates new components, it is to
the advantage of the development team to make use of this flexibility early and often, by
iterating and prototyping potential concepts or ideas throughout development.

Cons of Rapid Application Development

No software development method is without fault and RAD is no different. While the
benefits typically outweigh the disadvantages, we’ll examine a few of the most likely
roadblocks when implementing RAD into a new project.

 Requires Modular Systems: Since each component within the system should be iterable
and testable on its own accord, the overall system design when using RAD requires that each
component be modular, allowing elements to be swapped in and out or altered by a variety of
team members.
 Difficulty within Large-Scale Projects: While rapid application development methods lead
to far greater flexibility during the design and development process, it will also tend to reduce
control and restrictions. While this isn’t inherently negative, properly managing this added
flexibility and volatility within the scope of the whole project can be difficult for larger
applications.
 Demands Frequent User Interfacing: Gaining user insight and feedback early and often is
certainly a benefit from a design perspective, but this double-edged sword requires that the
team be both willing and able to communicate with users on a much more frequent basis, in
comparison to a typical waterfall development method.
 Depends Upon Skilled Developers: While many developers these days are multi-
disciplined, it is worth noting that use of RAD techniques does require a greater overall skill
across the development team, in order to quickly adapt as the system and components evolve.

Agile Model
Back in February of 2001, a small group of seventeen software developers met in the
high elevations of Snowbird, Utah to discuss software development methodologies. Out
of this assemblage emerged the Manifesto for Agile Software Development, a
publication that outlined the group’s vision for lightweight software development, and
which would go on to dramatically shape the landscape of modern software
development for years to come, up to the present day.

From the four fundamental values this group of developers set forth emerged one of
the most widely adopted software development methodologies in modern history –
agile model. At its core, the agile model emphasizes the need for every project to be
handled differently, based on the individual needs of the project, the schedule, and the
team behind it. Unlike other SDLC models, Agile focuses less on specific requirements or
guidelines, and far more on abstraction of these best practices to allow for greater
flexibility, or agility, during the development process.

Throughout this article we’ll dive deep into what the agile model is, the values and
principles that make up the core structure, and the overall advantages and
disadvantages of utilizing it during modern software development life cycles.

The Agile Values

Within the original Manifesto for Agile Software Development the authors focused on


four fundamental, core values that underpin solid software development.

 Individuals and interactions: Rather than solely emphasizing systems and tools, the focus
should be on the people within the team and the interactions they have while working together
on the project. For a project to be successful, it should adapt to not just the systems or budget
available, but most importantly to the people working on it. If team members are efficient and
effective at working together, the end result will be a polished and optimized product.
 Working software: While documentation can certainly be very beneficial during
development, it is far better to produce a working product, or even a simple prototype, that
illustrates the design goals or the components used throughout the application. This is
beneficial not only to other team members working on development, management, and
marketing, but especially to clients or testers who would otherwise be forced to rely on a
handful of documents and photoshopped illustrations to understand how the application is
expected to function.
 Customer collaboration: As with Rapid Application Development, or any other
development model born from the roots of the agile model, it is critical that the project be
constantly open, willing, and able to respond to customer feedback and behavior. By keeping
customers or clients in the loop throughout the entire life cycle, everyone involved will be on the
same page and there will not be any surprises at the end or massive rewrites necessary because
a module or integration wasn’t clear for all parties involved.
 Responding to change: Perhaps the most critical principle across the entirety of the agile
model is the ability for the project to adapt and respond to the ever-changing needs of
everyone and everything involved. As development progresses, software technologies will
change, the team will shift, clients will hem and haw, and throughout it all, the project should
remain malleable and remain capable of adapting along with these needs.

The Agile Principles

As further outlined in the Manifesto, the agile model is described using twelve key


principles, atop which the development life cycle should take place.
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.

Pros of the agile model

 Emphasis of Modern Techniques: While a core value of the agile model places emphasis


on people over technologies, stepping outside the realm of technologies themselves and into a
pure focus on techniques brings about powerful, agile practices such as test-driven
development, automated unit testing, refactoring, and iterative development.
 Highly Adaptive: As one of the fundamental agile values states, a key component to
the agile model, and which partially makes it such a good launching pad for the entire software
development life cycle, is the capability of the project to rapidly adapt to any necessary changes.
Whether this is from rapid iterations informing the changing needs within the code or client
feedback forcing a reshaping of the sign-up procedures, a properly Agile project is able to
quickly and effectively change course as needed.
 Constant Customer Feedback: Although the constant communication with customers
and clients requires a dedicated team member to take on this responsibility, it is a critical
component to ensuring the success of the product from both a development perspective as well
as from that of the client.
 Allows for Iterative Development: Common models like the Iterative Model are based on
the fundamentals of the agile model, and for good reason: It allows the project to be started
with relatively little upfront planning or cost. From these early components the project can
evolve over time as new incremental iterations are made, constantly learning from past
iterations and improving on them for future updates.
Cons of the agile model

 Potential for Increased Technical Debt: The concept of technical debt describes the act of
implementing a solution that is easier to complete right now, in favor of the solution that may
be better overall in the long run. Within the scope of the agile model, it is not uncommon for
technical debt to begin to run rampant, as rapid development techniques and frequent
iterations often mean developers feel hurried and thus forced to implement faster but generally
less-than-ideal Band-Aids. This issue can largely be reduced by ensuring the team properly
integrates refactoring, pair programming, and other techniques which emphasize collaboration
amongst team members.
 Difficult to Make Additions within an Iteration: Often referred to as use cases in other
development models, a story in the agile model simply refers to a description of some new
project requirements. When actively utilizing the agile model for an ongoing project, it can
sometimes be difficult to implement a new story into the current iteration, since it forces
backtracking and heavy mental overhead on how to implement the new requirements of this
story into the existing iteration that has largely already being developed. In such cases, it is often
necessary to delay the implementation of the new story until the next iteration comes about.
 Minimal Emphasis on Documentation: Unlike more traditional models like the Waterfall
Model, the agile model largely forgoes initial efforts to heavily design and document the project
requirements or scope, in favor of getting into the meat of the project and beginning that
iterative process. This can be a challenge for some projects, particularly within development
teams which may not be accustomed to this style of agile development and which may have
more traditional experience instead.

Iterative Model
The iterative model is a particular implementation of a software development life
cycle (SDLC) that focuses on an initial, simplified implementation, which then
progressively gains more complexity and a broader feature set until the final system is
complete. When discussing the iterative method, the concept of incremental
development will also often be used liberally and interchangeably, which describes the
incremental alterations made during the design and implementation of each new
iteration.

Throughout this article we will take a deeper dive into the iterative model, including
where it originated from, how the process is actually implemented within a project, and
both the advantages and disadvantages that can arise from its use, so let’s get crackin’!
Origination and Implementations
While agile development models such as the iterative model have come to be a
generally accepted evolution over the traditional waterfall model of the past, it turns
out that iterative methods were used in projects as early as the 1950s. During this
period, the United States Air Force and NASA worked together to develop the X-15
hypersonic aircraft, using a largely iterative design process throughout. While this wasn’t
directly a software development project, the success of this process led NASA to use an
iterative model for the software development of Project Mercury, which was the first
manned spaceflight for the United States.

In the subsequent decades since, iterative methods have been implemented in a wide
range of software applications, from modern web applications and high-performance
gaming clients, to the United States Department of Defense’s software acquisition
standard document 5000.2, stating that “There are two approaches, evolutionary and
single step [waterfall], to full capability. An evolutionary approach is preferred.”

The Process

Unlike the more traditional waterfall model, which focuses on a stringent step-by-step


process of development stages, the iterative model is best thought of as a cyclical
process. After an initial planning phase, a small handful of stages are repeated over and
over, with each completion of the cycle incrementally improving and iterating on the
software. Enhancements can quickly be recognized and implemented throughout each
iteration, allowing the next iteration to be at least marginally better than the last.

 Planning & Requirements: As with most any development project, the first step is go
through an initial planning stage to map out the specification documents, establish software or
hardware requirements, and generally prepare for the upcoming stages of the cycle.
 Analysis & Design: Once planning is complete, an analysis is performed to nail
down the appropriate business logic, database models, and the like that will be required at this
stage in the project. The design stage also occurs here, establishing any technical requirements
(languages, data layers, services, etc) that will be utilized in order to meet the needs of
the analysis stage.
 Implementation: With the planning and analysis out of the way, the
actual implementation and coding process can now begin. All planning, specification, and
design docs up to this point are coded and implemented into this initial iteration of the project.
 Testing: Once this current build iteration has been coded and implemented, the next
step is to go through a series of testing procedures to identify and locate any potential bugs
or issues that have have cropped up.
 Evaluation: Once all prior stages have been completed, it is time for a
thorough evaluation of development up to this stage. This allows the entire team, as well as
clients or other outside parties, to examine where the project is at, where it needs to be, what
can or should change, and so on.

Now the real fun begins! This is the crux of the entire iterative model, whereby the most
recently built iteration of the software, as well as all feedback from
the evaluation process, is brought back to the planning & development stage at
the top of the list, and the process repeats itself all over again.

Advantages of the Iterative Model

 Inherent Versioning: It is rather obvious that most software development life cycles will
include some form of versioning, indicating the release stage of the software at any particular
stage. However, the iterative model makes this even easier by ensuring that newer iterations are
incrementally improved versions of previous iterations. Moreover, in the event that a new
iteration fundamentally breaks a system in a catastrophic manner, a previous iteration can
quickly and easily be implemented or “rolled back,” with minimal losses; a particular boon for
post-release maintenance or web applications.
 Rapid Turnaround: While it may seem like each stage of the iterative process isn’t all
that different from the stages of a more traditional model like the waterfall method — and
thus the process will take a great deal of time — the beauty of the iterative process is that each
stage can effectively be slimmed down into smaller and smaller time frames; whatever is
necessary to suit the needs of the project or organization. While the initial run through of all
stages may take some time, each subsequent iteration will be faster and faster, lending itself to
that agile moniker so very well, and allowing the life cycle of each new iteration to be trimmed
down to a matter of days or even hours in some cases.
 Suited for Agile Organizations: While a step-by-step process like the waterfall
model may work well for large organizations with hundreds of team members, the iterative
model really starts to shine when its in the hands of a smaller, more agile team. Particularly
when combined with the power of modern version control systems, a full “iteration process” can
effectively be performed by a number of individual team members,
from planning and design through to implementation and testing, with little to no need
for outside feedback or assistance.
 Easy Adaptability: Hinging on the core strength of constant, frequent iterations coming
out on a regular basis, another primary advantage of the iterative model is the ability to rapidly
adapt to the ever-changing needs of both the project or the whims of the client. Even
fundamental changes to the underlying code structure or implementations (such as a new
database system or service implementation) can typically be made within a minimal time frame
and at a reasonable cost, because any detrimental changes can be recognized and reverted
within a short time frame back to a previous iteration.

Disadvantages of the Iterative Model

 Costly Late-Stage Issues: While not necessarily a problem for all projects, due to the
minimal initial planning before coding and implementation begin, when utilizing an iterative
model, it is possible that an unforeseen issue in design or underlying system architecture will
arise late into the project. Resolving this could have potentially devastating effects on the time
frame and costs of the project as a whole, requiring a great deal of future iterations just to
resolve one issue.
 Increased Pressure on User Engagement: Unlike the waterfall model, which
emphasizes nearly all user/client engagement within the initial stages of the project during a
brief crunch time period, the iterative model often requires user engagement throughout the
entirety of the process. This is sometimes an unfortunate obligation, since each new iteration will
likely require testing and feedback from users in order to properly evaluate any necessary
changes.
 Feature Creep: Not only does the iterative model require user feedback throughout the
process, but this also inherently means the project may be subject to undesired feature creep,
whereby users experience the changes in each iteration, and are inclined to constantly put forth
new requests for additional features to be added to future versions.

With the adept agility and rapid turnaround of iterative model projects, you need an
exception management tool that can keep up the pace, without the overhead of user-
intervention. Airbrake’s error monitoring software provides real-time error monitoring
and automatic exception reporting for all your development projects. Airbrake’s state of
the art web dashboard ensures you receive round-the-clock status updates on your
application’s health and error rates. No matter what you’re working on, Airbrake easily
integrates with all the most popular languages and frameworks. Plus, Airbrake makes it
easy to customize exception parameters, while giving you complete control of the active
error filter system, so you only gather the errors that matter most.

Spiral Model
The Spiral Model – first described by Barry Boehm in 1986 – is a software development
methodology that aids in choosing the optimal process model for a given project. It combines
aspects of the incremental build model, waterfall model and prototyping model, but is
distinguished by a set of six invariant characteristics.

The Spiral Model is concerned primarily with risk awareness and management. The risk-
driven approach of the spiral model ensures your team is highly flexible in its approach,
but also highly aware of and prepared for the challenges they can expect to face down
the road. The spiral model shines when stakes are highest and major setbacks are not an
option.

1. Define Artifacts Concurrently (AKA “Plan everything, then re-plan those plans,


then plan some more.”)
In programming, an ‘artifact’ is any thing produced by people involved in the software
development process. The spiral model suggests that all artifacts in a given project
lifecycle should be defined fully from the start.

By planning each and every artifact of a project, your team reduces the potential for
technical debt and other mishaps. For example, what if your software is reliant on an
unusual, expensive or nearly obsolete piece of hardware? Or worse, what if after months
of work you realize what you’ve been striving to build cannot actually be achieved?
These types of issues can be disastrous.

Defining the scope of your entire project ensures you make the most of your time, and
avoid potentially catastrophic scenarios.

2. Four Essential Spiral Tasks

According to Boehm, every spiral model cycle consists of the following four tasks.

1. Consider critical-stakeholder objectives and constraints.


2. Elaborate and evaluate alternatives for achieving your objectives.
3. Identify and resolve risks attendant on choices of alternative solutions.
4. Stakeholders’ review and agree to proceed based on satisfaction of their critical
objectives and constraints.

The second characteristic of the Spiral Model – just like the first – is primarily concerned
with mitigating risk and reducing the potential for setbacks. In this case, focusing on the
wishes of critical stakeholders rises to the forefront. By performing these four activities,
your team ensures it won’t pursue options that don’t satisfy the core needs of the
project or present a high potential for risk.

3. Risk determines level of effort

Invariant three suggests that the effort allocated to a component of your project should
be determined by the severity of risk associated with that component. Take the
following chart for example:
We can see that after a certain point, the risk of losing market share far outweighs the
gains made in testing. Yes, testing is important, and reduces the likelihood of releasing a
buggy product, but speed in software development, speed is just as important (if not
more important). Don’t let your aversion to one risk hinder your ability to account for
another.

4. Risk determines degree of details

Invariant four says the potential for risk should determine how much attention you pay
to the details of the project you’re working on.

Let’s say you’re introducing a new suite of features to your application. Seems like a no-
brainer, right? More features = happier customers. Well…is that always the case? What if
your existing customers become overwhelmed by a new interface, or miss the way your
product behaved in the previous version? This situation could be pretty bad – you might
have some people jumping ship. It would have been best to gather more data and
implemented your changes more carefully.
On the other hand, let’s say it’s time to spruce up the language on your site to
communicate your offering more clearly. Is this a critical component of your success?
Yes. Is getting it wrong going to ruin you? Probably not. In this case, it’s probably safe to
throw a few different things up on your site, test them and see what sticks! Don’t sweat
the small stuff.

5. Use the anchor point milestones

The spiral model consists of three “Anchor Point Milestones.” They are:

 Life Cycle Objectives (LCO)


 Life Cycle Architecture (LCA)
 Initial Operational Capability (IOC)

These milestones serve as intermediate checkpoints to keep the project moving full
steam ahead in the right direction.

The LCO milestone checks to see if the technical approach to a project is well-defined


enough to proceed, and that stakeholder conditions are met. If “Yes”, continue. If no,
abandon ship or commit to another lifecycle and try again.

The LCA milestone checks that an optimal approach has been defined and that all major


risks are accounted for and planned for. If “Yes”, continue. If no, abandon ship or
commit to another lifecycle and try again.

The ICO milestone checks that adequate preparations have been made to satisfy
stakeholders prior to launch. This includes the software, site, users, operators, and
maintainers. If “Yes”, its time for launch! If no, abandon ship or commit to another
lifecycle and try again.

6. Focus on the system and its life cycle (Or “Software Isn’t Everything”)

Yes, the Spiral Model is a software development process, but that doesn’t mean you can
ignore non-software aspects of your business, or that every problem can be solved with
a bit of code.

If you’re experiencing troubles converting leads, that doesn’t mean you need to build a
sophisticated sales robot. Maybe it’s just time to re-visit your sales tactics! More
software is not always better, and you may find that throwing software at non-software
problems only complicates them more. Focus on the underlying goals of the project and
see to it that the solution you employ is the one best suited for meeting your win
conditions.

So…what now?

While the Spiral Model can be a bit odd to define, one thing is for sure – it’s a great way
to keep your eyes on the prize and minimize the risk you assume when building
something new. The invariants are great to keep in mind, but we’ve only just scratched
the surface of this interesting software development life cycle tool. Check out Boehm &
Hansen’s official write-up below to learn even more about Spiral Model.

V-Model
The V-Model is a unique, linear development methodology used during a software
development life cycle (SDLC). The V-Model focuses on a fairly typical waterfall-
esque method that follows strict, step-by-step stages. While initial stages are broad
design stages, progress proceeds down through more and more granular stages,
leading into implementation and coding, and finally back through all testing stages prior
to completion of the project.

In this article we’ll examine just what the V-Model actually entails, and why it may (or
may not) be suitable for certain types of projects or organizations.

The Process of the V-Model

Much like the traditional waterfall model, the V-Model specifies a series of linear stages
that should occur across the life cycle, one at a time, until the project is complete. For
this reason V-Model is not considered an agile development method, and due to the
sheer volume of stages and their integration, understanding the model in detail can be
challenging for everyone on the team, let alone clients or users.

To begin, it’s best to visualize the rough stages of the V-Model, as seen in the diagram
below.
The V-shape of the V-Model method represents the various stages that will be passed
through during the software development life cycle. Beginning at the top-left stage and
working, over time, toward the top-right tip, the stages represent a linear progression of
development similar to the waterfall model.

Below we’ll briefly discuss each of roughly nine stages involved in the typical V-Model
and how they all come together to generate a finished product.

Requirements

During this initial phase, system requirements and analysis are performed to determine
the feature set and needs of users. Just as with the same phase from the waterfall
model or other similar methods, spending enough time and creating thorough user
requirement documentation is critical during this phase, as it only occurs once.

Another component unique to the V-Model is that during each design stage, the


corresponding tests are also designed to be implemented later during
the testing stages. Thus, during the requirements phase, acceptance tests are designed.

System Design

Utilizing feedback and user requirement documents created during


the requirements phase, this next stage is used to generate a specification document
that will outline all technical components such as the data layers, business logic, and so
on.

System Tests are also designed during this stage for later use.

Architecture Design

During this stage, specifications are drawn up that detail how the application will link up
all its various components, either internally or via outside integrations. Often this is
referred to as high-level design.

Integration tests are also developed during this time.

Module Design

This phase consists of all the low-level design for the system, including detailed
specifications for how all functional, coded business logic will be implemented, such as
models, components, interfaces, and so forth.

Unit tests should also be created during the module design phase.

Implementation/Coding

At this point, halfway through the stages along the process, the actual coding and
implementation occur. This period should allot for as much time as is necessary to
convert all previously generated design and specification docs into a coded, functional
system. This stage should be fully complete once the testing phases begin.

Unit Testing

Now the process moves back up the far side of the V-Model with inverse testing,
starting with the unit tests developed during the module design phase. Ideally, this
phase should eliminate the vast majority of potential bugs and issues, and thus will be
the lengthiest testing phase of the project.

That said, just as when performing unit testing with other development models, unit
tests cannot (or should not) cover every possible issue that can occur in the system, so
the less granular testing phases to follow should fill in these gaps.
Integration Testing

Testing devised during the architecture design phase are executed here, ensuring that
the system functions across all components and third-party integrations.

System Testing

The tests created during system design are next executed, largely focusing on


performance and regression testing.

Acceptance Testing

Lastly, acceptance testing is the process of implementing all tests created during the
initial requirements phase and should ensure that the system is functional in a live
environment with actual data, ready for deployment.

Advantages of the V-Model

 Suited for Restricted Projects: Due to the stringent nature of the V-Model and its linear
design, implementation, and testing phases, it’s perhaps no wonder that the V-Model has been
heavily adopted by the medical device industry in recent years. In situations where the project
length and scope are well-defined, the technology is stable, and the documentation & design
specifications are clear, the V-Model can be a great method.
 Ideal for Time Management: Along the same vein, V-Model is also well-suited for
projects that must maintain a strict deadline and meet key milestone dates throughout the
process. With fairly clear and well understood stages that the whole team can easily
comprehend and prepare for, it is relatively simple to create a time line for the entire
development life cycle, while generating milestones for each stage along the way. Of course, the
use of BM in no way ensures milestones will always be met, but the strict nature of the model
itself enforces the need to keep to a fairly tight schedule.

Disadvantages of the V-Model

 Lacks Adaptability: Similar to the issues facing the traditional waterfall model on which


the V-Model is based, the most problematic aspect to the V-Model is its inability to adapt to any
necessary changes during the development life cycle. For example, an overlooked issue within
some fundamental system design that is then only discovered during the implementation phase
can present a severe setback in terms of lost man-hours as well as increased costs.
 Timeline Restrictions: While not an inherent problem with the V-Model itself, the focus
on testing at the end of the life cycle means that it’s all too easy to be pigeonholed at the end of
the project into performing tests in a rushed manner to meet a particular deadline or milestone.
 Ill-Suited for Lengthy Life Cycles: Like the waterfall model, the V-Model is completely
linear and thus projects cannot be easily altered once the development train has left the station.
V-Model is therefore poorly suited to handle long-term projects that may require many versions
or constant updates/patches.
 Encourages ‘Design-by-Committee’ Development: While V-Model is certainly not the
only development model to fall under this criticism, it cannot be denied that the strict and
methodical nature of the V-Model and its various linear stages tend to emphasize a
development cycle befitting managers and users, rather than developers and designers. With a
method like V-Model, it can be all too easy for project managers or others to overlook the vast
complexities of software development in favor of trying to meet deadlines, or to simply feel
overly confident in the process or current progress, based solely on what stage in the life cycle is
actively being developed.

Вам также может понравиться