Reuse Environment

This rant discusses the requirements and characteristics of a software development environment geared toward achieving the benefits of reuseable software.

A good software development environment must:

  1. Enable software reuse
  2. Support the software development process
  3. Support heterogeneous host development platforms
  4. Support heterogeneous target platforms (cross)
While ease of use is desireable, it is omitted as a "requirement" since it is not necessary to achieving the software reuse. That is not to say, however, that is not important, since it also affects the bottom line of development through the time associated with learning the environment and more importantly the day to day use of the environment in terms of time. By supporting the software development process however, it is assumed that the critical software development processes are as simple as possible. The main thing to remember is the "... simple as possible, but no simpler ..." axiom.

Secondary requirements include:

  1. Ease of use (repetative)
  2. Ease of learning (one time)
  3. Support for heterogeneous host development platforms


Structure (the file namespace)
Build
Revision Control
Component Catalog. Finding /Searching for (Locating) Components.
Bug tracking/inter project communication. The traditional bug tracking system can be enhanced by careful design to be more of a product change tracking system. Such a system would have each change request/bug move through a series of states. In each state, exactly one person/entitiy/role is responsible for moving the change to another state. State changes cause the change request to move towards resolution, but the design must allow for iterative behavior of the system.

States:
    - New
    - Investigating
    - Assigning
    - Assigned
    - Debugging
    - Problem Found
    - Solution Pending
    - Ready To Test
    - Testing
    - Testing Passed / Resolved
    - Testing Failed
    - Released
    - Deferred
    - NotAProblem - Intended by design

Attributes
            - priority
            - urgency
            - reproduced - test case available
            - description
            - assigned-to-user
            - desired release date (next,future,next bug-fix)
            - type (feature request, bug)
            - type of change required (design,implementation)
            - estimated time to change ()
            - difficulty/impact

Bugzilla:
Component:
    General affected area/library/module.
Whitebord:
    Short notes about the bug.
keywords:
    testcase
    helpwanted
    ... others...
Target Milestone

P4DTI - Defect Tracking Integration
    - Red Hat RPM
 
 
 

Change requests should be divisible and mergable. Divisible requests can be broken into several sub-changes. Mergable change requests are created when multiple change requests reference the same root change/cause.
 

Project coupling created at shared repository.
Competition for files. Reason for branching.
Mitigated by small object granularity.
Mitigated by unit testing.
Validated as stable by use in many projects.

mike@mnmoran.org