This Article 
 Bibliographic References 
 Add to: 
Bottom-up Process Improvement Tricks
January/February 1998 (vol. 15 no. 1)
pp. 64-68
Most everyone in our field acknowledges that software process improvement cannot succeed unless management is committed to implementing it. Fortunately, the move to SPI can be a two-way street, initiated as easily from the bottom up as from the top down. Taking this bottom-up approach, I present some tricks that practitioners down in the trenches can use to win upper management's approval of and support for SPI. My first opportunity to introduce bottom-up process changes occurred on a project in which my job was basically coding and testing. Initially, I was assigned to the maintenance coding of the product's previous release, which proved to be a real headache. So I had my motives for making improvements. According to the waterfall model we were using, the project was about halfway through the design phase. A lot of lower-level design and unit and integration testing remained. I was assigned one part of the system, and the remaining design and unit testing tasks were given to the 15 people we had allocated to us for the next five months. Given the amount of work that lay before us, these resources were not nearly enough. One subproject leader realized that our complex and lengthy design task would prove a huge challenge.
Allan Baktoft Jakobsen, "Bottom-up Process Improvement Tricks," IEEE Software, vol. 15, no. 1, pp. 64-68, Jan.-Feb. 1998, doi:10.1109/52.646884
Usage of this product signifies your acceptance of the Terms of Use.