Strategies for software engineering: the management of risk and quality
Strategies for software engineering: the management of risk and quality
The software engineering laboratory: an operational software experience factory
ICSE '92 Proceedings of the 14th international conference on Software engineering
Establishing experience factories at Daimler-Benz: an experience report
Proceedings of the 20th international conference on Software engineering
A Taxonomy to Compare SPI Frameworks
EWSPT '01 Proceedings of the 8th European Workshop on Software Process Technology
Enabling Local SPI in a Multi-national Company
PROFES '01 Proceedings of the Third International Conference on Product Focused Software Process Improvement
Transition Management of Software Process Improvement
PROFES '02 Proceedings of the 4th International Conference on Product Focused Software Process Improvement
An Ongoing OO Software Engineering Measurement Experiment
SEEP '96 Proceedings of the 1996 International Conference on Software Engineering: Education and Practice (SE:EP '96)
Building AS-IS process models from task descriptions
Proceedings of the 8th International Conference on Frontiers of Information Technology
KPI modeling in MDA perspective
OTM'10 Proceedings of the 2010 international conference on On the move to meaningful internet systems
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 |
There are two approaches to process improvement. The top-down approach compares an organization's process with some generally accepted standard process. Process improvement is then the elimination of differences between an existing process and a standard one. The assumption is that, once the process is changed the generated products will be improved-or at least the risk of generating new software will he reduced. The bottom-up approach assumes that process change must be driven by an organization's goals, characteristics, product attributes, and experiences. Change is defined by a local domain instead of a universal set of accepted practices. For example, an organization whose primary goal is improving time to market may take a significantly different approach to process change than one whose primary goal is to produce defect-free software.