flipturn.org - stuff. things. other stuff.
dvorak | pantera | hacks


I took a graduate course called Software Management that used the aptly named book Software Project Management by Walker Royce. This is an excellent book and I recommend it for a good overview of the modern software development process.

It's not even ridiculously overpriced like most textbooks. It is also by far the best book I've ever used in a university course. Maybe because it was written by a person from industry and not someone cloistered in academia. I don't mean this as a slam against all Ph.D.s who write textbooks, because I'm sure there are some good ones out there. But in my experience, university professors who used their own books or books of fellow faculty members did so not because the books were good (they weren't), but because it was an extra revenue stream for them. Obviously I've had bad experiences.

So, anyhoo... Back to your regularly scheduled programming.

In the book, Mr. Royce describes the modern iterative approach to development. This methodology is pretty foreign to me coming from bigger companies with labyrinthine management practices and dictated requirements from yonder above. The modern approach he describes is iterative, where the project evolves as things go along. Constrast this to the traditional approach where everything is described on paper before a single line is coded. The traditional approach results in "late design breakage" where problems are discovered in the implementation that couldn't have been forseen through paper-only models. This contributes to much gnashing of teeth and adversarial stakeholder relationships.

They key as I understand it is to create an architecture model that can handle what you know about and perhaps is flexible enough so that it doesn't completely break when new requirements are discovered. The paradigm shift is: the thing of primary importance is the architecture, not the documentation. This is the "architecture first" approach, rather than the "document centric" approach.

My only issue with the modern software development process as described by Mr. Royce is that there aren't any publicly available examples that I could find when I was doing research to write some papers for my graduate class. This was extremely frustrating, as I always work better when I have a template or good example from which to work. I imagine that everyone would work better, actually.

So, thinking that the modern process is a good idea, but not having any available, I decided that I'd try to create one and see how it works. I found a project that interests me (peppy) that I'd be willing to spend some spare time developing, and now all I have to do is attempt to follow the modern process.

Stages and Phases

In Royce's model, there are two stages: engineering and production, where each stage is broken into two phases:

  • Engineering Stage
    • Inception Phase
    • Elaboration Phose
  • Production Stage
    • Construction Phase
    • Transition Phase

The modern approach focuses on those four project phases instead of the activities of the traditional approach: analysis, design, coding, testing, and operations. The architecture is the focus of the Engineering Stage (Inception and Elaboration), and the system development is the focus of the Production stage.


The Objectives Milestone occurs at the end of the inception phase, and is designed to present all stakeholders with enough information to approve further development. In a more business-centered development, it would include cost/schedule models and other business factors, but here it's mostly concerned with proveing the feasability of a potential architecture and showing the completeness of the vision.

The engineering stage culminates in the Architecture Lifecycle Milestone. Passing this milestone signals the transition from Engineering to Production, because means that the stakeholders all agree that the defined architecture satisfies the driving requirements and is likely to satisfy the future requirements as they are spiraled in during further iterations.

The construction phase concludes with the Initial Operations Capability Milestone, which signals sufficient development of the software to start acceptance testing and to begin the transition to early-adopters.

At the end of the production stage, the Product Release Milestone signals the transition from the development organization to the support organization. To meet this milestone, the results of acceptance testing must meet with the approval of the stakeholders and all open issues must be addressed. Software quality measurements must also be of a satisfactory level for successful transition.


Iterations are part of the process to provide the opportunity to manage it effectively. Instead of the old "big design up front" approach where everything had to be designed on paper and configuration controlled, the project is broken up into many iterations. Each iteration focuses on a subset of the problem, and it is much easier to define smaller portions than the entire project.

Early iterations focus on getting the architecture right, focusing on the driving requirements. The architecture stabilizes once the architecture passes its lifecycle milestone at the transition from the engineering state to the production stage. Iterations in the production stage focus on adding requirements that are tested against the acceptance criteria, producing releases (alpha, beta, etc.) at the deployment workflow of every iteration.


Each iteration uses the same set of seven workflows:

  • Management: planning details of next iteration
  • Environment: evolve change database & update baselines
  • Requirements: elaborate use cases to be demonstrated in this iteration
  • Design: evolve arch & design artifacts
  • Implementation: develop required stuff
  • Assessment: evaluate results of iteration against eval criteria. Quality & completeness
  • Deployment: transition to user, validate & verify, capturing lessons learned

but the time spent on each workflow will vary depending on the iteration. For example, during the Inception Phase, you might spend a lot of time on the Requirements workflow and not that much on Implementation, but during the Construction Phase, you'd spend much less time in Requirements and much more in Implementation.


Artifacts are the products of the process, not just the code, but the documentation that goes along with it. Royce provides templates for all of the artifacts in his book, but only in the form of outlines or section headings. I found the outlines difficult to understand, because there was little detail provided in the book about what actually goes in each section.

That's the one drawback of actually using this process: the scarcity of examples of its use. Doing my grad class, we were forced to shoehorn IEEE documents into this process, which ended up being this unholy combination of waterfall documents associated with the iterative process. Bad.

Finally, I ran across the ReadySET project that looks to be very helpful. It is an entire suite of templates that look to be tailored to the modern process.

Here's an example:

The artifacts in the ReadySET project are HTML and CSS templates designed to be maintained under version control, which takes them outside the realm of this wiki that I'm currently using. While I like editing under a wiki, my current wiki doesn't have any version control. It would be interesting, however, to see if Trac has version control of its wiki pages and convert the templates to wiki format under Trac.

erection pills new york erection pills california erection pharmacy erection pills california
levitra levitra buy levitra sale cialis online