Ћекции.ќрг


ѕоиск:




 атегории:

јстрономи€
Ѕиологи€
√еографи€
ƒругие €зыки
»нтернет
»нформатика
»стори€
 ультура
Ћитература
Ћогика
ћатематика
ћедицина
ћеханика
ќхрана труда
ѕедагогика
ѕолитика
ѕраво
ѕсихологи€
–елиги€
–иторика
—оциологи€
—порт
—троительство
“ехнологи€
“ранспорт
‘изика
‘илософи€
‘инансы
’ими€
Ёкологи€
Ёкономика
Ёлектроника

 

 

 

 


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




 

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

¬ стандарте ISO/IEC 12207 не конкретизируютс€ в детал€х методы реализации и выполнени€ действий и задач, вход€щих в процессы жизненного цикла информационной системы, а лишь описываютс€ структуры этих процессов. Ёто вполне пон€тно, так как регламенты стандарта €вл€ютс€ общими дл€ любых моделей жизненного цикла, методологий и технологий разработки. ћодель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создаетс€ и функционирует. ѕоэтому не имеет смысла предлагать какие-либо кон≠кретные модели жизненного цикла и методы разработки информационных систем дл€ общего случа€, без прив€зки к определенной предметной области.

  насто€щему времени наибольшее распространение получили следующие две основные модели жизненного цикла:

Ј каскадна€ модель, иногда также называема€ моделью Ђводопадї (waterfall);

Ј спиральна€ модель.

 аскадна€ модель демонстрирует классический подход к разработке различных систем в любых прикладных област€х. ƒл€ разработки информационных систем данна€ модель широко использовалась в 70-х и первой половине 80-х годов.  ас≠кадные методы проектировани€ хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографи€х, стандартах, учеб≠никах. ќрганизаци€ работ по каскадной схеме официально рекомендовалась и широко примен€лась в различных отрасл€х. “аким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение дес€тилетий позвол€ет называть каскад≠ные методы классическими.

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

ќсновные этапы разработки по каскадной модели. «а дес€тилети€ существовани€ модели Ђводопадї разбиение работ на стадии и названи€ этих стадий мен€лись.  роме того, наиболее разумные методики и стан≠дарты избегали жесткого и однозначного приписывани€ определенных работ к конкретным этапам. “ем не менее все же можно выделить р€д устойчивых этапов разработки, практически не завис€щих от предметной области:

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

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

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

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

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

Ќа первом этапе проводитс€ исследование проблемы, котора€ должна быть реше≠на, четко формулируютс€ все требовани€ заказчика. –езультатом, получаемым на данном этапе, €вл€етс€ техническое задание (задание на разработку), согласован≠ное со всеми заинтересованными сторонами.

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

“ретий этап Ц реализаци€ проекта. «десь осуществл€етс€ разработка программ≠ного обеспечени€ (кодирование) в соответствии с проектными решени€ми, полу≠ченными на предыдущем этапе. ћетоды, используемые дл€ реализации, не имеют принципиального значени€. –езультатом выполнени€ данного этапа €вл€етс€ го≠товый программный продукт.

Ќа четвертом этапе проводитс€ проверка полученного программного обеспечени€ на предмет соответстви€ требовани€м, за€вленным в техническом задании. ќпыт≠на€ эксплуатаци€ позвол€ет вы€вить различного рода скрытые недостатки, про≠€вл€ющиес€ в реальных услови€х работы информационной системы.

ѕоследний этап Ц сдача готового проекта. √лавна€ задача этого этапа Ц убедить заказчика, что все его требовани€ реализованы в полной мере.

Ётапы работ в рамках каскадной модели часто также называют част€ми Ђпроектно≠го циклаї системы. “акое название возникло потому, что этапы состо€т из многих итерационных процедур уточнени€ требований к системе и вариантов проектных решений. ∆изненный цикл самой системы существенно сложнее и больше. ќн мо≠жет включать в себ€ произвольное число циклов уточнени€, изменени€ и дополне≠ни€ уже прин€тых и реализованных проектных решений. ¬ этих циклах происходит развитие информационной системы и модернизаци€ отдельных ее компонентов.

ќсновные достоинства каскадной модели.  аскадна€ модель имеет р€д положительных сторон, благодар€ которым она хо≠рошо зарекомендовала себ€ при выполнении различного рода инженерных разра≠боток и получила широкое распространение. ќсновные достоинства модели Ђводопадї:

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

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

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

“ем не менее, несмотр€ на все свои достоинства, каскадна€ модель имеет р€д недо≠статков, ограничивающих ее применение при разработке информационных сис≠тем. ѕричем эти недостатки делают ее либо полностью неприменимой, либо при≠вод€т к увеличению сроков разработки и стоимости проекта. ¬ насто€щее врем€ многие неудачи программных проектов объ€сн€ютс€ именно применением после≠довательного процесса разработки.

Ќедостатки каскадной модели. ѕеречень недостатков каскадной модели при ее использовании дл€ разработки информационных систем достаточно обширен:

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

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

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

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

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

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

«адержка получени€ результатов обычно считаетс€ главным недостатком каскад≠ной схемы. ƒанный недостаток про€вл€етс€ в основном в том, что вследствие после≠довательного подхода к разработке согласование результатов с заинтересованными сторонами производитс€ только после завершени€ очередного этапа работ. ѕоэто≠му может оказатьс€, что разрабатываема€ информационна€ система не соответству≠ет требовани€м пользователей. ѕричем такие несоответстви€ могут возникать на любом этапе разработки Ц искажени€ могут непреднамеренно вноситьс€ и проек≠тировщиками-аналитиками, и программистами, так как они не об€зательно хорошо разбираютс€ в тех предметных област€х, дл€ которых производитс€ разработка ин≠формационной системы.

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

¬озврат на более ранние стадии. ƒанный недостаток каскадной модели €вл€етс€ одним из про€влений предыдущего. ѕоэтапна€ и последовательна€ работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаютс€ только на последующих стади€х ра≠боты над проектом. ѕоэтому, после того как ошибки про€в€тс€, проект возвраща≠етс€ на предыдущий этап, перерабатываетс€ и снова передаетс€ на последующую стадию. Ёто может служить причиной срыва графика работ и усложнени€ взаимо≠отношений между группами разработчиков, выполн€ющих отдельные этапы ра≠боты.

—амым же непри€тным €вл€етс€ то, что недоработки предыдущего уровн€ могут обнаруживатьс€ не сразу на последующем уровне, а позднее (например, на стадии опытной эксплуатации могут про€витьс€ ошибки в описании предметной облас≠ти). Ёто означает, что часть проекта должна быть возвращена на начальный уро≠вень работы. ¬ообще, работа может быть возвращена с любого этапа на любой пре≠дыдущий этап, поэтому в реальном случае каскадна€ схема разработки имеет вид, приведенный на рис. 1.

 
 

 

 


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

 

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

—ложность параллельного ведени€ работ. ќтмеченные выше проблемы возникают вследствие того, что работа над проектом строитс€ в виде цепочки последователь≠ных шагов. ѕричем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. —ложности параллельного ведени€ работ св€заны с необходимостью посто€нного согласовани€ различных частей проекта. „ем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполн€тьс€ синхронизаци€, тем сильнее зависимы друг от другагруппы разработчиков. ѕоэтому преимущества параллельного ведени€ работ просто тер€ютс€.

ќтсутствие параллелизма негативно сказываетс€ и на организации работы всего коллектива разработчиков. –абота одних групп сдерживаетс€ другими. ѕока производитс€ анализ предметной области, проектировщики, разработчики и те, ктозанимаетс€ тестированием и администрированием, почти не имеют работы.  роме того, при последовательной разработке крайне сложно внести изменени€ в проект после завершени€ этапа и передаче проекта на следующую ста≠дию. “ак, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Ёто св€зано с тем, что более раннее решение уже, возможно, реализовано и св€зано с другими част€ми проекта. ѕоэтому исключаетс€ (или, по крайней мере, существенно затрудн€етс€) доработка проекта после его передачи на следующий этап.

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

ѕричем синхронизаци€ документации на каждую часть системы Ц это не более чемпроцесс оповещени€ групп разработчиков. —амим же разработчикам необходимо ознакомитьс€ с изменени€ми и оценить, не сказались ли эти изменени€ на уже полученных результатах. ¬се это может потребовать проведени€ повторного тестировани€ и даже внесени€ изменений в уже готовые части проекта.

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

—ледует также отметить, что, кроме изучени€ нового материала, не отпадает и необходимость в изучении старой информации. Ёто св€зано с тем, что вполне веро€тна ситуаци€, когда в процессе выполнени€ разработки измен€етс€ состав группы разработчиков (этот процесс носит название ротации кадров). Ќовым разработчикам необходима информаци€ о том, что было сделано до них. ѕричем чем сложнее проект, тем больше времени требуетс€, чтобы ввести нового разработчика в курс дела.

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

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

¬ случае же обнаружени€ ошибок в выполненной работе необходим возврат к пре≠дыдущим этапам выполнени€ проекта. Ёто приводит к дополнительным сложнос≠т€м в управлении проектом. –азработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и зан€тьс€ исправле≠нием ошибок. —ледствием этого обычно €вл€етс€ срыв сроков выполнени€ как исправл€емого, так и нового проектов. “ребовать же от команды разработчиков ожидани€ окончани€ следующей стадии разработки нерационально, так как при≠водит к существенным потер€м рабочего времени.

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

¬ысокий уровень риска. „ем сложнее проект, тем больше продолжительность каж≠дого из этапов разработки и тем сложнее взаимосв€зи между отдельными част€ми проекта, количество которых также увеличиваетс€. ѕричем результаты разработ≠ки можно реально увидеть и оценить лишь на этапе тестировани€, то есть после завершени€ анализа, проектировани€ и разработки Ц этапов, выполнение кото≠рых требует значительного времени и средств.  ак уже было отмечено выше, запоздала€ оценка создает значительные проблемы при вы€влении ошибок анализа и проектировани€ Ц требуетс€ возврат проекта на предыдущие стадии и повторе≠ние процесса разработки.

ќднако возврат на предыдущие стадии может быть св€зан не только с ошибками, но и с изменени€ми, произошедшими за врем€ выполнени€ разработки в предмет≠ной области или в требовани€х заказчика. ѕричем возврат проекта вследствие этих причин на доработку не гарантирует, что предметна€ область снова не изменитс€ к тому моменту, когда будет готова следующа€ верси€ проекта. ‘актически это означает, что существует веро€тность того, что процесс разработки Ђзациклитс€ї и никогда не дойдет до сдачи в эксплуатацию. –асходы на проект будут посто€нно расти, а сроки сдачи готового продукта Ц посто€нно откладыватьс€.

ѕоэтому можно утверждать, что сложные проекты, разрабатываемые по каскад≠ной схеме, имеют повышенный уровень риска. Ётот вывод подтверждаетс€ прак≠тикой: по сведени€м консалтинговой компании The Standish Group, в —Ўј более 31 % проектов корпоративных информационных систем (IT-проектов) заканчи≠ваетс€ неуспехом; почти 53 % IT-проектов завершаетс€ с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладыва≠етс€ и в срок, и в бюджет.

—уществует еще один серьезный недостаток, присущий каскадной модели разработ≠ки, на который также следует обратить внимание. Ётот недостаток св€зан с конфлик≠том (не всегда €вным) между разработчиками, участвующими в выполнении проекта. Ётот конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождаетс€ поиском причин и виновных. ј так как однозначно персони≠фицировать ответственного за ошибки далеко не всегда возможно, то попытки поис≠ка виноватых могут сильно усложнить отношени€ в коллективе.  ак следствие, в рабочей группе часто ценитс€ не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет Ђотсто€тьї своих подчиненных, обеспечить им более удобные услови€ работы и т. п. ¬ результате по€вл€етс€ опасность снижени€ и квали≠фикации, и творческого потенциала всей команды. —оответственно, техническое ру≠ководство проектом начинает в большей степени подмен€тьс€ организационным ру≠ководством, все более детальной проработкой должностных инструкций и все более формальным исполнением этих инструкций. “от, кто не умеет организовать работу, обречен боротьс€ за дисциплину. » здесь возникает проблема несовместимости дис≠циплины и творчества. „ем строже дисциплина, тем менее творческой становитс€ атмосфера в коллективе. » такое положение вещей может привести к тому, что наи≠более одаренные кадры со временем покинут коллектив.

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





ѕоделитьс€ с друзь€ми:


ƒата добавлени€: 2017-02-28; ћы поможем в написании ваших работ!; просмотров: 6008 | Ќарушение авторских прав


ѕоиск на сайте:

Ћучшие изречени€:

“ак просто быть добрым - нужно только представить себ€ на месте другого человека прежде, чем начать его судить. © ћарлен ƒитрих
==> читать все изречени€...

1540 - | 1340 -


© 2015-2024 lektsii.org -  онтакты - ѕоследнее добавление

√ен: 0.017 с.