48606 (588579), страница 5

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

Текст из файла (страница 5)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любой разрабатываемый проект состоит из задач, которые необходимо выполнить для достижения определенного (необходимого) результата. Для того чтобы стало возможным выполнение той или иной задачи необходимо что-либо сделать для этого, то есть затратить какие-либо ресурсы (трудовые, материальные, интеллектуальные) /5/.

Одним из наиболее важных свойств любого ресурса является стоимость (Cost (Затраты)) его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 60 рублей в час или 480 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном мной проекте использовалась повременная ставка (рисунок 4.2) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.3.

Рисунок 4.2 – Повременная ставка в использовании ресурса

Рисунок 4.3 – Общие затраты на использовании ресурсов проекта в третьем проходе

1. 4.7 Распределение ресурсов проекта

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

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

Распределение ресурсов проекта при создании системы «учета гематологических анализов» можно представить в виде перечня представленного на рисунке 4.4.

Рисунок 4.4 – Распределение ресурсов проекта для третьего прохода

1. 4.8 Оценка экономической эффективности проекта

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

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

• Выделить цели работы системы.

• Определить наборы показателей, характеризующих определенную цель.

• Определить уровень достижения показателя.

• Рассчитать степень достижения каждой цели по выдвинутым показателям.

• Определить весовые коэффициенты целей.

• Рассчитать общий показатель эффективности разрабатываемой информационной системы.

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

• Выделить цели работы системы.

• Определить наборы показателей, характеризующих определенную цель.

• Определить уровень достижения показателя.

• Рассчитать степень достижения каждой цели по выдвинутым показателям.

• Определить весовые коэффициенты целей.

• Рассчитать общий показатель эффективности разрабатываемой информационной системы.

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

, (4.1)

где u(g_i) – степень достижения цели, баллы;

– значение показателя, баллы;

K – количество показателей.

Весовой коэффициент вычисляется по формуле:

, (4.2)

где – весовой коэффициент, баллы;

V_i – оценка, баллы.

Расчет оценки ведется по формуле:

, (4.3)

где V_i – оценка, баллы;

R_min – минимальное значение ранга, баллы;

R_i – сумма рангов, баллы.

Для расчета суммы рангов воспользуемся формулой:

, (4.4)

где R_i – сумма рангов, баллы;

r_i – значение, выставленное экспертом, баллы;

n – количество экспертов.

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

Общий показатель эффективности рассчитывается как:

, (4.5)

где E_m – показатель эффективности, баллы;

w_i – весовой коэффициент, баллы;

u(g_i) – степень достижения цели, баллы.

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

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

Все это сведем в таблицу (таблица 1).

Таблица 1 – Цели, показатели и уровень достижения работы ИС

Для определения весовых коэффициентов был применен экспертный опрос десяти человек. Список опрошенных приведен в таблице 2.

Характеристики

Список файлов ВКР