Recent Articles

Adopting Agile/Iterative Software Development

Iterative Software Development

Choosing An Approach To Agile/Iterative Software Development

Adopting AGILE In Your SDLC Shop

iterDev Documentation Model

GitHub.com Projects

Convert Log4Net to NLog

Log4Net integration in ASP.NET MVC

iterDev.com Iterative Development Process

iterDev.com Iterative Development Process

Overview

The Iterative Development Process is based on the Software Development Life Cycle, known as the SDLC.

The primary focus of the Iterative Development Process is the interior SDLC development stages: Requirements Analysis, Design, Development, Integration & Test and Implementation. The task of completing a 'best efforts' attempt at each of these tasks, in order, is referred to as a Project Milestone Cycle where the major resource allocation is devoted to one or more Iterative Development Cycles. Other activities, or cycles, are specified to ensure coverage of all project deliverables, artifacts and metrics.

It is important to note that the iterDev Iterative Development Process is not a replacement for any other software development methodology. It is a set of mechanics and process automation tools used to magnify the effort of team members in meeting project deliverable artifact and metrics requirements.

Naming of Activities

In the iterDev Iterative Development Process the following nomenclature mappings are made between this process and the SDLC model:

Iterative Development Model SDLC
Requirements Management Cycle
Project Documentation Cycle
Requirements Analysis
Iterative Development Cycle (initial) Design (initial)
Project Milestone Cycle
Iterative Development Cycle
Development
Project Milestone Cycle
Project Build & Demonstration Cycle
Integration & Test
Project Milestone Cycle
Project Deployment Cycle
Implementation

Hierarchy of Activities

The Iterative Development Process is a hierarchical set of process specifications. Within the hierarchy, higher level processes call lower level processes. This separation of concerns is meant to facilitate use of process automation tools. Each process, or cycle, is defined so that any one of many Commercial Off-The-Shelf, COTS, tools might be used to meet project artifact requirements for the cycle.This is intentional and is the source of much of the mechanical advantage offered by this development process.

Working from the top level downward the entire reason for this process is to facilitate a Managed Project Release.

Managed Project Release

The work product of a Managed Project Release is a deployed application to beta or production environments.

In simple terms this means:

  • Perform a Requirements Management Cycle to generate release requirements
  • Perform 1 or more Project Milestone Cycles
  • (Optional activities �)
  • Perform a Project Deployment Cycle, to Test, Demo...
  • Review all artifacts
  • Update Project and Organization Standards as needed

As you can see, this activity relies primarily on performing a Requirements Management Cycle and 1 or more Project Milestone Cycles.

Drilling down, we see the activities contained in a Requirements Management Cycle and Project Milestone Cycle.

Requirements Management Cycle

The work product of the Requirements Management Cycle is an updated User Requirements, Technical Design and Requirements Traceability Matrix, RTM, associating user requirements with technical design and development tasks.

In simple terms this means:

  • Create or update any new or changed requirements in the Requirements Management tool
  • Estimate or update Level Of Effort for new or changed user requirements
  • Perform a Project Documentation Cycle
  • Vet updated project schedule

From here we would drill down into the specifics of a Project Documentation Cycle. But at its core, software development relies on programmers writing, testing and debugging source code files to implement required feature and functionality. It is this activity that all processes are intended to facilitate.

The secret of success lies in automating as much of other processes as possible, to allow shifting of resources to source code development.This does not reduce the need for other staff except by magnifying their efforts and minimizing repetitive, error-prone, manual processes needed to produce required artifacts.

The core activity then becomes developing the highest quality source code possible, elevated by the mechanical advantage and additional resources captured through the automation of simpler, repeated, artifact producing processes.

Granting that the support of these automated processes is available, we can recast the core activity of development as the Iterative Development Cycle.

Iterative Development Cycle

This is an annotated, close examination of the Iterative Development Cycle. Under the SCRUM-Agile methodology this is called a Sprint.

The work product of an Iterative Development Cycle is a set of updated, tested, documented source files ready for use in a Project Build and Demonstration Cycle.

Evaluate Project Requirements and Design Requirements assigned to this cycle in the updated Requirements Traceability Matrix

In its simplest form a Requirements Traceability Matrix is a table containing Requirements along one side and Design Elements along the other.The cell marking an intersection of a Requirement and a Design Element indicates an association if it is checked. The developers responsible for the design element examine the requirement and determine if changes to the design and estimated Level Of Effort are needed. Changed Requirements are prioritized and assigned. This is equivalent to the SCRUM-Agile Product Backlog.

Team meets to update Design Model based on new or updated requirements

Very much like a SCRUM but all design elements are on the table for discussion. In Model Driven Design, this may mean the model is modified, rebuilt and current data is migrated to the new model. In traditional Entity-Relationship designs the same process is followed but it is usually more labor intensive. Each accepted requirement includes a test script to define success in addressing the requirement.

Check-out Project source files from Configuration Management

The Project Lead and developers cooperate on file allocation for work on the assigned requirements and associated design elements.

Develop: Code, Test, Debug, Confer

Edit, Compile, Test cycles. Time spent on each requirement is recorded.This is the basis for the SCRUM-Agile Burn-Down chart. The test script included in each requirement is used to verify the update is code complete.

Update Database scripts

Creating the schema, triggers and stored procedures, migrating current data, creating test sets to support code changes made. These script changes are usually written and tested by Developers and promoted to the Project DBA for clean up, test, documentation, and propagation to the test database, beta, and production environments.

Update Module Tests and Feature Test Scripts

In test first or Test Driven Design, these tests are completed and automated in the Project Build script. In other methodologies, individual test functions or scripts are written and run. The test script is based on the validation test script included with each requirement.

Check-in updated work products to Configuration Management

For substantial code changes a Code Review is performed. Code complete changes are checked back into Configuration Management by developer pairs, vetting each change.

Navigating the iterDev Process

The sections of this presentation are structured to be read once, sequentially, and then as needed in any order. The navigation links to the left and section descriptions below appear on every page.

To continue now with the iterDev.com Iterative Development Process, click each of the links to on the left in order. A brief description of each document's contents is below. The 'Home' link returns you to the home page.

Foreword - iterDev.com Home page and Author's Foreword to the Iterative Software Development web site.

Introduction - iterDev.com Introduction, Background and The Iterative Development Force Multiplier.

Iterative Process Model - The Iterative Development Process Model, its place in the Software Development Lifecycle and expected benefits.

Deliverable Prototype - The Deliverable Prototype, its down stream Advantages for projects and the Work Product that delivers them.

Development Process - The Iterative Development Process, Activities and their mapping to SDLC and a closer look at the core Iterative Development Cycle.

Project Delivery System - The Project Delivery System: Activities, Activity Specifications and how they combine to produce Managed Project Releases.

Epilog - A few final thoughts. A request for comments. What I hope to achieve with this site.