Студопедия

КАТЕГОРИИ:

АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника


Модели жизненного цикла информационной системы




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

В стандарте ISO/IEC 12207 не конкретизируются в деталях методы реализации и выполнения действий и задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо кон­кретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области. К настоящему времени наибольшее распространение получили следующие две основные модели жизненного цикла:

- каскадная модель, иногда также называемая моделью «водопад» (waterfall);

- спиральная модель.

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

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

За десятилетия существования модели «водопад» разбиение работ на стадии и
названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к
конкретным этапам. Тем не менее все же можно выделить ряд устойчивых этапов
разработки, практически не зависящих от предметной области (рис. 16):

- анализ требований заказчика;

- проектирование;

- разработка;

- тестирование и опытная эксплуатация;

- сдача готового продукта.

Рис. 16. Каскадная модель разработки

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

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

Третий этап — реализация проекта. Здесь осуществляется разработка программ­ного обеспечения (кодирование) в соответствии с проектными решениями, полу­ченными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является го­товый программный продукт.

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

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

Этапы работ в рамках каскадной модели часто также называют частями «проектно­го цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и больше. Он мо­жет включать в себя произвольное число циклов уточнения, изменения и дополне­ния уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.

Каскадная модель имеет ряд положительных сторон, благодаря которым она хо­рошо зарекомендовала себя при выполнении различного рода инженерных разра­боток и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:

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

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

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

Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных сис­тем. Причем эти недостатки делают ее либо полностью неприменимой, либо при­водят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно применением после­довательного процесса разработки.

Перечень недостатков каскадной модели при ее использовании для разработки Информационных систем достаточно обширен. Вначале просто перечислим их, а за­тем рассмотрим основные из них более подробно:

- существенная задержка получения результатов;

- ошибки и недоработки на любом из этапов выясняются, как правило, на после­дующих этапах работ, что приводит к необходимости возврата на предыдущие стадии;

- сложность распараллеливания работ по проекту;

- чрезмерная информационная перенасыщенность каждого из этапов;

- сложность управления проектом;

- высокий уровень риска и ненадежность инвестиций.

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

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

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

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

Рис. 17. Реальный процесс разработки по каскадной схеме

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфлик­том (не всегда явным) между разработчиками, участвующими в выполнении проекта. Этот конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персони­фицировать ответственного за ошибки далеко не всегда возможно, то попытки поис­ка виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабо­чей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т.п. В результате появляется опасность снижения и квали­фикации, и творческого потенциала всей команды. Соответственно, техническое ру­ководство проектом начинает в большей степени подменяться организационным ру­ководством, всё более детальной проработкой должностных инструкций и все более формальным исполнением этих инструкций. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. И такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

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

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

Рис. 18. Спиральная модель жизненного цикла информационной системы

 

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

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

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

Рассмотрим преимущества итерационного подхода более подробно:

- итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

Рис. 19. Зависимость рисков от времени разработки

 

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

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

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

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

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

Планирование работ обычно проводится на основе статистических данных, полу­ченных в предыдущих проектах, и личного опыта разработчиков.

 


Поделиться:

Дата добавления: 2015-01-29; просмотров: 98; Мы поможем в написании вашей работы!; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2024 год. (0.005 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты