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

 

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

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

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

7. Вместо подготовки к распространени системы для прикладного использования проводятся демонстрационне испытания, после завершения которых (контрольная точка 9) осуществляется переход к следующей итерации;
8. рервания процесса выполнения первой итерации для обработки дополнительных требований не допускаются. По существу это означает, что остается единственнй вариант работ с такими требованиями: откладывание их анализа и реализации до последуих итераций.
4.4. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ И ЖИЗНЕННЫЙ ЦИКЛ 231
Организация работ методом «Сначала в глубину» не предполагает предварительной подготовки элементов системы поддержки процесса разработки, которые зависят от прикладной области. Инструментальная часть этой системы вполне мо ет быть универсальной, в частности, когда разработчики выполня т совместно не первый проект, это, скорее всего, так и будет, но информационная часть системы всегда определяется область применения программного изделия.
В ходе первой итерации к моменту выбора сценариев для реализации долна быть составлена предварительная, гипотетическая система типов требований, которая меняется под воздействием сведений, получаемых при в -полнении мини-циклов, а так е при интеграции сценариев. тоговая система типов требований есть один из результатов этапа пополнения базового окружения проекта. Ситуация с глоссарием аналогична, с той лишь разницей, что нет необходимости до этого этапа фиксировать гипотетические поло ения о прикладной области, о составляемх моделях и т. п. редвари-тельно (до начала мини-циклов разрабоки сценариев) в глоссарий следует вкл чить сведения о стратегии разработки, соглаения о технологических регламентах, т. е. все то, что носит универсальный характер.
з приведенной модели видно, что метод « начала в глубину» дает хоро-ее представление о том, как происходит итеративное проектирование. Разработчики могут рассматривать мини-циклы в качестве прототипа итеративного нараивания, а поскольку кадый из мини-циклов обозрим, к концу первой итерации достигается решение задачи, о которой шла речь выше: доказательство того, что данная команда, используя даннй метод в конкрет-нх условиях, в дальнейем приведет проект к успенм результатам.
4.4.5. Фаза завершения
Завершение проекта редко описывают в моделях жизненного цикла структурно. бчно этот период только обозначается, а его работ лиь класси-фициру тся. Возмо но, что разнообразие вариантов организации эксплуатационной поддерки препятствует систематическому их изучени . е стимулирует изучение этих работ также неявное и не соответствующее действительности положение о том, что требования к системе, возникающие на фазе заверения, относятся у е к другому проекту. В то е время промленная разработка программных систем всегда ну дается в организации как мо но более скорых откликов на пользовательские запросы: рекламации, по ела-ния и требования развития.
232
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
В контексте изучения изненного цикла с точки зрения обработки требований задачу моделирования фазы завершения можно описать в стиле, который был использован при учете трассировки требований. Цели этого моделирования следуие.
a) Во-первх, это систематизация действий, которые необходимо выполнять в качестве реакции на пользовательские запрос .
b) Во-вторых, это явное разграничение реакций, относящихся:
i) к текущей версии,
ii) к одной из следуих версий,
iii) к другому проекту.
Для развития итеративных проектов такое разграничение очень важно из-за необходимости осуествлять одновременно и поддерку разнх версий, и нараивание возмо ностей систем 10.
сновой моделирования фазы заверения проекта (итерации) является обратная связь с пользователями системъі. Это, для коммерческого софта, обычные сообщения о ходе эксплуатации: мнения, рекламации, пожелания, нарекания, претензии и т. п. ля открытого софта необходимо так е добавить программные наработки и программне усоверенствования пользователей. Все подобные сообения могут бть классифицирован , раниро-ваны по степени важности для развиваемого (на данной фазе — обслуживаемого) проекта. Но это обстоятельство в модели не учитывается: считается, что из пользовательских сообений извлека тся требования к проекту в целом или к его итерации. Сообения, а значит, и требования могут поступать в ходе эксплуатации в течение всего периода использования систем или ее версии. Требования нуждаются в трассировке, о которой шла речь выше. По этой причине в качестве отправного момента моделирования фазы заверения проекта (итерации) слу ит модель изненного цикла, учитва-ая трассировку.
10 В частности, в связи с необходимостью сочетания этих двух, часто концептуально противоречивых, требований, в UNIX-подобных системах появилась концепция совместимости с точностью до ошибок и уникальная система компоновки служебных программ разных версий для поддержки данного конкретного продукта. Этому способствует модульная система организации программного обеспечения в UNIX и LINUX, контрастирующая, например, с централизованной системой Windows, которая начинает саморазрушаться при одновременном использовании программ, требующих разных версий стандартных утилит и системных библиотек.
Предыдущая << 1 .. 79 80 81 82 83 84 < 85 > 86 87 88 89 90 91 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100