Модели жизненного цикла программного обеспечения (стр. 6 )

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

Примечания

1.Проблемы языка спецификаций не в том, что нельзя (или трудно) строго и четко описать, что требуется в проекте. В большей степени они связаны с необходимо-стью добиваться и поддерживать соответствие описания «что» нечетким, неточным и часто противоречивым требованиям со стороны внешних по отношению к проек-ту людей. Нет оснований полагать, что эти люди будут знакомы с «самым хорошим языком спецификаций», что они будут заботиться о корректности своих требований. Задача этапа спецификаций в том и состоит, чтобы описание программы выстроить в виде логически выверенной системы, понятной как для заказчика данной разра-ботки, будущих пользователей, так и для исполнителей проекта.

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

3.Этап окончания работ мог бы быть представлен во всех традиционных моделях, но в то время, когда эти модели разрабатывались, ему не придавали особого значения. Вместе с тем, когда речь идет о совместной поддержке нескольких версий (а именно такая ситуация типична для объектно-ориентированного проектирования) окончание работ игнорировать нельзя.

4.В несколько модернизированном виде здесь приводится ставшая классической модель Г. Буча.

Литература

Как проектируются и создаются программные комплексы. — М.: Мир, 1979. Мифический человеко-месяц, или как создаются программные системы. — СПб: Символ-Плюс, 1999. Методы управления проектированием программного обеспечения. — М.: Мир, 1981. и др. Технология проектирования комплексов программ АСУ. — М.: Радио и связь, 1983. Инженерное проектирование программного обеспечения. — М.: Радио и связь, 1985. Объектно-ориентированное проектирование с примерами применения. — М.: Конкорд, 1992. Язык UML. Руководство пользователя. — М.: ДМК, 2000. и др. Объектно-ориентированные CASE - средства // СУБД. — 1966, № 5-6. С. 119-125 CASE - технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 1998. Ричардс и др. Oracle ® 7.3. Энциклопедия пользователя. — Киев: «ДиаСофт», 1997. IEEE IDEF0. “Standard Users Manual for the ICAM Function Modeling Method — IDEF0”. — IEEE draft standard P1320.1Rational Unified Process. — Copyright © 2001 Rational Software Corporation. http://www. /products/rup/index. jsp

часть 2

3. Требования к программному изделию
и жизненный цикл

В настоящем разделе рассматривается еще один очень важный мотив моделирования жизненного цикла программных изделий. Речь идет о более пристальном внимании к изучению требований при развитии программных проектов. Традиционные технологии рассматривают определение и анализ требований в рамках предварительного этапа, предшествующего собственно разработке, за который выявляется вся информация для последующего конструирования. Утверждается, что успешность дальнейшей работы над проектом прямо зависит от того, насколько полно и тщательно выполнен аналитический этап, что внесение корректив в зафиксированные требования приводит к необходимости повторения проектирования и всех других последующих этапов. Иными словами, изменение требований в процессе разработки рассматривается как ошибка аналитического этапа. Однако эта парадигма явно противоречит практике, что нашло отражение в известном афоризме: любая полезная программа нуждается в модификациях, а бесполезная — в документации.

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

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

3.1. Проблемы определения и анализа требований

В наиболее общем виде понятие требований сводится к следующим двум аспектам, фиксируемым для выполнения конструкторских работ:

  средства программного изделия, в которых нуждается пользователь для решения своих проблем или достижения определенных целей;

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

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

Основные проблемы управления требованиями, с которыми приходится сталкиваться при их анализе, сводятся к следующему.

  Требования имеют много источников.

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

  Требования не всегда очевидны.

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

  Требования не всегда легко выразить словами.

Интуитивное представление о том, какие средства должны предоставляться, чаще всего не формулируются явно. Приводится множество противоречивых примеров, наводящих соображений, но не описание нужных средств. В этой связи одна из главных задач анализа — представить требования в виде согласованных между заказчиком и разработчиками (одинаково понимаемых) утверждений, схем, диаграмм, моделей и т. п.;

  Существует множество различных типов требований и различных уровней их детализации.

Совокупность требований весьма многопланова и соотносится с различными аспектами проекта. Следовательно, одной из задач анализа является типизация имеющихся сведений о требованиях и распределение их по этапам и итерациям разработки;

  Требования чаще всего взаимосвязаны и взаимозависимы, иногда противоречивы.

Связи между требованиями обусловлены, в первую очередь, тем, что пожелания к разработке даются в системе понятий, которая исходит из предметной области и поведения пользователя, решающего задачи из этой области. Не следует ожидать, что связи между требованиями будут хорошо отслежены, что заранее будет сформулирована система объектов, которые воплощаются в программном изделии. Все, на что можно рассчитывать, получая сведения о требованиях, — это неформальное представление о том, кто будет работать с системой и зачем ему это нужно. Как следствие, в задачу анализа входит выявление взаимосвязей и взаимозависимостей, устранение противоречий путем выработки рациональных компромиссов;

  Требования всегда уникальны.