Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Непейвода Н.Н. -> "Основания программирования " -> 86

Основания программирования - Непейвода Н.Н.

Непейвода Н.Н., Скопин И.Н. Основания программирования — Институт компьютерных исследований , 2002. — 919 c.
Скачать (прямая ссылка): osnovanprogramm2002.pdf
Предыдущая << 1 .. 80 81 82 83 84 85 < 86 > 87 88 89 90 91 92 .. 316 >> Следующая

4.4. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ И ЖИЗНЕННЫЙ ЦИКЛ 233
В представленной на рис. 4.17 модели описываются операционные марш -
Начальная фаза проекта
Фазы (этапы):
Контрольные точки (события):
Итеративное зацикливание
V
Исследования -»|
(— Анализ осуществимости ->|
л
Конструирование
Y
0 1/2 Накопление, систематизация и группировка требований Решение о реализации требований принято (c) -—і
Пополнение базового окружения проекта
<- Программирование-»!
Завершение проекта (итерации)
<- I Использование ->\
?- Период сопровождения->|
I Решение оОкончан|ие
п u реализации: /ч
Первичный r I*- -*
в другом проекте
^-в следящих версиях I в текущей версии
3 45 6789 10
к—Реализация требований
— Проверка реализации
Распростанение изменения начато—
Сообщение поступило (a) j
Немедленная реализация
Требование отклоняется
11™г2
работ
(b) Решение о требовании принято Извлечение требования
Рис. 4.17.
рута, возникающие в связи с обработкой одного требования в ходе эксплуатации программной системы. Для упрощения предполагается, что операционные маршруты не зависят от накапливаемой информации. Это заведомо огрубляющее предположение в том смысле, что принятие решений о требовании фактически делается не только на основании первичных установок, но и с использованием знаний о системе, пользователях, о текущем представлении о приоритетах и предпочтениях. о но считать, что подобные сведения использу тся в точках разветвления операционных маррутов, но то, как осуществляется такое использование, моделью не описывается.
Аналогично организации мини-цикла для трассировки требований, в модели периода эксплуатации началом обработки является поступление сооб-ения о ходе эксплуатации системы, которое мо но трактовать как содержащее требования (контрольная точка (а)). Это событие может возникать в лбой момент периода сопрово дения, т. е. обсу даемая модель является естественным продолжением модели с обработкой требования в мини-цикле (см. § 4.4.3). Так как отобразить весь поток сообщений невозможно, рассматривается операционный маррут только одного сообения, при этом постулируется, что все сообщения обрабатываются подобно:
• поступление сообщения (контрольная точка (а));
234
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
• первичный анализ, в ходе которого из сообщения извлекаются требования. Этот период должен быть максимально кратким, ибо пользователю необходимо знать о реакции разработчиков на его сообщение. Результатом первичного анализа является принятие решения о требовании (контрольная точка (b), в которой происходит расепление линии жизненного цикла). Возможны следующие не взаимоисключаю -щие друг друга варианты такого решения:
- немедленная реакция — действия, направленные на быстрое устранение замечания (либо принятие предло ения, в случае открто-го софта), если это возмо но, либо указание пользовател сроков, когда и как будут учтены поступивие претензии или пред-ло ения, либо указание путей (возмо но, временных) преодоления трудностей. Немедленная реакция выполняется всегда, в том числе совместно с другими реениями;
- ребование оклоняе ся — действия, указываие пользовате-л причины отклонения требований и пути преодоления трудностей;
- реализация требования или предложения втекущей версии — если претензии обоснованы, а устранение замечаний, ошибок и т. п. возмо но в рамках обслу иваемой версии, то организуется мини-цикл обработки сообения в итерации;
- реализация требования или предложения в одной из следующих версий — если устранение замечаний в рамках обслу иваемой версии невозмо но или нецелесообразно, то сообение передается для исполнения на одной из следуих итераций проекта;
- реализация требования или предложения в другом проекте — если вясняется, что в данном проекте вполнить требование или учесть предло ение невозмо но или нецелесообразно, то, бть мо ет, оно станет одним из аргументов в пользу организации нового проекта.
• мини-цикл обработки сообщения начинается с анализа, цели которого обчны для итеративного развития проектов. В частности, определяется осуествимость реализации на данной итерации или целесообразность переноса ее на другу итераци , образуется группа требований, которе долн бть реализованы совместно. Выработка этих рее-ний о стратегии реализации требований приурочивается к контрольной
4.5. ИТОГИ И ПЕРСПЕКТИВЫ
235
точке (c). собенность анализа в данном случае является то, что он проводится, как возобновленный процесс, т. к. основные работы итерации уже выполнены;
• реализация ообраннх ребований или предло ений на данной итерации осуществляется по обычной схеме, включающей конструирование и программирование и оценку. В качестве специфики следует указать на особую роль проверочных работ — дополнительный этап проверки реализации, которй вкладывается в этап оценки. Эти работы обязательно долн вкл чать повторение проверки того, что бло отлажено ранее. Таким образом, пополнение базового окружения проекта приобретает дополнительное содерание: накопление тестовой базы проекта;
Предыдущая << 1 .. 80 81 82 83 84 85 < 86 > 87 88 89 90 91 92 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100