1. Экстремальное программирование. Ценности ХР. Практики ХР.
Экстремальное программирование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек (Kent Beck), Уорд Каннингем (Ward Cunningham).
Ценности XP
• Коммуникации (Communication)
• Обратная связь (Feedback)
• Простота (Simplicity)
• Храбрость (Courage)
Интенсивная разработка малыми группами (не больше 10 человек), активное общение в группе и между группами. Обратная связь с клиентом (feedback), который фактически вовлечен в процесс разработки. Простота решений. Достаточная степень смелости (courage) и желание идти на риск.
Практики XP
• Игра в планирование (Planning Game )
• Тестирование (Testing)
• Повторное кодирование (Refactoring)
• Коллективное владение кодом(Collective Code Ownership)
• Простота проектирования (Simple Design)
• Парное программирование (Pair Programming)
• Небольшие релизы (Small Release)
• Постоянная интеграция (Continuous Integration)
• Заказчик в команде разработки (On-site Customer)
• Стандарты кодирования (Coding Standards)
• Метафора (Metaphor)
• 40-часовая рабочая неделя (40-hour Work Week)
Обычно XP характеризуют набором из 12 действий (практик), которые необходимо выполнять для достижения хорошего результата. Практики XP не определяют сам процесс XP, но XP определяет эти практики — то есть выполнение практик не гарантирует результата.
• Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.
• Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).
• Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры — крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.
• Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.
• Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Определение наиболее важных объектов стандартизации в XP субъективно.
• Рефакторинг (refactoring). Рефакторинг — это оптимизация существующего кода в сторону упрощения, что предусматривает постоянную работу по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг надо отложить.
• Парное программирование (pair programming) — одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.
• 40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) — это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение — одно из основных правил.
• Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.
• Частая смена версий (small releases). Минимальная итерация — один день, максимальная — месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.
• Непрерывная интеграция (continuous integration). Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это жесткое и однозначное — если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.
• Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP — одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test — тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.
2. Экстремальное программирование. Методология. Технологии поддержки ХР.
• Этап планирования (planning game). Программисты реализуют только те функции, которые необходимы для возможностей, выбранных на данной итерации заказчиком.
• Постоянное участие заказчика (on-site customer). Представитель заказчика в период работы над системой находится в команде разработчиков, причем требования к квалификации этого человека или команды весьма высоки. Если заказчик не согласился предоставить персонал уровня экспертов, то проект попадает в группу наиболее высокого риска.
• Метафора (metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты. Если не ведется журнал данного процесса и структура наименований не стандартизована, то такой процесс может оказаться бесконечно итерационным.
• Простая архитектура (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз». Данный принцип вступает в противоречие с быстротой написания кода. Без наличия высокой самодисциплины и жестких стандартов кода система немедленно попадает в группу риска.
• Частая смена версий (small releases). Систему запускают в эксплуатацию уже через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых версий может варьироваться от ежедневной до ежемесячной. Протестировать за такой срок более-менее сложный компонент невозможно; заказчик фактически выступает в роли бета-тестера. Системы, к которым предъявляется требование непрерывной надежной работы (так называемое требование 24Ѕ7), входят в группу риска.
• Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов. Экстремальное программирование исходит из того, что переделать часть системы всегда можно, причем без особых затрат. Однако практика довольно часто свидетельствует об обратном.
• Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются. В данном случае не всегда понятно, кто именно будет исправлять ошибки, причем не только локальные, но и наведенные неправильным кодом. Проведение комплексных тестов на данном этапе не предполагается; кроме того, изменения сохраняются даже в том случае, когда ошибка обнаружена.
• Программирование в паре (pair programming). Весь код проекта пишут группы по два человека, использующих одно рабочее место. Человеческий фактор в данном случае играет определяющую роль: пара или работает или нет, третьего не дано.
• 40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, служат признаком серьезных проблем, которые требуют безотлагательного решения. Как показывает практика применения экстремального программирования (несмотря на целый ряд положительных примеров, приводимых сторонниками данного метода), сверхурочная работа при таком подходе — это правило, а не исключение, и борьба с проблемами в данном случае — явление постоянное. Усиливается она в период замены текущей сырой версии продукта очередной — менее сырой. Если заказчик не получает постоянных доказательств улучшения системы, значит, у вас возникли серьезные проблемы.
• Коллективное владение (collective ownership). Каждый программист имеет возможность при необходимости в любое время усовершенствовать любую часть кода в системе. Без стандарта контроля исходного кода процесс разработки приобретает абсолютно неконтролируемый характер.
• Открытое рабочее пространство (open workspace). Команда разработчиков располагается в большом помещении, окруженном комнатами меньшей площади. В центре рабочего пространства устанавливаются компьютеры, на которых работают пары программистов (причем в соответствии с вышеизложенными принципами, все это должно располагаться на территории заказчика, поскольку он весьма активно привлекается к процессу разработки). При наличии территориально распределенной группы разработчиков и заказчиков проект требует стандартизации протокола взаимодействия (быстро, надежно, безотказно) или попадает в группу риска.
• Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Для этапов итерации заказчики пишут функциональные тесты (functional tests), от которых также требуется правильная работа. Однако на практике это не всегда достижимо. Чтобы принять верное решение, необходимо понять, во что обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на его устранение. Тесты, написанные самими программистами (особенно в условиях сверхурочных работ), не являются полнофункциональными и уж тем более не учитывают особенностей многопользовательской работы. На более продвинутые тесты у разработчиков обычно не хватает времени. Решается данная проблема путем привлечения на определенный срок контакторов, что связано с большой ролью человеческого фактора: поскольку техническая документация изначально отсутствует, то информация передается посредством общения программистов. Хотя, конечно, можно построить систему разработки таким образом, что от начала до конца всем будут заниматься одни и те же люди. К сказанному необходимо добавить, что тестирование системы вовсе не исчерпывается тестами компонентов (units); не менее важны тесты взаимодействия между ними, это же относится и к тестам надежности работы. И тем не менее метод экстремального программирования не предусматривает создания тестов данного класса. Это объясняется тем, что сами подобные тесты могут представлять достаточно сложный код (особенно это касается тестов — имитаторов реальной работы системы). В данной технологии также никак не учитывается еще один важный класс тестов — тесты поведения системы при росте объемов обрабатываемой информации. При высокой частоте изменения версий выполнить такой тест технологически невозможно, поскольку его проведение требует стабильного и неизменного кода проекта, например в течение недели. В таком случае придется или приостанавливать разработку компонентов, или создавать на время проведения теста параллельную версию проекта, которая будет сохраняться неизменной, тогда как другая при этом будет изменяться. Затем нужно будет выполнить процесс слияния кода. Но в этом случае тест придется создавать заново, так как методы экстремального программирования просто не предусматривают разработку средств, позволяющих прогнозировать поведение системы при тех или иных изменениях. Решать данные проблемы в XP предлагается посредством все того же человеческого фактора и самодисциплины.
• Не более чем правила (just rules). Члены коллектива, работающего по технологии экстремального программирования, обязуются выполнять изложенные правила. Однако это не более чем правила, и команда может в любой момент изменить их, если ее члены достигнут принципиального соглашения по поводу внесенных изменений. Данный принцип серьезно зависит от человеческого фактора; нарушение дисциплины разработки влечет за собой срывы сроков и в результате ведет к краху проекта.
В итоге мы получаем метод, потенциально обладающий высокой адаптацией к серьезно и часто изменяющимся требованиям к проекту, но в то же время не свободный от ряда принципиальных недостатков и в очень высокой степени зависимый от человеческого фактора.
Таким образом, результат применения метода экстремального программирования может получиться либо экстремально хорошим, либо экстремально плохим.
Технологии поддержки XP
• Система контроля версий: CVS
• Система модульного тестирования: xUnit
3. Экстремальное программирование. Сравнение с классическим ЖЦ программного продукта. Кривая затрат.
Кривая затрат при XP (приближенно)
Кривая затрат при классическом ЖЦ ПП.
4. «Водопадная» модель ЖЦ. Общие принципы. Недостатки «водопадной» модели. 10 правил промышленного производства ПО.
Водопадная модель жизненного цикла ПО предполагает последовательное выполнение различных этапов деятельности, включая анализ требований, проектирование, кодирование и тестирование отдельных модулей (компонентов), тестирование сборок и интегрированное тестирование всего конечного продукта. При этом предполагается четкое разграничение этапов, на которых набор документов, выработанный на предыдущей этапе, передается в качестве входных данных для следующего. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла ПО, движение в обратную сторону по этой цепочке невозможно.
Анализ. На этапе анализа изучается и определяется задача, которую должна выполнять программа. Результатом выполнения этой фазы является совокупность требований, предъявляемых к ПО.
Проектирование. На этом этапе требования, выявленные при анализе, преобразуются в описание принципов решения – документ, в соответствии с которым принимаются конкретные решения при реализации программы. Основным итогом второй фазы является получение проекта, который может включать текст на естественном языке, модель ПО, алгоритмы, таблицы, математические формулы и т. п. Детальное проектирование предполагает выделение компонент ПО, определение их структуры и методов взаимодействия.
Реализация. По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и автономные тесты модулей. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию.
Внедрение и эксплуатация. Готовый программный продукт передается заказчику, производятся приемо-сдаточные испытания, осуществляется обучение пользователей и опытная эксплуатация, после чего ПО ставится на сопровождение и начинается производственная эксплуатация программной системы.
Недостатки водопадного подхода
- Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу.
- Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы. Очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему, поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе.
- Метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО.
- Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Правила промпроизводства ПО
1. Поиск и обнаружение ошибки в ПО после его сдачи обходится в 100 раз дороже, чем поиск и обнаружение ошибки на ранних стадиях разработки
2. Можно сократить срок разработки ПО на 25% от номинального, но не более
3. На каждую денежную единицу, вложенную в разработку, приходится тратить две денежных единицы на сопровождение
4. Стоимость разработки и сопровождения ПО является прежде всего функцией числа строк исходного кода
5. Различия в уровне разработчиков приводят к огромной разнице в продуктивности при создании ПО
6. Общее отношение стоимости ПО к стоимости аппаратуры продолжает расти. В 1955 г. оно составляло15:85; 1985 г. - 85:15
7. При создании ПО всего лишь около 15% усилий затрачивается собственно на программирование
8. Программные системы обычно стоят в 3 раза дороже в пересчете на 1 SLOC, чем отдельные программы. Продукты, состоящие из программных систем, дороже в 9 раз
9. Сквозной контроль позволяет обнаружить 60% ошибок
10. 80% работы выполняют 20% работающих
5. «Водопадная» модель ЖЦ. График хода разработки в типичном проекте. Распределение затрат. График риска.
Распределение трудоемкости и затрат времени в течение жизненного цикла типичного проекта. Rational Unified Project (RUP)
Водопадный профиль риска
6. «Водопадная» модель ЖЦ. Стадии разработки в соответствии с ЕСПД.
Стадии разработки | Этапы работ | Содержание работ |
Техническое задание | Обоснование необходимости разработки программы | Постановка задачи. |
Научно-исследовательские работы | Определение структуры входных и выходных данных. | |
Разработка и утверждение технического задания | Определение требований к программе. | |
Эскизный проект | Разработка эскизного проекта | Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования. |
Утверждение эскизного проекта | Разработка пояснительной записки. Согласование и утверждение эскизного проекта | |
Технический проект | Разработка технического проекта | Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств. |
Утверждение технического проекта | Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта. | |
Рабочий проект | Разработка программы | Программирование и отладка программы |
Разработка программной документации | Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77. | |
Испытания программы | Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний. | |
Внедрение | Подготовка и передача программы | Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ. |
7-8.Унифицированный процесс. Основные понятия. ЖЦ унифицированного процесса. История создания.
• Компания Ericsson •
(Проектирование на основе блоков, выделенных из диаграмм вариантов использования. Первый рабочий продукт – описание архитектуры)
• Язык спецификации и описания(SDL) •
(Специализированный стандарт объектного моделирования)
• Objectory •
(Концепция вариантов использования. Понимание, что архитектура направляет разработчиков и информирует заинтересованных лиц. Рабочие процессы представлены в виде моделей требований, вариантов использования, анализа, проектирования, реализации и тестирования)
• Компания Rational •
(Итеративная разработка и упор на архитектуру. Майкл Девлин (Michael T. Devlin), Филипп Крухтен (Philippe Kruchten). Детальное планирование фаз и порядка итераций. Уолкер Ройс (Walker Royce) и Рич Рейтман (Rich Reitman). «Управляемая архитектурой разработка наилучший способ создания очень сложных программных проектов», «Чтобы быть успешным, объектно-ориентированный проект должен применять инкрементальный и итеративный процесс» Гради Буч (Grady Booch) )
• Rational Objectory process •
(Разработана оригинальная архитектура процесса разработки программ. Определен набор моделей, в которые записывались результаты процесса. Проработаны части процесса: моделирование вариантов использования, анализ и проектирование. Отсутствовали части процесса: реализация и тестирование, управление требованиями. UML был в разработке и использовался в качестве языка моделирования для Rational Objectory Process (ROP). Rational Objectory Process 4.2)
• Унифицированный язык моделирования •
(Гради Буч(Graudy Booch) основатель «метода Буча», Джеймс Рамбо(James Rambo) разработчик из Центра исследований и разработок Дженерал Электрик по ОМТ(Технологии объектной методологии). Ивар Джекобсон (Ivar Jecobson) совместно выпустили версию 0.9 UML. Это была ассимиляция работ методологов и компаний, включая IBM, Microsoft, HP. В 1997 году UML 1.1 был объявлен стандартом Группы управления объектами)
• Rational Unified Process •
(Requisite Inc. - управление требованиями, SQA Inc. – процесс тестирования для тестирования продуктов, Pure-Atria – управление конфигурациями, Performance Awreness – тестирование производительности и загрузки, Vigortech – экспертиза структуры данных. К UP были также добавлены рабочие процессы бизнес-моделирования, проектирование пользовательских интерфейсов на основе вариантов использования. В июне 1998 года был выпущен Rational Unified Process 5.0 )
RUP является примером так называемого "тяжелого" процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр. Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять. Многочисленные вспомогательные действия дают надежду сделать возможным успешное решение задач по конструированию и поддержке сложных систем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами.
Для достижения этого выполняется иерархическое пошаговое детальное описание предпринимаемых в той или иной ситуации действий, чтобы можно было научить обычного работника действовать аналогичным образом. В ходе проекта создается много промежуточных документов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачи на более простые. Эти же документы служат для проверки правильности решений, принимаемых на каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов, необходимых для получения желаемых результатов.
В основу рационального унифицированного процесса положена итеративная разработка программного обеспечения. В рамках RUP разработка выполняется в виде нескольких краткосрочных итераций продолжительностью от 2 до 6 недель. Итерация по существу является мини-проектом фиксированной длительности, в результате которой расширяется и дополняется функциональность разрабатываемой системы. Поэтому унифицированный процесс разработки иногда называют итеративной и инкрементальной разработкой.
Фаза начала проекта (Inception)
Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов.
На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта.
Фаза проектирования (Elaboration)
Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.
На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.
Фаза построения (Construction)
Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования.
На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.
Фаза внедрения (Transition)
Цель этой фазы — сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.
На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.
9. Унифицированный процесс. Модели унифицированного процесса. Варианты.
Модель вариантов использования служит основой для проектирования и оценки готовности системы к внедрению.
Артефакт – общее название для любых видов информации, создаваемой, изменяемой или используемой сотрудниками при создании системы, например диаграммы UML, планы тестирования, тесты, бизнес-планы, план подбора сотрудников и т. д.
Модель – абстракция, описывающая моделирующую систему с определенной точки зрения, например, представление спецификации или представление проектирования.
Рабочий процесс – это часть процесса разработки, например, процесс Определения требований. В нем участвуют сотрудники: системный аналитик, архитектор, спецификатор использования, разработчик пользовательских интерфейсов. Артефакты процесса: модель вариантов использования, вариант использования и др.
Сотрудник – роль, которую должен играть человек в разработке программного обеспечения, например спецификатор вариантов использования, архитектор, тестер интеграции, инженер по компонентам. Пример варианта использования и действующих лиц
В рамках других подходов модель анализа часто называется концептуальной моделью системы. Она состоит из набора классов, совместно реализующих все варианты использования и служащих основой для понимания работы системы и объяснения ее правил всем заинтересованным лицам.
11. СММ. Пять уровней зрелости.
Начальный уровень
Этот уровень присущ большинству начинающих и малых компаний. Ведение бизнеса здесь носит хаотичный характер, что напрямую связано с борьбой за выживание. В компании, как правило, отсутствует стратегия развития: основное внимание уделяется решению сиюминутных тактических задач.
Одной из характерных черт начального уровня организационной зрелости являются спонтанные информационные связи в компании, которые аккумулируются в руководящем звене и носят в основном справочный характер. Эффективность управления в значительной степени зависит от небольшой группы единомышленников и от личности руководителя — от того, насколько четко он понимает цели и задачи развития компании. Через этот уровень проходят все предприятия и организации — кто быстрее, кто медленнее — но в конечном итоге они подступают вплотную к следующему уровню.
Уровень повторяемости
На этом уровне зрелости в компании уже возможна успешная реализация задуманных проектов, что достигается благодаря жесткому управлению, оперативному планированию и контролю. Основные бизнес-процессы становятся повторяемыми и управляемыми, они приобретают устойчивый характер. Компании начинают искать пути снижения издержек, и, прежде всего, за счет оптимизации повторяющихся процессов. Для организаций, находящихся на этом уровне, характерна автоматизация базовых составляющих, таких как кадры, бухгалтерия, зарплата.
Оперативные планы деятельности компании строятся с учетом предыдущего опыта. В компании начинают формироваться корпоративные традиции и культура, однако по-прежнемуотсутствует интеграция информации, а сами информационные потоки остаются неформализованными.
Уровень регламентируемости
На этом уровне процессы (как в управлении, так и в производстве) становятся формализованными и настолько повторяемыми, что их можно описать и задокументировать. В компаниях появляются описания ролевых функций сотрудников внутри организации или список задач, которые должен выполнять сотрудник внутри того или иного подразделения.
Все процессы стандартизированы, документированы и объединены в общий информационный поток. Благодаря этому в организации появляется возможность анализа информации по всем аспектам управленческой деятельности, а также получения оперативной информации о степени использования ресурсов. Тем не менее, в таких компаниях практически отсутствует процесс постановки долгосрочных целей, а планирование основывается на принципе «от достигнутого» (т. е. на показателях прошлых периодов). Следует отметить, что в обработке информации при этом преобладает ретроспективный анализ.
Для предприятий, находящихся на этом уровне, характерно формирование стратегии развития. Как только такие решения начинают приниматься на основе анализа, это означает, что предприятие переходит на следующий этап организационной зрелости.
Уровень управляемости
Здесь приоритетным направлением становится повышение качества продукции или предоставляемых услуг, а целью — достижение рыночной привлекательности и увеличение доли рынка, т. е. именно то, к чему стремится любая компания, добивающаяся успеха в том сегменте рынка, где она работает. В организации формируются внутрикорпоративные стандарты качества, касающиеся не только собственной продукции или процессов производства, но и всей цепочки поставки — от партнеров (контрагентов) до клиентов.
Наличие и сохранение постоянных клиентов дает возможность долгосрочного планирования бизнеса и прогнозирования будущих продаж. В компании налажены стратегические и оперативные взаимосвязи, а для принятия решений активно используются обратные связи, в частности данные от клиентов. Попытки принимать решения не только на основе анализа предыдущего опыта, но и на основе прогнозов будущего развития, стратегическое планирование с учетом тенденций (для чего необходимы корпоративные базы знаний) обуславливают постепенный переход организации на последний, высший уровень организационного развития.
Уровень оптимизируемости
Достичь этого уровня чрезвычайно трудно, и удается это лишь немногим компаниям, лидирующим в индустрии. Здесь управление качеством по количественным показателям происходит по всей цепи взаимосвязанных процессов, а модификация или совершенствование системы — по результатам обратной связи. Для организации характерно не только построение стратегических планов, но и оптимизация путей их достижения. Стратегия компании направлена на достижение организационного, финансового, технологического преимущества.
Вероятно, трудно найти предприятие, которое не стремилось бы достичь высшего уровня в своем развитии. Современное состояние всех отраслей человеческого знания и прикладных технологий предоставляет массу возможностей для скорейшего прохождения этого пути, но требует навыков и профессионального умения в их правильном применении. При этом ключевым фактором успеха становится время.
Современный этап развития управленческой культуры характеризуется развитием коллективной обработки и анализа информации и переходом
ñот анализа количественных показателей к качественному анализу;
ñот оперативного анализа к стратегическому планированию;
ñот единоличного анализа и принятия решений к коллегиальной работе.
10. СММ. Области ключевых процессов для 2-5 уровней зрелости
Capability Maturity Model for Software (CMM) – модель зрелости процесса создания программного обеспечения (ПСПО)
• CMM - не технология, не стандарт
• СММ не имеет жестких предписаний
• СММ не привязана ни к одной информационной технологии
• СММ не подсказывает как работать с персоналом
• СММ не говорит как улучшить работу компании
• CMM указывает ключевые действия по достижению необходимого качества ПО
• СММ содержит способы контроля за правильностью выполнения ключевых действий и методы их корректировки
• СММ позволяет точно оценить ПСПО
• СММ включает в себя набор критериев для определения зрелости ПСПО
2 уровень | Подбор сотрудников, учет производительности их труда и документирование обязанностей; контроль за соответствием создаваемого продукта требованиям заказчика; контроль качества в соответствии с внутрифирменными стандартами; контроль за работой над проектами; планирование проектов, определение их объемов и требуемых ресурсов |
3 уровень | Координация работы внутри групп - каждый сотрудник включается в процессы оценки и совершенствования своей работы; координация совместной работы групп для более полного видения проекта; создание формальных моделей для описания программных модулей, тестирования и ведения групповых проектов; выбор и использование наиболее подходящих программных и бизнес-технологий во всех процессах управления работой с использованием формальных методик; организация регулярной учебы; выявление ошибок на ранних стадиях |
4 уровень | Управление качеством, производительностью и эффективностью ПСПО на базе их количественных характеристик. Цели имеют числовые эквиваленты (реальные примеры: продукт должен иметь не более одной ошибки на 10000 строк кода; отклонение продолжительности проекта от запланированной не должно превышать 3%). Менеджеры способны точно оценить результаты своих решений. Влияние любых побочных воздействий оценивается перед началом проекта |
5 уровень | Непрерывное глобальное улучшение ПСПО. При этом процессы изменяться могут как постепенно, так и резко; предупреждение ошибок во избежание их повторения в будущем; управление технологиями - эффективность новых технологий оценивается количественно, и они легко интегрируются в ПСПО. Творческое озарение и уникальные открытия можно оценить численно и включить в план. |
12. Надежность программного обеспечения. Понятие ошибки. Программная и аппаратная ошибка. Показатели надежности. Функция риска.
В ПО имеется ошибка, если оно не выполняет того, что пользователю разумно от него ожидать. Отказ ПО – это проявление ошибки в нём. Понятие качества программного средства (функциональность, надежность, легкость применения, эффективность, сопровождаемость, мобильность). Четыре подхода обеспечению надежности (предупреждение ошибок, самообнаружение ошибок, самоисправление ошибок, обеспечение устойчивости к ошибкам). Цель предупреждения ошибок (борьба со сложностью, обеспечение точности перевода, преодоление барьера между пользователем и разработчиком, обеспечение контроля принимаемых решений).
Основные показатели надежности:
1. Количество оставшихся ошибок «B». Этот параметр меняется от стадии жизненного цикла программы, на котором находится программа; 2. Вероятность безотказной работы программы на интервале от [0,t] об. P(t); 3. Вероятность проявления хотя бы одного отказа на интервале от [0,t] об. Q(t)=1-P(t); 4. Плотность интервала появления отказов об. q(t)=dQ(t)/dt=-dP(t)/dt; 5. Функция риска, определяется как условная плотность отказов в программе, при условии, что до t отказов не было. Функция риска имеет размерность [1/время] и она очень полезна при классификации основных распределений отказов. Распределения с возрастающей функцией риска соответствуют тем ситуациям, когда статистические характеристики надежности ухудшаются со временем. И наоборот, распределения с убывающей функцией риска соответствуют обратной ситуации, когда надежность улучшается со временем в результате процесса обнаружения и коррекции ошибок.
13. Качество ПО. Показатели качества программного обеспечения: функциональность, удобство использования, эффективность, сопровождаемость, мобильность, надежность
Мобильность программного обеспечения- Переносимость программного обеспечения
Мобильность программного обеспечения - способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем.
Сопровождаемость программного обеспечения - характеристики программного продукта, позволяющие минимизировать усилия по внесению в него изменений: для устранения ошибок или для модификации в соответствии с изменяющимися потребностями пользователей.
Удобство программного обеспечения - Эргономичность программного обеспечения
Удобство программного обеспечения - характеристики программного продукта, которые: позволяют минимизировать усилия пользователей по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также позволяют вызывать положительные эмоции определенного или подразумеваемого пользователя.
Эффективность программного обеспечения - отношение уровня услуг, предоставляемых программным продуктом пользователю при заданных условиях, к объему используемых ресурсов.
Функциональность программного обеспечения - Интероперабельность программного обеспечения
Функциональность программного обеспечения - способность программного продукта выполнять набор функций: определенных в его внешнем описании и удовлетворяющих заданным или подразумеваемым потребностям пользователей.
14. Тестирование. Принципы тестирования ПО. Определения и подходы. Понятия: контроль, доказательство, испытание, аттестация. Виды тестирования. Подходы к тестированию.
Процесс тестирования со стороны среды, на которую оно опирается
• Тестирование – процесс выполнения программ с намерением найти ошибки
• Доказательство – попытка найти ошибки в программе безотносительно к внешней для программы среде
• Контроль – попытка найти ошибку, выполняя программу в тестовой или моделируемой среде
• Испытание – попытка найти ошибку в заданной реальной среде
Аттестация – авторитетное подтверждение правильности программы
Отладка – не является разновидностью тестирования. Процесс установления точной природы ошибки с последующим ее исправлением
Процесс тестирования как деятельность по выявлению ошибок
• Тестирование модуля (автономное тестирование) – контроль отдельного модуля, обычно в изолированной среде
• Тестирование сопряжений – контроль сопряжений между частями системы
• Тестирование внешних функций – контроль внешнего поведения системы, определенного внешними спецификациями
• Комплексное тестирование – контроль и/или испытание системы по отношению к исходным целям
• Тестирования приемлемости – проверка соответствие программы требованиям пользователя
• Тестирование настройки – проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки
15. Тестирование. Принципы тестирования ПО. Аксиомы тестирования. Тестирование модуля. Тестирование внешних функций и комплексное тестирование.
• Нисходящее тестирование (автономное тестирование головного модуля; заглушки; обеспечить функционирование операций физического ввода-вывода как можно быстрее; совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций)
• Восходящее тестирование (модули нижнего уровня тестируются автономно; требуются драйверы для каждого модуля – подают тесты в соответствии с сопряжением тестируемого модуля; инструментальная среда для подачи тестов)
• Модифицированный нисходящий метод (каждый модуль проходит автономное тестирование перед подключением к программе)
• Метод «большого скачка» (все модули тестируются автономно, по окончании тестирования они интегрируются в систему все сразу
• Метод сандвича (компромисс между восходящим и нисходящим подходом; одновременно начинается тестирование нисходящим и восходящим способом)
• Модифицированный метод сандвича (компромисс между восходящим и нисходящим подходом; модули верхних уровней тестируются автономно, модули нижних уровней тестируются строго снизу вверх)
Аксиомы
• Хорош тот тест, для которого велика вероятность обнаружить ошибку, а не тот который демонстрирует правильную работу программы
• Одна из самых сложных проблем при тестирование решить когда нужно его закончить
• Невозможно тестировать свою собственную программу
• Необходимая часть всякого теста – описание выходных данных или результатов
• Избегайте невоспроизводимых тестов, не тестируйте «с лету»
• Готовьте тесты как для правильных, так и не для правильных входных данных
• Детально изучайте результаты каждого теста
• По мере того как увеличивается число ошибок, обнаруженных в каждой компоненте программного обеспечения, растет вероятность существования в ней необнаруженных ошибок
• Считайте тестирование ключевой задачей вашей разработки
• Поручайте тестирование самым способным программистам
• Проект системы должен быть таким, чтобы каждый модуль подключался к системе один раз
• Никогда не изменяйте программу, чтобы облегчить тестирование
• Тестирование, как почти всякая другая деятельность, должна начинаться с постановки целей
Тестирование модуля
• Пример тестов для программа о треугольнике
• Правила по составлению набора тестов:
1. Руководствуясь внешними спецификациями модуля, подготовьте тест для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий
2. Проверьте текст программы, чтобы убедиться, что все условные переходы будут выполнены в каждом направлении. Если необходимо, добавьте соответствующих тесты
3. Убедитесь по тексту программы, что тесты охватывают достаточно много возможных путей. Например, для каждого цикла должен быть тест, соответствующий пути без выполнения тела цикла, с однократным его выполнением и максимальным числом повторений
4. Проверьте по тексту программы ее чувствительность к отдельным особым значениям входных данных и, если необходимо, добавьте соответствующие тесты
Минимальный критерий при автономном тестирование модуля – по крайней мере один раз выполнить все разветвления в каждом из возможных направлений
Тестирование внешних функций и комплексное тестирование
1. Методология проектирования тестов на основе функциональных диаграмм. Планирование сборки
2. Тесты регрессии – тесты которые выполняются в будущем при каждой модификации.
3. Тестирование функций – процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной)
4. Обязательный минимум при тестировании внешних функций – выполнить все разветвления по крайней мере один раз в каждом направлении, за исключением тех ветвей, которые обеспечивает защитное программирование
5. Комплексное тестирование – процесс поисков несоответствия системы ее исходным целям. Если вы не сформулировали цели вашего продукта или если эти цели не измеримы, вы не можете выполнить комплексное тестирование
6. Тестирование стрессов
7. Тестирование объемов
8. Тестирование конфигурации
9. Тестирование совместимости
10. Тестирование защиты
11. Тестирование требований к памяти
12. Тестирование производительности
13. Тестирование настройки
14. Требование надежности/готовности
15. Тестирование средств восстановления
16. Тестирование удобства обслуживания
17. Тестирование публикаций
18. Тестирование психологических факторов
19. Тестирование удобства эксплуатации
