Понятие жизненного цикла информационных систем и причины его появления

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

Жизненный цикл ИС, установленный ГОСТ 34.601.

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

Согласно ГОСТу выделяют

1. Формирование требований к АС,

2. Разработка концепции АС,

3. Техническое задание,

4. Эскизный проект,

5. Технический проект.,

6. Рабочая документация.,

7. Ввод в действие,

8.Сопровождение АС.

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

Процесс адаптации

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

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

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

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

Функционально-ориентированная разработка (FDD) и SCRUM

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Есть еще несколько не менее важных и требующих рассмотрения идей Agile:

1 Приоритет взаимодействия людей над процессами и традиционными инструментами управления.

2 Приоритет получения работающего продукта над исчерпывающей всеобъемлющей документацией.

3 Приоритет сотрудничества с потребителями (заказчиком) над формальными вопросами контрактов. Приоритет быстрого реагирования на изменения над неотступным следованием плану.

В качестве одного из важнейших элементов Agile-подхода к разработке выступают пользовательские истории (user stories). Это описанные одним или несколькими предложениями основные аспекты функциональности системы, необходимые для выполнения пользователем своей работы. В достаточно сжатом виде, они должны отвечать на вопросы: «Кто?», «Что?» и «Почему?».

В переводе с английского языка «SCRUM» означает «схватка». Впервые подобная методология была введена в употребление профессорами японского Hitotsubashi University в их статье «Новая игра в производстве продукта» («The New Product Development Game»), написанной в 1986 году. В ней разработка продукта была сравнена со схваткой вокруг мяча в регби – приемом, называемым «скрам». Тем не менее, авторами концепции считаются разработчики изСША, Кен Швабер и Джефф Сазерленд, впервые определившие и описавшие основополагающие принципы SCRUM – «гибкой» методологии управления проектами (чаще всего применяющейся в области разработки ПО). По своей сути SCRUM представляет собой набор принципов разработки, которые позволяет представлять конечному пользователю (и заказчику)действующий продукт / прототип, обладающий новыми функциями и возможностями с наивысшим приоритетом. Работа в этом случае проводится в четко фиксированные недлительные (в среднем от 1 до 6 недель, чаще от 2до 4) итерации (спринты). Ожидаемые результаты спринта определяются командой под руководством SCRUM-мастера в самом его начале и НЕ могут изменяться до завершения. К ним под руководством SCRUM-мастера (по сути руководителя проекта) и product-мастера (заказчика, владельца проекта) создается список работ на период спринта и на весь проект (sprint-backlog и product-backlog соответственно). При более глубоком рассмотрении SCRUM имеет очень важные основы: методология предполагает циклический и очень активный процесс, минимизирующий неопределенность требований за счет коротких итераций и предоставляя возможность детального прототипирования. Долгие, нестандартные, динамические проекты, при расплывчатом представлении оконечном ожидаемом результате и постоянной смене приоритетов не являются проблемой для SCRUM, и именно поэтому он часто применяется на первых этапах, затем в целях экономии средств / ресурсов переходя к использованию другой методологии. Соответственно, SCRUM может применяться практически любым типом организаций – от стартапов с их высокой неопределенностью до госзаказчиков с частым изменением требований и частой необходимостью демонстрации текущей версии для отчета о результатах.

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

- модель жизненного цикла

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ № 6

Разместите фазы по порядку.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз: