The Personal Software Process Body of Knowledge
resources.sei.cmu.edu
resources.sei.cmu.edu
The process itself largely consists of piles of paperwork. Piles. Tons of overhead monitoring your work.
All that said, the intended goal was to create a state of mindfulness of your software creation process, allowing you to understand the typical root causes of bugs and better estimating.
I think that the value of this isn't in what it suggests doing--because it's looking at the wrong things and is wildly out-of-step with how development is actually practiced--but in what it gets wrong, and why those things are wrong.
For example, there is a large focus on "size"...lines of code, pages of documentation, etc. These are metrics that lend themselves to straightforward analysis, but are incorrect--a developer writing a one-line map with a lambda is doing better than her peer using an explicit loop. At the same time, her other colleague who is doing everything with one-letter variables and no linebreaks is doing better quantitatively (fewer lines!), but is creating massive technical debt.
It's interesting to see these efforts.
Like any estimate, it is explicitly understood that there will be variation and error. The goal is to have a better guess than one sourced from near the back of one's trousers.
First, I reject the premise that software is poor quality when compared to other engineering disciplines. Software is immensely more complicated than any other field of engineering ever imagined. The space shuttle, commonly referred to as the most complex machine ever built, has around 2.5 million parts. The Linux kernel alone has over 16 million source lines of code. It's an order of magnitude more complex than the SPACE SHUTTLE!. And even given that difference in complexity, disasters and problems occur still in the physical engineering world.
I think the reason why people have a perception that software is bad, is because, perversely, most of the time, it's really good. It's so magical that I can, with a device in my pocket, call up the latest sporting results for a game happening on the other side of the planet with only a few seconds delay, and perhaps even see video footage of it happening - all this enabled, it should be clear, by millions and millions of lines of software - that I can't even conceive of all the things that went right to get that far if the youtube app crashes for some unforeseen reason. The magic stopped, ergo software is crap.
The document then goes on to attempt to define a process for developing software. What is lists is a bit laughable:
1. Planning: Produce a plan to do the work. 2. Development: Perform the work. a. Define the requirements (see 4.2.2) b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build or compile and fix all defects g. Test the program and fix all defects 3. Postmortem.
Anyone who's ever done software development, will tell you that the order for these is something like:
2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d, 2c, 2d, 2b, 2a, 2d...
Trying to develop software in a process-oriented fashion is doomed to failure, because developing software is the act of creating processes for a computer to execute. If it were possible to define a software development process, we could get someone to write it up in C, or Python, or whatever, and then just kick back and let the computer do the development for us! Heck, if we take the extra time to code in PV and EV calculations, it'll have a working progress bar too!
[|||||||||||||__________] Coding... (50%)
That being said, these elements of the "process" are useful as a taxonomy for the kinds of activities that must be performed as part of software development, and if you fail to do any of them, you will likely produce inferior quality software. But listing them in a regimented fashion, or trying to follow them as a "process", simply does not work.
But in the end there's an awful lot of waffle in what amounts to a pretty impenetrable document. There's got to be a better way to codify what we actually do when we develop good software. Not what we think we do, or wish we did, or claim we do to sound impressive.
Edit: grammar.
The first is that, as the "Acknowledgements" section and the copyright page (2) implies, the target audience for this type of thing is the kind of organization that enjoys the use of CMMI. It was one of the greater realizations in my career when I learned that CMMI isn't necessarily trying to improve software engineering as much as it is trying to make whatever process you have repeatable. It took you 6 months to make "hello world"? Great, please don't let it take you 5 or 7 months the next time.
And that segues into another aspect that you hinted at in your "2b, 2a, 2b" clause which is unlike traditional engineering disciplines, software engineering is almost always building something that no one has ever seen or imagined before. Thus, when asked to plan out what one is going to do that day, it's mostly "create a mental map of this unknown landscape as I discover where the theory meets the practice." It is absolutely helpful to have libraries and application servers, etc, but as for knowing _exactly_ what to type and exactly how long it should take to make another component that's shaped like the component from last week but who's innards are entirely different: good luck to us all.
However, I have to take issue with the statement that software engineering is always building something new. That's only true if you look at new houses being built and say they are each fundamentally different. Most software is very similar to many products before it. A large part of the reason that we need a Body of Knowledge is to extract the common parts and automate the making of them, or at least automate the process of making them.
I was under the impression that SEI has a pretty good reputation among people working on safety-critical systems like aerospace, automotive, and the DoD. Of the two authors with visible profiles, one led "software development projects and software process improvement efforts for the E-2C Hawkeye Program", and the other was "developing and maintaining nuclear engineering and scientific software for 14 years" before coming to SEI. I don't see that there's much basis to say that they are uninformed on software engineering.
> First, I reject the premise that software is poor quality when compared to other engineering disciplines.
If we're talking software on safety-critical systems, that may be true. I think NASA is a great example of software assurance done right. Outside of the SC area, I don't see how you can come to that conclusion: take the perceived decline in Apple's software quality as one example.
> The space shuttle, commonly referred to as the most complex machine ever built, has around 2.5 million parts. The Linux kernel alone has over 16 million source lines of code. It's an order of magnitude more complex than the SPACE SHUTTLE!.
I think this is a nonsensical comparison, but if you want to go with it, consider that each of the Space Shuttle parts has multiple steps going into it's creation. It'd be slightly more fair to say that the Space Shuttle has 2.5 million functions and compare that to the Linux kernel, but it remains a nonsensical comparison.
>Anyone who's ever done software development, will tell you that the order for these is something like: 2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d, 2c, 2d, 2b, 2a, 2d...
Anyone who's done work in a regulated environment will tell you that while your suggested process may happen in the conception stage for preliminary testing, once you're under design control you follow formally documented procedures in the order that they are specified.
> There's got to be a better way to codify what we actually do when we develop good software. Not what we think we do, or wish we did, or claim we do to sound impressive.
Plenty of groups work in this area besides SEI: ASQ, IEEE-CS, ACM, &c. Did you have something specific in mind?
As others are saying, I think you're misjudging the target audience for this document, which I would say is Software Engineers (as in the type that would have PE licensure or work in regulated industries). When you have a defined acceptable defect rate and need to deliver on schedule with proper documentation, then things like PSP, CMMI, &c. do work. It's overkill for a web app. That said, I think adopting some of the rigor and professionalism in Software Engineering as typified by regulated industries would be an overall improvement to software development as it is generally practiced.