Технологии разработки информационных систем кратко

Обновлено: 18.05.2024

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

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

АИС – это человеко-машинная система, обеспечивающая автоматизированную подготовку, поиск и обработку информации.

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

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

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

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

· Системы обработки данных

· Системы бухгалтерского учета и т.д.

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

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

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

Главная цель Пр.О - укрепление законности.

Модели ИС

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

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

Модель "Черного ящика"

Всякая система – это нечто цельное и выделенное из окружающей среды. Система и среда взаимодействуют между собой.

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

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

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

• модель черного ящика компьютера

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

И все-таки она дает более подробное представление, чем модель "черного ящика".

Модель состава системы

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

Структурная модель системы

Такую модель часто называют

структурной схемой.

На структурной схеме отражается состав системы и ее внутренние связи.

Наглядным способом описания структурной модели системы являются графы .

Здесь стрелки обозначают информационные связи между элементами системы. Направление стрелок указывает на направление передачи информации.

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

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

Модель объекта

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

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

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

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

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

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

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

Соответственно можно выделить следующие виды АИС :

· автоматизированные системы обработки данных (АСОД);

· автоматизированные информационно-поисковые системы (АИПС);

· автоматизированные информационно-справочные системы (АИСС);

· автоматизированные информационно-логические системы (АИЛС);

· автоматизированные рабочие места (АРМ);

· автоматизированные системы управления (АСУ);

· автоматизированные системы информационного обеспечения (АСИО);

· экспертные системы (ЭС) и системы поддержки принятия решений.

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

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

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

При создании модели формируется "язык общения" руководителей предприятия, консультантов, разработчиков и будущих пользователей, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятием (корпоративная система управления).

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

Термин CASE (Computer Aided Software Engineering) означает "компьютерная поддержка проектирования программного обеспечения" и связан с появлением так называемых CASE-средств - программных продуктов нового типа, предназначенных для автоматизации разработки ИС.

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

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

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

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

1. Анализ - определение требований, функций системы.

2. Проектирование - определение подсистем и их интерфейсов.

3. Реализация (программирование) - разработка подсистем и их интерфейсов.

4. Компоновка (интеграция) - соединение подсистем в единое целое.

5. Тестирование (верификация) - проверка работы системы.

6. Внедрение (инсталляция) - введение системы в действие.

7. Эксплуатация - использование системы, сопровождение и анализ опыта эксплуатации.

В разное время и в разных "школах" проектирования разрабатывались более детальные технологии. При этом разбиение работ на этапы и их названия менялись. Соответствующие технологии организации работ рекомендовались официально, фиксировались в стандартах (ГОСТы, ANSI, ISO), описывались в монографиях, учебниках и во многих отраслях широко использовались. Несмотря на все различия предлагаемых технологий можно выделить этапы, общие для большинства методик. В таблице 5.1 приведена такая типовая последовательность этапов проектирования, составленная Е.З. Зиндером [19]. Для сравнения в таблице 5.1 приведена технология SSADM, официально принятая в качестве государственного стандарта Великобритании [20].

Таблица 5.1

Технологии разработки информационных систем

Технология по Зиндеру

Технология SSADM

  1. Запуск: организация основания для деятельности и запуск работ - договор, задание на выполнение работ
  2. Обследование: предпроектный анализ, общий анализ ситуации, разработка обоснования целесообразности создания ИС
  3. Концепция, Техническое задание: исследование требований, выработка рекомендаций, ТЗ на всю систему и отдельные подсистемы
  4. Эскизный проект: разработка архитектуры будущей ИС
  5. Опытный вариант ИС: разработка пилотного проекта будущей ИС, его опытное использование
  6. ТП: Разработка технического проекта ИС
  7. РП: Разработка рабочей документации проекта
  8. Ввод в действие: внедрение ИС
  1. Оценивание реализуемости: предварительное технико-экономичес-кое обоснование проекта
  2. Анализ требований: предпроектное обследование, описание существующей системы
  3. Выбор варианта автоматизации
  4. Разработка технического задания: полностью определяются требования к выбранному варианту ИС, разработка демонстрационного прототипа
  5. Выбор варианта технической реализации: выбор технической и программной сред реализации ИС
  6. Разработка логического проекта: разработка и увязывание постановок задач, схем диалогового взаимодействия
  7. Физическое проектирование: описание данных на физическом уровне, руководящие указания по программированию

Создание промышленной информационной технологии SSADM (Structured System Analysis and Design Method), координируемое и финансируемое Государственным агентством по информатике и вычислительной технике Великобритании, началось еще с середины 70-х годов. В 1981 году данная технология была объявлена открытым отраслевым стандартом. В течение 80-х годов технология SSADM получила широкое распространение сначала в Великобритании, а затем и за ее пределами. Этому способствовало создание CASE-средств поддержки - инструментальных программных средств проектирования. В середине 1993 года технология SSADM была официально принята в качестве государственного стандарта Великобритании [20]. Если состав этапов, их назначение за прошедшие четверть века менялись незначительно, то схема их применения, порядок следования этапов и организация работ менялись кардинально.

Традиционная схема, используемая в 70-е - начало 80-х гг., называемая каскадной или водопадной моделью, предполагает строгое детерминированное следование этапов анализа, проектирования, реализации, внедрения и эксплуатации ИС по единому заранее разработанному плану. Положительные стороны данной схемы [19]:

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

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

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

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

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

- не выдерживался план-график выполнения работ, превышались сроки или смета, или и то, и другое.

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

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

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

Постепенно сложилась некоторая смешанная схема, лежащая где-то посредине между каскадной и спиральной моделями, которую можно назвать "макетной" или схемой "быстрого прототипирования" (rapid prototyping или fast-track). Последовательность этапов в данной модели внешне выглядит как каскадная, однако содержание технологических этапов таково, что многие проектные решения в процессе разработки ИС подвергаются многократным уточнениям и корректировкам, как это предусмотрено спиральной моделью [20]. Такой компромисс достигается за счет:

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

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

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

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

Рис. 5.1. Последовательность разработки информационных систем:
а) каскадная схема; б) спиральная схема; в) макетная схема

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

Введение

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

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

  1. Обеспечить реализацию информационных систем, которые отвечают целевым установкам и задачам организации и соответствуют выдвинутых к ним требованиям по автоматизации деловых процессов.
  2. Гарантировать реализацию системы с требуемыми параметрами в течении определённого временного интервала в границах утверждённого ранее бюджета.
  3. Обеспечить простоту сопровождения, улучшения и увеличения системы для того, чтобы поддержать её соответствие меняющимся условиям функционирования организации.
  4. Обеспечить реализацию корпоративных информационных систем, которые отвечают требованиям открытости, перемещаемости и масштабируемости.
  5. Обеспечить допустимость применения в реализуемой системе спроектированных раньше и используемых в организации средств информационных технологий.

Методология и технология разработки информационных систем

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

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

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

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

Все технологические операции следует обеспечить представленными ниже материальными и информационными ресурсами:

Готовые работы на аналогичную тему

  1. Информационными данными, которые получены на предыдущих операциях, отражёнными в стандартном формате.
  2. Методическим материалом, нормами, набором стандартов и инструкциями.
  3. Программным и аппаратным обеспечением.
  4. Коллективом исполнителей.

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

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

  1. Осуществление поддержки полного жизненного цикла информационной системы.
  2. Обеспечение гарантированного достижения намеченных целей реализации системы при требуемом качестве и в заданный временной период.
  3. Обеспечение возможности разбиения больших проектов на подсистемы, то есть обеспечение декомпозиции проекта на составляющие компоненты, которые будут разрабатывать коллективы работников определённой численности с дальнейшим объединением составляющих компонентов. Декомпозиция проектных работ даёт возможность повышения их общей эффективности.
  4. Технология обязана обеспечить возможность выполнения проектных работ по отдельным подсистемам небольшим коллективом, примерно от трёх до семи исполнителей. Это подтверждается законами управляемости исполнительского коллектива и увеличения производительности путём сведения к минимуму количества внешних связей.
  5. Гарантировать самое маленькое время реализации работоспособной системы. Обычно, даже когда есть целиком завершённый проект, внедрение спроектированной системы осуществляется поочерёдно, то есть по каждой подсистеме. Формирование же полной системы в короткие сроки требует вовлечения значительного количества проектировщиков. Причём эффект может быть даже меньше, чем при формировании отдельных подсистем за меньшие периоды времени и при меньшем количестве исполнителей.
  6. Должна быть предусмотрена возможность управления структурой проекта, рассмотрения разных вариантов проекта и его компонентов, а также автоматический выпуск проектной документации и синхронизация её вариантов с вариантами проекта.
  7. Следует обеспечить независимость осуществляемых проектных решений от средств формирования системы, а именно, от системы управления базами данных, операционных систем, языков систем программирования.

При проектировании сложных информационных систем используются так называемые CASE (Computer-Aided Software / System Engineering) технологии. Сложные информационные системы требуют коллективного осуществления проекта с участием специалистов самых разных направлений, например, таких как системные аналитики, программисты и собственно проектировщики. Главным преимуществом технологии CASE является реализация коллективного проектирования за счёт использования локальных сетей проектировщиков, возможности передачи и приёма всех компонентов проекта, организованного управления проектом. Данная технология является набором аналитических методик, средств проектирования, реализации и сопровождения сложных систем программного обеспечения, которые поддержаны комплектом программных средств автоматизации.

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

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

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

  • организации,
  • требований к ИС,
  • проекта ИС,
  • требований к приложениям

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

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

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

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

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

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

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

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

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

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

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

  • выбор платформы (платформ)
  • выбор операционной системы (операционных систем) .

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

  • будет ли это архитектура "файл-сервер" или "клиент-сервер";
  • будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
  • будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
  • будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);.
  • будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

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

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

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

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

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

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

  • тесты функциональности
  • тесты надежности системы.

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

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

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

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

Сопровождение - может отсутствовать. То есть разработчик передал продукт заказчику, а затем не усовершенствует его, не контролирует работу.

Читайте также: