Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

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

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

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

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

Требования к информационным системам требовательно формализуются и закрепляются в техническом задании. Основное внимание уделяется планированию работ, организации труда в коллективе специалистов, число которых может достигать сотен и тысяч человек, управлению работами и контролю за их выполнением, а также соблюдением заданных программных характеристик. Внедрение в эксплуатацию предупреждается проведением одностадийных испытаний в специально сформированных или реальных условиях. Обязательной замечается фаза сопровождения и связанная с этим необходимость подготовки качественной программной документации, тиражирования и передачи информационных систем в прочие эксплуатирующие организации. Общее время жизни информационных систем может достигать десяти и более лет, из которых 70 - 90% может приводиться на фазы эксплуатации и сопровождения. Продолжительность эксплуатации может вызвать необходимость модернизации информационных систем и, соответственно, к возвращению раньше изученным фазам.

Жизненный цикл информационных систем и его структура

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

Модель ЖЦ ИС включает в себя:

  • стадии;
  • результаты выполнения работ на каждой стадии;
  • ключевые события — точки завершения работ и принятия решений.

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

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

  • каскадная модель;
  • поэтапная модель с промежуточным контролем;
  • спиральная модель.

Каскадная модель жизненного цикла

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

https://intuit.ru/EDI/25_07_20_1/1595629193-15985/tutorial/134/objects/2/files/2-1.gif

Рисунок. 1. Каскадная модель ЖЦ

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

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

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

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

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем. Здесь разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. Поэтапная модель с промежуточным контролем продемонстрирована на рисунке 2.

http://900igr.net/up/datas/223717/007.jpg

Рисунок. 2. Поэтапная модель с промежуточным контролем

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

Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем каскадной модели. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Спиральная модель ЖЦ показана на рисунке 3.

https://intuit.ru/EDI/25_07_20_1/1595629193-15985/tutorial/134/objects/2/files/2-3.gif

Рисунок. 3. Спиральная модель ЖЦ

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

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

Преимущества итерационного подхода, применяемого в спиральной модели:

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

https://konspekta.net/studopediaru/baza22/2543313303627.files/image018.jpg

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

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

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

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

Инкрементная модель жизненного цикла

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

https://www.ok-t.ru/studopediaru/baza5/472067289700.files/image060.jpg

Рис. 5. Инкрементная модель жизненного цикла

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

С точки зрения структуры жизненного цикла модель называют итеративной (говоря о процессе). С точки зрения развития продукта – инкрементной (имеется ввиду наращивания функциональности продукта). Инкремент – приращение, увеличение (например, в языке программирование – увеличение значения переменной на 1).

Для каждого инкремента выполняется:

  • анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;
  • проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;
  • разработка;
  • тестирование.

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

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

Рис. 6. Иллюстрация различий между инкрементной и итеративной (спиральной) моделями

Преимущества инкрементной модели:

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

Недостатки инкрементной модели:

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

Заключение

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

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

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

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