Солонин. Управление проектами при разработке информационных систем
 Скачать 329.84 Kb.
|
|
3.3. Оценка трудоемкости создания ПО Для организации работ над проектом очень важно уметь оценить его тру- доемкость. Задачи, решаемые при оценке трудоемкости: 1) разработка бюджета проекта; 2) оценка ресурсов и степени риска (масштаб проекта, количество и ква- лификация разработчиков, возможность использования готовых решений, качество инструментальных средств и др.); 3) планирование проекта (распределение расходов финансов и других ресурсов по компонентам и этапам проекта); 4) анализ затрат на улучшение качества ПО (оценка целесообразности совершенствования средств и методов разработки). При определении трудоемкости проекта одинаково недопустимы как не- дооценка, так и переоценка стоимости, времени и других необходимых ресур- сов. Недооценка влечет за собой недостаточную численность проектной коман- ды, нарушение договорных сроков, низкое качество продукта. С другой сторо- ны, переоценка ведет к удорожанию проекта, т.к. при выделении ресурсов сверх необходимого они все равно будут потрачены. Основные методы оценки трудоемкости: 1. Статистическое моделирование. Метод основан на статистическом анализе данных о ранее выполненных проектах, при этом определяется зависи- мость трудоемкости проекта от какого-нибудь количественного показателя (на- пример, размера программного кода). Далее этот показатель оценивается для данного проекта, после чего прогнозируется трудоемкость. 2. Экспертные оценки. Проводится опрос нескольких экспертов, знаю- щих область применения разрабатываемого ПО. Каждый из них дает свою оценку трудоемкости. Потом все оценки сравниваются и обсуждаются до тех пор, пока не будет выработана единая оценка трудоемкости. 3. Оценка по аналогии. Метод основан на сравнении планируемого про- екта с предыдущими проектами, имеющими сходные характеристики. Могут вырабатываться три оценки: оптимистическая, пессимистическая и средняя. 27 Существуют и другие методы. В целом большинство моделей оценки трудоемкости использует пять основных параметров: 1) размер конечного продукта (для вновь создаваемых компонентов); 2) особенности организации процесса разработки (наличие формализо- ванных процедур, документирование, разделение функций и др.); 3) возможности персонала, участвующего в разработке ПО (квалифика- ция и стабильность коллектива и пр.); 4) среда разработки проекта, которая включает инструментальные сред- ства и адекватные методики ведения проекта; 5) требуемое качество продукта, особенно в плане надежности, произво- дительности и адаптируемости. Наиболее важный фактор из перечисленных – размер конечного продук- та. Основными единицами измерения размера ПО являются: 1) количество строк кода (LOC – Lines of Code); 2) количество функциональных точек (FP – Function Points). Количество строк кода – исторически самая первая и распространенная единица измерения. Ее главный недостаток – неспособность учесть особенно- сти языка и среды программирования. Например, как оценить в строках кода действия разработчика по созданию экранной формы методами визуального конструирования? Определение числа функциональных точек является методом оценки раз- мера ПО, не зависящим от технологии и языка программирования. В основу метода положена оценка функциональности разрабатываемой системы. Функ- циональность определяется на основе выявления и подсчета функциональных типов – групп взаимосвязанных данных, используемых системой, а также эле- ментарных процессов, связанных с вводом и выводом данных. К функциональным типам относятся (рис. 10): 1. Внутренний логический файл (ILF, Internal Logical File) – именован- ная совокупность данных, поддерживаемая изнутри приложения. 28 2. Внешний интерфейсный файл (EIF, External Interface File) – имено- ванная совокупность данных, передаваемых другому приложению или полу- чаемых из него. 3. Входной элемент приложения (EI, External Input) – элементарный процесс, связанный с обработкой входной информации – документа или экран- ной формы. 4. Выходной элемент приложения (EO, External Output) – элементарный процесс, связанный с обработкой выходной информации – отчета, документа или экранной формы. 5. Внешний запрос (EQ, External Query) – элементарный процесс, со- стоящий из комбинации запрос/ответ, не связанный с вычислением или обнов- лением ILF. Рис. 10. Функциональные типы Для каждого функционального типа определяется сложность (например, по количеству атрибутов объектов), затем подсчитывается количество функ- циональных точек по всем типам и вводится поправка на сложность системы. Количество функциональных точек UFP (Unadjusted Function Points) оп- ределяется в соответствии с табл. 4. вывод Пользо- ватель Бизнес- процес- сы Приложение ввод запрос внутренний файл внешний файл 29 Таблица 4 Функциональный тип Сложность Низкая Средняя Высокая ILF 7 10 15 EIF 5 7 10 EI 3 4 6 EO 4 5 7 EQ 3 4 6 В результате получается суммарная сложность элементов системы. Сложность самой системы оценивается поправочным коэффициентом VAF (Value Adjusted Factor), который зависит от 14 общих характеристик системы (GSC, General System Characteristics) и вычисляется по формуле: VAF = (0,65 + sum(GSC) ⋅ 0,01). К числу GSC относятся сложность коммуникации данных, наличие рас- пределенной обработки, величина производительности, эффективность работы конечных пользователей и т.д. Каждая характеристика оценивается в баллах от 0 до 5. Итоговое количество функциональных точек AFP (Adjusted Function Points) определяется формулой: AFP = UFP ⋅ VAF. AFP можно перевести в LOC с учетом среднестатистических данных табл. 5. 30 Таблица 5 Тип ПО Размер, FP LOC на одну FP Текстовые процессоры 3 500 125 Электронные таблицы 3 500 125 ПО баз данных 7 500 125 Крупные бизнес-приложения 10 000 105 Операционный системы 75 000 150 Системы масштаба предприятия 150 000 125 Крупные оборонные системы 250 000 100 Окончательные расчеты трудоемкости основываются на моделях COCO- MO (constructive cost model) и COCOMO II, применяемых для итерационных жизненных циклов ПО. Среднестатистическая производительность труда одно- го программиста составляет около 3 000 строк кода в год и существенно не ме- няется в течение многих лет. На реализацию проекта размером в одну функциональную точку требует- ся один день, и они всегда заканчиваются успешно. Таковы небольшие утилиты для временных нужд. Объем в 10 ФТ – это типичный объем небольших приложений и дополне- ний, вносимых в готовые системы. Здесь требуется до одного месяца работ, ко- торые также заканчиваются успешно. Объем в 100 ФТ близок к пределу возможностей программиста-одиночки. Проект доводится до конца в срок до 6 месяцев при успешности в 85 % случаев. Объем проекта в 1000 ФТ характерен для большинства сегодняшних коммерческих настольных и клиент-серверных приложений. Заметную долю общего объема работ начинает занимать документирование. Для реализации проекта нужна группа примерно из 10 человек, включая программистов, поста- новщиков, специалистов по тестированию, и около одного года работы. Прова- ливается 15 % проектов при работе группы и 65 % попыток программистов- 31 одиночек. В 20 % случаев не удается уложиться в сроки, в 25 % проектов отме- чается перерасход средств. Для проекта в 10 000 ФТ требуется около 100 разработчиков. Работы длятся от 1,5 до 5 лет, при этом запланированные сроки чаще всего не выдер- живаются. Важнейшую роль начинает играть технология тестирования. До 50 % проектов заканчиваются неудачей. Объем в 100 000 ФТ на сегодня близок к пределу возможностей создания информационных систем. Это объем современных ОС, таких как Microsoft Windows, и крупнейших военных систем. На их создание уходит 5–8 лет. Над проектом трудятся сотни разработчиков, иногда из разных стран. В закончен- ных системах остается много ошибок. До 65 % проектов завершаются неудач- но. Во всех успешных проектах используются системы управления конфигура- цией. Управление конфигурацией ПО предполагает применение администра- тивных и технических процедур на всем ЖЦ ПО для определения состояния компонентов ПО, управления модификациями (версиями) ПО, обеспечения полноты, совместимости и корректности компонентов ПО. 32 4. ТЕХНОЛОГИЯ RAD 4.1. Особенности технологии RAD Технология RAD (Rapid Application Development) является примером спиральной модели жизненного цикла ИС. Согласно этой модели, основные стадии и этапы жизненного цикла (ЖЦ) проходятся многократно, с постепен- ным усовершенствованием проекта и самой системы. Технология RAD обеспе- чивает быстрое построение ИС с привлечением пользователей к разработке. Она применима для систем средней сложности, обладающих элементами но- визны. Для данной технологии характерно перенесение основных объемов ра- бот с предпроектной стадии на стадию проектирования. Представители заказ- чика получают возможность контролировать процесс создания системы, опера- тивно влиять на состав и реализацию ее функций. Основные принципы RAD заключаются в следующих требованиях: 1. Использование прототипирования, позволяющего полнее выяснить потребности пользователей. 2. Вовлечение пользователей в процесс разработки системы. 3. Разработка приложений итерациями, многократное возвращение к бо- лее ранним этапам ЖЦ. 4. Необязательность полного завершения работ на одном этапе ЖЦ для начала работ на следующем этапе. При этом пропущенные работы можно вы- полнить впоследствии. Переход к следующему этапу осуществляется в соответ- ствии с планом, даже если не вся запланированная работа закончена. План со- ставляется на основе статистических данных, полученных в предыдущих про- ектах. 5. Средства управления проектами являются важным элементом техно- логии RAD. Они применяются для определения состава и объема работ, кон- троля над ходом работ и пр. 6. Высокая степень параллельности работ. 7. Повторное использование частей проекта. 33 8. Применение CASE-средств, обеспечивающих техническую целост- ность проекта на всех этапах проектирования; использование генераторов (мас- теров) для ускорения работ. 9. Применение средств управления конфигурациями, облегчающее вне- сение изменений в проект и сопровождение готовой системы. 10. Тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа. Жизненный цикл ИС в соответствии с RAD (рис. 11) состоит из много- кратно повторяемых стадий: 1) анализ требований к системе и постановка задачи; 2) проектирование прототипа; 3) доработка прототипа; 4) реализация и внедрение. Рис. 11. Технологическая сеть проектирования на основе RAD На рисунке обозначены: Д1 – техническое задание на разработку; Д2 – описание предметной области; Анализ и поста- новки задачи Д1 Д2 Д3 U1 G1 Разработка системы- прототипа Демонстрация работы прото- типа Доработка прототипа Разработка но- вой постановки задачи Разработка приложения Д4 G2 Д5 U1 Д6 U2 G3 34 Д3 – постановка задачи; U1 – универсум (т.е. множество) средств RAD; G1 – приложение-прототип; Д4 – результаты работы прототипа при демонстрации; Д5 – замечания и уточненные требования; G2 – доработанный прототип; Д6 – новая постановка задачи; U2 – универсум средств разработки приложений; G3 – готовое приложение. 4.2. Разновидности прототипов ИС Создание прототипов программного обеспечения (ПО) делает требования к системе более реальными, позволяя уточнить исходный вариант. Прототипы предоставляют пользователям экспериментальную модель новой системы, ак- тивизируя обсуждение требований. Обсуждение прототипов на ранних стадиях процесса разработки помогает заинтересованным в проекте лицам прийти к общему пониманию требований к системе, что уменьшает риск создания нека- чественного проекта. Прототип ПО – это частичная или возможная реализация предлагаемого нового продукта. Прототипы позволяют решать три основные задачи. 1. Прояснение и завершение процесса формулировки требований. Ис- пользуемый в качестве инструмента формулировки требований прототип пред- ставляет собой предварительную версию части системы, понимание которой вызывает затруднения. Оценка прототипа пользователями указывает на ошибки в формулировке требований, которые можно исправить до создания реального продукта без больших затрат. 2. Исследование альтернативных решений. Прототип, как инструмент конструирования, позволяет заинтересованным в проекте лицам исследовать различные варианты реализации будущей системы. Прототипы позволяют по- казать, насколько осуществимы требования. 35 3. Создание конечного продукта. Используемый в качестве инструмента разработки прототип – не что иное, как функциональная реализация первичных элементов системы, которую можно превратить в готовый продукт, осуществ- ляя последовательную цепочку небольших циклов разработки. Основная цель создания прототипа – устранение неясностей на ранних стадиях процесса разработки. Именно исходя из них следует решать, для каких частей системы необходим прототип и что нужно оценить, используя его. Про- тотип полезен для выявления и устранения двусмысленных и неполных утвер- ждений в требованиях. Различают следующие разновидности прототипов: 1) горизонтальные; 2) вертикальные; 3) одноразовые; 4) эволюционные. Горизонтальные прототипы Когда говорят о прототипе ПО, обычно имеют в виду горизонтальный прототип (horizontal prototype) предполагаемого интерфейса пользователя. Его также именуют поведенческим прототипом (behavioral prototype), или моде- лью. Горизонтальным прототип называется потому, что в нем не реализуются все слои архитектуры и нюансы системы, но воплощаются некоторые особен- ности интерфейса пользователя. Он позволяет пользователям исследовать по- ведение предполагаемой системы в тех или иных ситуациях для уточнения тре- бований, а также выяснить, смогут ли они с помощью системы, основанной на прототипе, выполнять свою работу. Горизонтальный прототип создает види- мость функциональности, не обеспечивая ее в действительности. Он показыва- ет внешний вид пользовательского интерфейса, позволяет осуществлять час- тичную навигацию, но не содержит никакой или почти никакой действительной функциональности. Горизонтальные прототипы демонстрируют функциональ- ные возможности, которые будут доступны пользователю, внешний вид поль- 36 зовательского интерфейса (цвета, планировку, графику, элементы управления) и структуру доступа к информации (структуру навигации). Перемещение между объектами интерфейса возможно, но вместо некото- рых элементов пользователь увидит краткое сообщение о том, что будет здесь находиться. Информация, появляющаяся в ответ на запрос к базе данных, мо- жет быть случайной или постоянной, а содержание отчетов – жестко закодиро- ванным. Лучше использовать реальные данные в образцах отчетов, диаграмм и таблиц – это увеличит достоверность прототипа как модели реальной системы. Горизонтальный прототип не выполняет почти никакой полезной работы, однако он очень полезен для того, чтобы пользователи могли решить, нет ли каких-либо упущений, неверных или ненужных функций. Некоторые прототи- пы выражают концепцию реализации конкретных вариантов использования, как ее видят разработчики. Оценивая прототип, пользователи могут указать на альтернативные возможности их реализации, пропущенные шаги взаимодейст- вия или дополнительные условия. Вертикальные прототипы Вертикальный прототип (vertical prototype), также называемый струк- турным прототипом (structural prototype), или проверкой концепции, воплоща- ет срез функциональности приложения от интерфейса пользователя до сервис- ных функций. Вертикальный прототип действует, как настоящая система, по- скольку затрагивает все уровни ее реализации. Разрабатывайте вертикальный прототип всякий раз, когда есть сомнения в осуществимости предполагаемого подхода к архитектуре системы или когда нужно оптимизировать алгоритмы, оценить предлагаемую схему базы данных или проверить критически важные временные требования. Чтобы получить значимые результаты, вертикальные прототипы создают, используя средства разработки в среде, аналогичной среде разработки. Вертикальные прототипы используются для исследования критиче- ски важных требований к интерфейсу и времени исполнения, а также для со- кращения рисков на стадии проектирования системы. 37 Одноразовые прототипы Прежде чем создавать прототип, необходимо принять решение, прекрати- те вы работать с ним после оценки или он станет частью выпускаемого продук- та. Создание одноразового прототипа (throwaway prototype), или исследова- тельского прототипа (exploratory prototype), необходимо, чтобы ответить на возникшие вопросы, разрешить возможные неясности и улучшить требования к ПО. Если после выполнения задачи работа с прототипом прекращается, его де- лают как можно более быстро и дешево. Чем больше усилий вложено в прото- тип, тем труднее будет участникам проекта отказаться от него. Создавая одноразовый прототип, разработчики пренебрегают большинст- вом известных им методов конструирования качественного ПО. В одноразовом прототипе предпочтение отдается быстроте реализации и модификации, а не устойчивости, надежности, производительности и долговременному удобству сопровождения. Поэтому нужно следить, чтобы код одноразового прототипа не попал в окончательный продукт. В противном случае пользователи и персонал технического обслуживания будут страдать от последствий этого в течение все- го срока эксплуатации продукта. Эволюционные прототипы В отличие от одноразового прототипа эволюционный прототип (evolutionary prototype) представляет собой прочный архитектурный «фунда- мент» для постепенного создания окончательного продукта – по мере проясне- ния требований. Эволюционное прототипирование – один из компонентов мо- дели спирального цикла разработки ПО и некоторых процессов разработки объектно-ориентированного ПО. В отличие от одноразовых прототипов, созда- ваемых быстро и начерно, для построения эволюционного прототипа необхо- димо с самого начала использовать качественный код. Поэтому на конструирование эволюционного прототипа требуется боль- ше времени, чем на одноразовый прототип, моделирующий те же свойства сис- темы. Эволюционный прототип следует создавать в расчете на легкий рост и частое расширение, поэтому разработчики должны уделять большое внимание 38 архитектуре и принципам проектирования. При создании такого прототипа ни в коем случае не стоит экономить на качестве. Многие черты технологии RAD можно обнаружить в системе разработки приложений MSF (Microsoft Solutions Framework) корпорации Microsoft [5]. Технология RAD близка к подходу XP (Extreme Programming), предна- значенному для использования небольшими высокопрофессиональными ко- мандами разработчиков. Разработка ведется небольшими трехнедельными ите- рациями, в течение которых уточняются и реализуются требования к системе. Для оценки проектов с точки зрения применимости RAD и XP применя- ются два показателя – критичность и масштаб. Критичность определяется по- следствиями, вызываемыми дефектами ПО, и может иметь один из четырех уровней: 1) C – дефекты вызывают потерю удобства; 2) D – дефекты вызывают потерю возместимых ресурсов; 3) E – дефекты вызывают потерю невозместимых ресурсов; 4) L – дефекты могут создавать угрозу для человеческой жизни. Масштаб определяется количеством разработчиков, участвующих в проекте: 1) от 1 до 6 человек – малый масштаб; 2) от 6 до 20 человек – средний масштаб; 3) свыше 20 человек – большой масштаб. По оценке специалиста по быстрой разработке ПО А. Коберна, техноло- гия XP применима в проектах малого и среднего масштаба с низкой критично- стью (C или D). 39 ЗАКЛЮЧЕНИЕ В настоящем пособии рассматривается применение проектного управле- ния к процессу разработки ИС. Однако сфера приложений управления проек- тами гораздо шире. Оно используется при организации строительства уникаль- ных сооружений, в кораблестроении, при реорганизации предприятий, при про- ведении крупных консалтинговых и маркетинговых мероприятий и во многих других ситуациях. Ныне подобные виды деятельности уже немыслимы без про- ектного подхода и использования систем управления проектами, так как, начи- ная с определенного уровня сложности, проекты уже не поддаются традицион- ному управлению. Можно не сомневаться, что в будущем роль управления про- ектами и специализированных программных средств для этого станет еще зна- чительнее. 40 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Гультяев, А.К. Microsoft Office Project 2003 / А.К. Гультяев. – СПб. : Корона-принт, 2004. 2. Пайрон, Т. Использование Microsoft Project 2002 / Т. Пайрон. – М. : Вильямс, 2003. 3. Мармел, Э. Microsoft Project 2002. Библия пользователя / Э. Мармел. – М. : Вильямс, 2003. 4. Богданов, В. Управление проектами в Microsoft Project 2007 / В. Богданов. – СПб. : Питер, 2008. 5. Уилсон, С. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD / С. Уилсон, Б. Мэйплс, Т. Лэндгрейв. – М. : Русская редакция, 2002. Учебное электронное текстовое издание Солонин Евгений Борисович УПРАВЛЕНИЕ ПРОЕКТАМИ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ Редактор А.В. Поротникова Компьютерная верстка Е.Б. Солонина Рекомендовано Методическим советом Разрешен к публикации 24.12.10. Электронный формат – pdf Объем 2,05 уч.-изд. л. УрФУ 620002, Екатеринбург, ул. Мира, 19 Информационный портал УрФУ http://www.ustu.ru |