Search Results for:

The Spiral Model

Barry W. Boehm is a mathematician and TRW Professor of Software Engineering, Computer Science Department Director, USC Center for Software Engineering. He started working as a Programmer-Analyst at General Dynamics in 1955 and switched to the Rand Corporation four years later where he was Head of the Information Sciences Department until 1973. From 1973 to 1989 he served as Chief Scientist of the Defense Systems Groupworked at TRW. Afterward he served until 1992 within the U.S. Department of Defense as Director of the Defense Advanced Research Projects Agency (DARPA) Information Science and Technology Office, and as Director of the DDR&E Software and Computer Technology Office.

He is known for his many contributions to software engineering including “the Constructive Cost Model (COCOMO), the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination and two advanced software engineering environments: the TRW Software Productivity System and Quantum Leap Environment.” He defined the Spiral Model in his 1986 article “A Spiral Model of Software Development and Enhancement.” The Spiral Model is a risk based approach which combines characteristics of evolutionary prototyping with the Waterfall Model. As envisioned by Boehm, the Spiral Model is intended for large, complex projects with durations of 6 months to 2 years. This iterative model influenced Model-Based Architecture and Software Engineering (MBASE) and Extreme Programming.

The United States Army adopted the Spiral Model for the development and upgrades of its Future Combat Systems (FCS) modernization program. Officially launched in 2003, FCS was foreseen to equip troops with manned and unmanned vehicles connected through an extraordinarily fast and flexible real-time battlefield network. The project was apportioned to four 2-year development spirals. Spiral 1 was scheduled to begin in FY2008 and deliver prototypes for use and evaluation. Following a successful Spiral 1 evaluation, Spiral 2 was scheduled to commence in FY2010. Production deployment as planned for 2015.

In August 2005, Boeing announced the completion of the project’s first major milestone, the Systems of Systems Functional Review. Boeing Company and Science Applications International Corporation (SAIC) we’re co-leads for the systems integration, coordinating more than 550 contractors and subcontractors in 41 states. By October 2005, the Pentagon recommended delaying the FCS project due to the high cost impact of the Iraq War, Hurricane Katrina relief efforts and the anticipation of future budget reductions. Budget cuts did arise and the project was canceled in June 2009. While the Spiral Model is suited for large projects, it never had the chance to prove its benefits in the intricate $3B interoperable, distributed combat related mission.

Today the Spiral Model has found a welcome home in the gaming industry. The large (>$3M) projects and continuously shifting goals of gaming systems development and resolutions achieved through evolutionary prototyping has created a demand for the process. For every spiral’s iteration, there are four activity quadrants which are:

Determine objectives, alternatives and constraints:
1. System requirements are defined in as much detail as possible and include artifacts for functionality, performance, hardware/software interfaces, key success metrics, etc.
2. Alternatives such as build vs. buy, can we reuse existing components or do we sub-contract are examined
3. Constraints such as cost, schedule and interfaces are addressed
Identify and resolve risks, evaluate alternatives:
1. All possible and available alternatives for developing a cost effective project are evaluated and strategies developed to determinate their use
2. Identify and resolve all the possible risks in the project such as lack of experience, new technology, tight schedules, poor process, etc.
3. Resolve any found risks and uncertainties. Subset reviews may be commissioned to investigate other process models until all high risk situations are resolved
Development and test: Prototype the system from the preliminary design. Follow the usual pattern of create and review design, code, inspect code and test
Plan the next iteration:
1. Review the first prototype for strengths, weaknesses, and risks
2. Elicit the requirements for the second prototype
3. Plan and design the second prototype;
  1. Create the project plan
  2. Document the configuration management plan
  3. Construct a test plan
  4. Devise an installation plan

As the spirals progress and development intensifies, increasingly detailed system elaborations are defined, culminating in incremental releases of the system’s operational capability. A couple of the major problems with this approach are that spirals may continue indefinitely and each spiral is its own waterfall. It is iterative in terms of the delivery of evolutionary prototypes and linear in terms of how those prototypes are evaluated for risk and constructed. For the most part it’s best to avoid long-term project commitments due to potential changes in business priorities.

A Good SDLC = Team Empowerment

By Victor M Font Jr Leave a Comment

Team Empowerment, Public Domain Image — Public Domain Image from Pixabay.com

A good SDLC does not force developers to use any specific methodology such as Waterfall or Agile. Instead, it empowers project teams to decide which practices to use, within guidelines, for each project. Once the choice is made the teams remain on that pathway until production deployment.

Team empowerment is a greatly misunderstood concept. Empowerment does not mean senior leaders have abdicated their responsibility to lead their organizations. To the contrary, empowerment requires stronger leadership and accountability at the team level. Empowerment means allowing people at all levels of the organization to extend their decision making scope in order to furnish them with the latitude to more fully exploit their intrinsic resourcefulness, talents and skills. Empowerment leads to greater innovation, creativity, commitment and motivation; it broadens the breadth of individual and team contributions. Since the team has made the choice of which development practices to pursue, there is greater cohesiveness among its members.

Empowerment cannot be endowed without constraints. The last thing you want or need is for teams to select from any development model they desire. They might randomly choose any of the multitudes of models to be found on the net; or they may come up with their own model and call it “Because We Can.” If that’s allowed to happen, chaos becomes the rule the day. Restraint is found in limiting choices to among a preferred few. The select few are those practices that have been elected through management prerogative because they most closely align with IT strategy. Management continues to lead the organization, but has granted privilege to the project teams to choose how they control their implementations.

Having several practice models to pick from does not mean that everyone is going to be doing their own thing. That would defeat the purpose of the SDLC. The permitted models are subordinate to the overall SDLC framework. They are subsets of the grander design to achieve project success. They all have common deliverables and processes that bind them together to ensure consistency across the enterprise. They have to be agile enough to adapt to the organization’s culture and supple enough to be able to assimilate process improvements through the test of time. Depending on the team’s choice, the artifacts are flexible in terms of quantity of content, but are steadfast in the type and quality of content required, the documents needed, their naming conventions, their format and continuous improvement metrics.

In Chapter 2 of The Ultimate Guide to the SDLC, we examine, compare and synthesize best practices from twelve different historical models including waterfall, iterative and incremental varieties, RAD, agile variants, a hybrid and at least one that isn’t a model at all but a philosophy—Lean.

Are Your Requirements Good or Just Good Enough?

By Victor M Font Jr Leave a Comment

Are Your Requirements Good Enough — Leonardo da Vinci [Public domain], via Wikimedia Commons

As an operational definition, good requirements are cohesive, complete, consistent, correct, feasible, modifiable, necessary, prioritized, reusable, testable, traceable, verifiable and unambiguous. If requirements aren’t captured to this high standard, rework or project failure is the natural consequence. No one will ever get good requirements that meet this standard by walking into a room and asking the customers “What are your requirements?” This is not a disciplined enough approach. Yet, it’s what many companies do. Good requirements are elicited. The word “elicit” means to “draw out” which means the competency of requirements elicitation necessitates a great degree of interaction, organization and customer involvement to draw good requirements out of the users.

To help you evaluate whether or not you are eliciting good requirements, The Ultimate Guide to the SDLC includes a comprehensive requirements checklist to serve as a guide for your Business and Quality Assurance Analysts.

The good requirements quality checklist is partially reproduced below. It is a quality guide to ensure requirements meet the operational definition of good requirements. The checklist is based on the Requirements Verification Checklist released to the public domain in May 2008 by the United States of America State of Texas Department of Information Resources as part of Version 1.1 of the Texas Project Delivery Framework.^[1] In the book, each characteristic of good requirements applicable to the quality inspection is listed in alphabetical order, defined and reinforced by supporting questions intended to direct a quality review.

Cohesive: A set of requirements is cohesive if it relates to only one thing. All requirements in a set or group support the overall purpose and scope of the system or component under discussion, whether that is a business process definition, business rule, information flow, data flow or so forth.
Complete: To be complete, all known relevant requirements are documented and all conditions under which a requirement applies are stated. A BRD is complete if, and only if, it includes the following elements:
Consistent: Consistency demands that the requirement can be met without causing conflict or contradiction with any of the other requirements. Requirement should be stated in a way to allow the widest possible selection of implementation options.
Correct: Requirements must accurately describe the functionality to be built. Only the source of the requirements, the customers, users or stakeholders, can determine their correctness.
Feasible: Feasibility means each requirement is implementable within the existing infrastructure, budget, timeline and resources available to the team. The business analyst needs to work with the project team to make these determinations.
Necessary & Prioritized: Requirements must be ranked for importance and/or stability. A necessary requirement is one that is essential to meet business goals and objectives. A priority is assigned to each functional requirement or feature to indicate how essential it is to a particular solution release. If all requirements are considered equally important, it is difficult for the project team to respond to budget cuts, schedule overruns, staff turnover or new requirements added during development. Ranking requirements for stability is in terms of the number of expected changes to the requirement. Stable requirements are ready to be developed.
Measurable, Testable & Verifiable: Verifiable means that the requirement states something that can be confirmed by examination, analysis, test or demonstration. A good requirement does not contain words that are not testable and measurable. If it is impossible to ensure that the requirement is met in the solution, it should be removed or revised.
Traceable: Requirements are traceable if their origin is known and the requirement can be referenced or located throughout the solution. The requirement should be traceable to a goal stated in the project charter, vision document, business case or other initiating document. Requirements are traceable backwards and forwards.
Unambiguous: Requirements must be clear, concise, simple and free from ambiguity. They must be stated without technical jargon, acronyms (unless defined) or other obscure verbiage. Requirements express objective facts, not subjective opinions. Vague requirements are often misunderstood resulting in rework and corrective actions during the design, development and testing phases. If the requirement can be interpreted in more than one way, it should be removed or clarified.

Download the Requirements Verification Checklist to use with your your requirements elicitation efforts.

^[1] The Texas Project Delivery Framework is available from http://www.dir.state.tx.us/pubs/framework/extensions/

Who’s to Blame for Troubled Projects, IT or the Business?

By Victor M Font Jr Leave a Comment

There is enough empirical evidence to say that poor requirements contribute to the majority of project failures. Look at these study conclusions published over a 13 year period beginning in 1995:

Requirements problems have been proven to contribute to 20-25% of all project failures. The average project overran its budget 189% and its schedule by 222%—Chaos Report / The Standish Group 1995

Requirements Errors account for 70% to 85% of rework—Liffingwell, 1997

Poor requirements account for 71% of project failures—Grady, 1999

Between 40 and 60 per cent of all software defects can be attributed to bad requirements—Abbott, 2001

Only 34% of projects expected to finish on time; 52% had proposed functionality; 82% had time overruns; 43% had budget overruns—The Chaos Chronicles / The Standish Group 2004

Flawed Requirements Trigger 70% of Project Failures—Infotech Research, 2005

Gaps in the Technical Requirements accounted for more than 70% of program problems—United States Government Accountability Office, 2008

In addition to these startling conclusions about how poor requirements contribute to project rework and failures, the 1995 Chaos Report added that 94 out of every 100 projects require restarts, sometimes multiple restarts, citing a California Department of Motor Vehicles case study to illustrate the claim. The Standish Group reports, “Only 9% of projects in large companies were successful.” Medium size companies demonstrated a 16.2% success rate and small companies showed 28% successes. The most successful case study highlighted in the report is the Hyatt hotel reservation system. The report stated, “Hyatt had all the right ingredients for success: user involvement, executive management support, a clear statement of requirements, proper planning, and small project milestones.” Hyatt finished their project early and under budget.

You would think the statistics would reveal an improving trend line considering the advances made in system development methodologies. Instead, we observe the opposite with the best statistics in 1995 and a worsening trend over time leveling off at a 70% failure/rework rate since 2005. And this is only with the projects that have been surveyed. How many more are out there we don’t know about? The cost of these project failures and cancellations run into the high billions. The Chaos Report estimated American companies and government would spend $81 billion dollars (USD) on failed or canceled projects in 1995. How much more would that be in today’s dollars in light of the worsening failure rate?<

A February 2009 article by Jeff Roster, a member of the Gartner Blog Network, revealed 2008 worldwide spending statistics broken out by industry segment. The article predicted the growth rates through 2012 in IT spend for these industries which range from a low of 2.8% for manufacturing to 5.2% for Utilities. In 2008, total IT investment was just under $1.9 trillion dollars in these market segments which do not take into account government spending. If we apply the conservative 1995 Chaos Report metric of 25% for project failures to the 2008 spending statistic, it means that we can estimate that in 2008 $475 billion dollars was spent on failed or canceled projects worldwide.

Getting back to the question, "Who's to blame?" If the right ingredients for success are user involvement, executive management support, a clear statement of requirements, proper planning, and small project milestones as the Chaos Report indicates, then it's a combination of both the business and IT with the scales tipped toward the IT side of the equation.

The SDLC Triangle

By Victor M Font Jr Leave a Comment

Have you ever heard of the SDLC triangle? Probably not unless you’ve downloaded my free sample chapter or have read The Ultimate Guide to the SDLC. It’s something I invented to demonstrate the complementary nature of project management methods and the system development life cycle. In terms of importance to a project, the SDLC and a project management method are co-equals which complement each other. Together they harmonize to form a complete methodology for delivering high quality products to our customers that meet or exceed their expectations. Neither can stand on its own to deliver high value to the business. They each have different roles in support of business initiatives. Throughout the life cycle both of these methods work together to achieve business goals, drive the value equation and progress organizational maturity. Though their activities differ greatly, they interrelate and harmonize to produce superior results.

Project management is often expressed in terms of the constraints of scope, time and cost. This is also known as the project management triangle. Each side of the triangle represents a constraint. No side can be changed without affecting the others. At one time, “quality” or “performance” was considered a component of scope. The model has since been refined to delineate quality as a fourth constraint. Time is the period available to complete a project. Cost is the project’s budget. Scope is what must be done to complete the project’s deliverables. The three constraints often compete with each other: scope creep means increased time and higher cost, a tight time frame may mean higher costs and less scope, and a tight budget may mean less time and reduced scope. Quality may be at risk if there are changes to any of the constraints.

The SDLC is about quality, consistency and product delivery. Quality, consistency and product delivery are the outputs of a defined, managed, measurable, repeatable and reusable set of processes and practices. The processes and practices form the core framework of the SDLC. Where a project is defined by its constraints, the SDLC is defined by its freedoms and empowerment. The SDLC empowers a project team to choose from among several approved pathways to deliver the highest quality products possible in the shortest amount of time and at the lowest possible cost.

Scope is a constraint that SDLC processes liberate by managing scope creep. Scope creep is a project killer. In The Ultimate Guide to the SDLC, I provide simple, effective, practical examples on how to manage scope creep during requirements workshops. Let’s be clear, project scope will change during the course of a project. That’s because business priorities are fluid and may drive changes in projects so that evolving current needs are met. It’s how we manage scope that’s important. We’ll never be able to eliminate scope creep, but we can manage it effectively so it doesn’t become the constraint that kills our project. In most cases, managing scope creep begins with the project’s business analyst.

Consistency of process helps keep the cost constraint under control by practicing repeatable, measurable and defined algorithms. Let’s be pragmatic. Whenever we practice something, we get good at it. It doesn’t matter if we’re talking about music and the arts or sports or anything else. The old adage is “Practice makes perfect.” If we do something the same way over and over again, not only will we get good at it; we’ll find ways to improve what we are doing so we can do it faster, better and cheaper.

The schedule constraint is complemented by the SDLC’s timely delivery of a quality product that meets or exceeds customers’ expectations. If we manage scope creep effectively and are consistent in our ability to repeat and improve our processes, not only will we deliver a product on time, there may even be enough wiggle room in the schedule to address lower priority items or deliver the product ahead of the due date. Compare the project management and SDLC triangles below:

The Project Management Triangle — Project Management Triangle

The central attribute of each of these triangles is quality. In the project management method, quality is constrained by changes to any of the other three dimensions. In the SDLC, quality processes are built in from day one and remain a continuous activity throughout the various phases of the life cycle. As SDLC processes become second nature to development teams, quality is enhanced because the processes are being measured to support a continuous improvement cycle. Continuous improvement is an on-going effort to improve our products, processes and services. The SDLC framework provides methods in which we can constantly evaluate and improve our processes and practices in terms of their efficiency, effectiveness and flexibility.

« Previous Page
1
…
3
4
5
6
7
…
12
Next Page »

Search Results for:

The Spiral Model

A Good SDLC = Team Empowerment

Are Your Requirements Good or Just Good Enough?

Who’s to Blame for Troubled Projects, IT or the Business?

The SDLC Triangle

Testimonials

Consulting Services

Copyright Notice

Copyright © 2010–2026 Victor M. Font Jr.

Recent Posts

Recent Comments

Search Results for:

Testimonials

Consulting Services

Copyright Notice

Copyright © 2010–2026 Victor M. Font Jr.

Recent Posts

Recent Comments

Tags