Софтуерни технологии

• 
  проучване на потребителското мнение във фазата анализ на осъществи-
  мостта;
  
• 
  защитаване интересите на потребителя още при избора на проектантски
  или програмистки решения;
  
• 
  обучение на потребителя;
  
• 
  регламентиране и осъществяване на обратна връзка с потребителя на
  даден ПП: получаване и систематизиране на съобщенията за грешки и на заяв-
  ките за изменения по искане от страна на потребителите;
  
• 
  връзки с обществеността.
  

Съпровождане
Обхваща всички дейности по внасяне на промени в готовия ПП:

• 
  поправяне на грешки;
  
• 
  добавяне на нови възможности;
  
• 
  адаптиране на ПП към нова операционна или хардуерна среда.
  

Извършва се от разработчиците. Изисква най-високата възможна квалифи-
кация, защото, както е известно, в повечето случаи внасянето на коректни изме-
нения в съществуваща програма е по-трудно, отколкото създаването на нова
програма.
Съпровождането може да се извършва на различни равнища:
а) гаранционно съпровождане — обикновено то включва задължения за
безусловно и безвъзмездно отстраняване на грешки по искане на потребителя,
като по българските стандарти има срок 12 месеца;
б) развитие на ПП и отстраняване на грешки;
в) отстраняване на грешки;
г) регистриране на съобщенията за грешки и на заявките за подобряване с оглед
вземането им под внимание при евентуално разработване на нов подобен ПП.
Режимът на съпровождане може да зависи от конкретно подписания дого-
вор, ако има пряка връзка между разработчика и потребителя.
На фиг. 2.7. са представени по хоризонталната ос фазите на ЖЦ на ПП, по
вертикалната — функциите, а така също и интензивността на отделните функ-
ции по време на отделните фази. Както обикновено се приема, колкото една
функция се изпълнява по-интензивно, толкова по-наситен е цветът па предста-
вянето.
Литература

1. 
   Gunther R.C., Management methodology for software product engineering. New York, 1978.
   
2. 
   Hamilton M., S. Zeldin. The Functional Life Cycle Model and Its Automation: USE.IT J of
   System and Software, 3 (1983), p. 25—62.
   
3. 
   Fox J.M., Software and its Development. Prentice-Hall, Inc., Englewood Cliffs, 1982.
   
4. 
   Appleton D., The Asset-based Life Cycle Model, Very Large Projects, Datamation January
   15,1986,p.63-70.
   
5. 
   Sommerville I., Software Process Models, ACM Computing Surveys, Vol.28, No.l, March
   1996, p. 269-271.
   
6. 
   Boehm B.W., A spiral model of software development and enhancement. IEEE Computer 21
   5,p.61-72. ' '
   

	Изследване	Осъщест- вимост	Проекти- ране	Програми- ране	Изпитания	Използване
Планиране
Разработване
Обслужване
Документиране
Изпитания
Поддържане
Съпровождане

Фиг. 2.7. Модел на Гънтър
34
35

3. КОНВЕНЦИОНАЛЕН ПОДХОД
ЗА РАЗРАБОТВАНЕ НА СОФТУЕР
Когато текущото състояние на научното знание не е в състояние да удов-
летвори очакванията ни, се оказваме в състояние на криза. Тази криза се следва
от радикална смяна на научното знание, т. е. на начина, по който моделираме
или правим нещо. Следователно сегашната ситуацията в софтуерното произ-
водство не е нова — просто се преминава от един подход към друг с неизбеж-
ните за такъв преход трудности, породени от необходимостта от усвояване и
прилагане на нови идеи.
В тази глава ще представим основните принципи на традиционния подход
на разработване на софтуер, следвайки хронологичен модел на ЖЦ, последова-
телните фази на който са определяне на софтуерната система, проектиране,
програмиране, интегриране и тестване, използване.