ОСНОВЫ ИНЖЕНЕРИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Конспект лекций
для студентов специальности 5В070200 – Автоматизация и управление
Алматы 2015
АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ
Кафедра инженерной кибернетики
Некоммерческое акционерное общество
СОСТАВИТЕЛЬ: Н.В.Сябина. Основы инженерии программного обеспечения. Конспект лекций для студентов специальности 5В070200 – Автоматизация и управление. – Алматы: АУЭС, 2015. – 78 с.
Настоящий конспект лекций содержит материалы для ознакомления студентов 4 курса с основными понятиями инженерии программного обеспечения и принципами проектирования программных продуктов.
Конспект содержит теоретический материал по 15 темам. В приложения включены необходимые иллюстративные и справочные материалы.
Конспект лекций предназначен для студентов всех форм обучения специальности 5В070200 – Автоматизация и управление.
Ил.25, табл.4, библиогр. – 18 назв.
Рецензент: ст. преп., канд. техн. наук Мусапирова Г.Д.
Печатается по плану издания некоммерческого акционерного общества
«Алматинский университет энергетики и связи» на 2014 г.
© НАО «Алматинский университет энергетики и связи», 2015 г.
Содержание
Лекция №1. Введение в программную инженерию ... 4
Лекция №2. Ресурсы. Управление рисками проекта ... 9
Лекция №3. Модели жизненного цикла программного обеспечения ... 12
Лекция №4. Качество программного обеспечения ... 17
Лекция №5. Парадигмы программирования ... 22
Лекция №6. Программирование без ошибок ... 28
Лекция №7. Основные подходы к разработке программного обеспечения. Требования и исходные данные к разработке ... 30
Лекция №8. Принятие принципиальных решений ... 34
Лекция №9. Анализ требований и определение спецификаций ... 37
Лекция №10. Особенности проектирования программного обеспечения при структурном подходе ... 41
Лекция №11. Особенности проектирования программного обеспечения при объектном подходе... 43
Лекция №12. Пользовательские интерфейсы ... 47
Лекция №13. Типы пользовательских интерфейсов ... 50
Лекция №14. Тестирование и отладка программных продуктов ... 54
Лекция №15. Составление программной документации ... 59
Приложение А ... 61
Приложение Б ... 75
Список литературы ... 78
Лекция №1. Введение в программную инженерию
Цель: получить представление о программной инженерии, о методах управления программными проектами, о классификации моделей программного обеспечения по «весу», а также о принципах организации эффективной команды разработчиков.
Программная инженерия - это применение определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного обеспечения (ПО) [1]. Термин software (программное обеспечение) ввел в 1958 году всемирно известный статистик Джон Тьюкей. Термин software engineering (программная инженерия). Он впервые появился в названии конференции НАТО, состоявшейся в Германии в 1968 году и посвященной так называемому кризису программного обеспечения. С 1990-го по 1995 год велась работа над международным стандартом, который должен был дать единое представление о процессах разработки программного обеспечения. В результате был выпущен стандарт ISO/IEC 12207, а в 2004 году в отрасли был создан основополагающий труд
«Руководство к своду знаний по программной инженерии» (SWEBOK), в котором были собраны основные теоретические и практические знания, накопленные в этой отрасли.
Программирование — процесс отображения определенного множества целей на множество машинных команд и данных, интерпретация которых на компьютере или вычислительном комплексе обеспечивает достижение поставленных целей [1]. Цели могут быть любые: воспроизведение звука в динамике компьютера, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены.
Профессиональное программирование – это деятельность, направленная на получение доходов при помощи программирования. Принципиальным отличием от просто программирования является то, что имеется или, по крайней мере, предполагается некоторый потребитель, который готов платить за использование программного продукта. Отсюда следует важный вывод о том, что профессиональное производство программ - это всегда коллективная деятельность, в которой участвуют, минимум, два человека: программист и потребитель.
За 50 лет развития программной инженерии накопилось большое количество моделей разработки программного обеспечения. Можно провести аналогию между историей развития методов, применяемых в системах автоматического управления, и эволюцией подходов к управлению программными проектами.
«Как получится» - разомкнутая система управления. Предполагает полное доверие техническим лидерам, представители бизнеса практически не
участвует в проекте. Планирование, если оно и есть, то неформальное и словесное. Время и бюджет, как правило, не контролируются. Аналогия:
баллистический полет без обратной связи. Можно, но недалеко и неточно.
«Водопад», или каскадная модель, - жесткое управление с обратной связью. Расчет опорной траектории (план проекта), измерение отклонений, коррекция и возврат на опорную траекторию. Лучше, но не эффективно.
«Гибкое управление». Расчет опорной траектории, измерение отклонений, расчет новой попадающей траектории и коррекция для выхода на нее. «Планы — ничто, планирование — все» (Эйзенхауэр, Дуайт Дэвид).
«Метод частых поставок» - самонаведение. Расчет опорной траектории, измерение отклонений, уточнение цели, расчет новой попадающей траектории и коррекция для выхода на нее.
Классические методы управления перестают работать в случаях, когда структура и свойства управляемого объекта нам не известны и/или изменяются со временем. Эти подходы не помогут, если текущие свойства объекта не позволяют ему двигаться с требуемыми характеристиками.
Например, летательный аппарат не может развить требуемое ускорение или разрушается при недопустимой перегрузке. Аналогично, если рабочая группа проекта не может обеспечить требуемую эффективность и поэтому постоянно работает в режиме аврала, то это приводит не к росту производительности, а к уходу профессионалов из проекта.
Когда структура и свойства управляемого объекта нам не известны, необходимо использовать адаптивное управление, которое, дополнительно к прямым управляющим воздействиям, направлено на изучение и изменение свойств управляемого объекта. Продолжая аналогию с управлением летательными аппаратами, это расчет опорной траектории, измерение отклонений, уточнение цели, уточнение объекта управления, адаптация (необходимое изменение) объекта управления, расчет новой попадающей траектории и коррекция для выхода на нее. Для того чтобы понять структуру и свойства объекта и воздействовать на него с целью их приведения к желаемому состоянию, в проекте должен быть дополнительный контур обратной связи — контур адаптации.
Известно, что производительность разных программистов может отличаться в десятки раз. Поэтому, помимо чисто управленческих задач, руководитель, если он стремится получить наивысшую производительность рабочей группы, должен направлять постоянные усилия на изучение и изменение объекта управления: людей и их взаимодействия.
Модели (методологии) процессов разработки программного обеспечения принято классифицировать по «весу» - количеству формализованных процессов и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше
«вес» модели. Наиболее распространенные современные модели процесса разработки ПО [1] представлены на рисунке А.1.
ГОСТ 19 «Единая система программной документации» и ГОСТ 34
«Стандарты на разработку и сопровождение автоматизированных систем»
ориентированы на последовательный подход к разработке ПО. Разработка в соответствии с этими стандартами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Строгое следование им не только приводит к водопадному подходу, но и требует очень высокой степени формализованности разработки.
В середине 80-х годов минувшего столетия по заказу Министерства обороны США Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения, которая определяет пять уровней зрелости процесса разработки ПО: начальный, повторяемый, определенный, управляемый, оптимизируемый. Документация с полным описанием SW- CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.
Унифицированный процесс (Rational Unified Process, RUP) был разработан компанией «Rational Software» в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. В результате общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.
Microsoft Solutions Framework (MSF) — это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки.
Особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process (PSP/TSP). PSP определяет требования к компетенциям разработчика. TSP делает ставку на самоуправляемые команды численностью 3-20 разработчиков.
Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.
Основная идея всех гибких моделей заключается в том, что применяемый в разработке ПО процесс должен быть адаптивным. Они декларируют в первую очередь ориентированность на людей и их взаимодействие, а не на процессы и средства. По сути, гибкие методологии это не методологии, а набор практик, которые могут позволить добиваться
эффективной разработки ПО, основываясь на принципах итеративности, инкрементальности, самоуправляемости команды и адаптивности процесса.
Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО», проанализировал разные программные проекты, которые выполнялись на разных моделях от легких до тяжелых, и не обнаружил зависимости между успехом или провалом проектов и моделями процесса разработки. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, т.е. не существует единственного правильного процесса разработки ПО. В каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с
«Законом четырех П» (рисунок А.2). Совершенно разные процессы должны применяться в проектах, имеющих различное назначение, а также в которых участвует разное количество человек с разным опытом ведения разработки.
«Закон четырех П» гласит: процесс должен определяться в зависимости от проекта, продукта и персонала. Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны подстраиваться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.
Задача программного проекта – это достижение конкретной бизнес- цели, при соблюдении ограничений «железного треугольника» (рисунок А.3).
Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие. Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание.
Согласно текущей редакции стандарта PMBOK, проект считается успешным, если удовлетворены все требования заказчика и участников проекта. Поэтому проект разработки оценивают по четырем факторам:
выполнение в соответствие со спецификациями;
выполнение в срок;
выполнение в пределах бюджета;
удовлетворенность каждого участника команды.
Эффективность - это отношение полученного результата к произведенным затратам. Нельзя рассматривать эффективность, исходя только из результативности: чем больше производишь, чем больше делаешь, тем выше твоя эффективность. Затраты не следует путать с инвестициями.
Цели проекта должны отвечать на вопрос, зачем данный проект нужен.
Цели проекта должны описывать бизнес-потребности и задачи, которые решаются в результате исполнения проекта. Целями проекта могут быть:
изменения в компании, реализация стратегических планов, выполнение контрактов, разрешение специфических проблем. Цели должны быть значимыми, конкретными, измеримыми и, наконец, реальными. Четкое определение бизнес-целей важно, поскольку существенно влияет на все
процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным.
Результаты проекта отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять:
какие именно бизнес-выгоды получит заказчик в результате проекта;
какой конкретно продукт или услуга будут произведены по окончании проекта;
краткое описание и при необходимости ключевые свойства и/или характеристики продукта/услуги.
Следует помнить, что результаты должны быть измеримыми, т.е. при оценке результатов проекта должна иметься возможность сделать заключение достигнуты оговоренные в концепции результаты или нет.
Наконец, немаловажным моментом при разработке успешного проекта является эффективность команды разработчиков. Рабочая группа прежде, чем она станет эффективной командой, должна пройти четыре обязательных последовательных стадии:
а) формирование - характеризуется избытком энтузиазма, связанного с новизной. Люди должны преодолеть внутренние противоречия, переболеть конфликтами прежде, чем сформируется действительно спаянный коллектив.
На этом этапе многое зависит от руководителя. Он должен четко поставить цели членам команды, верно определить роль каждого в проекте;
б) разногласия и конфликты - самый сложный и опасный период.
Мотивация новизны уже исчезла, а сильные и глубокие стимулы у команды еще не появились. Неизбежные сложности или неудачи порождают конфликты и «поиск виновных». Участники команды методом проб и ошибок вырабатывают наиболее эффективные процессы взаимодействия.
Руководителю на этом этапе важно обеспечить открытую коммуникацию в команде. Конфликты не следует прятать, а споры необходимо разрешать спокойно, терпеливо и тщательно;
в) становление - в команде растет доверие, люди начинают замечать в коллегах не только проблемные, но и сильные стороны. Закрепляются и оттачиваются наиболее эффективные процессы взаимодействия. На смену битве амбиций приходит продуктивное сотрудничество. Четче становится разделение труда, исчезает дублирование функций. Руководитель перестает находиться в состоянии постоянного аврала, работа по построению команды на этом этапе - скрупулезный труд по отработке общих норм и правил;
г) отдача - команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Все стремятся придерживаться выработанных общих процессов. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов. Задача менеджера на этом этапе - поддерживать требуемый уровень мотивации, искать новые пути и открывать новые возможности. Четыре стадии развития команды должны циклически повторяться, чтобы обеспечить непрерывный рост производительности.
Лекция №2. Ресурсы. Управление рисками проекта
Цель: получить представление о ресурсах, сроках разработки, рисках проекта и возможностях их идентификации.
Чтобы понять, сколько будет стоить реализация программного проекта, требуется определить и оценить ресурсы, необходимые для его выполнения, а именно: человеческие ресурсы и требования к квалификации персонала;
оборудование, услуги, расходные материалы, лицензии на ПО, критические компьютерные ресурсы; бюджет проекта - план расходов и предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта.
Специфика программного проекта заключается в том, что человеческие ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами [1]. Необходимо помнить, что, помимо непосредственно программирования в проекте разработки ПО, есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Пример распределения трудозатрат по основным производственным процессам при современном процессе разработки ПО показан на рисунке А.4.
Немаловажной составляющей проекта является оценка сроков его разработки. Ф. Брукс в работе [2] приводит эмпирическую формулу оценки срока проекта по его трудоемкости, выведенную Б.Боэмом на основе анализа результатов 63 проектов разработки ПО в аэрокосмической области.
Графическое описание закона Боэма показано на рисунке А.5. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м.
(человеко-месяцев), можно утверждать, что:
существует оптимальное время выполнения графика для первой поставки: T = 2,5(N ч.*м.)1/3, то есть оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в человеко-месяцах. Следствием является кривая, дающая оптимальную численность проектной команды (рисунок А.5);
кривая стоимости медленно растет, если запланированный график длиннее оптимального, т.е. работа занимает все отведенное для нее время;
кривая стоимости резко растет, если запланированный график короче оптимального, т.е. практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне зависимости от количества занятых в нем.
Для серьезного программного проекта недостаточно определить только срок его завершения. Необходимо еще определить его этапы - контрольные точки, в которых будет происходить переоценка проекта на основе реально достигнутых показателей. Контрольная точка - важный момент или событие в расписании проекта, отмечающее достижение заданного результата и/или
начало/завершение определенного объема работы. Каждая контрольная точка характеризуется датой и объективными критериями ее достижения.
Риск - это проблема, которая еще не возникла, а проблема — это риск, который материализовался. Характеристики риска [1]:
а) причина или источник – явление (обстоятельство), обусловливающее наступление риска;
б) симптомы риска - указание на то, что событие риска произошло или вот-вот произойдет;
в) последствия риска - проблема или возможность, которая может реализоваться в проекте в результате произошедшего риска;
г) влияние риска - влияние реализовавшегося риска на возможность достижения целей проекта.
Риск - это всегда вероятность и последствия. Пример характеристик риска приведен на рисунке А.6. Выделяют две категории рисков:
а) «известные неизвестные» - это те риски, которые можно идентифицировать и подвергнуть анализу, кроме того, в отношении таких рисков можно спланировать ответные действия;
б) «неизвестные неизвестные» - риски, которые невозможно идентифицировать и, следовательно, спланировать ответные действия.
Управление рисками - это определенная деятельность, которая выполняется в проекте от его начала до завершения. Как и любая другая работа, в проекте управление рисками требует времени и затрат ресурсов.
Поэтому эта работа обязательно должна планироваться. Планирование управления рисками - это процесс определения подходов и планирования операций по управлению рисками проекта. Тщательное и подробное планирование управления рисками позволяет: выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками, определить общие основания для оценки рисков, а также повысить вероятность успешного достижения результатов проекта.
Планирование управления рисками должен быть завершено на ранней стадии планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов.
Шкала оценки воздействия отражает значимость риска в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.
Еще одной важной характеристикой риска является близость его наступления.
Идентификация рисков - это выявление рисков, способных повлиять на проект, и документальное оформление их характеристик. Это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые
риски. Исходные данные для выявления и описания характеристик рисков могут браться из разных источников.
Каждый проект задумывается и разрабатывается на основании ряда гипотез, сценариев и допущений. Как правило, в описании содержания проекта перечисляются принятые допущения - факторы, которые для целей планирования считаются верными, реальными или определенными без привлечения доказательств. Неопределенность в допущениях проекта следует также обязательно рассматривать в качестве потенциального источника возникновения рисков проекта. Анализ допущения позволяет идентифицировать риски проекта, происходящие от неточности, несовместимости или неполноты допущений.
Для сбора информации о рисках могут применяться различные подходы.
Среди этих подходов наиболее распространены опрос экспертов, мозговой штурм, метод Дельфи, карточки Кроуфорда. В качестве источника информации при выявлении рисков могут служить различные доступные контрольные списки рисков проектов разработки ПО, которые следует проанализировать на применимость к данному конкретному проекту [1, 3]. Не существует исчерпывающих контрольных списков рисков программного проекта, поэтому необходимо внимательно анализировать особенности каждого конкретного проекта. Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причины, условия, последствий и ущерба.
Качественный анализ рисков включает в себя расстановку рангов для идентифицированных рисков. При анализе вероятности и влияния предполагается, что никаких мер по предупреждению рисков не производится. Качественный анализ рисков включает:
определение вероятности реализации рисков;
определение тяжести последствий реализации рисков;
определения ранга риска по матрице «вероятность - последствия»;
определение близости наступления риска;
оценку качества использованной информации.
Результаты качественного анализа используются в ходе последующего количественного анализа рисков и планирования реагирования на риски.
Количественный анализ производится в отношении тех рисков, которые в процессе качественного анализа были квалифицированы как имеющие высокий и средний ранг. Для количественного анализа рисков могут быть использованы следующие методы:
анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект;
анализ дерева решений, описывающего ситуацию с учетом каждой из имеющихся возможностей выбора и возможного сценария;
моделирование и имитация - используется модель для определения последствий от воздействия подробно описанных неопределенностей на результаты проекта в целом.
После проведения качественного и количественного анализа рисков начинается процесс разработки путей и определения действий по увеличению возможностей и снижению угроз для целей проекта - планирование реагирования на риски.
Возможны четыре метода реагирования на риски [3]:
уклонение от риска;
передача риска;
снижение рисков;
принятие риска.
Важно помнить о вторичных рисках, возникающих в результате применения реагирования на риски, которые тоже должны быть идентифицированы, проанализированы и при необходимости включены в список управляемых рисков.
Управление рисками должно осуществляться на протяжении всего проекта. Мониторинг и управление рисками - это процесс идентификации, анализа и планирования реагирования на новые риски, отслеживания ранее идентифицированных рисков, а также проверки и исполнения операций реагирования на риски и оценка эффективности этих операций. Мониторинг и управление рисками включает в себя задачи пересмотра рисков, аудита рисков, анализа отклонений и трендов.
В разработке ПО часто приходится формулировать риски в виде допущений. Например, оценивая проект разработки и внедрения по схеме с фиксированной ценой, следует записать в допущения предположение о том, что стоимость лицензий на стороннее ПО не изменится, до завершения проекта. Ограничения, как правило, сокращают возможности проектной команды в выборе решений. В частности, они могут содержать специфические нормативные требования, специфические технические требования, а также специфические требования к защите информации. Кроме того, уместно сформулировать те требования к системе, которые могут ожидаться заказчиком по умолчанию, но не включаются в рамки данного проекта.
Лекция №3. Модели жизненного цикла программного обеспечения Цель: получить представление об основных моделях жизненного цикла программного обеспечения и их использования.
На протяжении последних тридцати лет в программировании сменились несколько моделей жизненного цикла программного обеспечения [4]. Каждой из моделей соответствует определенная стратегия конструирования ПО [5].
Модели в процессе эволюции усложнялись и совершенствовались.
В 1970 году Уинстон Ройс предложил схему разработки, которая активно использовалась в течение последующих 15 лет (1970-1985).
Каскадная схема разработки ПО предполагала, что переход на следующую стадию осуществляется только после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии (см. рисунок А.7).
Эту модель в разных источниках часто называют классическим жизненным циклом [5] или водопадной моделью [4]. Достоинствами такой схемы являются:
- получение плана и временного графика по всем этапам проекта;
- простота планирования процесса разработки;
- получение в конце каждой стадии законченного набора проектной документации, отвечающего требованиям полноты и согласованности.
Именно эту схему используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности разработки. Однако каскадная схема имеет недостатки:
- реальные проекты часто требуют отклонения от стандартной последовательности шагов;
- цикл основан на точной формулировке исходных требований к ПО;
- результаты проекта доступны заказчику только в конце работы.
Схема оказалась применимой только к созданию систем, для которых в самом начале разработки удавалось точно и полно сформулировать все требования, что уменьшало вероятность возникновения в процессе разработки проблем, связанных с принятием неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне редко. Каскадной (водопадной) схеме соответствует стратегия конструирования называемая однократным проходом или водопадной стратегией.
Реальный же процесс носит итерационный характер. Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в возможности приспособления продукта под операционную систему, в форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях используется макетирование, основная цель которого - снять неопределенности в требованиях заказчика. При макетировании модель может принимать одну из трех форм:
- бумажный макет или макет на основе компьютера (изображается человеко-машинный диалог);
- работающий макет (выполняется некоторая часть требуемых функций);
- существующая программа (впоследствии характеристики программы должны быть улучшены).
Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик (рисунок А.8). Макетирование начинается со сбора и уточнения требований к программе. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование, причем внимание сосредотачивается на тех характеристиках программного обеспечения, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета.
Макет оценивается заказчиком и используется для уточнения требований к программному обеспечению. Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и тем самым не даст возможность разработчику понять, что должно быть сделано.
Несомненным достоинством макетирования является то, что оно обеспечивает определение полных требований к программному продукту.
Однако, когда заказчик видит работающую версию программного продукта, он перестает осознавать, что это всего лишь макет, который далек от законченного программного продукта. При этом в погоне за работающим вариантом остаются нерешенными вопросы качества и удобства сопровождения программного обеспечения. Кроме того, разработчик так же, как и заказчик может принять макет за продукт. Желаемое принимается за действительное.
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Могут использоваться не самые подходящие язык программирования или операционная система.
Для простой демонстрации возможностей может применяться неэффективный алгоритм. Спустя некоторое время при разработке финишной версии разработчик забывает о причинах, по которым эти средства не подходят. В результате далеко не идеальный выбранный вариант интегрируется в систему.
Аналогичная схема, поддерживающая итерационный характер процесса разработки, была названа моделью с промежуточным контролем (рисунок А.9).
Контроль, выполняемый по данной схеме после завершения каждого этапа, позволяет вернуться на любой уровень и внести изменения. Основная опасность использования такой схемы связана с тем, что разработка никогда не будет завершена, постоянно находясь в состоянии уточнения и усовершенствования.
Сочетание элементов последовательной водопадной модели с итерационной философией макетирования позволило получить инкрементную модель [5], которая соответствует инкрементной стратегии конструирования.
Инкрементная модель в отличие от макетирования позволяет получать на каждой итерации работающий продукт. Примерами современной реализации инкрементного подхода могут служить технология быстрой разработки приложений (RAD-технология) и экстремальное программирование ХР, предложенное Кентом Беком в 1999 году.
В конце 1980-х годов Германией и США независимо друг от друга была разработана концепция V-образной модели - вариации каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования — вверх по правой стороне буквы V (рисунок А.10).
Внутри V проводятся горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на каждой из фаз тестирования.
Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы.
Немецкая V-модель была разработана аэрокосмической компанией IABG в Оттобрунне для Министерства обороны Германии и летом 1992 была принята немецкой федеральной администрацией для гражданских нужд.
Американская V-Model (VEE) была разработана национальным советом по системной инженерии для спутниковых систем, включая оборудование, программное обеспечение и взаимодействие с пользователями. Современной версией V-Model является V-Model XT, которая была утверждена в феврале 2005 года и используется для управления процессом разработки программного обеспечения для немецкой федеральной администрации.
Сейчас она является стандартом для немецких правительственных и оборонных проектов, а также для производителей программного обеспечения в Германии. V-Model представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов.
Несомненным достоинством V-модели является то, что пользователи сами участвуют в процессах разработки и поддержки. Комитет по контролю за изменениями поддерживает проект и собирается раз в год для обработки всех полученных запросов на внесение изменений в V-Model. На старте любого проекта V-образная модель может быть адаптирована под этот проект.
В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения - перед разработкой компонентов. Модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию.
Несмотря на указанные достоинства, V-модель не предусматривает работу с параллельными событиями; не позволяет вносить требования динамических изменений на разных этапах жизненного цикла; тестирование требований в жизненном цикле происходит слишком поздно, а некоторый результат можно посмотреть только при достижении низа буквы V.
Для преодоления проблем моделей итеративной разработки в 1988 году Барри Боэмом была предложена спиральная схема (рисунок А.11).
Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска. В соответствии с приведенной выше схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования.
Метод базируется на создании прототипов - действующих программных продуктов, реализующих отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения. Создание программного обеспечения выполняется в несколько итераций:
а) I итерация: специфицируется, проектируется, реализуется и тестируется интерфейс пользователя;
б) II итерация: добавляется некоторый ограниченный набор функций;
в) III … N- итерации: расширяется функционал продукта.
На каждом витке спирали проводится анализ риска. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое на этапе проектирования).
Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации.
Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
Достоинство схемы: начиная с некоторой итерации, на которой обеспечена определенная функциональная полнота, продукт можно предоставлять пользователю, что позволяет:
сократить время до появления первых версий программного продукта;
заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке;
ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;
уменьшить вероятность морального устаревания системы за время разработки.
Основной проблемой использования схемы является определение моментов перехода на следующие стадии, для чего ограничивают сроки прохождения каждой стадии, основываясь на экспертных оценках.
Спиральная модель является классическим примером применения эволюционной стратегии конструирования.
Развитием спиральной модели является компонентно-ориентированная модель, которая также основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание этапа проектирования: в современных условиях новая разработка должна
основываться на повторном использовании существующих программных компонентов.
Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку.
Достоинства компонентно-ориентированной модели:
- уменьшает на 30% время разработки программного продукта;
- уменьшает стоимость программной разработки до 70%;
- увеличивает в 1,5 раза производительность разработки.
Альтернативой спиральной и каскадной моделям жизненного цикла является модель хаоса (Raccoon, 1995), которая предполагает, что фазы жизненного цикла распространяются на все уровни проекта: от всего проекта в целом до отдельной строки кода. Это означает, что проект, все его системы, модули, функции и строки кода должны быть определены, реализованы и интегрированы. Главное правило - всегда решать наиболее важную задачу первой.
Лекция №4. Качество программного обеспечения
Цель: получить представление о технологичности программного обеспечения, ее критериях, а также модулях и их характеристках.
Для заказчика одной из важнейших характеристик программного обеспечения является качество программного продукта, поскольку именно это определяет насколько оправдаются вложенные в разработку ПО финансовые затраты. С точки же зрения разработчика немаловажно, чтобы разрабатываемый проект быстро и легко кодировался, тестировался, отлаживался и модифицировался.
Таким образом, качество проекта программного продукта, от которого зависят трудовые и материальные затраты на его реализацию и последующие модификации, называют технологичностью [6]. Высокая технологичность проекта особенно важна, если необходимо обеспечить повышенные требования к его качеству или разрабатывается программный продукт, рассчитанный на многолетнее интенсивное использование.
В настоящее время критериями качества программного обеспечения (criteria of software quality) принято считать [4]:
а) функциональность это способность ПО выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей;
