Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции - Управление жизненны циклом ИС - файл 1.doc


Лекции - Управление жизненны циклом ИС
скачать (336 kb.)

Доступные файлы (1):

1.doc336kb.29.11.2011 20:37скачать

1.doc

  1   2

1. Жизненный цикл ИС и его модели.



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

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

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

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

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

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

^ Поэтапная модель с промежуточным контролем:



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

^ Спиральная модель:



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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

^

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



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

^

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



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

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

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

Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.

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

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

^

4. Стандартизация процессов жизненного цикла ИС



Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.
Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4].

^ ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].

^ Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

^ Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML [6].

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

^ Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

^ Основные процессы: приобретение; поставка; разработка; эксплуатация; сопровождение.

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

^ Организационные процессы:

создание инфраструктуры; управление; обучение; усовершенствование.
Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.
в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.
Согласно стандарту ISO/IEC серии 15288 [7] в структуру ЖЦ следует включать следующие группы процессов:

^ Договорные процессы: приобретение (внутренние решения или решения внешнего поставщика); поставка (внутренние решения или решения внешнего поставщика).

Процессы предприятия: управление окружающей средой предприятия; инвестиционное управление; управление ЖЦ ИС; управление ресурсами; управление качеством.

^ Проектные процессы: планирование проекта; оценка проекта; контроль проекта; управление рисками; управление конфигурацией; управление информационными потоками; принятие решений.

^ Технические процессы: определение требований; анализ требований; разработка архитектуры; внедрение; интеграция; верификация; переход; аттестация; эксплуатация; сопровождение; утилизация.

^ Специальные процессы: определение и установка взаимосвязей исходя из задач и целей.
Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288:

1 - Формирование концепции - Анализ потребностей, выбор концепции и проектных решений;

2 - Разработка – Проектирование системы;

3 - Реализация – Изготовление системы;

4 - Эксплуатация – Ввод в эксплуатацию и использование системы;

5 - Поддержка – Обеспечение функционирования системы;

6 - Снятие с эксплуатации –Прекращение использования, демонтаж, архивирование системы.

^

5. Стратегическое планирование ИС на предприятиях



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

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

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

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

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

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

- При всей обеспеченности ресурсами эффективность работы ниже требуемой;

- Неудовлетворенность пользователей текущим состоянием их информационной поддержки;

- Появление очередных новых технологий (CRM, мобильная коммерция) – стоит ли в них вкладываться и, если да, то когда;

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

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

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

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

- организационная структура информационной службы.
Методы стратегического планирования к разработке стратегии развития информационного обеспечения предприятия: классический подход к информационному обеспечению, как к одной из подсистем предприятия; стратегическое планирование информационных систем; «выравнивание» стратегий организации и информационной системы; планирование технических и программных средств; планирование качества информации; внутрикорпоративный отбор проектов; ключевые факторы успеха и др.

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

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

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

1.3. Планы и амбиции топ-менеджеров холдинга и руководителей ИТ-службы

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

3. Планирование перехода к требуемому состоянию:

3.1. Анализ различий между имеющимся и требуемым состоянием

3.2. Разработка общей стратегии развития информационного обеспечения

3.3. Развитие информационных услуг

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

3.5. Развитие организационной структуры информационной службы

3.6. Отбор возможных проектов по развитию информационной системы

3.7. Разработка плана реализации стратегии развития ИС

4. Реализация стратегии развития ИС

5. Периодический контроль процесса реализации стратегии развития ИС. Корректировка реализуемой стратегии

^

6. Выбор проектов создания ИС предприятий



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

Ключевые вопросы при оценке проектов:

1. Как этот проект поможет достичь бизнес-целей?

2. Подходит ли он технически?

3. Является ли он лучшим использованием ресурсов?

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

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

Ключевые вопросы:

1. Помогает ли ИС организации делать то, что она делает, с минимальными затратами ресурсов?

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

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

^ Управленческую архитектуру:

- роль менеджера-пользователя и т.д.;

- системы менеджмента;

- связывающий механизм бизнес-плана;

- механизмы ИС планирования и контроля.
^ Техническую архитектуру:

- инфраструктуру;

- расположение;

- рабочие станции и т.д.;

- данные (владение и деление, защита и т.д.);

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

- обзор текущей ситуации;

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

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

- идентификация видения роли информации;

- определение архитектуры;

- связь видения и архитектуры;

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

Пряма в тексте выделил вопросы.

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

Для того что бы не ошибится читаем внимательно табличку, выбираем нужный этап и расписываем)


  • ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов.

  • Комплекс рассчитан на взаимодействие заказчика и разработчика.

  • ГОСТ 34 в основном уделяет внимание содержанию проектных документов.




  • Комплекс стандартов на автоматизированные системы:

  • ^ ГОСТ 34.201-89 ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ.

  • ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ СТАДИИ СОЗДАНИЯ.

  • ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.

  • ГОСТ 34.603—92 ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ



^

7-11. Этапы и стадии процесса проектирования ИС по ГОСТ 34.


Стандарт устанавливает стадии и этапы создания АС.

Стадии

Этапы работ

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

8) ГОСТ 34. Состав и содержание работ на предпроектной стадии проектирования ИС
возможно и 2 стадия тоже

1.1. Обследование объекта и обоснование необходимости создания АС.
1.2. Формирование требований пользователя к АС.
1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

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

8) ГОСТ 34. Состав и содержание работ на предпроектной стадии проектирования ИС

2.1. Изучение объекта.
2.2. Проведение необходимых научно-исследовательских работ.
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.
2.4. Оформление отчёта о выполненной работе.

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

9) ГОСТ 34. Состав и содержание работ на стадии технического проектирования ИС.

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


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

9) ГОСТ 34. Состав и содержание работ на стадии технического проектирования ИС.

4.1. Разработка предварительных проектных решений по системе и её частям.
4.2. Разработка документации на АС и её части.

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

10) ГОСТ 34. Состав и содержание работ на стадии рабочего проектирования ИС.







5.1. Разработка проектных решений по системе и её частям.
5.2. Разработка документации на АС и её части.
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

10) ГОСТ 34. Состав и содержание работ на стадии рабочего проектирования ИС.



6.1. Разработка рабочей документации на систему и её части.
6.2. Разработка или адаптация программ.

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

11) ГОСТ 34. Состав и содержание работ на стадии ввода ИС в эксплуатацию

7.1. Подготовка объекта автоматизации к вводу АС в действие.
7.2. Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний.


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

8.1. Выполнение работ в соответствии с гарантийными обязательствами.
8.2. Послегарантийное обслуживание.


Стадии этапы, выполняемые организациями - участниками работ по созданию АС, устанавливаются в договорах и техническом задании
Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". Допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ
ГОСТ 34.201-89
^ ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

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

1) акт завершения работ;

2) акт приемки в опытную эксплуатацию;

3) акт приемки в промышленную эксплуатацию;

4) план-график работ;

5) приказ о составе приемочной комиссии;

6) приказ о проведении работ;

7) программа работ;

8) протокол испытаний;

9) протокол согласования.
ГОСТ 34.603-92
^ ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ


  • Испытания АС проводят на стадии “Ввода в действие” по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ).

  • Виды испытаний и статус приемочной комиссии устанавливают в договоре и (или) ТЗ.

  • Для планирования проведения всех видов испытаний разрабатывают документ “Программа и методика испытаний”. Разработчик документа устанавливается в договоре или ТЗ.


^

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


ГОСТ 34.602-89
ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.

ОБЩИЕ ПОЛОЖЕНИЯ

  • ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

  • Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись “Действует с ... ”.

^ СОСТАВ И СОДЕРЖАНИЕ

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

  • общие сведения;

  • назначение и цели создания (развития) системы;

  • характеристика объектов автоматизации;

  • требования к системе;

  • состав и содержание работ по созданию системы; .

  • порядок контроля и приемки системы;

  • требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

  • требования к документированию;

  • источники разработки.

В ТЗ на АС могут включаться приложения, допускается вводить дополнительные, исключать или объединять подразделы.
В разделе “Общие сведения” указывают:


  • полное наименование системы и ее условное обозначение;

  • шифр темы или шифр (номер) договора;

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

  • перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

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

  • сведения об источниках и порядке финансирования работ;

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


Раздел “Требования к системе” состоит из следующих подразделов:

  • требования к системе в целом;

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

  • требования к видам обеспечения.


Раздел “Состав и содержание работ по созданию (развитию) системы” должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601, сроки их выполнения, перечень организаций — исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ. В данном разделе также приводят:

  • перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

  • вид и порядок проведения экспертиза технической документации (стадия, этап, объем проверяемой 'документации, организация-эксперт);


^ ПОРЯДОК РАЗРАБОТКИ СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

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

Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием.

Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий

Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

^

13. Современные методологии создания ИС



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

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

гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета;

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

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

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

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

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

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

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

Мощные импульсы развитию методологий дало появление двух принципиально новых подходов к созданию корпоративных ИС: информационного инжиниринга и реинжиниринга бизнес-процессов (BPR). Предлагаемые в них методы позволили описывать, анализировать и проектировать структуру и деятельность корпораций подобно техническим системам. Каждый из этих подходов породил свой класс методологий, обладающих общими характеристиками. В настоящее время продолжается активный процесс развития и совершенствования методологий создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире. В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений (ИС). В консорциуме участвуют и российские компании.

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

Сегодня в нашей стране недостаточно оценивается роль и значение методологии (в отличии от средств проектирования прикладного программного обеспечения). В предстоящие годы задача создания корпоративных ИС на базе современных методологий встанет перед многими отечественными организациями. (При этом заметим, что на Западе методологии по-прежнему считают стратегической продукцией. Многие из них представляют собой ноу-хау и по сей день.)
^ 2. Основные составляющие методологии
Целью работы является описание методологии, обеспечивающей решение перечисленных выше основных задач. Предлагаемая методология создания корпоративных ИС состоит из двух основных взаимосвязанных частей: методологии анализа ИС, включающей описание деятельности организации и формирование требований к ИС на основе бизнес-процессов, и методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения ИС. Предлагаемая методология строится на основе итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой методологии является то, что охватывая все этапы жизненного цикла ИС, она делает основной упор на поддержку начальных этапов создания корпоративных ИС, главной задачей которых является формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с подходом информационного инжиниринга, который Джеймс Мартин определяет как "применение взаимосвязанного набора формальных технологий (моделей) для планирования, анализа, проектирования и создания информационных систем на уровне корпораций или отдельных ее частей ...", процесс создания ИС строится как процесс построения и развития моделей. Реализация методологии базируется на применении комплекса согласованных между собой инструментальных средств, обеспечивающих высокий уровень автоматизации всех процессов, выполняемых в соответствии с методологией на протяжении ЖЦ ИС.
Таким образом, фундамент предлагаемой методологии составляют:

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

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

методология анализа ИС на основе бизнес-процессов;

методология проектирования от данных;

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

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

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

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

ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями.

Современные средства CASE, 4GL, СУБД и др. предоставляют возможности быстрого проектирования, прототипирования, разработки и тестирования приложений и баз данных на основе построенных моделей.

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

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

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

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

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

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

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


^

14. Метод структурного анализа и проектирования SADT


Метод SADT (Structured Analysis and Design Technique) разработан в 1973 г . Дугласом Россом (SoftTech, Inc.). Успешно использовался в военных, промышленных и коммерческих организациях США. Метод поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 (Icam DEFinition) - подмножества SADT, являющегося основной частью программы ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства). Более того, среди менеджеров и руководителей компьютерных фирм считается, чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

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

• функция - некоторое действие ЭИС, необходимое для решения экономической задачи.

• декомпозиция функции - разбиение функции на множество подфункций.

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

Метод основан на следующих концепциях :

• графическое представление блочного моделирования;

• строгость и точность;

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

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

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

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

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

  • Анализ — определение того, что система будет делать,

  • Проектирование — определение подсистем и их взаимодействие,

  • Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое,

  • Тестирование — проверка работы системы,

  • Установка — введение системы в действие,

  • Эксплуатация — использование системы.

Современный уровень информационных технологий предоставляет богатый выбор методов для создания автоматизированной поддержки SADT. Наиболее доступным на сегодняшний день SADT-средством является Design/IDEF (Meta Software Corp.) — изначально построенный в рамках программы интегрированной компьютеризации производства и широко используемый ныне в различных областях деятельности. Автоматизированная поддержка SADT происходит в развитии от просто графического средства до программного обеспечения, функционирующего на базе знаний более общих понятий моделирования.
^

15. Основные элементы IDEF0-диаграмм


Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).



Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.
IDEF0 сочетает в себе небольшую по объему графическую нотацию (систему обозначений, содержащую только два знака: блоки и стрелки) с четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.

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

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

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

Цель моделирования (Purpose). Модель должна строиться при ясном осознании объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:

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

что выявит данная модель;

какие результаты может принести применение данной модели.

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

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

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

Действия. Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом - контекстная функция. Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть отглагольным существительным (например, "производить услуги", а не "производство услуг"). Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования. Каждая из четырех сторон функционального блока имеет своё определенное значение (роль).

Верхняя сторона имеет значение "Управление" (Control) - стрелки сверху, означающие, на основании чего выполняется данный процесс: законы, стандарты, приказы и т.д.

Левая сторона имеет значение "Вход" (Input) - стрелки слева, означающие данные или объекты, потребляемые или изменяемые процессом

Правая сторона имеет значение "Выход" (Output) - стрелки справа, означающие основные результаты деятельности процесса, конечные продукты.

Нижняя сторона имеет значение "Механизм" (Mechanism) -стрелки снизу, означающие, посредством чего или с помощью кого реализуется данный процесс: материальные и/или кадровые ресурсы, необходимые для процесса.

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

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

^

16. Основные элементы IDEF3-диаграмм


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

IDEF3 широко применяется при разработке информационных систем. При этом используется инструмент визуального моделирования бизнес-процессов.
^ Два типа диаграмм в IDEF3

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

IDEF3 состоит из двух методов. Process Flow Description (PFD) - Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса. Object State Transition Description (OSTD) - Описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов. Модель в нотации IDEF3 может содержать два типа диаграмм:

  • диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD)

  • диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN)

[править]
Компоненты диаграммы описания процесса

Диаграмма IDEF3 Process Flow Description может состоять из 5 основных описательных блоков:

  • работы (boxes, activities)

  • стрелки или связи (arrows, links)

  • перекрёстки (junctions)

  • объекты ссылок


^

17. Основные элементы DFD-диаграммы


DFD – диаграммы потоков данных

В соответствии с DFD (Data Flow Diagram) методологией, модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

Элементы DFD диаграмм

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

  • внешние сущности;

  • процессы;

  • накопители данных;

  • потоки данных.

Внешние сущности

Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации. В качестве внешней сущности на  DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. К сожалению, DFD методология не оформлена как стандарт. По этой причине в диаграммах потоков данных используются различные условные обозначения. На рисунке 1 показаны символы внешних сущностей, используемые в  нотациях «Yourdon and Coad Process Notation» и «Gane and Sarson Process Notation».



^ Рис. 1. Символы внешних сущностей

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

Процессы

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

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



^ Рис. 2. Символы процессов

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить) и поясняющими существительными, например: «Напечатать адрес получателя», «Акцептовать счет».

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

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

^ Накопители данных

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



^ Рис. 3. Символы накопителей данных

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

^ Потоки данных

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


^

18. Словарь данных DFD-диаграмм


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

Создается словарь данных ( Data Dictionary ), в котором хранится и анализируется состав потоков и накопителей данных, взаимосвязь отдельных элементов потоков и накопителей данных. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.
^

19. Спецификации процессов DFD-диаграмм


DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших в "доюмээльную" эпоху. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, "старинные" структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.
Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.
Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.
Модель DFD, как и большинство других структурных моделей - иереархическая модель. Каждый процесс может быть подвергнут декомпозиции, т.е. разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции - процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).
Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.
Нотация DFD - удобное средство для формирования контекстной диаграммы, т.е. диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы - диаграмма SADT1), диаграмма Диаграмма вариантов использования.

^

20. Диаграммы "сущность-связь"


Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных.

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г . и получила дальнейшее развитие в работах Ричарда Баркера.

Методология IDEF 1Х была разработана для армии США и широко используется в государственных учреждениях, финансовых и промышленных корпорациях. Является развитием методологии IDEF 1, но в большей мере ориентирована на автоматизацию и более проста для понимания. Позволяет построить модель данных, эквивалентную реляционной модели, приведенной к третьей нормальной форме.

^ Нотация Чена

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



^ Нотация Мартина

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


^ Нотация IDEF1X.

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



^ Нотация Баркера.

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



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

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

Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой предметной области. Атрибут предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности.

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

21. Основные принципы структурного программирования.


Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.

В соответствии с данной методологией:

  • ^ Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

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

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

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

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

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




  • ^ Разработка программы ведётся пошагово, методом «сверху вниз».

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

^ Перечислим некоторые достоинства структурного программирования:

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

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

  • Сильно упрощается процесс тестирования и отладки структурированных программ.


^

22. Основные принципы тестирования ИС.


Тестирование – это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта.

Виды тестирования перечислены ниже:

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

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

  • ^ Интеграционное тестирование – это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами.

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

  • ^ Тестирование системы – это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами.


Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними.

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

Особенности тестирования «белого ящика».

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

В этом случае формируются тестовые варианты, в которых:

  • Гарантируется проверка всех независимых маршрутов программы.

  • Находятся ветви True, False для всех логических решений.

  • Выполняются все циклы (в пределах их границ и диапазонов).

  • Анализируется правильность внутренних структур данных.

Недостатки тестирования «белого ящика»:

  • Количество независимых маршрутов может быть очень велико.

  • Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

  • В программе могут быть пропущены некоторые маршруты.

  • Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных.
  1   2



Скачать файл (336 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации