Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Автоматизация предприятий. Новости, Интервью,Программы


Здраствуйте, уважаемые подписчики

Наши партнеры:

SotikGSM.org - Просто хороший магазин

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

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

Требования к информационной системе и модели жизненного цикла.

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

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

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

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

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

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

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

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

  • ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
  • ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.
  • Custom Development Method (и, методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.
  • Степень адаптивности CDM ограничивается тремя моделями ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track), "облегченный подход", рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.
  • Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (UML), а так же конкретной технологии проектирования и разработки (объектно-ориентированный анализ, object-oriented analysis, OOA, объектно-ориентированное программирование, object-oriented programming, OOP).
  • Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
  • Extreme Programming (XP). Экстремальное программирование является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

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

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

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

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

Продолжение следует...

http://www.silicontaiga.ru/home.asp?artId=2142

Все замечания отправляйте по почте: work_tol@inbox.ru

До свидания


В избранное