Математика делает то, что можно, так, как нужно, то-гда как информатика делает то, что нужно, так, как можно

Упражнения к лекции 13.
13.1. Что такое менеджер программного средства?
13.2. Что такое ординарный пользователь программного средства?
13.3. Что такое администратор программного средства?
13.4. Что такое руководство по инсталляции программного средства?
13.5. Что такое руководство по управлению программным средством?
13.6. Что такое руководство по сопровождению программного средства?


Литература к лекции 13.
13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.

2. 
   ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
   
3. 
   ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
   
4. 
   ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
   
5. 
   ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.
   
6. 
   ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.
   
7. 
   ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
   
8. 
   ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.
   

Губа не дура, язык не лопата.

Народная поговорка


Лекция 14.
УПРАВЛЕНИЕ РАЗРАБОТКОЙ И АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА.


Назначение управления разработкой программного средства и его основные процессы. Структура управления разработкой программных средств. Подходы к организации бригад разработчиков. Управление качеством программного средства. Аттестация программного средства и характеристика методов оценки качества программного средства.

14.1. Назначение и процессы управления разработкой программного средства.

Управление разработкой ПС (software management) – это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков ПС, на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПС, выполнения сроков и бюджета разработки ПС [14.1, 14.2]. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПС, а ход выполнения этих работ называют развитием программного проекта (software project progress). К необходимым условиям работы коллектива относятся помещения, аппаратно-программные средства разработки, документация и материально-финансовое обеспечение. Планирование и контроль предполагает разбиение всего процесса разработки ПС на отдельные конкретные работы (задания), подбор и расстановка исполнителей, установление сроков и порядка выполнения этих работ, оценка качества выполнения каждой работы. Финальной частью этой деятельности является организация и проведения аттестации (сертификации) ПС, которой завершается стадия разработки ПС. Влияние правильной расстановки исполнителей на обеспечение надежности ПС уже обсуждалось в лекции 2. Вопросы документации обсуждались в предыдущей лекции. Другие вопросы управления разработки ПС кратко обсудим в настоящей лекции.
Хотя виды деятельности по управлению разработкой ПС могут быть весьма разнообразными в зависимости от специфики разрабатываемого ПС и организации работ по его созданию, можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПС:

1. 
   составление плана-проспекта по разработке ПС;
   
2. 
   планирование и составление расписаний по разработке ПС;
   
3. 
   управление издержками по разработке ПС;
   
4. 
   текущий контроль и документирование деятельности коллектива по разработке ПС.
   
5. 
   подбор и оценка персонала коллектива разработчиков ПС.
   

Составление плана-проспекта по разработке ПС включает формулирование предложений о том, как выполнять разработку ПС. Прежде всего, должно быть зафиксировано, для кого разрабатывается ПС:

64. 
    для внешнего заказчика,
    
65. 
    для других подразделений той же организации,
    
66. 
    или является инициативной внутренней разработкой.
    

В плане-проспекте должны быть установлены общие очертания работ по создания ПС и оценена стоимость разработки, а также предоставляемые для разработки ПС материально-финансовые ресурсы и временные ограничения. Кроме того, он должен включать обоснование, какого рода коллективом должно разрабатываться ПС (специальной организацией, отдельной бригадой и т.п.). И, наконец, должны быть сформулированы необходимые технологические требования (включая, возможно, и выбор подходящей технологии программирования).
Планирование и составление расписаний по разработке ПС – это деятельность, связанная с распределением работ между исполнителями и по времени их выполнения в рамках намеченных сроков и имеющихся ресурсов. Более подробно этот процесс будет рассмотрен в п. 14.3.
Управление издержками по разработке ПС – это деятельность, направленная на обеспечение подходящей стоимости разработки в рамках выделенного бюджета. Она включает оценивание стоимости разработки проекта в целом или отдельных его частей, контроль выполнения бюджета, выбор подходящих вариантов расходования бюджета. Эта деятельность тесно связана с планированием и составлением расписаний в течение всего периода выполнения проекта. Основными источниками издержек являются

• 
  затраты на аппаратное оборудование (hardware);
  
• 
  затраты на вербовку и обучение персонала;
  
• 
  затраты на оплату труда разработчиков.
  

Текущий контроль и документирование деятельности коллектива по разработке ПС – это непрерывный процесс слежения за ходом развития проекта, сравнения действительных состояния и издержек с запланированными, а также документирования различных аспектов развития проекта (см. лекцию 13). Этот процесс помогает вовремя обнаружить затруднения и предсказать возможные проблемы в развитии проекта.
Подбор и оценка персонала коллектива разработчиков ПС – это деятельность, связанная с формированием коллектива разработчиков ПС. Имеющийся в распоряжении штат разработчиков далеко не всегда будет подходящим по квалификации и опыту работы для данного проекта. Поэтому приходится, частично, вербовать подходящий персонал, а, частично, организовывать дополнительное обучение имеющихся разработчиков. В любом случае в формируемом коллективе хотя бы один его член должен иметь опыт разработки программных средств (систем), сопоставимых с ПС, который требуется разработать. Это поможет избежать многих простых ошибок в развитии проекта.