Основные понятия проектирования ИС

 Проектирование

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

Проектирование информационной системы (ИС) – процесс длительный, сложный и трудоёмкий. Будем рассматривать ИС как некоторый проект.

Согласно словарю Даля слово “проект” толкуется так:

ПРОЕКТ (лат) – план, предположение, задуманное дело, или само изложение этого плана на письме или в чертеже.

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

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

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

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

 

1. Жизненный цикл ИС (Этапы создания проекта)

 

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

потребности и заканчивая выводом ИС из эксплуатации.

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

Разработка ИС в свою очередь состоит из четырех основных этапов:

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

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

 

Рис.1. Этапы жизненного цикла ИС

 

Системный анализ

Этап  анализ предполагает проведение:

• анализа осуществимости проекта
• анализа предметной области
• сбора и анализа требований к проекту
• прогнозирование и планирование стоимости, времени его разработки и ресурсов;
• составления технического задания (ТЗ).

 

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

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

 

 

Рис. 2 Процесс системного синтеза

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

Для новых ИС работа над проектом начинается с анализа его осуществимости.

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

1. Отвечает ли система общим и бизнес - целям организации-заказчика и организации-разработчика?
2. Можно ли реализовать систему, используя существующие на данный момент технологии знакомые разработчику?
3. Можно ли объединить систему с другими системами, которые уже эксплуатируются?
4. Есть ли гарантия, что завтра будут в рамках финансирования, а сложность системы посильна для разработчиков.

Сбор и классификация требований

Что такое требование? За долгие годы уже появилось множество определений требований к программному обеспечению, вполне приемлемым является следующее определение, предложенное специалистами в области разработки требований Дорфманом (Dorfman) и Тэйером (Thayer).

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

Многие наиболее часто встречающиеся серьезные проблемы при разработке программного обеспечения связаны именно с требованиями. Результат опроса организации ESPITI (European Software Process Improvement Training Initiative— Европейская инициатива по обучению совершенствованию процесса программирования) показал, что  двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались следующие:

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

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

 

   Проблемы сбора требований

 

Процесс сбора требований весьма сложен по следующим причинам:

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

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

Методы  сбора требований

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

Для этого  используются:

• Интервьюирование и анкетирование
• Мозговой штурм и отбор идей
• Сценарии (прецеденты)
• Прототипирование
• Обыгрывание ролей

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

Интервьюирование  и анкетирование

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

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

 

Сценарии

 

Сценарии описывают последовательность работы пользователя с системой.

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

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

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

5. Описание состояния системы после завершения сценария.

Пример  сценария событий

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

Рис. 3  Сценарий обработки банкоматом PIN- кода.

Прототипирование

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

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

Функциональные и нефункциональные требования

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

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

1.  Пользователь  должен иметь возможность проводить  поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных

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

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

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

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

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

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

Пример   системного требования:

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

Данное требование лучше сформулировать так:

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

В таблице 1Таблица 1 приведены показатели, с помощью которых можно специфицировать системные свойства.

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