ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 16873
Скачиваний: 11
216
ект,
но
и
внутренний
и
только
после
этого
браться
за
програм-
мирование.
Следует
иметь
в
виду
один
серьезный
недостаток
волно-
вого
эффекта:
задержка
с
утверждением
внешних
специфика-
ций
может
крайне
неблагоприятно
отразиться
на
выполнении
многих
функций.
То есть
нельзя
утверждать
спецификации
ис-
пытаний,
невозможно
закончить
рекламные
материалы
и
т.д.
Помимо
кодирования,
отладки
и
компоновки
деятель-
ность
группы
разработки
связана
с
демонстрацией
работающего
изделия
в
конце
фазы
программирования
и
организацией
взаи-
модействия
группы
с
другими
функциональными
группами.
Сначала
на
рассмотрение
поступает
план
поддержки.
В
группе
разработки
должна,
прежде
всего,
существовать
уверенность
в
обоснованности
плановых
сроков
и
правильности
предложений
группы
поддержки,
касающихся
описания
программного
изде-
лия.
Любые
ошибки
в
описании
характеристик
программного
изделия
или в
определении
сроков
его
готовности,
которые
мо-
гут
дойти
до
пользователя
через
рекламные
материалы,
могут
породить
недоразумения
или,
хуже
того,
штрафы
за
невыпол-
нение
обязательств.
В
фазе
программирования
группа
выпуска
документации
представляет
на
рассмотрение
ряд
вариантов
справочных
мате-
риалов.
В
середине
фазы
программирования
группой
испыта-
ний
представляется
на
рассмотрение
график
испытаний.
Группа
разработки
тщательно
изучает
варианты
документации
и
спе-
цификации
испытаний
с
тем,
чтобы
в
них
не
было
ошибок,
по-
рожденных
неверными
исходными
предложениями.
Если
груп-
па
разработки
в
свое
время
подготовила
корректные
внешние
спецификации,
то
их
анализ
не
вызывает
больших
затруднений
и
займет
немного
времени.
Если
же
некоторые
положения
внешних
спецификаций
пропущены
или
изложены
недостаточ-
но
полно,
то
их
проверка
отнимет
не
только
много
времени,
но
и
вызовет
большие
трудности.
В
этом
случае
придется
изменять
внешние
спецификации,
что
может
свести
на
нет
запас
времени,
имеющийся
в
календарном
плане
проектирования.
Группа
поддержки
после
утверждения
изготовляет
и
на-
правляет
на
рассмотрение
рекламные
материалы.
Группа
разра-
217
ботки
анализирует
эти
материалы,
чтобы
не
допустить
техниче-
ских
ошибок,
порождающих
недоразумения
и
соответствующие
финансовые
санкции.
Обычно
во
время
фазы
программирова-
ния
оказывается
целесообразной
демонстрация
программного
изделия
в
действии,
чтобы
показать,
что
наиболее
критические
эксплутационные
характеристики
изделия
реализованы
в
соот-
ветствии
с
требованиями,
или
чтобы
установить,
насколько
да-
леко
продвинулся
проект.
Группа
разработки
стремится
закон-
чить
этот
этап
как
можно
раньше,
чтобы
учесть
замечания
тех,
кому
демонстрировалось
программное
изделие.
8.3.5 Организация разработки программного изделия
в фазе оценки
Фаза
оценки
открывается
началом
испытаний
класса
A,
проводимых
группой
разработки.
Испытания
класса
A
—
это
всесторонняя
проверка
программного
изделия,
которая
начина-
ется
после
того,
как
все
модули
программ
были
подвергнуты
индивидуальной
проверке
и
включены
в
работоспособную
сис-
тему.
Испытания
класса
A
начинаются
сразу
же
после
того,
как
в
систему
включен
последний
модуль.
Проводя
испытания
класса
A,
группа
разработки
прогоня-
ет
как
можно
больше
контрольных
примеров,
предложенных
группой
испытаний.
Это
ускоряет
фактическое
завершение
не-
зависимых
испытаний,
которые
проводит
группа
испытаний,
и
помогает
устранить
ошибки
в
самих
тестах,
являющиеся
часто
причиной
разногласий
между
этими
двумя
группами.
К
концу
испытаний
класса
A
группа
разработки
подготавливает
специ-
фикацию
выпуска
—
документ,
который
связывает
воедино
со-
ставные
части
программного
изделия.
Форма
спецификации
строго
стандартизована.
После
того,
как
число
ошибок,
обна-
руживаемых
во
время
испытаний
класса
A,
становится
незначи-
тельным,
группа
разработки
начинает
приемочные
испытания
по
программе,
составленной
группой
испытаний.
Приемочные
испытания
основываются
на
наборе
тестов,
выбранных
из
общей
программы
испытаний,
и
предназначены
для
выявления
недостатков
плохо
продуманного
программного
изделия.
К
сожалению,
под
впечатлением
результатов
испыта-
218
ний
группа
разработки
склонна
к
проведению
поспешных
из-
менений
в
модулях,
которые
могут
разрушить
целостность
про-
граммного
изделия.
Проведение
приемочных
испытаний
убеж-
дает
всех,
что
для
внесения
дополнительных
изменений
в
моду-
ли
нет
оснований.
Испытания
класса
B
представляют
собой
независимую
проверку
программного
изделия
на
соответствие
спецификаци-
ям.
Программное
изделие
считается
готовым
к
проведению
ис-
пытаний
класса
B
после
успешного
проведения
приемочных
испытаний.
Группа
разработки
составляет
отчет
об
испытаниях
класса
A,
подытоживая
результаты
этих
испытаний,
в
том
числе
и
приемочных,
свидетельствующих
о
готовности
программного
изделия
к
испытанию
класса
B.
Группа
испытаний
подготавливает
набор
тестов.
Испыта-
ния
на
основе
этих
тестов
обычно
проводятся
циклами,
начиная
с
повторных
приемочных
испытаний.
Цикл
испытаний
предпо-
лагает
прогон
как
можно
большего
числа
тестов
в
максимально
сжатые
сроки
и
завершается
отчетом
о
результатах
испытаний,
который
направляется
в
группу
разработки.
Если
после
цикла
испытаний
в
программном
изделии
будут
обнаружены
недос-
татки,
препятствующие
его
выпуску,
группа
разработки
с
мак-
симальной
быстротой
реагирует
на
результаты
цикла
и
предъ-
являет
программное
изделие
в
исправленном
виде
для
нового
цикла
испытаний.
Группа
разработки
получит
наивысшую
оценку,
если
испытания
класса
B
пройдут
за
один
цикл.
Хотя
это
иногда
и
случается,
чаще
всего
приходится
проводить
около
трех
циклов
испытаний.
Однако
на
практике
известны
случаи,
когда
количество
циклов
достигало
10.
В
то
время
как
группа
испытаний
проводит
испытания
класса
B,
группа
выпуска
документации
представляет
на
рас-
смотрение
справочные
материалы.
Группа
разработки
имеет
последнюю
возможность
исправить
ошибки
в
этих
материалах,
и
поэтому
их
рассмотрение
должно
проводиться
наиболее
тща-
тельно.
Группа
выпуска
документации
учитывает
замечания
разработчиков
и
проводит
последний
просмотр
материала
перед
сдачей
в
печать.
219
Фаза
оценки
заканчивается
тогда,
когда
группа
испыта-
ний
излагает
свои
замечания
в
отчете
об
испытаниях
класса
B.
Отчет
составляется
после
того,
как
группа
испытаний
приходит
к
выводу,
что
программное
изделие
удовлетворяет
или
не
удов-
летворяет
критериям
испытаний.
Чаще
всего
при
испытаниях
выявляется
ряд
нерешенных
проблем,
к
рассмотрению
которых
привлекаются
разработчики.
Решение
о
выпуске
программного
изделия
для
широкого
использования
принимается
на
основе
отчета
группы
испытаний
и
пояснительной
записки
группы
разработки,
которая
обычно
предлагает
план
устранения
недос-
татков.
Поэтому
группа
разработки
тщательно
изучает
отчет
об
испытаниях
класса
B
и
рекомендует
меры
для
устранения
всех
замеченных
дефектов.
При
этом
группа
разработки
может
всту-
пать
во
взаимодействие
с
группой
сопровождения,
если
выяв-
ленные
дефекты
могут
быть
компенсированы
какими-либо
средствами
во
время
эксплуатации.
8.3.6 Окончание проекта
Независимо
от
причин,
вызвавших
завершение
проекта,
группа
разработки
выпускает
отчет,
из
которого
могут
почерп-
нуть
опыт
разработчики
будущего
проекта.
Заключительный
отчет
составляется
всеми
участниками
проекта
и
содержит,
как
минимум,
следующую
информацию:
•
опыт
преодоления
наибольших
трудностей,
встретив-
шихся
при
разработке
проекта;
•
рекомендации
по
разработке
последующих
проектов
(включая
различные
варианты);
•
сводку
плановых
и
фактических
сроков
выполнения
этапов
(включая
все
случаи
изменения
запланирован-
ных
сроков);
•
сводку
запланированных
и
фактических
расходов;
•
сводку
запланированных
и
фактических
трудозатрат;
•
сводку
запланированных
и
фактически
используемых
машинных
ресурсов;
•
хронологию
затруднений
в
работе
с
оборудованием
и
рекомендации
по
устранению
недостатков
в
будущем;
220
•
хронологию
возникновения
трудностей,
связанных
с
взаимодействием
функциональных
подразделений;
•
рекомендации
по
планированию
в
условиях
неопреде-
ленности;
•
хронологическую
запись
наиболее
значимых
событий.
Если
разработка
программного
изделия
завершена
полно-
стью,
то
заключительный
отчет
включается
в
спецификацию
сопровождения.
Нормальное
завершение
проекта
наступает
на
этапе
фазо-
вого
обзора
V,
когда
принимается
решение
о
выпуске
про-
граммного
продукта.
Группа
разработки
составляет
заключи-
тельный
отчет
как
можно
быстрее,
прежде
чем
сотрудники
про-
екта
окажутся
занятыми
своими
новыми
обязанностями.
Она
также
выпускает
заключительное
уведомление
о
календарных
сроках
и
просит
о
закрытии
финансового
счета.
В
случае
нор-
мального
завершения
проекта
сотрудники
переключаются
на
другую
работу.
Преждевременное
завершение
работ
(прекра-
щение
финансирования,
исчезновение
необходимости
в
про-
граммном
изделии)
обычно
застает
разработчиков
врасплох.
В
любом
случае,
руководитель
обязан
обеспечить
порядок
пере-
хода
на
новую
работу.
Он
должен
проследить,
чтобы
сотрудни-
ки
завершили
документирование,
сдали
в
архив
все
необходи-
мые
данные
(тексты
программ,
тесты
и
т.д.),
составили
заклю-
чительный
отчет.
Заключительные
операции
надо
проводить
и
в
том
случае,
если
проект
окажется
неудачным.
8.3.7 Участие группы разработки в фазовых обзорах
Группа
разработки
участвует
в
пяти
из
шести
предусмот-
ренных
фазовых
обзорах
(табл.
8.4).
В
фазовом
обзоре
I
эта
группа
дает
первоначальную
оценку
стоимости
проекта
и
со-
ставляет
предварительный
график
проектирования.
Она
рас-
сматривает
все
представленные
данные,
утверждает
календар-
ные
сроки,
в
особенности
срок
готовности
соглашения
о
требо-
ваниях,
а
также
распределение
ресурсов.
На
этом
этапе
целесо-
образно
планировать
только
те
расходы,
которые
необходимы
для
доведения
проекта
до
этапа
утверждения
соглашения
о
тре-
бованиях,
что
позволит
избежать
перерасхода
средств,
если