Сравнительный анализ каскадной и спиральной моделей разработки программного обеспечения — страница 4

  • Просмотров 4875
  • Скачиваний 184
  • Размер файла 27
    Кб

реализовать в оговоренный срок. 4. На данном этапе определяются архитектура и ядро будущей системы. Это наиболее ответственный момент, так как здесь необходимо учесть пока еще не детализированные полностью требования к проекту - а они вполне могут быть противоречивыми. Ядро должно представлять собой законченный работающий вариант системы с небольшим набором необходимых возможностей. Не исключено, что заказчик видит

архитектуру как жесткую конструкцию и не предусматривает средств ее расширения для обеспечения дополнительной или менее приоритетной функциональности. Поэтому далее определяется способ реализации требований с более низкими приоритетами - это можно делать, например, с помощью встроенного языка сценариев или подключением динамических библиотек, для чего необходимо определить внутренние интерфейсы ядра. Этот шаг

выполняется, как правило, в два и большее число итерационных циклов. 5. Готовится план работ. Он ориентирован на сроки, определенные на третьем этапе, и нацелен на скорейшую реализацию ядра системы. Взаимодействуя с работающим прототипом, заказчик быстрее и точнее вырабатывает и уточняет дальнейшие требования и корректирует приоритеты. 6. Разработка системы в соответствии с планом. Для этого этапа характерны три типичных класса

проблем: - изменения в требованиях к проекту; - изменения параметров самого проекта (сроков, бюджета, качества); - временные задержки, связанные с текущими вопросами (техникой, персоналом). В ходе их решения приходится избавляться от задач с меньшими приоритетами и, возможно, изменять критический путь проекта. Все изменения вносятся с учетом основного критерия - сохранения сроков проекта. Данный подход, конечно, не гарантирует

соблюдения сроков - они могут быть сорваны, например, в случае резкого сокращения бюджета или серьезного изменения требований. Общие характеристики этапов разработки программного обеспечения Этап планирования и анализа требований Цель: - получение требований ; - выработка производных от них требований для этапа оценки безопасности. Входные данные: - требования к системе, аппаратный интерфейс, архитектура системы; - план

разработки ПО; - стандарты на требования к ПО. Первичный результат - данные о требованиях. Основные принципы: - интерфейсные и функциональные требования к системе, реализуемые на базе ПО, должны быть проанализированы на предмет противоречий, несоответствия и неопределенности; - неадекватные и некорректные входные данные должны быть направлены на выработавшие их подэтапы для разъяснения или исправления; - каждое требование к