ОРГАНИЗАЦИОННО УПРАВЛЕНИЕ

Литература

1. 
   Schulmeyer G.G. Zero Defect Software. New York, McGraw-Hill, 1990.
   
2. 
   Humphrey W.S. Characterizing the Software Process: A Maturity Framework. IEEE Software,
   Marchl988,p.73-79.
   
3. 
   Humphrey W.S. (ed.). Managing the Software Process. SEI (USA), Addison-Wesley,New York,
   

1989, 489 pp.

4. 
   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.
   
5. 
   Jones C. Assessment and Control ofSoftware Risks, Prentice-Hall, Englewood Cliffs, 1994.
   

6. 
   BOOTSTRAP Team, „BOOTSTRAP: Europe's Assessment Method", IEEE Software, July
   1993, pp. 93—95.
   
7. 
   Brown B.J., Assurance ofSoftware Quality, SEI Curriculum Module SEI-CM-7-1.1, Carnegie
   Mellon University, Software Engineering Institute, 1987.
   
8. 
   Jones C., Applied Software Measurement, McGraw-Hill, New York, 1997.
   

110
9.1.Bъведение
Според Б. Боем целта на софтуерните технологии е осигуряване на ефек-
тивен процес на разработване на висококачествен софтуер. Основна тех-
ника за преодоляване на стихийността в създаването на ПП е мениджърският
подход. Разглеждането му е актуално заради все още тревожните данни за
незавършване (изобщо или в срок) на софтуерните проекти, на превишаване
на предварително определените ресурси за разработване или за разпростра-
нение на ПП, които затрудняват потребителите със сложността и ненадежд-
ното си функциониране. По публикувани данни през 1998 г. 26% от софтуер-
ните проекти са преустановени, а 46% са завършили с превишаване на плани-
раните ресурси за разработване.
За съжаление не е възможно автоматично пренасяне в софтуерното произ-
водство на полезни мениджърски практики от материалното производство или
други области поради:

• 
  същността на софтуера. Програмните продукти не са чисто материални,
  а са продукт на интелектуални усилия, професионални умения, прилагане на
  научни знания и др.
  
• 
  уникалността на всеки софтуерен проект, която се обуславя от естест-
  вото и сложността на конкретно решавания проблем. Затова могат да се опре-
  делят само най-общите рамки, а реалното протичане на проекта се управлява с
  избирани според случая (ad hoc) техники. Опитът от предишни проекти е поле-
  зен, но не може да бъде директно използван.
  

Изтегляне 2.27 Mb.

Сподели с приятели: