metoda_2013

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

2.1.уровнем завершенности (отсутствия ошибок);

2.2.устойчивостью к дефектам;

2.3.восстанавливаемостью;

2.4.доступностью;

2.5.готовностью;

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

3.1.временной эффективностью;

3.2.используемостью ресурсов;

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

4.1.понятностью;

4.2.простотой использования;

4.3.изучаемостью;

4.4.привлекательностью;

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

5.1.удобством для анализа;

5.2.изменяемостью;

5.3.стабильностью;

5.4.тестируемостью;

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

6.1.адаптируемостью;

6.2.простотой установки (инсталляции);

6.3.сосуществованием (соответствием);

6.4.замещаемостью.

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

80

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

системная эффективность - применения программного продукта (ПП) по назначению;

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

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

удовлетворение требований и затрат пользователей в соответствии с целями применения ПС.

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

7 Сравнение технологий разработки ПО

ключевыми характеристиками для сравнения методологий следует считать, прежде всего:

отношение методологии к итеративной разработке и степень формальности в оформлении рабочих материалов и вообще в проведении разработки

Отличие итеративной разработки от каскадной («водопада»).

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

81

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

С какими методологиями имеет смысл сравнивать RUP? Конечно, с теми, которые наиболее распространены или про которые хотя бы можно прочитать.

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

Структурные методологии, в частности, основанные на подходах Эдварда Йордона, диаграммах «сущность-отношение» и потоках данных, были первыми активно продвигаемыми в нашей стране методологиями. Хотя они нередко связывались (по крайней мере, у слушателей презентаций) с реализующими их CASE средствами, а не рассматривались как самостоятельные методологии, тем не менее, они оказались достаточно известными, хотя нельзя сказать, что широко используемыми. Тем не менее, сравнение с ними имеет определенный смысл. По крайней мере, оно должно показать, насколько RUP отличается от них.

Наибольший интерес в настоящее время, видимо, представляет сравнение с гибкими (Agile) методологиями, которые в последние годы активно развиваются и приобрели определенную популярность. Так называется группа относительно новых методов, развиваемых участниками Agile Manifest — объединения в поддержку гибких методов. Общее число таких методологий достаточно велико. Но не все из них широко известны, и не по всем из них можно найти материалы на русском

82

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

языке. Поэтому для сравнения были выбраны Экстремальное программирование (XP), Crystal Clear и FDD (Feature Driven Development).

Кроме методологий, описывающих что, как и в каком порядке надо делать, есть еще один тип документов, регламентирующих разработку ПО. Это международные и государственные стандарты и другие разработки, направленные на определение требований к процессам разработки. Среди стандартов наибольший интерес для отечественного производителя представляют, конечно, ГОСТы 19-ой и 34-ой серий и ГОСТ 12207 Р ИСО МЭК. А среди других регламентирующих документов наиболее известна модель зрелости процессов разработки ПО

CMM, разработанная Software Engineering Institute.

Как получится… Увы, это самая сложная для описания категория. Ибо в нее

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

А что с использованием итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего, потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный. И требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 90% готово, проходит только до момента завершения первой итерации…

83

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

8. Уровень формализма. Количество итерации

В понятие формализма входит:

1)количество документов;

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

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

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

Факторы, влияющие на уровень формализации

Масштаб проекта. Чем больше людей участвуют, тем формально он, как правило, должен вестись;

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

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

Новизна проекта. Чем более новые для разработчиков

технологии вы используете, чем меньше вы знакомы с

84

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Требования заказчика. Они существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий;

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

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

Количество итерации

Показательным параметром, чем количество итерац. является длительность итерации.

Итерация — это не просто календарный срок, это опред. этап выполнения проекта:

на который составляется детальный план

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

85

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

или даже ежедневно, но итоговый релиз выпускается единственный раз в конце итерации)

по завершении которого могут меняться приоритеты дальнейшей разработки

по завершении которого проводится оценка и если надо вносятся соответ. изменения.

Итерации в процессе разработки позволяют:

контролировать и корректировать ход выполнения вашего проекта (необходимость продемонстрировать работающий релиз в конце итерации не позволяет программисту ограничиться типичным ответом о 90% -ной готовности класса или метода);

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

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

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

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

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

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

Средства управления изменениями и конфигурациями и средства автоматизации тестирования позволяют снизить не только

86

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

9. Требования. Анализ требований.

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

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

УРОВНИ ТРЕБОВАНИЙ

•Бизнес – требования;

•Требования пользователей;

•Функциональные требования;

•Системные требования.

ХАРАКТЕРИСТИКИ ТРЕБОВАНИЙ

•Полнота;

•Корректность;

•Осуществимость;

•Необходимость;

•Назначение приоритетов;

•Недвусмысленность;

•Проверяемость;

•Согласованность;

•Способность к модификации;

•Трассируемость.

ПРАВА КЛИЕНТОВ ПРИ ФОРМИРОВАНИИ ТРЕБОВАНИЙ

1)Иметь дело с аналитиком, который разговаривает на вашем языке;

2)Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создаётся система;

3)Потребовать, чтобы аналитик преобразовал требования , представленные вами устно, в письменную спецификацию требований к программному продукту;

4)Получить от аналитика подробный отчёт обо всех рабочих продуктах, созданных в процессе формулирования требований;

5)На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков;

6)Знать о вариантах и альтернативах требований и их реализации;

87

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

7)Описать характеристики, упрощающие работу с продуктом;

8)Изменить требования или разрешить использование имеющихся программных компонентов;

9)Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО;

10)Потребовать, чтобы система функциональностью и

качеством удовлетворяла требованиям заказчика .

ОБЯЗАННОСТИ КЛИЕНТОВ ПРИ ФОРМИРОВАНИИ ТРЕБОВАНИЙ

1)Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса;

2)Потратить столько времени, сколько необходимо, на объяснение требований;

3)Точно и корректно описать требования к системе;

4)Принимать своевременные решения;

5)Уважать определённую разработчиком оценку стоимости и возможность реализации ваших требований;

6)Определять приоритеты требований;

7)Просматривать документы с требованиями и оценивать прототипы;

8)Своевременно сообщать об изменениях требований;

9)Поддерживать принятый в организации порядок контроля

изменений;

РАЗРАБОТКА ТРЕБОВАНИЙ

1)Извлечение

Определите процесс формулирования требований;

Определите образ и границы проекта;

Определите классы пользователей;

Выделите из пользователей ярого сторонника продукта;

Создайте фокус – группу;

Определите назначение проекта;

Определите системные события и реакцию на них;

Проводите совместные семинары, упрощающие сбор требований;

Наблюдайте за пользователями на рабочих местах;

Изучите отчёты о проблемах;

Используйте требования многократно.

2)Анализ

Нарисуйте контекстную диаграмму;

Создайте прототипы;

Проанализируйте осуществимость;

88

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Расставьте приоритеты для требований;

Смоделируйте требования;

Создайте словарь терминов;

Распределите требования по подсистемам;

Воспользуйтесь технологией развёртывания функций качества.

3)Документирование

Используйте шаблон спецификации требований к ПО;

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

Задайте каждому требованию уникальный идентификатор;

Задокументируйте бизнес – правила;

Укажите атрибуты качества.

4)Проверка

Изучите документы с требованиями;

Протестируйте требования;

Определите критерии приемлемости.

После того, как разработка требований успешно завершена, мы переходим к анализу этих самых требований.

•Создание контекстной диаграммы;

•Создание пользовательского интерфейса и технических прототипов;

•Анализ осуществимости требований;

•Определение приоритетов требований;

•Моделирование требований;

•Создание словаря терминов;

•Распределение требований по подсистемам;

•Применение технологий развёртывания функций

качества.

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

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

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

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

89