ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 30.07.2021

Просмотров: 598

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.


По дисциплине «Проектирование информационных систем»

        1. Понятие ИС. Цели создания ИС. Особенности проектов современных ИС. [8]

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

Выделяют 7 видов обеспечивающих подсистем ппилот М

    • информационное;

    • программное;

    • техническое;

    • организационное;

    • метрологическое;

    • правовое;

    • лингвистическое.

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

Современные крупные проекты ИС характеризуются, как правило, следующими особенностями (Error: Reference source not found):

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

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

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

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

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

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

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

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


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

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

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

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

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

Условно можно выделить два подхода к созданию ИС (Error: Reference source not found):

  1. "снизу-вверх", когда изменения в систему вносятся по мере появления новых проблем.

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



        1. Проект создания ИС. Жизненный цикл ИС. Модели Жизненного цикла ИС. Стандарты на модель и структуру жизненного цикла ИС. [8]

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

и способы их взаимодействия в системе.

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

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

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

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

    • инструментальные средства проектирования (CASE-средства).

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

Жизненный цикл проекта включает все фазы от момента инициации до момента завершения…

Существует общее соглашение о выделении четырех обобщенных фаз жизненного цикла:

  • концепция (инициация, идентификация, отбор);

  • определение (анализ, проектирование);

  • выполнение (практическая реализация или внедрение, производство и развертывание, сдача в эксплуатацию, тестирование …);

  • закрытие (завершение, вывод из эксплуатации) …».

В определении ЖЦ проекта требуется уточнить значение ряда понятий:


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

  • фаза; см. стадия. Щас почти не используется.

  • этап; это локальная группировка работ проекта внутри стадии

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

  • контрольная точка. Переход между этапами.

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

  • ISO/IEC 12207: 1995, 15504 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного программного обеспечения. Стандарт не содержит описания фаз, стадий и этапов;

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

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

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

  • XP (Extreme Programming). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 г. В основе методологии положен принципы командной работы, эффективной коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов;

  • план Уайта, по сути, не является стандартом в прямом смысле. Этот подход был предложен одним из разработчиков стандарта MRP Оливером Уайтом. Этот подход содержит подробный план внедрения программ комплексного управления предприятием.


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

Итеративная и инкрементальная модель ЖЦ – эволюционная (гибридная, смешанная) или поэтапная модель с промежуточным контролем (Error: Reference source not found). Эта модель ЖЦИС появилась спустя непродолжительное время после появления на свет каскадной модели, которая была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания. В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов.

Спиральная модель (Error: Reference source not found). Вариантов организации спиральной модели в зависимости от выделения стадий каждого витка достаточно много, поэтому рассмотрим ее на примере модели Б.Боэма (Barry Boehm). На каждом витке спирали выполняется создание фрагмента или цели, проводится характеристика очередной версии продукта, уточняются цели, характеристика и требования проекта, определяется качество его выполнения, а также планируются работы следующего витка. Каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса.

        1. Каноническое проектирование ИС (ГОСТ 34.601-90). [8]

Стадии ЖЦ по ГОСТ 34.601-90

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

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

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

На начальной стадии проектирования выделяют следующие этапы работ:

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

  • формирование требований пользователей к ИС;

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

Комментарии:

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


  • обоснования разработки и поэтапного внедрения систем;

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

  • разработки технического и рабочего проектов систем.

  • изучение объекта автоматизации;

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

  • разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

  • оформление отчета и утверждение концепции.

Комментарии:

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

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

  • получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;

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

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

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

Комментарии:

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

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

В соответствии с ГОСТ 34.601-90 порядок разработки, состав, структура и оформление технического задания регламентируется ГОСТ 34.602-89.

Цель, которая достигается при подготовке правильно составленного технического задания очень проста. Это однозначное распределение сфер ответственности между Заказчиком и Исполнителем. ТЗ – это тот документ, который становиться основой при принятии решения о закрытии проекта и о размере и порядке расчета Заказчика и Исполнителя. Если ТЗ составлено правильно, то стороны могут формально подходить к вопросу сдачи-приемки работ. В противном случае характерна ситуация, когда одна из сторон, как правило этой стороной является Исполнитель, оказывается не в состоянии отстоять свои интересы. Для того, чтобы заявленная цель была реализована и до начала работ по реализации были однозначно определены критерии по которым будет осуществляться приемка ИС, при разработке технического задания необходимо решить следующие задачи (Error: Reference source not found):


Смотрите также файлы