Теоретические основы проектирования информационных систем

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

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

Жизненный цикл информационной системы включает в себя включает в себя 4 основных стадии.

На предпроектном этапе можно выделить следующие этапы:

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

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

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

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

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

-Каскадная;

-Спиральная;

-Инкрементная.

1.1 Каскадная модель разработки информационных систем

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

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

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

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

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

-о требуемых показателях, измерениях;

-о возможных системах-источниках данных;

-о системном ландшафте;

-о сетевом окружении.

Проектирование описывает внутреннюю структуру проекта. Обычно описание выполняется в виде диаграмм и текстов.

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

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

Каскадная модель разработки информационных систем имеет 2 подвида.

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

Каскадная модель с обратными связями.

1.2 Спиральная модель жизненного цикла информационной системы

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

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

- Необходимость предупреждения рисков;

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

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

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

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

Недостатки итерационной модели:

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

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

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

На начальных этапах (анализ и проектирование) реализуемость технических решений проверяется созданием прототипов.

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

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

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

1.3 Инкрементная модель жизненного цикла информационной системы

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

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

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

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

Преимущества инкрементной модели:

-Получение функционального продукта после реализации каждого инкремента;

-Предотвращение формирования громоздких перечней требований;

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

-Улучшение понимания требований для более поздних инкрементов за счет практической работы с наиболее разработанными инкрементами;

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

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

-Снижение риска неудачи и пересмотра требований;

-Распределение риска между несколькими небольшими инкрементами, что сокращает его общую величину;

-Снижение затрат на первоначальную поставку программного продукта;

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

-Ускорение начального графика поставки и графика всего проекта в целом;

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

-Упрощение работы над проектом при смене состава разработчиков;

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

-Постепенное привыкание заказчика к системе;

-Возможность оценки заказчиком наиболее важных функциональных особенностей продукта на более ранних этапах разработки;

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

ГОСТ Р ИСО/МЭК ТО 15271-2002 выделяет следующие достоинства инкрементной модели:

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

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

-Естественное разделение системы на наращиваемые компоненты;

-Возможности наращивания привлекаемого персонала и средств.

Этим же документом отмечен ряд недостатков инкрементного подхода к созданию ИС в случае его использования для создания не подходящего к данной модели проекта:

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

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

-Недостаточно четкое определение требований;

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

-Сложность формального анализа и проверки отдельных инкрементов;

-Наличие тенденции к оттягиванию решения трудных проблем на более поздние инкременты и связанные с этим задержки работ;

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

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

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

-Необходимость хорошего планирования и проектирования, грамотного распределения работы;

-Ограниченность привлечения ресурсов на длительный срок.

Область применения инкрементной модели:

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

-Большинство требований можно сформулировать заранее;

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

-Для проектов, на выполнение которых отведен большой срок;

-При равномерном распределении свойств различной степени важности; информационный каскадный инкрементный программа

-Если при рассмотрении риска, финансирования, графика выполнения проекта, его размера самым оправданным оказывается применение принципа пофазовой разработки;

-При разработке программ с низкой степенью риска;

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

-Когда однопроходная разработка системы связана с большой степенью риска;

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

Недостатки инкрементной модели разработки:

-В модели не предусмотрены итерации в рамках каждого инкремента;

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

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

-Невозможность снижения затрат проекта;

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

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

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

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

Глава 2. Проектирование гипертекстовой информационной системы «Наши дети»

На территории Российской Федерации функционирует несколько сотен тысяч учреждений для детей-сирот. Многие из них в штатном расписании имеют собственные подразделения охраны, что ограничивает возможности общественного контроля за воспитательным процессом. Между тем, в этих учреждениях работает большое количество случайных людей, не имеющих педагогического образования, позволяющих себе применять непедагогичные воспитательные меры, зачастую граничащие с уголовно-наказуемыми деяниями. Предлагаемый проект информационной системы позволит поставить деятельность интернатных учреждений под общественный контроль путем публикации в открытом доступе информации о персонале и о контингенте учреждений, а в дальнейшем путем установки web-камер в интернатных учреждениях. Однако в этом случае может возникнуть ряд проблем технического и юридического характера. Во-первых, необходимо помнить о требованиях Федерального закона от 8 августа 2006 года №152-ФЗ «О защите персональных данных», статья 9 которого требует получения согласия субъекта (носителя персональных данных) на их обработку. Под обработкой в данном законе понимаются «действия с персональными данными, включая сбор, систематизацию, накопление, хранение, уточнение (обновление или изменение), использование, распространение (в т.ч., передачу), обезличивание, (возникает блокирование и уничтожение персональных данных. Предполагается, однако, что получение согласия на обработку персональных данных добросовестно работающих сотрудников интернатных учреждений не составит особой проблемы.

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

2.2 Анализ работы стационарного учреждения социального обслуживания (детский дом для умственно-отсталых детей) с использованием модели «сущность -- связь»

Модель представления данных «сущность -- связь» основывается на некоторой семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными.

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

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

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

Атрибутами сущности 2 (дети) являются: имя, группа, возраст, увлечения, особенности развития.

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

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

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

Сущности 5 и 6 (поставщики мед. препаратов, одежды и продуктов питания) имеют следующие атрибуты: наименование, юридический адрес, ИНН, коды по ОКД/ОКПО, данные лицензий и разрешений на работу, номера счетов и т.д.

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

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

Попытка сконструировать связи между вышеозначенными сущностями дает следующий результат. Сущность 1 (сотрудник) связана с сущностью 2 (ребенок) через понятие «отвечает за безопасность». Сотрудник связан также с «мероприятием» через понятие «готовит». Ребенок связан с «мероприятием» связью «участвует». Одновременно ребенок связан с сущностями «Медицинские препараты» и «Продукты питания» связью «получает». Атрибуты этих сущностей частично совпадают. К их числу относятся название, дозировка (размер порции), цена одной единицы (порции), итоговая стоимость.

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

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

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

2.3 Вопросы регулирования правоотношений, возникающих в связи с созданием и эксплуатацией информационной системы «Наши дети»

База данных, являющаяся составной частью информационной системы «Наши дети» подпадает под действие статьи 1225 Гражданского кодекса Российской Федерации. Данная статья устанавливает общий перечень объектов, на которые распространяется понятие «авторское право». В данном случае объективной формой существования информационной системы является описание (письменная форма записи). Материальным носителем базы данных является носитель -- накопитель Transcend ® Jet Flash. Авторское право на информационно-поисковую систему принадлежит разработчику и возникает с момента создания базы данных.

Размещено на Allbest.ru