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

 

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

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

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

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