9. ОРГАНИЗАЦИОННО УПРАВЛЕНИЕ
Литература
Schulmeyer G.G. Zero Defect Software. New York, McGraw-Hill, 1990.
Humphrey W.S. Characterizing the Software Process: A Maturity Framework. IEEE Software,
Marchl988,p.73-79.
Humphrey W.S. (ed.). Managing the Software Process. SEI (USA), Addison-Wesley,New York,
1989, 489 pp.
Paulk M. C., Weber C.V, Garcia S.M., Chrissis M.B., Bush M., Key Practices of the Capability
Maturity Model for Software, Version 1.1, TR CMU/SEI-93-TR-025, Software Engineering
Institute (USA), Carnegie Mellon University, Pittsburgh, 1993.
Jones C. Assessment and Control ofSoftware Risks, Prentice-Hall, Englewood Cliffs, 1994.
BOOTSTRAP Team, „BOOTSTRAP: Europe's Assessment Method", IEEE Software, July
1993, pp. 93—95.
Brown B.J., Assurance ofSoftware Quality, SEI Curriculum Module SEI-CM-7-1.1, Carnegie
Mellon University, Software Engineering Institute, 1987.
Jones C., Applied Software Measurement, McGraw-Hill, New York, 1997.
110
9.1.Bъведение
Според Б. Боем целта на софтуерните технологии е осигуряване на ефек-
тивен процес на разработване на висококачествен софтуер. Основна тех-
ника за преодоляване на стихийността в създаването на ПП е мениджърският
подход. Разглеждането му е актуално заради все още тревожните данни за
незавършване (изобщо или в срок) на софтуерните проекти, на превишаване
на предварително определените ресурси за разработване или за разпростра-
нение на ПП, които затрудняват потребителите със сложността и ненадежд-
ното си функциониране. По публикувани данни през 1998 г. 26% от софтуер-
ните проекти са преустановени, а 46% са завършили с превишаване на плани-
раните ресурси за разработване.
За съжаление не е възможно автоматично пренасяне в софтуерното произ-
водство на полезни мениджърски практики от материалното производство или
други области поради:
същността на софтуера. Програмните продукти не са чисто материални,
а са продукт на интелектуални усилия, професионални умения, прилагане на
научни знания и др.
уникалността на всеки софтуерен проект, която се обуславя от естест-
вото и сложността на конкретно решавания проблем. Затова могат да се опре-
делят само най-общите рамки, а реалното протичане на проекта се управлява с
избирани според случая (ad hoc) техники. Опитът от предишни проекти е поле-
зен, но не може да бъде директно използван.
Сподели с приятели: |