Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products
Enough About Process: What We Need are Heroes
IEEE Software
Heuristics for Iterative Software Development
IEEE Software
Transition Management of Software Process Improvement
PROFES '02 Proceedings of the 4th International Conference on Product Focused Software Process Improvement
Process improvement solution for co-design in radio base station DSP SW
PROFES'05 Proceedings of the 6th international conference on Product Focused Software Process Improvement
| Hi-index | 0.00 |
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.