что такое проектирование информационных систем

Некоторые заметки по проектированию информационных систем

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

Проектирование не для программистов

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

Уважаемые программисты, для того, чтобы выяснить, ЧТО должна делать система, нужно знать вовсе не C# или JAVA, а владеть предметной областью. Для проектирования логистической системы, надо быть логистом: иметь опыт работы в этой сфере или в нескольких смежных, похожих сферах. Поэтому и существуют бизнес-аналитики, задача которых как раз определить функциональный облик системы.

Заказчик в лучшем случае выдаст 30-50% нужной информации, остальное следует додумать самостоятельно. Причем додумать крайне критически. Вначале заказчик не знает, чего хочет! Как правило, происходит совместная разработка бизнес-модели, и только потом составляется список функций.

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

Заметки по Agile

Agile — это новая религия?

Обсуждение темы Agile vs. Проектная технология (каскад, водопад, waterfall) больше похоже на спор религиозных фанатиков! Статья вообще была не про Agile, но все комментарии — именно про «гибких». Ребята! Ну неужели нельзя взглянуть шире и увидеть, что для обоих методик есть место под солнцем?!

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

Agile годится не всюду, как и проектная технология

Как написал один из прокомментировавших, «Agile не для ИТ, и не про ИТ. Agile для бизнеса и про бизнес». Действительно, иногда нужно получить очень быстрый результат, выйти на рынок хоть с чем-то, чтобы застолбить место и найти инвесторов. Или идет отработка новых технологий, требования по которым составить проблематично. Это однозначно ниша Agile.

С другой стороны, а где вы найдете достаточно заказчиков, согласных работать по гибким технологиям? 70-80% заказов на рынке — это госструктуры, где используется стандартная проектная технология. Более того, по ГОСТ 34. И за это неплохо платят.
Кроме того, эти методы можно сочетать в одной разработке: ядро создается по проектной технологии, а некоторые части — методом проб и ошибок (Agile). Ну не все возможно продумать заранее. Кроме того, и в проектной технологии есть гибкость: имеется такое понятие, как опытная эксплуатация, в процессе которой многое может меняться.

Agile — это как мыслят разработчики

Не могу ручаться за всех, но создается впечатление, что программисты думают «гибко», Agile отвечает структуре их мышления! Ведь программирование — это постоянный поиск наилучших решений. Вы садитесь за задачу, еще не знаете, как она должна быть решена. Вам не спрогнозировать заранее ни результат, ни сроки (да-да, сроки разработчиков умножаешь в 6-10 раз и только так получаешь реальную картину, ведь про тестирование и доработки они забыли). Это мышление многих программистов, ведь они — творческие личности. Так вот и не надо творческих личностей заставлять заниматься проектной скукотой. Для этого есть аналитики, руководители проекта.

Мы поняли, что Agile — это суть мышления разработчиков. Но заказчик-то думает иначе! И заказчику хочется понять, за что он платит, «пощупать» будущий результат, до начала разработки. А то получается игра в одни ворота: разработчикам удобно, а заказчик по ночам не спи, думай, получится или нет, а если получится, то что получится, когда получится, и сколько это будет стоить. Зато программисту лафа — спокойно работаю, что сделаю, то и сделаю, когда закончу, тогда и закончу, сколько запрошу, столько и заплатят. Не так что ли?

Но иногда заказчику так и следует сказать: мы делаем новое, поэтому спрогнозировать ни сроки, ни стоимость, ни результат не готовы. Согласны? Тогда делаем. Это хотя бы по-честному.

Голову надо включать всегда

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

Чтобы что-то критиковать, надо это изучить

Когда критикуют либо проектную технологию, либо Agile, критики редко знают предмет своего возмущения. Очень мало тех, кто реально изучал (в том числе и стандарты: ГОСТ, ISO, IEEE) и пытался серьезно применять проектную технологию. Но критиков ее хватает. Очень мало команд, которые реально успешно (так, чтобы клиент был доволен!) применяет Agile, но «проповедников» хватает.

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

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

Источник

Тема 1. Основные понятия технологии проектирования информационных систем (стр. 1 )

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5

Тема 1. Основные понятия технологии проектирования информационных систем

Понятие и сущность проектирования ИС

Определение Проектирование (от лат. projectus – брошенный вперед) – это процесс создания проекта – прототипа, прообраза предлагаемого или возможного объекта, состояния.

Особенности понятия «проектирование»

· Охватывает все составляющие процесса научных/прикладных исследований: анализ, синтез, «исследование», «разработка» и т. п.;

· В отличие от таких размытых понятий как «познание» или «мышление» имеет конкретную цель: создание проекта.

· Обладает возможностью последовательной детализации и конкретизации (могут быть выделены стадии/этапы проектирования).

· Предполагает возможность частичной автоматизации

Традиционные виды проектирования: архитектурно-строительное, машиностроительное, технологическое. Проектирование информационных систем – сравнительно новый вид проектирования.

Здесь необходимо вспомнить определение проектируемого объекта:

Определение Информационная система (ИС) — это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели

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

Содержание процесса проектирования

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

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

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

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

Проектирование ИС охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе данных; проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.

Цель проектирования ИС

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

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

Составные элементы процесса проектирования

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

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

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

В качестве субъектов проектирования ИС выступают:

· заказчик (физическое лицо или организация), для которого необходимо разработать ИС.

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

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

Понятие технологии проектирования

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

Определение. Технология проектирования – это совокупность концептуальных методов и средств (методологий) проектирования ИС, а также методов и средств организации проектирования, то есть управления процессом создания или модернизации проекта информационной системы.

Составные элементы технологии проектирования:

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

Требования к технологии проектирования

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

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

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

Классификация методов проектирования

Методы проектирования ИС можно классифицировать по следующим основаниям:

· По степени автоматизации:

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

o Методы компьютерного проектирования – с использованием специальных программных средств, позволяющих выполнять генерацию или конфигурацию проектных решений.

· По степени использования типовых проектных решений:

o Методы оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями конкретной ИС;

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

· По степени адаптивности проектных решений:

o Адаптация путем реконструкции (переработка соответствующих компонентов ИС, перепрограммирование программных модулей);

o Адаптация путем параметризации (настройка проектных решений в соответствии с изменяемыми параметрами);

o Адаптация путем реструктуризации (перегенерация используемого набора проектных решений в соответствии с изменениями модели предметной области).

Анализ различных методов проектирования позволил выделить следующие классы технологий проектирования:

Каноническое проектирование; Индустриальное проектирование, которое подразделяется на два подкласса:
Автоматизированное проектирование; Типовое проектирование.

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

Средства проектирования ИС

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

Используя указанное определение, можно сформулировать основные признаки средств проектирования ИС:

· Инвариантность к объекту проектирования (в рамках выбранной методологии проектирования);

· Охват всех этапов жизненного цикла ИС (для совокупности средств!);

· Техническая, программная и информационная совместимость друг с другом;

· Простота освоения и применения;

· Экономическая целесообразность использования.

Все средства проектирования ИС можно разделить на два класса:

· Компьютерные, которые можно подразделить на следующие подклассы:

o Средства проектирования операций обработки информации (алгоритмические языки, библиотеки стандартных подпрограмм и классов, инструменты тестирования и отладки программ);

o Средства проектирования отдельных компонентов ИС (специализированные пакеты программ мат. статистики и мат. программирования, СУБД, графические и текстовые редакторы и др.);

o Средства автоматизированной разработки различных этапов проекта ИС – CASE-средства.

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

Тема 2. Жизненный цикл информационных систем

В курсе ИС мы уже касались таких понятий как «жизненный цикл изделия» и «жизненный цикл ИС».

Определение Жизненный цикл (ЖЦ) информационной системы – это множество событий, происходящих с системой в процессе ее создания и использования.

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

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

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

Модель жизненного цикла и технология проектирования

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

· задачи, состав и последовательность выполняемых работ;

· получаемые результаты каждого выполняемого действия;

· методы и средства, необходимые для выполнения работ;

· роли и ответственность участников;

· иную информацию, необходимую для планирования, организации и управления коллективной разработкой ИС,

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

Этапы и стадии проектирования

Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?

Следует помнить, что в разных международных стандартах используемая терминология может отличаться. Мы будем, по возможности, ориентироваться на терминологию отечественных ГОСТов. Этапом проектирования будем называть часть процесса создания ИС, ограниченную некоторыми временными рамками и заканчивающуюся выпуском конкретного продукта (модели, документации, текста программы и т. п.). По общности целей этапы проектирования могут объединяться в стадии. Например, стадия «Технический проект», стадия «Внедрение» и т. п.

Не зависимо от выбранного подхода, модель жизненного цикла ИС состоит из следующих стадий:

· Формирование требований к системе (предпроектная стадия, стадия системного анализа). В рамках данной стадии проводится исследование и анализ деятельности автоматизируемого объекта; значение имеют, разумеется, только те процессы, которые соответствуют целям и задачам этого объекта. В результате получается модель объекта, которую обычно описывают в терминах бизнес-процессов и бизнес-функций. Параллельно с этим выявляются недостатки существующих информационных систем (вспоминаем принцип преемственности) и формулируются потребности в совершенствовании системы управления объектом и/или автоматизации его отдельных функций. Требования должны быть экономически обоснованными. Результатом выполнения описанных этапов стадии является оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ИС. Обычно ТЭО оформляется как часть ТЗ. Кроме того, в ТЗ обязательно отражаются требования к ИС и ограничения на ресурсы проектирования (в первую очередь, сроки исполнения). Требования к ИС определяются как множество функций, реализуемых системой, а также описание предоставляемой ей информации.

· Проектирование (техническое проектирование, логическое проектирование). В соответствии с полученными требованиями проектировщики разрабатывают функциональную архитектуру ИС, которая отражает структуру выполняемых ей функций, и системную архитектуру ИС, которая представляет собой состав обеспечивающих подсистем. Построение системной архитектуры проводится на базе описания функциональной архитектуры ИС и фактически заключается в составлении технологии обработки информации с участием всех обеспечивающих подсистем ИС (в первую очередь, информационного, технического, и программного обеспечения). Результатом выполнения стадии проектирования обычно являются: 1) концептуальная, логическая и физическая модели данных ИС; 2) спецификации модулей ИС; 3) спецификация пользовательских интерфейсов ИС; 4) множество выбранных проектных решений, определяющих архитектуру ИС – в том числе выбранная платформа ПО, количество звеньев в архитектуре (однозвенная, двухзвенная [клиент-сервер или файл-сервер], трехзвенная) и др. Итоговый документ, завершающий стадию проектирования, – технический проект (ТП).

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

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

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

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

Вопросы к семинарскому занятию:

Привести пример, когда «отсутствие лишних функций» является существенным требованием к ИС; Объяснить смысл названия «стадия системного синтеза».

Модели жизненного цикла

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

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

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

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

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

Достоинства каскадного подхода:

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

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

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

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

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

Спиральную модель предложил Б. Боем (Barry Boehm) в 1988 году – как метод разработки и доработки программного обеспечения. Постепенно предложенную им модель стали использовать как базовый метод разработки информационных систем в сфере информационных технологий. Считается, что такая модель предназначена для применения в больших, дорогостоящих и сложных проектах. Спиральная модель легла в основу методологии быстрой разработки приложений (RAD).

Достоинства спиральной модели ЖЦ:

· Позволяет как можно скорее показать заказчику системы работоспособный продукт, активизируя тем самым процесс уточнения и дополнения требований;

· Позволяет заказчику принимать активное участие при планировании, анализе рисков, разработке и оценивании версий ИС;

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

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

· Объединяет достоинства каскадной модели и поэтапной модели с промежуточным контролем;

· Обеспечивает предсказуемое поведение проектируемой ИС, поскольку на каждой итерации выполняется формирование и уточнение целей очередного витка спирали и всего проекта в целом;

· При использовании модели не обязательно заранее распределять все необходимые для создания ИС ресурсы.

Недостатки спиральной модели ЖЦ:

· Организация проектирования ИС по спиральной модели обычно имеет высокую стоимость (поэтому ее имеет смысл использовать для сложных и дорогостоящих систем);

· Модель имеет сложную структуру, что может затруднить ее применение на практике неподготовленными специалистами и заказчиками (которые иногда «в силу привычки» предпочитают каскадную модель);

· Спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл работ;

· Большое количество промежуточных стадий усложняет ведение документации проекта;

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

· Необходимость в специальных средствах и методологии прототипирования (конструирования прототипов), без которых использование модели становится неудобным.

· Проблема внедрения. В некоторых ситуациях применение спиральной модели невозможно или ограничено, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т. д.). Поэтапное итерационное внедрение корпоративных информационных систем обычно сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а неграмотное управление процессом внедрения может свести на нет все полученные результаты. По этой причине на этапе внедрения часто обходятся без итерационных моделей, внедряя систему «раз и навсегда».

Стандарты, регламентирующие жизненный цикл ИС

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

Процесс ЖЦ = Перечень решаемых задач + Исходные данные + Результаты.

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

· ГОСТ 34.601-90. Введен в действие 01.01.1992. Устанавливает стадии и этапы создания автоматизированных систем и дает содержание работ на каждой стадии. Стадии и этапы работы, закрепленные в стандарте, соответствуют каскадной модели жизненного цикла.

· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:

o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);

o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);

o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).

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

o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;

o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.

· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т. д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.

· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).

· Microsoft Solution Framework (MSF). Итерационная методология разработки приложений, аналогичная RUP. Так же включает четыре фазы: анализ, проектирование, разработка, стабилизация и предполагает использование объектно-ориентированного моделирования. По сравнению с RUP в большей степени ориентирована на разработку ИС для бизнеса.

· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).

Тема 3. Каноническое проектирование информационных систем

Каноническое проектирование ИС характеризуется следующими особенностями:

· Отражает особенности ручной технологии проектирование;

· Предполагает выполнение индивидуального (оригинального) проектирования;

· Не предполагает использования средств интеграции;

· Соответствует каскадной модели ЖЦ ИС.

На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС.

Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». Всего предусматривается 8 стадий:

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

2. Разработка концепции;

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

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

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

Между стадиями ГОСТа и стадиями, которые мы ранее изучали применительно к моделям жизненного цикла ИС, нетрудно установить соответствие. Первые три –соответствуют предпроектной стадии ЖЦ ИС, следующие две – стадии проектирования, 6 стадия – стадии рабочего проектирования (реализации), 7 – стадии тестирования и внедрения, 8 – стадии эксплуатации.

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

Формирование требований к ИС включает в себя следующие этапы:

· Обследование объекта и обоснование необходимости создания ИС;

· Формирование требований пользователя к ИС;

· Оформление отчёта о выполненной работе и заявки на разработку ИС (тактико-технического задания)

Обследование объекта автоматизации (ОА) – важнейшая составляющая предпроектной стадии.

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

Обследование проводится на основании принятия следующих проектных решений:

· Выбор методики проведения обследования:

o По цели обследования: локальное (для разработки проекта решения отдельной задачи) или системное (для разработки проекта решения комплекса задач);

o По количеству участников (индивидуальное и бригадное);

o По степени охвата предметной области (сплошное и выборочное – при наличии типовых по структуре и организации подразделений);

· Выбор методов сбора материалов обследования (рассмотрим чуть далее);

· Составление программы обследования. Обычно имеет такую форму:

Источник