Skip Navigation Links > Process > Principals

Principals


Software engineering is based on architecture and design models to provide visibility, prioritized use-cases to keep development cycles short and focused, modern programming languages to map objects from the problem space into the solution space, and a development process that provides the framework for guiding development activities and reporting feedback. In general, a modern development process supports the following principals:

  • Software increments are released to the customer at regular intervals.
  • Only fully tested software (free of any known bugs) may be released.
  • The development process is iterative in nature. That is, analysis, design, implementation, and testing are overlapping activities.
  • Each use-case is traceable to one or more enumerated requirements and visa-versa.
  • Each requirement is traceable to one or more areas of the code and visa-versa.
  • The architecture clearly identifies interfaces and their contracts, components and their coupling, subsystems dependencies, and inter-process mechanisms.
  • The architecture is visually modeled and never falls out of sync with the code.
  • Each component is delivered with a corresponding suite of automated regression tests.
  • All software artifacts (e.g. requirements, models, components, build scripts, unit tests) are maintained in a change management & version control system.
  • A software component checked into version control will automatically trigger a build of that component.
  • The entire system is built and integrated every night and any resulting errors, and/or warnings are dealt with the next morning at the highest priority.

In the context of this discussion, an increment refers to a software release which has been built by iterating as often as necessary over the various work activities in the development cycle in order to implement a set of use-cases that are free of any known defects. Each incremental release represents the successful conclusion and delivery of a mini-project. Although an incremental release at say version 0.3.4 may not do much, it will be rock-solid and contain no surprises. Contrast this with that of an ad hoc event-driven organization where version 1.0 is normally unstable, full of bugs, and avoided like the plague.

Depending on the complexity of the domain, an incremental release can require from four to six weeks to produce. It is important that a release never exceed the 6-week limit since each release provides essential feedback, especially from the customer. With the exception of small projects, it is important that each release allow a minimum of 4-weeks (20 working days) to develop, otherwise the process will degenerate into hacking in order to meet the deadline. A 4-week period also provides sufficient time to allow the release to demonstrate some meaningful capabilities. A healthy project should be able to establish a 5-week rhythm of releases.

Iteration Cycle

The incremental/iterative process is the only pragmatic way to develop and maintain software because it acknowledges that during development discoveries will occur that require evolutionary changes. For example, assumptions made in the mini-project plan (i.e. the plan for the current iteration) may prove to be false, a mistake might exist in a model artifact, or an algorithm may need to modified to improve performance. However, since a cycle represents a relatively short time period, incorrect assumptions are detected early before costly rework is required. Also, knowledge and wisdom gained from the current release will influence the next release. Frequent feedback is the key to success.

Professionally managed projects do NOT allow last minute requirements to enter a development cycle once it has started since this is not in the best interests of the customer nor the project. Such requirements must be respectfully noted and addressed in the next mini-release. A customer who tries to push a new requirement into a development cycle is like someone who will not let another person finish speaking before making their next statement. In conversation such a person would be quickly admonished, and by analogy so should it be when imposing last-minute requirements on the development team.

At the conclusion of each release, risk assessment and customer feedback information is provided to project management to facilitate the creation of meaningful plans for the next release. Risk assessment is an essential activity for identifying the set of use-case scenarios that will drive the next release. The strategy of implementing the highest risks as early as possible is not always popular with management at the executive level since risky use-cases usually require more time and resources and raises the possibility of having to report bad news early in a project. In most cases the highest risks can be overcome and closure is eventually reached when all use-case scenarios are implemented and tested.

Summary

 

Quote StartWorking software must be released to the customer in manageable increments.

 

Quote StartPrioritized use-cases keep development cycles short and focused.

 

Quote StartEach requirement must be traceable to one or more areas of the code and visa-versa.

 

Quote StartRegression tests and static analysis tools must constantly measure the quality of the code.

 

Quote StartIncremental release & iterative development is the only pragmatic way to develop software.

 

Quote StartFrequent feedback is the key to success.

 

Quote StartThe risk assessment activity identifies the use-cases that will drive the next release.

 

Quote StartAllow a minimum of 4-weeks to develop a release, otherwise the process will degenerate into hacking in order to meet the deadline.

 

Quote StartThe strategy of implementing the highest risks as early as possible is not always popular with management

 

Quote StartProfessionally managed projects do NOT allow last minute requirements to enter a development cycle once it has started.

Top-of-page | Rationale | Principals | Phases | Workflow | Graph