ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10764
Скачиваний: 8
196
Должностные
лица,
руководящие
выполнением
планов,
называются
администраторами
планирования.
Однако
надо
помнить,
что
слишком
большое
число
людей
в
группах
плани-
рования
порождает
бюрократию,
поэтому
группа
планирования
должна
быть
организована
по
принципу
предметно-производ
-
ственной
специализации.
В
должностных
инструкциях
должна
быть
четко
определена
одна-единственная
точка
соприкоснове-
ния,
где
каждая
функциональная
группа
взаимодействует
с
группой
планирования
(рис.
8.4).
Корпорация
Фирма
…
Другие
фирмы
Отдел
планирования
и
администратор
управления
Отдел
исследований
и
разработок
…
Другие
отделы
–
Управление
разработкой
серии
изделий,
включая
управления
планами
Программные
изделия
Компоновка и
выпуск
…
Другие
сектора
–
Обеспечение
целостности
проекта,
включая
управление
планами
Обслуживание
разработки
программного
обеспечения
–
Управление
планами
…
Другие
низовые
подразделения
Рис.
8.4
—
Схема
взаимодействия
группы
планирования
и
функциональных
подразделений
197
В
большинстве
организаций
роль
администратора
плани-
рования
выполняет
руководитель
целевой
программы.
Планирование
должно
опираться
на
гарантии
правильного
применения
принципов
конфигурационного
управления.
Для
этой
цели
вводятся
функции
контроля
документации,
включая
проце-
дуры
хранения
и
распространения
проектной
документации.
Вместе
с
тем
планирование
невозможно
только
по
иерар-
хии
сверху.
Поэтому
каждая
функциональная
группа
должна
иметь
собственный
персонал
тактического
планирования.
Их
взаимодействие
должно
строиться
по
схеме:
−
подразделение
планирования
отвечает
за
целевое
и
стратегическое
планирование,
управление
бюджетом
и
планами
для
всей
организации;
−
функциональная
группа
отвечает
за
тактическое
пла-
нирование.
8.2.4 Планы, связанные с созданием программных
изделий
При
использовании
нисходящего
планирования
осущест-
вляется
постепенный
переход
от
общего
к
частному
(от
целевой
программы
к
стратегическим
и
тактическим
планам)
и
от
гло-
бального
к
локальному
(от
плана
семейства
изделий,
через
план
выпуска
серии
и
совокупности
изделий,
к
проекту
конкретного
программного
изделия).
Для
облегчения
понимания
структуры
различных
планов
вводятся
«стандартные»
определения.
Программное
изделие
—
совокупность
отдельных
про-
граммных
средств,
их
документации,
гарантии
качества
(ISO
9000),
рекламных
материалов,
мер
по
обучению
пользователей,
распространению
и
сопровождению
программного
обеспечения.
Независимо
от
того,
является
ли
программное
обеспечение
це-
лостным
изделием
или
только
частной
его
модификацией,
обычно
изделие
представляет
собой
тот
наименьший
объект,
относительно
которого
рассматриваются
все
вышеназванные
элементы.
Совокупность
изделий
—
это
группа
изделий,
имеющих
одну
или
несколько
общих
характеристик
и
работающих
совме-
стно
в
некоторой
комбинации
(ОС,
компиляторы,
сервисные
198
программы,
средства
диагностики,
которые
управляются
опера-
ционной
системой,
составляют
такую
группу).
Серия
изделий
—
это
сочетание
аппаратных
и
программ-
ных
средств,
которые
имеют
одну
и
более
общих
связей
и
функционируют
совместно
в
некоторой
комбинации
как
само-
стоятельная
система.
Семейство
изделий
—
несколько
связанных
программных
изделий,
которые
необязательно
должны
иметь
какой-либо
об-
щий
интерфейс
и
работать
на
одной
и
той
же
аппаратуре
(на-
пример,
все
компиляторы
языка
FORTRAN,
созданные
некото-
рым
поставщиком
для
различных
ЭВМ).
Планом
самого
высокого
уровня
является
план
выпуска
семейства
или
серии
изделий.
Так
как
в
их
названии
присутст-
вует
слово
изделие
—
это
стратегический
план.
В
целом
он
формулируется
в
терминах
технических
средств,
программного
обеспечения,
задач
обучения
персонала
и
т.д.
Он
содержит
эле-
менты
стратегии:
−
как
обеспечить
совместимость
с
конкурирующими
из-
делиями,
благоприятствующую
проникновению
на
рынок;
−
периодичность
усовершенствования
в
целях
продления
цикла
жизни
изделия
и
т.д.
Обычно
элементы
стратегии
охватывают
длительный
ин-
тервал
(5—10
лет).
Как
только
план
серии
одобрен,
разрабатываются
планы
выпуска
совокупности
изделий.
Лучшим
средством
представле-
ния
таких
планов
является
конфигуратор.
Это
понятие
исполь-
зуется
для
определения
таблицы,
в
которой
кратко
характери-
зуются
взаимосвязи
между
операционными
системами
и
подчи-
ненными
им
элементами
совокупности
изделий
(табл.
8.1).
Компактная
форма
конфигуратора
позволяет
передавать
большое
количество
информации
верхним
уровням
управления.
Когда
наступит
время
исследовательской
деятельности
по
разработке
программного
изделия,
сначала
создается
приблизи-
тельный
план
работы,
производится
первоначальное
выделение
средств,
фиксируются
фонды,
необходимые
для
завершения
работы.
Документ,
создаваемый
при
этом,
есть
не
что
иное,
как
199
распределение
бюджета.
Этот
документ
реализует
концепцию
приростного
финансирования,
он
обеспечивает
контроль
за
вы
-
полнением
планов.
Таблица
8.1
—
Конфигуратор
Совокупность
программных
изделий
VSOS2
VSOS3
VSOS4
Наименование
программного
изделия
Стр
аниц
Со
сто
яние
У
ров
ен
ь
по
ддер
ж
ки
Со
сто
яние
У
ров
ен
ь
по
ддер
ж
ки
Со
сто
яние
У
ров
ен
ь
по
ддер
ж
ки
VSOS2
VSOS3
VSOS4
4
4
5
7.07
///
///
3
///
7.07
///
2
///
///
7.08
1
///
—
изделие
не
будет
доступно
для
использо-
вания;
дата
—
месяц
и
год,
когда
изделие
станет
доступно
для
использо-
вания
1
—
поддержка
через
уведомление
о
выявленных
дефектах,
посылается
сообщение
об
изменениях,
рассматриваются
заявки
на
расширение
возмож-
ностей;
2
—
поддержка
через
уведомление
о
выявленных
дефектах,
посылается
сообщение
об
изменениях,
заявки
на
расширение
возможностей
не
прини-
маются;
3
—
только
обработка
уведомлений
о
дефектах
Окончательный
план
выпуска
изделий
вырабатывается
после
серьезного
изучения
и
обсуждения
проблемы.
Первая
задача
решается
после
распределения
бюджета,
формируется
план,
который
называется
соглашением
о
требо-
ваниях.
В
этом
документе
устанавливаются
договорные
отно-
шения
между
разработчиком
и
пользователем,
а
также
тем,
кто
должен
заниматься
продажей
изделия.
Помимо
разработчика,
который
обычно
готовит
этот
документ,
в
его
составлении
уча-
ствуют
многие
функциональные
подразделения,
в
том
числе
и
группа
испытаний,
группа
выпуска
документации,
персонал,
занятый
внедрением,
сопровождением,
сбытом
и
др.
Рассмотрение,
утверждение
и
корректировка
соглашения
о
требованиях
являются
наиболее
важным
моментом
во
всем
процессе
планирования
разработки.
Именно
благодаря
согла-
200
шению
о
требованиях
все
заинтересованные
стороны
знают,
какие
ожидания
можно
связать
с
созданием
изделия.
Как
только
разработка
становится
реальностью,
форми-
руются
планы
отдельных
групп:
группы
испытаний,
план
вы-
пуска
документации,
план
обеспечения
поддержки.
8.2.5 Опытный образец изделия
Там,
где
существует
хотя
бы
небольшая
вероятность
не-
удачи,
план
должен
предусматривать
возможность
создания
экспериментального
изделия.
Опытный
образец
—
это
почти
законченное
изделие.
Он
включает
в
себя
все
компоненты
завершенного
изделия,
в
том
числе
и
черновой
вариант
технической
документации,
и
пред-
полагает
проведение
небольшого
объема
независимых
испыта-
ний
с
целью
обеспечения
необходимых
условий
для
выработки
критических
замечаний
по
доработке
изделия
и
гарантий
мини-
мального
риска
пользователя.
При
создании
опытного
образца
необходимо
следовать
той
же
методике
управления,
которая
применяется
для
разра-
ботки
основного
изделия.
Для
принятия
решения
о
том,
какую
документацию
и
ка-
кой
контроль
следует
предусмотреть
для
опытного
образца,
обычно
используют
правило:
считать
опытный
образец
первой
версией
реального
изделия
и
тут
же
запланировать
реализа-
цию
второй
версии.
Если
программное
изделие
предназначено
для
многих
пользователей,
целесообразно
выбрать
одного
или
двух
из
них
для
поставки
им
бесплатно
и
с
полной
поддержкой
опытного
образца.
При
этом
пользователи
настолько
будут
польщены
вашим
выбором,
что
обеспечат
отдачу,
значительно
превы-
шающую
стоимость
опытного
образца.
8.2.6 Организация планирования в фазе исследования
Фаза
исследований
начинается
тогда,
когда
подтверждается
необходимость
создания
программного
изделия,
и
заканчивается
тогда,
когда
утверждены
технические
требования
(рис.
8.5).