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

 

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

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

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

Однако эта парадигма явно противоречит практике, что нашло отражение в известном афоризме:
любая полезная программа нуждается в модификациях, а бесполезная — в
документации.
оэтому сейчас получили распространение технологии программирования, основываиеся на методе итеративного нараивания предоставляемых пользователям средств системы, в частности, на базе объектно-ориентированного проектирования. Как у е было сказано, в таких технологиях постулируется, что все этапы разработки системы рассредоточиваются по итерациям, кадая из которх заверается предъявлением продукции, реализующей не все, а только выделенные для нее требования. Соответственно, на следуих итерациях этапы анализа, конструирования и т. д. продола-тся, а не повторя т пройденное в стиле исправления оибок. Понятно, что проблемы, связанные с определением и анализом требований, не исчеза т и в этом случае, но благодаря специальной организации труда преодолевать трудности мо но с меньими затратами. менно это обстоятельство побу дает к исследовани моделей изненного цикла, ко-торе более точно отраа т рациональне схем анализа и оперирования с
4.4. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ И ЖИЗНЕННЫЙ ЦИКЛ 215
требованиями.
4.4.1. Проблемы определения и анализа требований
В наиболее обем виде понятие требований сводится к следуим двум аспектам, фиксируемым для выполнения конструкторских работ:
• средства программного изделия, в которых нуждается пользователь для решения своих проблем или достижения определенных целей;
• характеристики программного изделия, которыми должна обладать система в целом или ее компонент, чтобы удовлетворять соглаениям, спецификациям, стандартам или другой формально установленной документации.
Даже это не очень точное определение понятия требования указывает, что в реальности очень трудно, исходя из аморфнх и противоречивых по ела-ний, вявить, что конкретно и в каком виде долно бть воплоено в программном изделии. Требования первичны по отношению к программной разработке, определя т все ее развитие, явля тся начальным звеном в слагаемых качества конструируемых программ. А потому задача управления требованиями должна рассматриваться в качестве одной из главных задач проекта, претендующего на реальную полезность для пользователя.
сновне проблем управления требованиями, с которми приходится сталкиваться при их анализе, сводятся к следуему:
1. Требования имеют много источников
Даже если программная система разрабатывается по заказу, существует широкий круг людей, так или иначе заинтересованных в развитии проекта. Это, разумеется, и будуие пользователи, и заказчик, и другие лица, которые осозна т как необходимость автоматизации деятельности с помоь данной системы, так и рамки, за которе входить не стоит. Все прикосновенные (в частности, сами разработчики и их руководители) имеют свои, как правило, взаимно противоречивые представления о задачах проекта. Это тем более так, когда ее разработка претендует на удовлетворение рночной потребности. ица, от кото-рх зависит, какие работ целесообразн для реализации в проекте, называются инициаторами работ;
2. Требования не всегда очевидны
216
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
мысл утвердения как минимум в том, что инициатор работ далеко не всегда знают, какими средствами должна обеспечиваться поддержка автоматизируемой деятельности, в каких интерфейсных формах эта поддерка долна бть выра ена. чень часто не получается четко выделить и саму автоматизируемую деятельность;
3. Требования не всегда легко выразить словами
нтуитивное представление о том, какие средства долны предоставляться, чае всего не формулиру тся явно. Вместо этого приводится мно ество противоречивх примеров, наводяих сообра ений. В этой связи одна из главнх задач анализа — представить требования в виде согласованных между заказчиком и разработчиками (одинаково понимаемых) утвердений, схем, диаграмм, моделей и т. п.;
4. Существует множество различных типов требований и различных уровней их детализации
Совокупность требований весьма многопланова и соотносится с различными аспектами проекта. ледовательно, одной из задач анализа является типизация имеихся сведений о требованиях и распределение их по этапам и итерациям разработки;
5. Требования почти всегда взаимосвязаны и взаимозависимы, и часто противоречивы
вязи меду требованиями обусловлен , в перву очередь, тем, что по елания к разработке да тся в системе понятий, которая исходит из предметной области и поведения пользователя, решающего задачи из этой области. Не следует ожидать, что связи между требованиями будут хороо отсле ен , что заранее будет сформулирована система объектов, которые воплоа тся в программном изделии. се, на что мо но рассчитвать, получая сведения о требованиях, — это неформальное представление о том, к о будет работать с системой и зачем ему это нужно. Как следствие, в задачу анализа входит выявление взаимосвязей и взаимозависимостей и устранение противоречий (в дости-
имом, но практически не встречаемся в современном индустриальном программировании идеале путем преобразования их в идеи ре-
Предыдущая << 1 .. 73 74 75 76 77 78 < 79 > 80 81 82 83 84 85 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100