Лекции по "Информационные системы"

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

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

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

5)Сложность управления  проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта.

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

 В случае же обнаружения  ошибок в выполненной работе  необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени.

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

6) Высокий уровень  риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки — этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено выше, запоздалая оценка создает значительные проблемы при выявлении ошибок анализа и проектирования — требуется возврат проекта на предыдущие стадии и повторение процесса разработки.

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

 Поэтому можно утверждать, что сложные проекты, разрабатываемые  по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group, в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

Лекция 11

Спиральная модель жизненного цикла.

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

Итерации.

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

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

Главная задача каждой итерации — как можно быстрее создать  работоспособный продукт, который  можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и  дополнений в проект.

Преимущества спиральной модели.

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

• итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;
• при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта);
• уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации и при выполнении начальных итераций выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и ПО, квалификация разработчиков и т. п. Ниже приведены зависимости уровня рисков от времени разработки при использовании каскадного и итерационного подходов;
• итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет уменьшения функциональности системы пли использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок.

• итерационный подход упрощает повторное использование компонентов позволяет использовать компонентный подход к программированию — более подробно об этом мы будем говорить в следующей главе). Это обусловлено тем. что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итерации позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;
• спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что при использовании каскадной модели выполняется только перед внедрением системы;
• итерационный подход позволяет совершенствовать процесс разработки — анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.

Проблемы, возникающие при  использовании спиральной модели.

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