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

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

• предпроектное обследование;
• технико-экономическое обоснование;

я составление технического задания;
я техническое проектирование;
я рабочее проектирование.
Две последние стадии могут для небольших проектов быть объединены одну - технорабочее проектирование.
Прежде чем начинать проектирование, необходимо выполнить обследование объекта, для которого создается ИС. Это достаточно важный этап, так как позволяет выделить характерные особенности объекта, которые следует учесть в характеристиках разрабатываемой ИС и которые определяют дальнейшую работу по проектированию. Любой процесс проектирования (и проектирования ИС в частности) является итерационным процессом, когда неоднократно приходится возвращаться на предыдущие этапы проектирования коррекции имеющихся результатов. От качества предпроектного обследования во многом зависит, придется ли в дальнейшем пересматривать основные концепции создаваемой ИС и вносить в нее принципиальные изменения, что всегда является трудоемкой задачей. На этапе предпроектного обследования следует сразу же настраиваться на то, что любое предприятие имеет свою специфику в производственных и бизнес-процессах. Поэтому знания о других предприятиях и о стандартных правилах организации этих процессов могут служить в большей части подспорьем в изучении предприятия, но отнюдь не являться целью внедрения. Обследование сводится к анализу существующей системы и объекта, для которого создается система. В частности, при этом следует уделять
особое внимание общению на предприятии с экспертами и специалистами в интересующей предметной области, а также анализу документов и их движения. Обследование (сбор материалов) выполняется по двум основным направлениям: обоснованию эффективности создаваемой системы и выбору технических средств.
Материалы для обоснования эффективности создаваемой системы включают в себя:

• структуру существующей системы;
• объемы выполняемой работы и трудозатраты;
• качество выполняемой работы;
• методы выполнения работы;

ш ведение документации и др.
Данные для выбора технических средств включают в себя:

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

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

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

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

• исходные положения, характеристики и технико-экономические данные об объекте;
• обоснование цели создания ИС;
• обоснование комплекса задач, решаемых в ИС, и ДР.

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

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

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

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

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

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

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

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

• операционные системы,

• ¦ АСУ - автоматизированные системы управления,

• САПР - системы автоматизированного проектирования,
• ГИС - геоинформационные системы,
• Связь и телекоммуникация, "
• Справочно-поисковые системы,
• Системы информационной безопасности,
• Системы подготовки и обработки мультимедийной информации (звука, изображения, видео),
• редакционно-издательские системы.

В отдельных системах могут сочетаться различные комбинации базовых. Например, АСУ магистральных газопроводов будет включать в себя и ГИС, и АСУ ТП (автоматизированную систему управления технологическими процессами), и элементы телекоммуникаций и т.п.

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

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

Или, САПР делятся на:

• САПР в строительстве,
• САПР в машиностроении,
• САПР в электронной промышленности,
• САПР в авиастроительстве и т.д.

Другое разделение соответствует назначению системы. Так, например, системы САПР могут разделяться на:

• системы подготовки чертежной документации,
• системы расчета на прочность, жесткость и устойчивость,
• системы подготовки проектно-сметной документации,
• системы подготовки документации на конкурс и т.п.

Кроме того, следует рассмотреть деление по возможности пересечения видов деятельности. При этом необходимо рассматривать системы общего и специализированного назначения. Например, такие системы разработки чертежной документации, как AutoCAD и MicroStation являются системами САПР общего назначения. Оперируя общими графическими примитивами (отрезками, дугами, размерными линиями и т.п.), пользователь может подготовить чертежную документацию для любой отрасли промышлен
ности. Наоборот, САПР ArchiCAD, speedikon, ArCON являются специализированными для строительства, и здесь пользователь оперирует не общими, а специализированными примитивами-объектами, как то: стены, окна или проемы, лестницами и т.д. С помощью этих систем можно быстрее и качественнее подготовить проектную документацию по объекту строительства, чем с помощью систем общего назначения. Однако подготовить проектную документацию для строительства корабля или самолета практически невозможно. Аналогично обстоит дело с САПР расчета на прочность. Например, системы ANSYS и NASTRAN - системы общего назначения, с их помощью можно рассчитать хоть здание, хоть самолет. А вот система ProFET amp; Stark ES ориентированна на расчет здания, с ее помощью можно быстрее и более «профильно» рассчитать здание. А вот при расчете самолета эти САПР лучше не использовать.
Заметим, что вокруг оболочки программ САПР общего назначения создаются десятки различных расширений возможностей. Многие компьютерные фирмы разрабатывают подсистемы к программам общего назначения, предоставляющие пользователю больший круг возможностей для использования общей системы в конкретной отрасли промышленности.
Вместе с тем на рынке программных продуктов существует множество различных ИС сходного назначения. Так, для автоматизации бухгалтерского учета сегодня предлагаются системы «1C», «Инфо-бухгалтер», «Парус», «Инотек НТ», «Gendalf», «Овионт информ», «Камин», «Плюс-мик- ро», «СБиС++» и многие другие. Успех той или иной системы на рынке зависит порой не только от качества программного продукта, но и от грамотно организованной маркетинговой и рекламной политики фирмы, от организации разветвленной сети дилеров и технического сопровождения. Аналогичное многообразие программных продуктов наблюдается и в других сферах деятельности человека.

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Под этапами (стадиями или фазами) будем понимать совокупность ступеней развития проекта от возникновения идеи до полного завершения проекта. В определении количества этапов и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки ИС почти во всех случаях являются общими. [Избачков с. 40-43] Обычно выделяют следующие этапы создания проекта ИС [Вендеров]:

Анализ. Задача формирование требований к системе является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки.Анализ деятельности организации, выполняемый на данном этапе, должен помочь в формировании требований к ИС, корректно и точно отражающих цели и задачи организации- заказчика. Наряду с изучением требований пользователя и имеющихся систем на этапе анализа необходимо создать логический проект системы. С помощью логического проектирования необходимо определить концептуальную модель данных, входные данные, процессы и предполагаемые выходные данные. Моделирование данных, выполняемое на данном этапе, включает в себя выявление и описание объектов и их атрибутов, а также связи между сущностями (описание модели в виде ER-диаграммы). Описание и документирование всех преобразований данных (процессов) может быть выполнено с помощью таких средств анализа, как схемы информационных потоков (DFD – data flow diagram) или моделей функций и процессов.Конечной целью моделирования бизнес-процессов, протекающих в организации и реализующих ее цели и задачи является построение моделей организации, описанных в терминах бизнес-процессов и бизнес-функций. На этом же этапе изучаются имеющееся оборудование и программные средства. Результатом анализа должно стать лучшее понимание функционального назначения системы, существующие и потенциальные проблемы, а также сфера ее действия.

На этом этапе конечные пользователи и проектировщики должны работать сообща.

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

Схема БД (на основании ER-модели, разработанной на этапе анализа); - набор спецификаций модулей системы (на базе моделей функций). Также на этапе проектирования определяется: - выбор платформы и ОС (могут быть не единственными); - характеристики архитектуры: ф/с или к/с; количество уровней (1, 2 или 3); централизованная или распределенная БД; однородность или неоднородность БД (по количеству используемых серверов). Этап проектирования заканчивается разработкой технического проекта ИС.

Реализация. На этом этапе осуществляется создание всех компонент ПО ИС, установка технических средств, разработка эксплуатационной документации.

Этап тестирования обычно оказывается распределенным по времени.

А) после завершения разработки отдельного модуля системы выполняют автономный тест , который преследует следующие цели: - обнаружение отказов модуля (жестких сбоев); - соответствие модуля спецификации (наличие всех необходимых функций и отсутствие лишних функций). Б) После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходиттесты связей , которые должны отследить их взаимное влияние. После тестирования на взаимное влияние модулей необходимо выполнить еще ряд тестов: В)тесты на проверку надежности работы: 1) тест имитации отказов, демонстрирующий, насколько хорошо система восстанавливается после сбоев ПО и отказов аппаратного обеспечения; 2) тест наработки на отказ (устойчивость системы при штатной работе для оценки времени безотказной работы системы); 3) системный тест (проверка функциональности системы); 4) приемо-сдаточные испытания (такой тест предусматривает показ ИС заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика). Как правило, тестирование и эксплуатация занимают от 50% до 60% общего времени разработки ИС. V.Ввод в действие. Эксплуатация и сопровождение. После ввода в действия организуется обучение конечных пользователей. Практически сразу после ввода системы в строй конечные пользователи начинают просить внести в нее изменения. Внесение изменений и исправлений выполняется службой сопровождения системы, работающей в трех направлениях: - корректирующее обслуживание – как ответ на возникающие ошибки системы; - адаптивное обслуживание – как ответ на изменение корпоративной среды; - усовершенствование – расширение возможностей системы.

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

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

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

Проектирование объектов данных, которые будут реализованы в базе данных;

Проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

Требуемой пропускной способности системы;

Требуемого времени реакции системы на запрос;

Безотказной работы системы;

Необходимого уровня безопасности;

Простоты эксплуатации и поддержки системы .

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

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

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

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

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

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

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

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

Технология должна максимально отражать все этапы цикла жизни проекта;

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

Технология должна способствовать росту производительности труда проектировщиков;

Технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта;

Технология должна способствовать простому ведению проектной документации.

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

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

По степени автоматизации различают:

Ручное проектирование;

Компьютерное проектирование;

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

Оригинальное проектирование;

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

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

Реконструкция – адаптация проектных решений выполняется путем переработки соответствующих компонентов;

Параметризация – проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами;

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

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

Основные стадии создания автоматизированной информационной системы:

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

Разработка концепции АИС;

Разработка технического задания;

Разработка эскиза проекта;

Разработка технической части проекта;

Разработка рабочей документации на АИС;

Ввод в действие;

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

Методология проектирования

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

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

1. Ручное, при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках;

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

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

1. Оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;

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

По степени адаптивности проектных решений выделяют методы:

1. Реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей);

2. Параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми параметрами;

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

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

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

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

Пошаговой процедуры, определяющей последовательность технологических операций проектирования;

Критериев и правил, используемых для оценки результатов выполнения технологических операций;

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

Сравнительная характеристика инструментов проектирования

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

Существует около 30 технологий проектирования организационно-технических систем и несколько сотен инструментов, предназначенных для автоматизации этого процесса. Поэтому, с учетом временного фактора, сравнительный анализ был ограничен четырьмя наиболее популярными на российском рынке продуктами: Bpwin/Erwin (Platinum Technology), Rational Rose (Rational Software Corporation), ARIS (Scheer AG) и Oracle Designer (Oracle Developer Suite). Справочные данные по CASE-технологиям и средствам проектирования приведены ниже по тексту и в таблице №1.

Таблица 1

Средства проектирования и их сравнительная характеристика

Критерии				Oracle Designer
Поддержка полного жизненного цикла ИС
Обеспечение целостности проекта
Независимость от платформы	+ (DoDAF, TeaF/FeaT, Zachman)	+ (ORACLE, Informix, Sybase)	+ (ORACLE, Informix, Sybase, Ingres и др.)
Одновременная групповая разработка БД и приложений

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

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

Согласно обзору передовых технологий, составленному фирмой Systems Development Inc. в 2007 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

1. CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

2. Реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

1. Широкое разнообразие качества и возможностей CASE-средств;

2. Относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

3. Широкое разнообразие в практике внедрения различных организаций;

4. Отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

5. Широкий диапазон предметных областей проектов;

6. Различная степень интеграции CASE-средств в различных проектах.

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

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

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми СП:

ERWin / BPWin;

Rational Rose;

Oracle Designer.

ARIS - Интегрированное средство моделирования бизнес-процессов, объединяющее разнообразные методы моделирования и анализа систем. В первую очередь, это средство описания, анализа, оптимизации и документирования бизнес-процессов, чем средство проектирования программного обеспечения.

BPWin - инструмент визуального моделирования бизнес-процессов. ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность - связь».

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

Oracle Designer - функциональное средство для описания предметной области. Входит в комплекс инструментальных средств Oracle9i Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - «CDM», позволяющих команде разработчиков провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Это средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы.

Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс ARIS наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Rational Rose целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Corba. Следует отметить, что каждый из двух продуктов сам по себе является одним из наиболее мощных в своем классе.

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

Этапы проектирования автоматизированных информационных систем. К проектированию АИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.

Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС(например, Price Waterhouse, Jet Info, Consistent Software и др.).

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

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

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

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

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

Результаты анализа - техническое предложение и бизнес-план создания АИС -представляются заказчику для окончательного согласования.

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

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

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

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

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

Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.

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

I этап - предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);

II этап - проектный (составление технического и рабочего проектов);

III этап - внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);

IV этап - анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

Рис.1.

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

К методам изучения и анализа состояния экономического объекта и его системы управления относятся:

устный и письменный опрос;

письменное анкетирование;

наблюдение, измерение, оценка;

групповое обсуждение;

анализ задач;

анализ производственных, управленческих и информационных процессов.

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

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

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

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

В процессе постановки задачи раскрываются:

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

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

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

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

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

Требования к технологиям разработки ИС.

Фазы и этапы программного проекта.

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

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

1. Обследование объекта и обоснование необходимости создания АС

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

   Оформление отчета о выполнении работ и заявки на разработку АС

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

1. Изучение объекта

   Проведение необходимых научно-исследовательских работ

   Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

   Оформление отчета о проделанной работе

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

1. Разработка и утверждение технического задания на создание АС

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

1. Разработка предварительных проектных решений по системе и ее частям

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

1. Разработка проектных решений по системе и ее частям

   Разработка документации на АС и ее части

   Разработка и оформление документации на поставку комплектующих изделий

   Разработка заданий на проектирование в смежных частях проекта

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

1. Разработка рабочей документации на АС и ее части

   Разработка и адаптация программ

Ввод в действие

1. Подготовка объекта автоматизации

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

   Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

   Строительно-монтажные работы

   Пусконаладочные работы

   Проведение предварительных испытаний

   Проведение опытной эксплуатации

   Проведение приемочных испытаний

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

1. Выполнение работ в соответствии с гарантийными обязательствами

   Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Жизненный цикл программного проекта.

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

процессы соглашения - два процесса;

процессы организационного обеспечения проекта - пять процессов;

процессы проекта - семь процессов;

технические процессы - одиннадцать процессов;

процессы реализации программных средств - семь процессов;

процессы поддержки программных средств - восемь процессов;

процессы повторного применения программных средств - три процесса.

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

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

1. Результаты выполнения работ на каждой стадии;

   Ключевые события - точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Каскадная модель.

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

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

Рис. 1. Каскадная схема разработки ПО.

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

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

Для преодоления этих проблем предложена поэтапная модель с промежуточным контролем (рис. 2).

Рис. 2. Поэтапная схема разработки ПО.

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

Спиралевидная модель.

Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.

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

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

Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.

Итерационная модель.

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки(англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .

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

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

Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP,MSF,XP).

Разновидности моделей.

Моделирование – представление объекта моделью для получения информации о нём путём проведения экспериментов с его моделью.

Под термином “моделирование ” обычно понимают процесс создания точного описания системы; метод познания, состоящий в создании и исследовании моделей.

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

Для формирования модели используются:

структурная схема объекта;

структурно-функциональная схема объекта;

алгоритмы функционирования системы;

схема расположения технических средств на объекте;

схема связи и др.

Все модели можно разбить на два больших класса: предметные (материальные) и знаковые (информационные).

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

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

Она является основой разработки моделей ИС.

Для создания описательных текстовых информационных моделей обычно используют естественные языки .

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

Основное отличие формальных языков от естественных состоит в наличие у формальных языков не только жёстко зафиксированного алфавита, но и строгих правил грамматики и синтаксиса.

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

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

Процесс построения информационных моделей с помощью формальных языков называют формализацией .

Модели, построенные с использованием математических понятий и формул, называют математическими моделями .

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

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

Обычно различают реальное (материальное, предметное) и мысленное (идеализированное, концептуально-методологическое)моделирование.

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

Концептуальное моделирование представляет собой структурированный процесс создания систем, состоящий из следующих этапов:

1. Проектирование,

   Программирование,

   Тестирование,

   Внедрение.

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

Существует нескольких методов и принципов построения информационных систем (автоматизированных ИС), среди которых можно выделить: методы “снизу-вверх” и “сверху-вниз”, принципы “дуализма”, многокомпонентности и др.

Метод “снизу-вверх” Опыт и методы работы отечественных программистов сформировались в крупных вычислительных центрах (ВЦ), основной целью которых было не создание тиражируемых продуктов, а выполнение задач конкретного учреждения. Современные руководители зачастую прибегают к нему, полагая, что им удобно иметь своих специалистов. Разработка программ “снизу-вверх”, осуществляемая квалифицированными программистами, позволяет автоматизировать, как правило, отдельные рабочие процессы.Такой метод весьма затратный и всё реже используется, особенно в малых и средних предприятиях.

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

Такая идея ограничила возможности разработчиков в структуре информационных множеств БД, в использовании вариантов экранных форм, алгоритмов расчёта и, следовательно, лишила возможности принципиально расширить круг решаемых задач. Заложенные “сверху” жёсткие рамки (“общие для всех”) ограничивают возможности ИС. Стало очевидным, что для успешной реализации задач полной автоматизации организации следует менять идеологию построения автоматизированных информационных систем (АИС).

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

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

Такой подход лег в основу “принципа дуализма ”. Его реализация потребовала построения АИС нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать автономно.

Многокомпонентная система обеспечивает соблюдение основополагающего принципа построения АИС – отсутствия дублирования ввода исходных данных.

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

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

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

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

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

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

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

Автоматизированная система моделирования (АСМ) – компьютерная система, предназначенная для оказания помощи пользователю по представлению нужной ему задачи в виде определённой математической схемы, принятой в данной системе, решить задачу (провести моделирование по полученной схеме) и проанализировать результаты.

АСМ состоит из трёх основных компонент: функциональное наполнение, язык заданий и системное наполнение.

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

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

Язык заданий (ЯЗ) служит для описания задач, вводимых в систему.

Средствами и инструментом автоматизированного проектирования и разработки информационных систем являются CASE-средства и системы (Глава1), ориентированные на поддержку разработки информационных систем.

Методики (методологии) управления ИТ-проектами (тяжеловесные, легковесные): особенности, примеры.

Методики (методологии) управления ИТ-проектами

Модели (методики, методологии) процессов разработки ПО принято классифицировать по «весу» - количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

Делятся на:

Тяжеловесные: RUP, MSF

Легковесные или agile-методики.

ГОСТы

Таблица 6

Вес модели
	Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды. Отсутствуют ограничения по объему и сложности выполняемых проектов.	Требуют существенной управленческой надстройки Более длительные стадии анализа и проектирования. Более формализованные /коммуникации. 8
	Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации.	Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды. Объем и сложность выполняемых проектов ограничены.

ГОСТ 19 «Единая система программной документации» и ГОСТ 34 «Стандарты на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход к разработке ПО.

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

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

На основе этих стандартов разрабатываются программные системы по госзаказам в России.

В середине 80-х годов 20-го столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Модель определяет 5уровней зрелости процесса разработки ПО:

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

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

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

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

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

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Один из самых известных процессов, использующих итеративную модель разработки – Rational Unified Process (RUP).

Cоздан во второй половине 1990-х годов в компании Rational Software.

Основныt разработчики Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson).

Последние трое являются также создателями нотации UML.

Rational Unified Process предлагает итеративную модель разработки, включающую 4 фазы: начало, исследование, построение и внедрение.

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

Прохождение через фазы - цикл разработки , каждый цикл завершается генерацией версии системы.

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

Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки.

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

Рабочий процесс в RUP

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles).

Артефактами являются спецификации, модели, исходный код и т.п.

Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline).

В дисциплины входят:

Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.

Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.

Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.

Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.

Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.

Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.

Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (change requests).

Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.

Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

В ходе жизненного цикла проекта распределение усилий проектной команды между дисциплинами постоянно меняется.

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

Рисунок иллюстрирует выполнение проекта среднего размера.

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

При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

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

Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF:

«Модель процессов MSF»,

«Модель проектной группы MSF»,

«Дисциплина управления проектами MSF»,

«Дисциплина управления рисками MSF» и

«Дисциплина управления подготовкой MSF».

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process.

Personal Software Process определяет требования к компетенциям разработчика.

Согласно этой модели каждый программист должен уметь:

учитывать время, затраченное на работу над проектом;

учитывать найденные дефекты;

классифицировать типы дефектов;

оценивать размер задачи;

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

планировать программные задачи;

распределять их по времени и составлять график работы.

выполнять индивидуальную проверку проекта и архитектуры;

осуществлять индивидуальную проверку кода;

выполнять регрессионное тестирование.

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков.

Команды должны:

установить собственные цели;

составить свой процесс и планы;

отслеживать работу;

поддерживать мотивацию и максимальную производительность.

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

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

Они декларируют своей высшей ценностью ориентированность на людей и их взаимодействие, а не на процессы и средства.

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

В течение 1990-х годов все больше разработчиков ПО начинали искать альтернативу традиционным, как правило, основанным на модели водопада, процессам разработки. К 2000 году существовало уже целое множество так называемых легковесных (lightweight) методологий .

В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto) – манифест гибкой разработки.

На том же семинаре было предложено новое название легковесных методологий – гибкая разработка (agile software development).

Общими особенностями гибких методологий являются:

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

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

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

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

Принципы, которые разъясняет Agile Manifesto :

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

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

работающее программное обеспечение - лучший измеритель прогресса;

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

постоянное внимание улучшению технического мастерства и удобному дизайну;

простота - искусство не делать лишней работы;

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

постоянная адаптация к изменяющимся обстоятельствам.

eXtreme Programming или XP (экстремальное программирование)

Методология XP была создана Кентом Беком (Kent Beck) в 1996 году в ходе попытки спасти провальный проект по разработке системы расчета зарплаты для компании Крайслер.

В 2000 году проект был закрыт, но XP к тому времени уже получила известность и начала распространяться среди разработчиков ПО.

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

Она описывается как 12 практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода (refactoring), разработка "тестами вперед", парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода.

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

Crystal Clear

Разработчик Алистер Коуберн

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

Уступает XP по производительности, зато максимально проста в использовании. Требует минимальных усилий для внедрения, так как ориентирована на человеческие привычки.

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

Основные характеристики методологии:

Итеративная инкрементная разработка;

Автоматическое регрессионное тестирование;

Пользователи привлекаются к активному участию в проекте;

Состав документации определяется участниками проекта;

Как правило, используются средства контроля версий кода.

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

Feature Driven Development

Функционально-ориентированная разработка (FDD, Feature Driven Development).

На самом деле используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP.

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

FDD включает 5 процессов, последние два из которых повторяются для каждой функции:

Разработка общей модели.

Составление списка необходимых функций системы.

Планирование работы над каждой функцией.

Проектирование функции.

Конструирование функции.

Разработчики в FDD делятся на "хозяев классов" – class owners и "главных программистов" chief programmers.

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

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

OpenUP

Итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP.

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

В основу OpenUP положены следующие основные принципы :

Совместная работа с целью согласования интересов и достижения общего понимания;

Развитие с целью непрерывного обеспечения обратной связи и совершенствования проекта;

Концентрация на архитектурных вопросах на ранних стадиях для минимизации рисков и организации разработки;

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

Scrum

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

Scrum чётко делает акцент на качественном контроле процесса разработки.

Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

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

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

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

Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель.

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

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур».

Названия были использованы из-за шутки:

Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать "Яичница с беконом"?». «Так не пойдёт», - отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Основные роли:

Скрам-мастер (ScrumMaster) – проводит совещания следит за соблюдением всех принципов, разрешает противоречия и защищает команду от отвлекающих факторов. Только ведет скрам-процесс.

Владелец проекта (Product Owner) – представляет интересы конечных пользователей и других заинтересованных в продукте сторон.

Скрам-команда (Scrum Team) – кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат.

Неосновные роли:

Пользователи (Users)

Клиенты, Продавцы (Stakeholders) – лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

Управляющие (Managers) – люди, которые управляют персоналом.

Эксперты-консультанты (Consulting Experts)

Ежедневное совещание (Daily Scrum meeting):

начинается точно вовремя;

все могут наблюдать, но только основные говорят;

длится не более 15 минут;

проводится в одном и том же месте в течение спринта.

В течение совещания каждый член команды отвечает на 3 вопроса:

Что сделано с момента предыдущего ежедневного совещания?

Что будет сделано с момента текущего совещания до следующего?

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