Методика развертывания приложения

Чтобы приложение оценили по достоинству, оно прежде всего должно оказаться на компьютерах своей целевой аудитории. Microsoft Visual Studio 2005 поддерживает самые разные способы развертывания проектов: от простейшего с использованием команды XCOPY до самого сложного и гибкого с применением программы Microsoft Windows Installer.

Простые приложения.NET Framework позволяет развертывать, просто копируя их каталоги на клиентские компьютеры. Для развертывания более сложных приложений в Visual Studio 2005 предусмотрена технология Windows Installer, позволяющая создавать проекты установочных программ с широкими возможностями настройки [24,26,34].

Но для того чтобы приложение работало на компьютере клиента должна быть установлена требуемая версия общеязыковой среды исполнения Frameworks, в данном случае под данную информационную систему необходимо установить Microsoft.NET Framework SDK v2.0. В данном наборе библиотек классов есть все классы которые потребуются разработанной информационной системе. Для развертывания приложения были использованы инструменты с использованием команды XCOPY и установки на компьютер клиентам Microsoft.NET Framework SDK v2.0 [26].

Выводы к разделу

Во втором разделе рассмотрены архитектурное проектирование информационной системы, определяется пользовательский интерфейс системы. Проводится проектирование баз данных. Выбирается база данных которая будет удовлетворять требованиям разрабатываемой информационной системы. Определяются таблицы и тип хранимых данных в них. Определяется структура базы данных. Выбирается платформа для создания информационной системы. Для разрабатываемой информационной системы была выбрана платформа Microsoft Visual Studio 2005. В качестве языка реализации приложения выбран C#.

В данном разделе дипломного проекта рассмотрены реализация информационной системы. Описаны способы нахождения ошибок в приложении, так же описаны методики тестирования, которые использовались при тестировании приложения. Описана методика развертывания данной информационной системы, с указанием версии общеязыковой среды исполнения Frameworks необходимой для работы данной системы. Рассмотрена методика взаимодействия информационной системы с СУБД MS SQL Server 2005.

3 ЭКОНОМИЧЕСКИЙ РАСЧЁТ ПРОЕКТА

 

3.1 Оценка затрат на разработку ПО

 

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

 

К=К₁+К₂₊К₃, (3.1)

 

где К₁ - затраты на оборудование, тг;

К₂ - затраты на лицензионные программные продукты, тг.;

К₃ - затраты на создание программного продукта, тг.

Поскольку оборудование для создания ПП уже куплено, то принимаем затраты на оборудование равными нулю (К₁ = 0).

Затраты (условные) на лицензионные программные продукты для реализации ПП К₂ приведены в таблице 3.1.

 

Таблица 3.1 – Затраты на лицензионные программные продукты

Лицензионный программный продукт	Стоимость, тг.
Borland Delphi версии 5.0 Windows 98	2 950

Затраты на лицензионные программные продукты составят

 

К₂ =2 950+300 = 3250 тг.

 

Затраты на создание ПП К₃ считаем по формуле

 

К₃ = З₁ + З₂ + З₃, (3.2)

 

где З₁ - затраты труда программистов-разработчиков, тг.;

З₂ - затраты компьютерного времени, тг.;

З₃ - косвенные (накладные) расходы, тг

Рассчитаем затраты труда программистов-разработчиков по формуле

 

, (3.3)

 

где – количество разработчиков k-й профессии, чел;

– часовая зарплата разработчика k-й профессии, грн.;

– трудоёмкость разработки для k-го разработчика (количество затраченного разработчиком времени), ч.;

K_зар – коэффициент начислений на фонд заработной платы, доли.

Принимаем, что данный ПП разрабатывал один человек ( =1).

Часовая зарплата разработчика определяется по формуле

 

, (3.4)

 

где М_к – месячная зарплата к-го разработчика, тг.;

- месячный фонд времени его работы, ч.

Принимаем для разработчика ПП: М_к =300 тг; =170 ч.

Из формулы (3.4) получаем часовую зарплату разработчика

 

=300/170 =1,76 тг.

 

Трудоёмкость разработки включает время выполнения работ, представленных в таблице 3.2.

 

Таблица 3.2 – Время выполнения работ

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

 

Расчет трудоемкости разработки для каждого разработчика осуществляется по формуле

 

T_k = t_1k + t_2k + t_3k + t_4k + t_5k, (3.5)

 

где t_1k, t_2k, t_3k, t_4k, t_5k - время, затраченное на каждом этапе разработки k-м разработчиком, ч.

Принимаем:

 

t_1k = 15 ч;

t_2k = 90 ч;

t_3k = 80 ч;

t_4k = 120 ч;

t_5k = 80 ч.

 

По формуле (3.5) получили

 

= 15+90+80+120+80= 385 ч.

 

Принимаем коэффициент начислений на фонд заработной платы K_зар =1,475.

Подставляя в формулу (3.3), получим

З₁ = 1 × 1,76 × 385 × 1,475 = 999,46 тг.

 

Рассчитаем затраты компьютерного времени по формуле

 

З₂ = С_к ·F_0, (3.6)

 

где С_к – себестоимость компьютерного часа, тг.;

F₀ – затраты компьютерного времени на разработку программы, ч.

Себестоимость компьютерного часа исчисляется по формуле

 

С_К= С_А + С_Э + С_ТО , (3.7)

 

где С_А – амортизационные отчисления, тг.;

С_Э – энергозатраты, тг.;

С_ТО – затраты на техобслуживание, тг.

Амортизационные отчисления составят

 

С_А=С_i· N_Аi / F_годi, (3.8)

 

где С_i – балансовая стоимость i-го оборудования, которое использовалось для создания ПП (стоимость ПК, принтера и плоттера), тг.;

N_А – годовая норма амортизации i-го оборудования, доли;

F_год – годовой фонд времени работы i-го оборудования, час.

Стоимость каждого отдельного оборудования приведена в таблице 3.3.

 

Таблица 3.3 – Стоимость оборудования.

Наименование оборудования и его конфигурация	Балансовая стоимость, тг.
PC Amd Duron 950 RAM 128/HDD 30Gb/ CD-RW-48x
Итого

 

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

Принимаем норму амортизации N_А = 0,25.

Принимаем годовой фонд времени работы оборудования F_год = 2036 ч.

Из (4.8) получим: С_А =2700 × 0,25 / 2 036 =0,33 тг.

Энергозатраты составят

 

С_Э= Р_Э × С_кВт, (3.9)

 

где Р_Э - расход электроэнергии, потребляемой компьютером;

С_кВт - стоимость 1 кВт/ч электроэнергии, тг.

Принимаем: Р_Э = 0,4 кВт/ч; С_кВт = 0,15 тг.

Из (4.9) получим: С_Э=0,4 × 0,15 = 0,06 тг.

Затраты на техническое обслуживание рассчитываются по формуле

 

С_ТО= r_ТО·× l, (3.10)

 

где r_ТО – часовая зарплата работника обслуживающего оборудование, тг.;

l - периодичность обслуживания.

Принимаем: r_ТО:=250/170 =1,5 тг.

Периодичность обслуживания

 

l= N_то / F^мес, (3.11)

 

где N_то – количество обслуживаний оборудования в месяц;

F^мес – месячный фонд времени работы оборудования, ч.

 

Принимаем: N_то =1; F^мес =2036/12 = 170 ч.

Из (4.11) получим: l=1/170 = 0,006.

Из (4.10) получим: С_ТО=0,006 × 1,5 = 0,009 тг.

Из (4.7) получим: С_К= 0,33+0,06+0,009 = 0,399 тг.

Из (4.6) получим: З₂ = 0,399 × 200 = 79,8 тг.

Косвенные расходы определяются по формуле

 

З₃ = С₁+ С₂+ С_3, (3.12)

 

где С₁ – затраты на содержание помещений, тг;

С₂ – расходы на освещение,отопление охрану и уборку помещений,тг;

C₃ – прочие расходы (стоимость различных материалов, используемых при разработке проекта,услуги сторонних организаций и т.п.).

Стоимость помещения площадью 20 м² составит: 20×100= 2000 тг. (100 грн. – цена 1 м²).

Затраты на содержание помещений С₁ составляют 2 - 2,5 % от стоимости здания

 

С₁ = 2000 × 2% = 40 тг.

 

Расходы на освещение,отопление охрану и уборку помещений С₂ составляют 0,2 ‑ 0,5 % от стоимости здания

 

С₂ =2000 × 0,3% = 6 тг.

 

Прочие расходы (стоимость различных материалов,используемых при разработке проекта,услуги сторонних организаций) C₃ составляют 100 – 120 % от стоимости вычислительной техники

 

C₃ = 2700 × 100%= 2700 тг.

Из формулы (3.12) получим

 

З₃ = 40 + 6 + 2700 = 2 746 тг.

 

Из формулы (3.2) затраты на создание ПП

 

К₃= 999,46 + 79,8 + 2 746 = 3 825 тг.

 

Из формулы (3.1) капитальные затраты на выполнение и реализацию ПП составят

 

К_Затр. =0 + 3250+3 825 = 7 075 тг.

 

Расчет годового экономического эффекта

 

В случае создания одного ПП экономический эффект определяется по формуле

 

Э_ф = Э_г - Е_н × K_Затр, (3.19)

 

где Э_г – годовая экономия текущих затрат, тг.;

К – капитальные затраты на создание программного продукта, грн;

Е_н – нормативный коэффициент экономической эффективности капиталовложений, доли. (Е_н = 0,42).

Из формулы (3.19) получим экономический эффект

 

Э_ф = 6793 – 0,42 × 7075 =3821,5 тг.

 

 

3.2 Расчет затрат на разработку проекта

 

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

 

. (3.20)

 

Согласно формулы (3.20) получаем

 

E_Р = 6793 /7075 = 0,95.

 

Разработанная программа является экономически эффективной, поскольку выполняется неравенство:

 

(0,95 >0,42).

 

Срок окупаемости капиталовложений – период времени, в течение которого окупаются затраты на ПП

 

. (3.21)

 

Из формулы (3.21) получим:

 

T_Р = 1 / 0,95 = 1,1 г.

 

При эффективном использовании капиталовложений расчётный срок окупаемости должен быть меньше нормативного:

 

(1,1<2,4 года).

 

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

годовая экономия текущих затрат при внедрении подсистемы проектирования составит 6793 тг.;

экономическая эффективность составляет 3821,5 тг.;

cрок окупаемости капиталовложений в ПП составит порядка 20 месяцев (1,7 года).

Для наглядности все показатели сведены в таблицу (см. табл. 3.4).

 

Таблица 3.4 - Основные экономические показатели

Показатель	Обозначение	Ед. изм.	Значение
Капитальные затраты на создание программного изделия	К	тг.
Годовая экономия текущих затрат	Эг	тг.	4178,5
Годовой экономический эффект	Эф	тг.	3821,5
Коэффициент экономической эффективности	Ер	-	0,95
Срок окупаемости капитальных вложений	Тр	год	1,1

 

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

 

(3.22)

 

где Тручн.,Тавт. - трудоёмкости операций в ручном и автоматизированном вариантах;

Фд – годовой действительный фонд времени.

 

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

 

(3.23)

 

где Зпр – средняя заработная плата рабочих;

0,9 – коэффициент, учитывающий выплаты из фонда материальных поощрений.

 

тг.

 

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

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

Сравнительный анализ показателей при выполнения работ в ручном и автоматизированном вариантах приведен в таблице 3.5.

 

Таблица 3.5 – Анализ показателей при выполнении работ в ручном и автоматизированном вариантах

Показатели	Единицы измерения	Варианты
ручной	автома-тизированный
Себестоимость проектирования, час	тг.	9,96	3,94
Количество персонала	чел.
Заработная плата персонала	тг..
Косвенные расходы	тг	5,12

 

4 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ И ОХРАНА ТРУДА

 

4.1 Эргономичность программного продукта

 

 

Основным стандартом качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEC 9126. Он определяет номенклатуру, атрибуты и метрики требований качества программного обеспечения. Относительно недавно этот стандарт стал одним из определяющих факторов при моделировании качества программного обеспечения и остаётся им до сих пор.

В дополнение к нему выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).

Общий подход к моделированию качества программного обеспечения заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении «сверху вниз» разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEC 9126 является типичным примером такого подхода.

В рамках модели SQuaRE выделяются следующие шесть основных характеристик качества.

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

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

1. Надежность (устойчивость, завершенность, восстанавливаемость). Показатели надежности характеризуют поведение системы при выходе за пределы штатных значений параметров функционирования по причине сбоя в окружении либо в самой системе. При оценке атрибутов надежности применяются методы теории вероятностей и математической статистики. Требования к надежности особенно важны при разработке критических систем обеспечения безопасности жизнедеятельности (dependable systems). Хотя использование формальных методов способствует снижению количества внутренних ошибок (т.е. росту завершенности системы), однако обеспечение надежности в целом требует специальных подходов, учитывающих специфику различных типов систем.

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

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

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

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

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

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

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

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

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

Переносимость программного обеспечения (мобильность) – способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем

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

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

Жизненный цикл – совокупность стадий и этапов, которые проходит информационная система в своём развитии от момента принятия решения о создании системы до момента прекращения её функционирования [35, 39].

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

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

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

Таблицы с вопросами, ответы на которые будут определять оптимальную модель жизненного цикла для информационной системы приведено в ПРИЛОЖЕНИИ Г.

В таблице 4.1 представлены итоговые результаты выбора модели жизненного цикла.

Таблица 4.1 – Определение оптимальной модели жизненного цикла в баллах.

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования
Участники команды разработчиков
Коллектив пользователей
Типы проектов и рисков
Итого

 

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

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

Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений — RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем.

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

В последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

¾ небольшую команду программистов (от 2 до 10 человек);

¾ короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

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

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

¾ фаза построения;

¾ фаза внедрения.

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

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

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

¾ общая информационная модель системы;

¾ функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

¾ точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

¾ построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

¾ определяется необходимость распределения данных;

¾ производится анализ использования данных;

¾ производится физическое проектирование базы данных;

¾ определяются требования к аппаратным ресурсам;

¾ определяются способы увеличения производительности;

¾ завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

 

Таблица 4.2 – определение размера приложения по методологии RAD

< 1000 функциональных элементов	один человек
1000-4000 функциональных элементов	одна команда разработчиков
> 4000 функциональных элементов	4000 функциональных элементов на одну команду разработчиков

 

В качестве итога перечислим основные принципы методологии RAD:

¾ разработка приложений итерациями;

¾ необязательность полного завершения работ на каждом из этапов жизненного цикла;

¾ обязательное вовлечение пользователей в процесс разработки ИС;

¾ необходимое применение CASE-средств, обеспечивающих целостность проекта;

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