Лекции ТИПИС. Лекция Введение. Основные понятия. Корпоративные информационные системы. Структура кис

• Название: Лекция Введение. Основные понятия. Корпоративные информационные системы. Структура кис
• Анкор: Лекции ТИПИС
• Дата: 10.05.2023
• Размер: 329.16 Kb.
• Имя файла: Лекции ТИПИС.docx
• Тип: Лекция; #1119634
• страница: 4 из 9

Лекция 6. Основные модели ЖЦ ИС. Каскадная модель: характеристика, достоинства, недостатки. Спиральная модель: характеристика, достоинства, проблемы.

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

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

     К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ИС: каскадная модель (модель «водопад» – waterfall ) и спиральная модель.

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

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

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

Основные этапы разработки по КМ

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

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

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

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

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

· сдача готового проекта

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

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

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

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

     Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования реализованы в полной мере.

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

Основные достоинства каскадной модели

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

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

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

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

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

Основные недостатки каскадной модели следующие:

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

2. необходимость возврата на предыдущие этапы;

3. сложность распараллеливания работ по проекту;

4. информационная перенасыщенность каждого этапа;

5. сложность управления проектом ;

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

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

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

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

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

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

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

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

      Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого этапа разработки. Результат можно увидеть лишь в конце работ. Изменения в предметной области или в законодательстве  изменения в проекте  «зацикливание» процесса разработки. Расходы растут, срок сдачи откладывается. Поэтому сложные проекты, разрабатываемые по КС, имеют повышенный уровень риска. По данным консалтинговой компании The Standish Group, в США более 31% проектов КИС (IT-проектов) прогорают; почти 53% IT-проектов завершаются с перерасходом бюджета в среднем на 189%, и только 16,2% проектов укладываются и в срок, и в бюджет.

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

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

Итерации

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

Схема 7



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

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

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

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

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

1. итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

2. при использовании СМ отдельные элементы интегрируются в единое целое постепенно, интеграция производится непрерывно, и поскольку она начинается с меньшего количества элементов, при ее проведении возникает гораздо меньше проблем (при использовании КМ разработки на интеграцию в конце проекта приходится до 40% всех затрат);

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

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

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

6. СМ позволяет получить более надежную и устойчивую систему, т.к. ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно можно корректировать критические параметры эффективности, что при использовании КМ выполняется только перед внедрением ИС;

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

Проблемы использования спиральной модели

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

Лекция 7. Основные методологии и технологии разработки ИС. Методология RAD)

Тема 3. Методология и технология разработки информационных систем Основные методологии и технологии разработки ИС. Методология RAD

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

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

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

· гарантия создания ИС с заданными параметрами в заданный срок в рамках оговоренного бюджета;

· простота сопровождения, модификации и расширения системы;

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

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

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

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

1. заданной последовательности выполнения ТО проектирования;

2. критериев и правил для оценки результатов выполнения ТО;

3. графических и текстовых средств для описания проектируемой ИС.

     Каждая ТО должна обеспечиваться следующими материальными и информационными ресурсами:

· данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

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

· программными и техническими средствами;

· исполнителями .

     Результаты ТО должны представляться в стандартном виде .

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

1. поддержка полного ЖЦ ИС;

2. обеспечение достижения целей разработки ИС с заданным качеством и в заданные сроки;

3. обеспечение возможности декомпозиции проекта на составные части, разрабатываемые отдельными группами (3 – 7 человек), с последующей интеграцией частей;

4. обеспечение минимального времени получения работоспособной ИС;

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

6. обеспечение независимости выполняемых проектных решений от средств реализации (СУБД, ОС, языка и системы программирования).

Методология RAD – Rapid Application Development

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

Основные особенности методологии RAD

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

     Под методологией RAD обычно понимают процесс разработки ИС, основанный на небольшой команде программистов (2 – 10 человек), тщательно проработанном графике работ (рассчитанном на 2 – 6 месяцев), итерационной модели разработки (основанной на тесном взаимодействии с заказчиком).

     Основные принципы методологии RAD следующие:

1. использование спиральной модели разработки;

2. необязательное полное завершение работ на каждом этапе;

3. тесное взаимодействие с заказчиком и будущими пользователями в процессе разработки ИС;

4. применение CASE -средств и средств БРП;

5. применение средств управления конфигурацией проекта;

6. использование прототипов;

7. осуществление тестирования одновременно с разработкой;

8. небольшая группа разработчиков-профессионалов;

9. грамотное руководство, четкое планирование и контроль.

 

     Объектно-ориентированный подход

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

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

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

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

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

Объектно-ориентированное программирование

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

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

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

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

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

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

Визуальное программирование

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

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

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

1. специализированные средства разработки, ориентированные исключительно на работу с определенной СУБД и не предназначенные для разработки приложений, не использующих БД. Как правило, они привязаны к вполне определенным СУБД. Например, система Power Builder фирмы Sybase (для работы с СУБД Sybase Anywhere Server ); система Visual FoxPro фирмы Microsoft ;

2. универсальные системы визуального программирования , которые могут использоваться как для разработки информационных приложений, взаимодействующих с БД, так и для разработки любых других приложений, не использующих БД. Причем приложения, разработанные с помощью универсальных систем, могут взаимодействовать практически с любыми СУБД. Это обеспечивается использованием драйверов ODBC или OLE DB и применением специализированных компонентов. Наиболее популярны универсальные системы Borland Delphi фирмы Borland и Visual Basic фирмы Microsoft .

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

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

Событийное программирование

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

     Разработчик реализует логику приложения путем определения обработчика каждого события – процедуры, выполняемой объектом при наступлении соответствующего события, Например, обработчик события «нажатие кнопки» может открыть диалоговое окно. Таким образом, управление объектами осуществляется с помощью событий.

Фазы жизненного цикла в рамках методологии RAD

     По методологии RAD ЖЦ ИС состоит из четырех фаз: фазы анализа и планирования требований, фазы проектирования, фазы построения и фазы внедрения.

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

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

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

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

Ограничения методологии RAD

     Применение методологии RAD наиболее эффективно при создании сравнительно небольших ИС, разрабатываемых для вполне определенного предприятия.

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

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

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

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

Лекция 8. Основные стандарты и методики разработки ИС (Oracle, ISO/IEC 12207, ГОСТ 34)

Основные стандарты и методики

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

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

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

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

     Это определение комитета IEEE POSIS 1003.0 (институт инженеров по электротехнике и электронике США).

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

     Другими словами, открытая система – это система, доступная для взаимодействия с другими системами в соответствии с принятыми стандартами.

     Иногда открытой называют систему со встроенным редактором, позволяющим добавлять в нее новые объекты ( Delphi – открытая система, Word , Excel – нет).

     Одним из способов адаптивного проектирования ИС является также разработка и применение профилей ЖЦ ИС и ПО.

Группы стандартов

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

· по предмету стандартизации : к этой группе относятся функциональные стандарты (на языки программирования, на интерфейсы, протоколы) и стандарты на организацию ЖЦ ИС и ПО;

· по утверждающей организации : здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандарты (например, ГОСТы, ANSI, IDEF 0/1), стандарты международных консорциумов и комитетов по стандартизации (например, консор-циум OMG), стандарты «de facto» – официально никем не утвержденные, но фактически действующие (как было с языками SQL и C), фирменные стандарты (например, Microsoft ODBC);

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

Рассмотрим кратко следующие стандарты и методики, касающиеся организации ЖЦ ИС и ПО:

1. методику Oracle CDM ( Custom Development Method ) по разработке прикладных ИС

2. международный стандарт ISO / IEC 12207:1995-08-01 на организацию ЖЦ продуктов ПО ;

3. отечественный комплекс стандартов ГОСТ 34.

Методика Oracle CDM

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

     Основу CASE-технологии и инструментальной среды фирмы Oracle составляют:

1. методология структурного нисходящего проектирования ИС по каскадной схеме;

2. ориентация на реализацию приложений в архитектуре клиент-сервер;

3. наличие централизованной БД (репозитария) для хранения спецификаций проекта ИС на всех этапах ее разработки;

4. возможность одновременной работы с репозитарием многих пользователей;

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

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

Общая структура ЖЦ ИС (по методике Oracle CDM )

     Методика Oracle CDM определяет следующие фазы ЖЦ ИС:

1. стратегия (определение требований);

2. анализ (разработка концептуальных моделей ИС);

3. проектирование (разработка технических спецификаций ИС на базе концептуальных моделей, структуры и состава БД);

4. реализация (написание кода, тестирование приложения);

5. внедрение (установка ИС, подготовка к эксплуатации);

6. эксплуатация (поддержка ИС, планирование будущих расширений).

Особенности методики Oracle CDM

1. Методика не является обязательной, но может считаться фирменным стандартом.

2. CDM существенно опирается на использование инструментария Oracle .

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

4. Используется только каскадная модель разработки ИС.

Международный стандарт ISO/IEC 12207:1995-08-01

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

     Целесообразность совместного использования стандартов на ИС и ПО обусловлена одним из положений стандарта ISO 12207, согласно которому процессы, используемые во время ЖЦ ПО, долж ны быть совместимы с процессами, используемыми во время ЖЦ автоматизированной системы.

Общая структура ЖЦ ИС (по стандарту ISO /IEC 12207)

     Стандарт ISO 12207 не предусматривает каких-либо этапов, фаз, стадий ЖЦ ИС, а определяет лишь ряд процессов, причем очень крупных. Каждый процесс подразделяется на ряд действий, а действия – на ряд задач. Важное отличие ISO 12207 от CDM – каждый процесс, действие или задача инициируются и выполняются по мере необходимости, причем нет заранее определенной последовательности выполнения.

     В стандарте ISO / IEC 12207 описаны пять основных процессов ЖЦ ИС:

1. процесс приобретения определяет действия предприятия-покупателя, приобретающего ИС, ПП или службу ПО;

2. процесс поставки определяет действия предприятия-поставщика;

3. процесс разработки определяет действия предприятия-разработчика, которое разрабатывает принцип построения ПИзделия;

4. процесс функционирования определяет действия предприятия-оператора, которое обслуживает систему в целом (а не только ПО) в процессе ее функционирования;

5. процесс сопровождения определяет действия персонала, обеспечивающего сопровождение ПП (установка, удаление, поддержка текущего состояния, управление модификациями ПП).

    Кроме основных, стандарт ISO 12207 определяет восемь вспомогательных процессов: процесс решения проблем, процесс документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместной оценки, аудита.

     В ISO 12207 также определены четыре организационных процесса: процесс управления, создания инфраструктуры, усовершенствования, обучения.

     Наконец, ISO 12207 определяет особый процесс – процесс адаптации, регламентирующий основные действия для адаптации самого стандарта к условиям конкретного проекта.

Особенности стандарта ISO /IEC 12207

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

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

3. Стандарт принципиально не содержит описания конкретных методов действия, заготовок решений или документации. Он лишь описывает архитектуру процессов ЖЦ ПО, не конкретизируя детали.

4. Стандарт содержит предельно мало описаний, связанных с проектированием БД.

     Ценность стандарта ISO/IEC 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.п., дающие всесторонний охват проектных ситуаций.

Стандарты комплекса ГОСТ 34

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

Общая структура ЖЦ ИС (по стандарту ГОСТ 34)

     Согласно ГОСТ 34, разработка ИС разбивается на следующие этапы и стадии:

1. Этап формирования требований к ИС. Состоит из стадий: обследование объекта и обоснование необходимости разработки ИС; формирование требований заказчика к ИС; разработка заявки на ТЗ, отчет о работе.

2. Разработка концепции: изучение объекта; проведение необходимых научно-исследовательских работ; разработка вариантов концепции ИС; отчет о работе.

3. Разработка и утверждение ТЗ на разработку ИС.

4. Разработка эскизного проекта ИС: разработка предварительных проектных решений; разработка документации.

5. Разработка технического проекта: разработка проектных решений по всей ИС и по ее частям; разработка документации на ИС и ее подсистемы; разработка и оформление документов на поставку изделий для комплектования ИС и/или технических требований на их разработку.

6. Разработка технической документации.

7. Ввод ИС в действие: подготовка объекта автоматизации; подготовка персонала; комплектация ИС программными и техническими средствами; монтажные работы; пуско-нала дочные работы; предварительные испытания; опытная эксплуатация; приемочные испытания.

8. Сопровождение: выполнение работ в соответствии с гарантийными обязательствами; постгарантийное обслуживание.

     В ГОСТ 34 дано описание содержания документов, разрабатываемых на каждом этапе. См. ГОСТ 34.601-90 (стадии создания АИС), ГОСТ 34.602-89 (ТЗ на создание АИС) и методические указания РД 50-34.698-90 (требования к содержанию документов).

Особенности ГОСТ 34

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

2. ГОСТ 34 позволяет: отказаться от этапа эскизного проектирования, объединять этапы разработки технического проекта, отказаться от некоторых стадий разработки, объединять большинство документов и т.д.

3. ГОСТ 34 ориентирует разработчиков на каскадную схему ЖЦ ИС.

4. Документы ГОСТ 34 определяют единую терминологию и разумно классифицируют работы по созданию АИС и соответствующую документацию. ГОСГ 34 упрощает интеграцию разных ИС и повышает качество интеграции.

5. Комплекс стандартов ГОСТ 34 ближе к схемам конкретных методик, чем к стандартам типа ISO 12207.

6. Ключевым документом взаимодействия сторон является ТЗ на разработку ИС. ТЗ разрабатывается организацией-разработчиком по ГОСТ 34.602-89, но формально ТЗ выдает разработчику заказчик по РД 50-680-88.

Выводы

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

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

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

4. ГОСТ 34 позволяет избежать ситуаций, в которых разработчики разных профессий (например, финансовые аналитики и проектировщики БД) “говорят на разных языках”.

5. ГОСТ 34 и CDM в первую очередь ориентированы на создание и поддержку ИС, а ISO 12207 – на приобретение и эксплуатацию ИС (при этом разработка является процессом, логически вытекающим из приобретения).

Лекция 9. Основные понятия теории систем