Разработка подсистемы учета гематологических анализов для КДЛ ГБСМП-2 (стр. 6 из 12)

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

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

- в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

- основное внимание переносится с документации на код, причем при этом, соблюдая принцип «получите то, что видите»;

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

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

4.2 Определение цели и области действия программного проекта

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

Задачи проекта:

- выполнить сбор, спецификацию и аттестацию требований

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

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

- провести тестирование программного продукта;

Программный проект должен быть:

- продуктом для внутреннего использования в БСМП-2;

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

- проектом, который обеспечивает возможность учета гематологических анализов в рамках КДЛ.

Программный проект не должен быть:

- проектом, доступным для посторонних лиц.

При определении области действия программного продукта эффективнее всего воспользоваться методикой «будет,/не будет». Ниже определены рамки проекта.

Проект будет:

- сетевым;

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

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

- применяться в операционных системах Windows.

Проект не будет:

- локальным;

- использоваться в системах отличных от Windows.

4.3 Создание структуры пооперационного перечня работ

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

¾ планирование и активизация проекта;

¾ фаза планирования требований;

¾ фаза описания пользователя;

¾ фаза «расчистки».

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

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

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

Рисунок 4.1 – Пооперационный перечень работ ИС

4.4 Идентификация задач и действий

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

Разрабатываемый модуль является частью проектируемой ЛИС. ЛИС разрабатывается на основе спиральной модели, первые два прохода которой выполнены в 2006-2007 году. В настоящее время идет третий проход разработки. Подсистема по учету гематологических анализов разрабатывается в рамках третьего прохода как независимый проект. Для этого модуля была определена технология проектирования RAD. Данный проект включает в себя следующие фазы:

- Планирование и активизация проекта;

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

- Описание пользователя (процесс разработки проекта, разработка проекта, процесс внедрения);

- «расчистка», которая включает в себя установку.

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

4.5Оценка размера и возможности повторного использования

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

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

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

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

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

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

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

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

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

При разработке системы средствами СУБД происходит повторное использование модулей и функций системы. Например, при разработке нам ИС «Учет гематологических анализов» было решено повторно использовать функции кнопок, которые мы ранее разработали для других форм (например, авторизация пользователей), только немного подстроив их под новые данные. Это приводит к уменьшению времени разработки.

4.6 Оценка длительности и стоимости разработки проекта

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