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.
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.
In Royce's model, there are two stages: engineering and production, where each stage is broken into two phases:
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:
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.