Какие темы будут освещены?
| Тема | Рассматривается |
| 1. Назначение программной инженерии | Краткий обзор причин, истории возникновения и становления ПИ; Основные проблемы и ключевые понятия ПИ. |
| 2. Жизненный цикл и процессы разработки ПО | Понятия программный процесс, модель жизненного цикла и модель организации работ. Основные процессы программной инженерии, модели жизненного цикла ПО. Объясняется, что такое определение процесса и оценка процесса. Рассказывается об измерение в отношении процесса и продукта. На базовом уровне вводится понятие модели зрелости процессов |
| 3. Разработка и управление требованиями | Ключевые понятия, связанные с разработкой и управлением требованиями. Описываются ключевые процессы работы с требованиями: извлечение, анализ, создание спецификаций требований, их проверка и трассировка. |
| 4. Проектирование | Ключевые вопросы проектирования. Понятие архитектуры ПО, Анализ качества архитектуры Нотации проектирования. Стратегии и методы проектирования. |
| 5. Конструирование | (Конструирование – это область знаний (ОЗ), связанная с кодированием, низкоуровневым проектированием, отладкой и интеграцией ПО) В этой теме рассматриваются принципы управления сложностью и ожидания изменений, конструирования с возможностью проверки и повторного использования кода. Стандарты конструирования. Управление конструированием.. Интеграция. |
| 6. Тестирование | Основы тестирования ПО. Уровни тестирования. Техники тестирования. Измерение результатов тестирования. Процесс тестирования. |
| 7. Сопровождение | Технические и управленческие вопросы сопровождения. Оценка стоимости сопровождения. Измерения в сопровождении. Процессы сопровождения. Реинжиниринг. Обратный инжиниринг. |
| 8. Управление конфигурацией и изменениями | (Управление конфигурацией – это ОЗ, связанная с идентификации версий системы в определенные заданные моменты времени, с целью систематического контроля изменений, а также поддержки и сопровождения целостности и отслеживаемой конфигурации на протяжении всего жизненного цикла системы ). В данной теме рассматриваются: понятие программной конфигурации; организация управления конфигурацией и изменениями; план конфигурационного управления; идентификация, контроль и аудит программных конфигураций; управление выпуском и поставкой. |
| 9. Управление программной инженерией | Рассматриваются процессы инициирования, планирования, выполнения, оценки и закрытия программного проекта (в связи с дисциплиной управление проектами). Затрагиваются также аспекты измерений в программной инженерии. |
| 10. Управление качеством | Культура и этика программной инженерии; значение и стоимость качества; модели и характеристики качества; процессы повышения качества и управления качеством; требования к качеству. Классифицируются дефекты. Затрагивается тема количественная оценка качества ПО. |
| 11. Инструменты и методы | Инструменты работы с требованиями, проектирования, конструирования, тестирования, сопровождения, конфигурационного управления, управления инженерной деятельностью, поддержки процессов, обеспечения качества. |
1.2 Определение программной инженерии
Прежде чем дать определение непосредственно термину «инженерия программного обеспечения» рассмотрим понятия инженерия и программное обеспечение и программа.
Программное обеспечение (ПО) – совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ.
Программа – данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
Инженерия (или инженерное дело) – область технической деятельности, включающая в себя целый ряд специализированных областей и дисциплин, направленная на практическое приложение и применение научных, экономических, социальных и практических знаний с целью обращения природных ресурсов на пользу человека. ИЛИ целенаправленное использование научных знаний в создании и эксплуатации инженерных технических устройств, являющихся результатом преобразовательной деятельности инженера.
Рассмотрим непосредственно определение программной инженерии:
Программная инженерия чаще всего определяется как системный подход к анализу, проектированию, оценке, реализации, тестированию, обслуживанию и модернизации программного обеспечения, то есть применение инженерии к разработке программного обеспечения.
Еще одно определение:
Программная инженерия – инженерная дисциплина, охватывающая все аспекты разработки ПО (Соммервилл, 2002).
Целью программной инженерии является эффективное создание программных систем.
ПИ связана с многими дисциплинами – прежде всего с информатикой, управлением проектами, инженерной психологией, экономикой предприятия и т.д.
Часто говорят, что ПИ является составной частью системной инженерии.
Системная инженерия – междисциплинарный подход и методика, определяющие полный набор технических и управленческих усилий, необходимых для того, чтобы преобразовать совокупность потребностей заказчика и других заинтересованных сторон, имеющихся ожиданий и ограничений в эффективное системное решение и поддержать это решение в течение его жизни.
| Какое определение имеет понятие «система»? |
1.3 Предпосылки развития программной инженерии
1.3.1 Что происходило во всем мире?
Можно сказать, что элементы программирования возникали еще до появления электронных вычислительных машин: уже в XIX в. были изобретены механические пианино, арифмометры, ткацкие станки, которые в определенной мере можно считать программируемыми.
В 1930-1940 гг. были разработаны первые математические абстракции, предназначенные для формализации алгоритмов: нормальные алгорифмы Маркова, машины Тьюринга, лямбда-исчисление Алонзо Чёрча…
В это же время, в 1940-е годы, появились электрические цифровые компьютеры и был разработан язык, который можно считать первым высокоуровневым языком программирования для ЭВМ.
До появления архитектуры фон Неймана в середине 40 г первые современные цифровые компьютеры имели встроенные в машину наборы исполняемых команд. Данный подход был не слишком удобен, что привело к разделению аппаратного и программного обеспечения (появлению архитектуры хранимых программ или архитектуры фон Неймана). Абстракция программы была призвана решить назревающую проблему сложности вычислений (2015).
Всего через несколько лет в начале 50 гг. Грейс Хоппер создала первый в мире компилятор и язык программирования MATH-MATIC, который стал прообразом Кобола и Фортрана.
Далее развитие программирования шло очень бурно. Волны миниатюризации ЭВМ сопровождались увеличением их вычислительных возможностей, что приводило к увеличению размера и сложности программ. Стоимость вычислительных систем постепенно снижалась, тогда, как стоимость ПО стремительно возрастала. Все это приводило к развитию приемов и парадигм, направленных на сокращение объема программ и повышение продуктивности труда разработчика ПО. Появление новых возможностей: более производительных средств вычислительной техники и продвинутых технологий программирования (например, структурного программирования) в свою очередь приводило к скачкообразному увеличению сложности ПО.
Подобный рост сложности разработки программного обеспечения привел к явлению, названному кризис программного обеспечения. Данный термин был введен Фридрихом Бауэром в 1968 г. в Германии на конференции стран НАТО «Инженерия программного обеспечения». Кризис проявлял себя самым различным образом:
- стоимость проектов превышает бюджет;
- в проектах превышаются сроки выполнения;
- ПО было слишком неэффективным;
- ПО имело слишком низкое качество;
- ПО зачастую не отвечало необходимым требованиям;
- проекты были неуправляемыми, и возникали трудности с поддержкой кода;
- программное обеспечение было непригодным для распространения и т.д.
Термин программная инженерия появился впервые на той же конференции в Германии в 1968 г. и предназначался, чтобы спровоцировать поиск решений для кризиса ПО. С тех пор это переросло в область исследований, посвященных созданию ПО, более качественного, доступного, лучше поддерживаемого и быстрее разрабатываемого.
Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 году IEEE выпустило IEEE Std 1002 ―Taxonomy of Software Engineering Standards‖.
Наконец, в 1990 году началось планирование всеобъемлющих международных стандартов. В 1995 году была выпущена первая версию международного стандарта ISO/IEC 12207 – Software Lifecycle Processes. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207.
Накопление в мире знаний, опыта разработки и применения огромного количества различных сложных программ для ЭВМ, способствовало систематизации и обобщению методов и технологий их разработки, сокращению дефектов и неопределенностей в характеристиках и качестве поставляемых и применяемых программных продуктов. В результате в 90-е годы в основном сформировалась современная методология и инженерная дисциплина обеспечения процессов жизненного цикла сложных программных продуктов – программная инженерия для различных областей применения.
1.3.2 Что же происходило у нас?
На протяжении нескольких десятилетий XX века в Советском Союзе происходило практически независимое от Запада, оригинальное развитие отечественной вычислительной техники и программирования, науки и техники в этой области. Созданные нашими учеными и инженерами сложные вычислительные системы и комплексы программ для различных сфер применения многие годы находились на уровне мировых достижений и не содержали зарубежных компонентов (Липаев, 2010).
Важнейшее направление составляли крупные комплексы программ реального времени для сложных систем управления и обработки информации, которые создавались большими коллективами специалистов преимущественно для оборонных систем и оформлялись в виде программных продуктов с гарантированным качеством. Методологии управления проектами ПС зависели от многих факторов: от персонала, технических, организационных и договорных требований и сложности функций программ. Организованная, контролируемая и слаженная коллективная разработка при строгом учете и контроле каждого изменения, являлась основой эффективного поступательного развития каждой крупной системы методами программной инженерии. Однако методологические и технологические достижения в этой области передовых предприятий оборонной промышленности оставались секретными, не отражались в открытых публикациях и были неизвестны даже специалистам близких по функциям и задачам предприятий.
Разработки комплексов программ для оборонных систем с самого начала отличались организованностью и тесным взаимодействием с заказчиками. При этом требования заказчиков к функциям и качеству программных продуктов хронически превышали возможности разработчиков и ресурсы доступных вычислительных машин. Это стимулировало совершенствование тех и других и необходимость формализации технологий применявшейся тогда программной инженерии. Одновременно повышалась производительность труда специалистов и качество программного продукта. Результатами этих усилий в разработке сложных комплексов программ для оборонных систем стало то, что в период 1960–90-х годов основные отечественные системы вооружения с использованием вычислительной техники имели функциональные характеристики и качество, практически адекватные аналогичным оборонным системам в США (Липаев, 2010).
Однако в 80-е годы государственная политика в области вычислительной техники и программирования круто изменилась в сторону копирования и массового нелегального заимствования программных средств западных фирм. Это привело к деградации и отставанию на десяток лет отечественной школы программной инженерии. Ориентация на программные продукты, поступающие на рынок с Запада, не могла удовлетворить многие специфические проблемы конкретного создания и применения программных продуктов в стране.
В 1990-е годы программная инженерия в стране (как и вся промышленность) переживала глубокий спад. До недавнего времени типичный способ разработки ПО в России был ориентирован на программистов-одиночек, программистов-кустарей. Интереса к индустриальному производству ПО почти не было из-за низкого платежеспособного спроса на сложные программные комплексы. Разработка программного обеспечения велась спонтанно, не уделялось особого внимания вопросам организации самого процесса: планированию, тестированию, межгрупповому взаимодействию, управлению конфигурацией (Рябикин, 2003).
Однако в последние годы наблюдается взросление экономики страны, а вслед за ней и технологий производства. Возросшая конкуренция на внутреннем рынке и попытки выхода на мировой резко повысили интерес к повышению производительности труда в экономике России, рост которой сейчас напрямую связывают с информатизацией. Возросла ценность программного обеспечения и, таким образом, интерес к постановке индустриального процесса разработки ПО заметно усилился. Отрасль производства программного обеспечения растет и переходит от кустарных разработок к промышленным методам, так как первые просто становятся невыгодны экономически. Кроме того, активно развивается отрасль “оффшорного” программирования, при которой непосредственно производство программ передается в страну, имеющую квалифицированных недорогих специалистов. Таким образом, конкуренция и работа с западными заказчиками стали подталкивать отечественных программистов к совершенствованию своих методов работы (Рябикин, 2003).
1.4 Основные проблемы программной инженерии
1. Объективная сложность создаваемых систем.
2. Кустарный подход к производству.
3. Незнание основ экономики в сфере производства ПП
4. Проблемы формализации ПИ.
5. Рост требований к качеству.
6. Проблемы профессиональной квалификации
7. Зависимость успеха проекта от индивидуальных особенностей исполнителей.
| «Есть два способа разработки проекта: сделать его настолько простым, чтобы было очевидно, что в нем нет недостатков, или сделать его настолько сложным, чтобы в нем не было очевидных недостатков» Хоар, Чарльз Энтони Ричард – английский учёный, специализирующийся в области информатики и вычислительной техники, лауреат премии Тьюринга, разработчик алгоритма быстрой сортировки и т.д. |
Массовое создание сложных программных продуктов промышленными методами и большими коллективами специалистов вызвало необходимость их четкой организации, планирования работ по требуемым ресурсам, этапам и срокам реализации. Индустриализация производства комплексов программ позволяет автоматизировать нетворческие, технические и рутинные операции и этапы, а также облегчить творческие процессы за счет селекции, обработки и отображения информации, необходимой для принятия творческих решений. Однако, с повышением инструментальной оснащенности технологии разработки ПО (опять-таки) растут также размеры и сложность программных продуктов (Липаев, 2010).
Американский психолог Джордж Миллер обнаружил закономерность, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7±2 элементов. Это существенное ограничение нашего сознания необходимо учитывать на всех этапах создания сложных систем.
Дейкстра, Э́дсгер Ви́бе (1930-2002) – нидерландский учёный в области информатики и программирования, один из разработчиков концепции структурного программирования, лауреат премии Тьюринга.
|
Кустарный подход к производству. На сегодняшний день на многих предприятиях и в вузах отношение к программам для ЭВМ исторически базируется на подходе как к «искусству и художественному творчеству» отдельных специалистов (программирование «в малом»). При этом считается, что невозможно применять какие-либо экономические характеристики для определения
| Что означает слово «кустарный»? Какой вид производства противопоставляется кустарному? Чем характеризуется «кустарное производство»? Чем характеризуется «массовое производство»? |
| В 1902 году, на Съезде деятелей кустарной промышленности участники съезда попытались дать определение кустарной и ремесленной промышленности, но после длительных дебатов отказались от этой попытки. |
Программное средство
Объект, состоящий из программ, процедур, правил, а также, если предусмотрено, сопутствующих им документации и данных, относящихся к функционированию системы обработки информации.
Требование
Требования это спецификация того, что должно быть реализовано.
В них описано поведение системы, свойства системы или ее атрибуты.
Они могут служить ограничениями в процессе разработки системы.
Качество программного обеспечения
Совокупность свойств ПО, которые обусловливают его пригодность удовлетворять заданные или подразумеваемые требования в соответствии с его назначением.
Надежность ПО
| Чем отличаются ошибка, дефект и сбой? Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья. Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом. Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ. Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! В системе произошел сбой — проявился ранее скрытый дефект. |
Ошибка, дефект, сбой
Ошибка – неправильность в действиях.
Дефект – результат ошибки.
Сбой – результат проявления дефекта.
1.6 Итоги занятия
ü Программная инженерия содержит свод общепринятых знаний и правил, накопленных в мире за последние 40-50 лет разработки ПО.
ü Основная проблема разработки ПО – сложность (под этим понимается как объективная сложность программируемых процессов или явления, так и сложность управления и организации процесса разработки);
ü Для успешного выполнения программного проекта (да впрочем и любого) требуется нечто большее, чем армия умных и технически грамотных людей.
ü Адекватное планирование, прогнозирование трудовых и временных затрат, оценка и контроль в процессе производства ПО возможны, но для этого необходимо наличие явно определенных рационально организованных производственных процессов и опыт их применения, что в совокупности называется зрелостью процессов организации.
Грубо говоря, основное содержание данной лекции – это «философские рассуждения», направленные на достижение одной цели: показать важность ПИ.
Остальные лекции напротив будут иметь вполне конкретное содержание, связанное с отдельными областями знаний ПИ, такими как: управление требований, проектирование или конструирование программных систем. Следующая лекция (одна из самых важных) является базовой и характеризует в целом процессный подход к управлению программным проектами.
Спасибо за внимание!
2. Жизненный цикл и процессы разработки ПО
4 часа
Цели данной лекции:
1. Раскрыть значения и связь понятий жизненный цикл и процесс программной инженерии;
2. Рассмотреть основные модели жизненного цикла программных продуктов;
3. Рассмотреть структуру процессов программной инженерии.
4. Рассмотреть (кратко) основные виды деятельности по управлению процессами: реализация, изменение, определение, оценка процессов, а также и измерение процессов и продуктов;
5. Рассмотреть модель зрелости процессов.
Сегодняшняя лекция показывает насколько все-таки справедливо слово «Введение» в названии нашего курса. Просто на то, чтобы структурировать (по сути перечислить) основные процессы программной инженерии у нас уйдет больше часа. Небольшая доля перечисленных процессов (самые основные) будут рассматриваться на обзорном уровне в оставшейся части курса лекций.
Вы также прочувствуете, почему настоящий сильно связан с управленческой деятельностью и управлением проектами.
Очень (очень!) кратко затронем общепринятые подходы к улучшению процессов, в частности на примере модели зрелости процессов (CMM-SW – Capability Maturity Model for Software) – стандартизованного пошагового подхода к повышению продуктивности деятельности в организациях-разработчиках ПО.
2.1 Основы жизненного цикла программных средств
Одними из основных понятий программной инженерии являются понятия жизненного цикла программного средства и программного процесса.
Жизненный цикл системы
Это непрерывный процесс, охватывающий различные состояния системы, начиная с момента возникновения необходимости в такой системе и заканчивая её полным выводом из эксплуатации.
Модель жизненного цикла
Это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
Иначе говоря, модель ЖЦ – это упрощенное описание жизненного цикла, представленное с некоторой точки зрения. В модели мы говорим, что и как мы будем делать – т.е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять.
Выбор модели жизненного цикла является первым шагом в создании ПО. Правильный выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор тяжелых процессов может утопить проект, а слишком легкое отношение к процессам – к потере контроля над ходом выполнения.
| Для понятий разработка требований, проектирование, конструирование, тестирование, документирование мы будем впредь использовать термин процессы, а не этапы, т.к. этапность подразумевает привязку ко времени и последовательное выполнение указанных действий, что справедливо только для каскадной (водопадной) модели. |
Процесс
Совокупность взаимосвязанных действий, направленных на достижение определенных результатов.
Процессы являются элементами жизненного цикла. Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит следующим образом:
Ø Категория процессов
v группа процессов
¨ процессы
· работы
ü задачи
Состав и степень определенности процессов программной инженерии непосредственно влияют на производительность труда и результат проекта.
Конечно, не только процессы непосредственно влияют на результат проекта. Существуют и другие факторы, играющие не менее важную роль, например, возможности инструментов и потенциал, знания и опыт специалистов. Когда оценивается влияние изменения процессов, такие факторы должны учитываться (например, попытка внедрения развитых процессов программной инженерии при отсутствии ресурсов или в неподготовленной организационной среде практически наверняка приведет к краху таких инициатив). Кроме того, важна степень институализации процессов (process institualization или process fidelity – следование заданным процессам как повседневная практика работы). Фактор институализации в большинстве случаев объясняет, почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге.
В общем случае процессы ЖЦ разнятся в разных организациях и зависят от принятой модели ЖЦ. Но можно выделить т.н. основные процессы ЖЦ.
Основными классическими процессами (этапами или фазами) жизненного цикла являются:
- разработка спецификации или разработка требований (результат - описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность;
- проектирование (результат — описание того, как программа будет работать);
- конструирование (результат - исходный код и файлы конфигурации);
- тестирование (результат - контроль соответствия программы требованиям);
- документирование (результат - документация к программе).
Примечание: На самом деле, современная программная инженерия (как мы увидим чуть дальше) рассматривает процессы разработки программных средств в контексте системной инженерии и кроме основных, выделяет много дополнительных и вспомогательных процессов, связанных не с созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, управления повторным использованием программ, разрешения противоречий, управление конфигурацией и т.д.
Инфраструктура процесса
Для внедрения процессов жизненного цикла необходимо обладать соответствующей инфраструктурой, подразумевая, что ресурсы (компетентный персонал, инструменты, финансирование) – доступны, а ответственность – распределена <по членам проектной команды и/или организационной единицы, в терминах структуры компании или организации, например, отдела или группы>. Выполнение этих задач является хорошим индикатором того, что менеджмент <управленческий персонал проекта/организации> реально прилагает усилия по поддержке процесса программной инженерии. Как следствие таких усилий могут создаваться различные комитеты и другие специализированные организационные структуры и органы, в общем случае называемые steering committee – “управляющий комитет”, обладающий наблюдательными функциями в отношении усилий, направленных на мониторинг, контроль и выработку рекомендаций по поддержке и улучшению процесса программной инженерии. На основе таких функций будем в дальнейшем использовать термин “наблюдательный орган”, подчеркивая реальные задачи такой комиссии и возможность как формальной, так и неформальной его организации.
Наблюдательный орган является основой процессной инфраструктуры в проектной команде, подразделении или организации, в целом. Обычно, выделяют два типа инфраструктуры, применяемые на практике Software Engineering Process Group (SEPG, обычно, в русском языке для такой структуры используется приведенная англоязычная аббревиатура) и Experience Factory (EF, “фабрика опыта”).
SEPG создается как центральный орган, принимающий на себя работу по совершенствованию процессов. SEPG берет на себя ответственность по множеству вопросов, связанных с этой задачей в терминах инициирования улучшений, поддержки существующего процесса и его постоянного совершенствования.
Часто SEPG формируется из нескольких ведущих членов проектной команды (если, SEPG создается в рамках проекта) или на уровне подразделения или всей организации. При этом, в большинстве случаев, SEPG не включает “освобожденных” специалистов и, таким образом, ее члены всегда находятся в контексте реальных проблем, с которыми сталкиваются выполняя свои “основные” обязанности. Исключение, обычно, составляют SEPG, формируемые для достижения определенных организационных целей - приведения процессов в соответствие тем или иным требованиям и, в частности, для достижения того или иного уровня зрелости процессов (рассмотрим далее, что это такое), обеспечения качества в рамках национального стандарта и т.п. В этих случаях SEPG обычно возглавляется выделенным экспертом (или группой) в области постановки и совершенствования процессов.
Концепция фабрики опыта отделяет проектную организацию (например, организационную структуру, отвечающую за разработку программного обеспечения – ИТ-подразделение, группу разработки или проектную команду) от организации, отвечающей за улучшение процесса. Проектная организация, в этом случае, фокусируется на разработке и сопровождении программного обеспечения, а EF – занята совершенствованием процесса программной инженерии.
Основной задачей фабрики опыта является институализация (внедрение в повседневную практику) коллективного опыта и полученных уроков в масштабах организации на основе разработки, обновления и внедрения в проектную организацию “пакетов опыта” (например, руководств, моделей, курсов обучения и т.п.), типовых активов процесса. Проектная организация предлагает на рассмотрение фабрике опыта свои продукты, планы, использовавшиеся при разработке, а также данные, собранные в процессе разработки и эксплуатации.
Управление процессами в области программного обеспечения состоит из четырех действий, представленных в рамках итеративного цикла. Это позволяет получать и анализировать отклики на постоянной основе и, <более оперативно> совершенствовать процесс. Вот эти четыре действия, предлагаемые SWEBOK
Адаптация процесса
Важно отметить, что предопределенные процессы, даже стандартизированные, должны адаптироваться в соответствии с локальными (конкретными) потребностями, например, организационным контекстом, размером проекта, регулирующих требованиях, индустриальных практиках и корпоративной культурой. Ряд стандартов, в первую очередь, IEEE/ISO/ГОСТ 12207 и ISO 15504, содержат механизмы и рекомендации по процессу адаптации и его совершенствованию.
2.4.2.4 Примеры определения процесса
2.4.3 Оценка процесса
| В 1990 году стартовала европейская инициатива European Strategic Program for Information Technology (ESPRIT), целью которой было внедрение современных программных технологий в Европе. В основу инициативы легли работы Уотса Хампфри (Watts S. Humphrey) – идеолога CMMI, PSP (People Software Process) и многих других современных концепций программной инженерии как дисциплины. Результат этот инициативы был назван “Bootstrap” – “самонастройка”. В то время, как модель CMM – Capability Maturity Model (в частности, CMM-SW – CMM for Software), а потом и CMMI, разрабатывались с учетом потребностей крупных государственных структур США (в первую очередь, министерства обороны) и их подрядчиков, модель Bootstrap изначально была ориентирована на малые и средние коммерческие компании, с определенным акцентом на индивидуальные практики. |
Оценка процесса(-ов) может проводиться как неформально, подразумевая внутрикорпоративные инициативы по повышению качества, и формально (то есть с получением аттестационного документа), в том числе, с привлечением внешних специалистов по оценке и, часто, с целью подтверждения соответствующего качества/уровня зрелости процессов.
Модель оценки задает, что именно признается лучшими практиками оценки. Эти практики могут касаться только технических работ программной инженерии (например, проектирования или кодирования), а могут иметь отношение и к вопросам управления, системной инженерии, управления персоналом и т.п.
Стандарт ISO/IEC 15504 (SPICE) определяет типовую (exemplar) модель оценки и требования соответствия к другим моделям. В каждом конкретном случае используется та или иная существующая модель – CMM-SW, CMMI, Bootstrap. Также имеются и другие модели, например, ISO 9000-3 (теперь именуемый как ISO 90003) “Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to Computer Software”, являющаяся приложением общей модели качества ISO 9001 “Quality Management Systems - Requirements” к программной инженерии. Кроме того, существуют частные модели, охватывающие, например, только вопросы документирования, проектирования и т.п.
В конце данной лекции (если успеем) проведем небольшой обзор модели зрелости процессов программной инженерии (CMM-SW – Capability Maturity Model for Software).
2.4.4 Измерение процессов и продуктов
Измерения могут проводиться для поддержки инициирования реализации и изменения процессов и для оценки результатов таких работ. Также, измерения могут выполняться и в отношении самих продуктов. Более того, результаты усилий по совершенствованию процессов и продуктов, могут быть оценены только в том случае, если установлены количественные характеристики заданных параметров процессов и продуктов.
В силу того, что приложение количественных оценок к программной инженерии может быть достаточно сложным, существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе многих более детальных измерений и процессов анализа.
Ключевые понятия, термины и методы измерений в приложении к программному обеспечению определены в стандарте ISO 15939 “Software Engineering - Software Measurement Process”. Данный стандарт также определяет стандартный процесс для измерения характеристик процессов и продуктов.
Структура уровней зрелости
Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process Area), содержащих цели (Goal), обязательства по выполнению (Commitment to Perform), осуществимость выполнения (Ability to Perform), выполняемые действия (Activity Performed), их измерение и анализ (Measurement and Analysis) и проверку внедрения (Verifying Implementation). Таким образом, СММ фактически является комплексом требований к ключевым параметрам эффективного стандартного процесса разработки ПО и способам его постоянного улучшения. Выполнение этих требований, в конечном счете, увеличивает вероятность достижения предприятием поставленных целей в области качества.
2.6 Итоги занятия
ü Ключевую роль в достижении эффективности разработки ПО играют процессы управления и корпоративная культура, поэтому прежде всего оптимизировать необходимо именно подходы к управлению.
ü Современные общепринятые подходы к управлению разработкой ПО описаны в международных и отечественных стандартах и широко освящены в литературе.
ü Заниматься организацией процесса должно руководство организации или проекта, однако знать и понимать данные подходы необходимо всем участникам рабочего процесса.
ü Существуют стандартизованные (де юре или де факто) промышленные методы, определяющие стратегию поэтапного развития организаций в области разработки ПО.
3. Разработка и управление требованиями
4 часа
Почти все прошлое занятие мы посвятили обзору основных процессов программной инженерии. В соответствии с планом нашего курса, начиная с сегодняшнего занятия и до предпоследнего, мы будем рассматривать отдельные (ключевые) процессы разработки ПО.
Одним из таких «ключевых» процессов является процесс разработки и управления требованиями. О нём и поговорим сегодня..
Одной только данной теме можно посвятить целый курс. Это было бы хорошим введением в специальность бизнес-аналитика (специалиста по разработке требований). Освоение профессии аналитика требует многолетнего опыта, особых знаний и навыков. Сегодня мы всего лишь узнаем некоторые особенности работы с программными требованиями. Этого не достаточно для организации процесса. Однако, если вас заинтересует данная область знаний, могу посоветовать отличную литературу по разработке требований к ПО.
3.1 Основы программных требований
3.1.1 Общие сведения
Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени - на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями (Орлик, 2004).
По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований (Бармин, 2011).
Разработка и управление требованиями – краеугольные камни успеха любого проекта.
Что же такое требования?
Требования – это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
Обычно требования разделяются на требования к продукту , соответствущие свойствам продукта и требования к процессу, ограничения процесса, с помощью которого продукт будет создаваться.
3.1.2 Иерархия требований
На практике часто применяется подход, базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Классический пример высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса (Карл Вигерс, 2014).
Рисунок 3.1 – Уровни требований по Вигерсу
На рисунке 3.1 овалы обозначают типы информации требований, а прямоугольники – документы, в которых хранится эта информация. Сплошные линии указывают, что в указанном документе хранится информация определенного типа. Пунктирная линия указывает, что информация одного типа является источником или влияет на информацию другого типа или на требование.
Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание – бизнес-цели организации или клиента, заказывающих систему.
Примеры бизнес-целей:
1. Разработать надежную платформу для семейства связанных продуктов.
2. Увеличить долю рынка в стране W c X % до Y% за Z месяцев.
3. Сократить трудозатраты на проведение научной конференции в 2 раза.
4. Привлечь участников конференции не только из Миасса, но и из других городов России.
Помимо бизнес-целей бизнес требования включают также концепцию и границы продукта (о них речь пойдет чуть дальше). Допустим, что авиакомпания хочет на 25% снизить затраты на сотрудников у стойки в аэропорту. В процессе достижения этой цели может возникнуть идея поставить терминал, который пассажиры будут использовать для самостоятельной регистрации в аэропорту.
Как правило, бизнес-требования высказывают те, кто финансируют проект, покупатели системы, управляющий реальными пользователями, отдел маркетинга или ответственный за концепцию продукта.
Карл Вигерс (Карл Вигерс, 2014) рекомендует записывать бизнес-требования в документе концепции и границ (рассмотрим ниже).
Пользовательские требования описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта. Область пользовательских требований также включает описание атрибутов или характеристик продукта, которые важны для удовлетворения пользователей. К отличным способам представления этого вида требований относятся варианты (сценарии) использования, пользовательские истории и таблицы события-отклик. Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой. Примером сценария использования является регистрация на рейс с использованием веб-сайта или терминала в аэропорту. Будучи сформулированным в виде пользовательской истории, то же пользовательское требование может звучать так: «Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет». Важно помнить, что в большинстве проектов есть несколько классов пользователей, а также других участников, потребности которых тоже надо выявить.
Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований. Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна»: «У пассажира должна быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался» или «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место».
Функциональные требования заносят в спецификации требований к ПО, где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и в связанных с проектом функциях. Этот артефакт называют по-разному: функциональная спецификация, документ требований, техническое задание и т.п. Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями.
Термин системные требования описывает требования к продукту, который содержит многие компоненты или подсистемы (в рамках системной инженерии). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди и процессы тоже часть системы, поэтому определенные системные функции могут распространяться и на людей.
Хороший пример системы – рабочее место кассира в супермаркете. В нем есть сканер штрих-кода, интегрированный с весами, а также ручной сканер штрих-кода. У кассира есть клавиатура, монитор и выдвижной ящик-касса. Есть также устройство чтения кредитных карточек и клавиатура для ввода ПИН-кода и чтения карт постоянного покупателя. На рабочем месте установлен один или несколько принтеров: для печати чека, квитанции кредитной карты и купонов на скидку. Все эти устройства взаимодействуют под управлением программного обеспечения. На основе требований к системе или продукту в целом бизнес-аналитик формулирует конкретную функциональность, которую должны поддерживать тот или иной компонент или подсистема, а также интерфейсы взаимодействия между ними.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы (рисунок 3.2).
Рисунок 3.2 – Источники бизнес-правил
Бизнес-правила не являются сами требованиями к ПО, потому что они находятся за пределами любой системы ПО. Однако они часто налагают ограничения, определяя, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда, как в случае с корпоративными политиками безопасности, бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональных требованиях. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
В дополнение к функциональным требованиям спецификация требований к ПО содержит нефункциональные.
Атрибуты качества еще называют параметрам качества, требованиями по уровню обслуживания и т.п. Они представляют собой описание различных измерений характеристик продукта, таких как производительность, доступность и переносимость, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему.
Другие нефункциональные требования описывают внешние интерфейсы между системой и внешним миром. Речь идет о подключениях к другим программным системам, аппаратным устройствам и пользователям, а также коммуникационные интерфейсы.
Ограничения проектирования и реализации накладывают границы на возможности выбора разработчика при проектировании продукта.
Характеристика (feature) – это набор логически связанных функциональных требований, которые представляют ценность для пользователя и удовлетворяют бизнес-цели. Желательные характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки веб-браузера, средства проверки орфографии, запись макрокоманды, автоматическое обновление определений вирусов в антивирусной программе. Характеристики могут охватывать множество пользовательских требований, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач.
Обратите внимание, как много существует видов требований.
Чтобы вы лучше восприняли некоторые из различных видов требований, проанализируем проект по разработке системы регистрации участников научной конференции.
Одна из сформулированных бизнес-целей «Сократить трудозатраты на проведение конференции в 2 раза». В процессе анализа было выявлено 2 класса пользователей: «Участник конференции» и «Организатор конференции». Бизнес-правило «Участник будет допущен к выступлению, только если внесет регистрационный взнос» выявило пользовательские требования по оплате регистрационного взноса. Анализ показал, что автоматизация внесения платежей позволяет существенно уменьшить трудозатраты организаторов. Это легло в основу соответствующих вариантов использования. На основе них были сформированы функциональные требования: «Оплатить картой», «… по СМС», «оплатить наличными», «Подтвердить платеж», «Вернуть платеж» и т.д..
3.1.3 Определение концепции и границ проекта
Концепция и границы – два базовых элемента бизнес-требований.
Концепция продукта (product vision) сжато описывает конечный продукт, который достигнет заданных бизнес-целей. Этот продукт может полностью удовлетворять бизнес-требованиям или быть только частью решения. Концепция описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Она обеспечивает контекст для принятия решений на протяжении жизненного цикла продукта и выстраивает работу всех заинтересованных лиц в одном направлении.
Границы проекта (project scope) показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне.
Говоря о концепции, мы подразумеваем весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту или его итерации, в которых реализуются возможности продукта, как показано на рис. 3.3. Границы более динамичны, чем концепция, так как заинтересованные лица изменяют содержимое каждой версии в соответствии с ограничениями графика, бюджета, ресурсов и качества. Границы текущего выпуска должны быть четко определены, но границы будущих выпусков тем менее четко определены, чем более дальняя перспектива рассматривается.
Рисунок 3.3 – Концепция и границы продукта
3.1.4 Характеристики качественных требований:
3.1.4.1 Характеристики отдельных требований
Рассмотрим характеристики качества отдельных требований.
Полнота
Каждое требование должно содержать всю информацию, необходимую читателю, чтобы понять его. В случае функциональных требований это означает предоставление всей информации, необходимой разработчику, чтобы реализовать их (Карл Вигерс, 2014).
Корректность
Каждое требование должно точно описывать возможность, которая будет удовлетворять какую-то потребность заинтересованного лица и четко определять функциональность, которую надо построить. Для соблюдения корректности необходима связь с источниками требований, в качестве которых могут выступать пользователь, предоставивший начальное требование, высокоуровневое системное требование, вариант использования, бизнес-правило или другой документ. Низкоуровневое требование, которое конфликтует со своим родительским требованием нельзя считать корректными. Однако основная оценка здесь – за представителями пользователей (Карл Вигерс, 2014).
Осуществимость
Необходима возможность реализовать каждое требование при известных возможностях и ограничениях системы и рабочей среды, а также в рамках временных, бюджетных и ресурсных ограничений проекта. Разработчик, участвующий на этапе выявления требований может выполнить проверку на предмет того, что можно и что нельзя выполнить с технической точки зрения, а на что требуются только исключительные затраты и усилия. Если требование нужно удалить, потому что оно неосуществимо, нужно понимать его влияние на концепцию и границы проекта (Карл Вигерс, 2014).
Необходимость
Каждое требование должно отражать возможность, которая действительно предоставит заинтересованным лицам ожидаемую бизнес-пользу, выделит продукт на рынке или необходима для соблюдения внешних стандартов, политик или правил. Каждое требование должно поступать из источника, которое имеет полномочия на предоставление требований. Необходимо отследить каждое требование до бизнес-целей, которые четко определяют, почему оно необходимо. Если кто-то спросит, почему включено то или иное требование, у вас будет наготове обоснованный ответ (Карл Вигерс, 2014).
Определенные приоритеты
Назначьте приоритеты реализации каждому функциональному или пользовательскому требованию, варианту использования или функции, чтобы определить, насколько они важны для конкретного выпуска продукта. Если все требования одинаково важны, менеджеру проекта будет трудно справиться с нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки. Приоритизация требований должна выполняться коллективно, чтобы учесть интересы многих заинтересованных лиц (Карл Вигерс, 2014).
Недвусмысленность
Естественный язык несет в себе два типа двусмысленности. Первый тип можно определить самостоятельно, прикинув, нет ли более одного способа интерпретации данного требования. Другой тип двузначности поймать сложнее. Это происходит, когда разные люди читают одно требование, но интерпретируют его по-разному. Они находят требование содержательным, но оно имеет для них разное значение. Рецензирование — хороший способ обнаружить двусмысленности. Вам никогда не удастся полностью устранить двусмысленность из требований – такова природа человеческого языка. В большинстве случаев разумные люди делают правильные выводы даже из немного туманных требований. Но помощь со стороны коллег в виде рецензирования позволит избавиться от многих самых плохих проблем. (Карл Вигерс, 2014).
Проверяемость
Сможет ли тестировщик разработать тесты или применить другие приемы, чтобы установить, действительно ли в продукте реализовано каждое требование? Если требование не поддается проверке, вопрос корректности его реализации становится предметом оценки, а не объективного анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не поддаются проверке.
3.1.4.2 Характеристики наборов требований
Недостаточно получить прекрасные отдельные формулировки требований. Некоторые характеристики качества применимы только к набору требований (как к системе). Рассмотрим их поподробнее.
Полнота
Никакие требования или необходимые данные не должны быть пропущены. На практике никогда не документируются все и каждое требование к системе. Всегда есть предполагаемые и подразумеваемые требования, хотя они и более рисковые, чем явно сформулированные требования. Недостающие требования сложно обнаружить, потому что их просто нет!
Согласованность
Согласованные требования не конфликтуют с другими требованиями того же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Если не устранить несогласованность требований до начала процесса разработки, ее придется устранять разработчикам. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если будет обнаружен конфликт. Выявить несоответствия может быть сложным, если соответствующая информация хранится в разных местах, например в документе концепции и границ проекта и в средстве управления требованиями.
Способность к модификации
Требование всегда можно переписать, но нужно поддерживать историю изменений каждого требования, особенно после достижения базового соглашения о требованиях. Нужно также знать о связях и зависимостях между требованиями, чтобы можно было найти те, что должны меняться одновременно. Возможность модификации диктует, что каждое требование должно уникально именоваться и выражаться отдельно от других, чтобы на него можно было однозначно ссылаться из других требований (Карл Вигерс, 2014).
Требования должны быть поставлены под контроль конфигурационного управления, также как исходные тексты или тестовые варианты.
Для сохранения возможности модификации необходимо избегать излишней информации в требованиях. Повторяя требования в нескольких местах спецификации требований к ПО, где они уместны, вы облегчаете чтение документа, но затрудняете его поддержку. Одинаковые требования придется изменять одновременно, в противном случае возникнет несогласованность. Перекрестные ссылки на связанные между собой элементы в спецификации вам синхронизировать внесение изменений. Храня отдельные требования в средстве управления требованиями или в базе данных только один раз, вы решите проблему избыточности и упростите повторное использование требований, общих для нескольких проектов (Карл Вигерс, 2014).
| Вам никогда не удастся создать идеальную спецификацию, в которой бы у всех требований присутствовали все эти атрибуты. Однако если вы будете помнить об этих характеристиках при написании и проверке требований, вы создадите более качественную спецификацию требований, а значит, и программный продукт. |
Отслеживаемое требование можно отследить как назад, к первоисточнику, так и вперед, к производным требованиям, элементам дизайна и исходному коду, который его реализует, а также к тестам, которые позволяют проверить корректность реализации.
3.1.5 Важность взаимодействия с клиентом
Отдельно стоит отметить важность взаимодействия с представителями клиента (пользователем, заказчиком и т.д.).
Герхард, старший менеджер компании Contoso Pharmaceuticals, встретился с Синтией, начальником ИТ-отдела. «Нам нужно создать новую систему учета химических препаратов Chemical Tracking System, – начал Герхард. – Она должна обеспечить учет всех химических контейнеров на складе и в лабораториях. Если химикам понадобится новый реактив, который уже есть в компании, они смогут взять его в соответствующем отделе, не тратя деньги на заказ нового контейнера. Система сэкономит компании уйму денег. Кроме того, она позволит отделу охраны труда и техники безопасности тратить меньше сил на создание предоставляемых в контролирующие органы отчетов об использовании и утилизации химикатов. Ты сможешь создать систему к началу аудита, который у нас будет через пять месяцев?»
«Понимаю, почему этот проект важен, Герхард, – сказала Синтия. – Но прежде чем я набросаю график разработки проекта, нам потребуется собрать требования к системе».
Герхрад удивился: «Что вы имеете в виду? Я только что перечислил вам требования».
«На самом деле вы описали общие бизнес-цели проекта, – объяснила Синтия. – Бизнес-требования такого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько времени на это может потребоваться. Я хочу, чтобы мой аналитик поработал с несколькими пользователями и понял, что они ожидают от системы».
«Химики – занятые люди, – запротестовал он. – Вряд ли у них найдется время объяснять все подробности до того, как вы начнете писать программу. Не могут ли ваши люди сами определить, что создавать?»
Синтия попыталась объяснить: «Если мы сами будем пытаться угадать ожидания пользователей, ничего хорошего не выйдет. Мы – разработчики ПО, а не химики. Я по собственному опыту знаю, что, если не потратить время на изучение проблемы до начала программирования, результат не понравится никому».
«У нас нет времени на это, – настаивал Герхард. – Я описал вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы». (Карл Вигерс, 2014)
Такие диалоги регулярно возникают при разработке ПО. Клиенты, которым требуется новая информационная система, зачастую не понимают, насколько важно непосредственно опросить будущих пользователей и других заинтересованных лиц. Специалисты по маркетингу, разработавшие концепцию нового замечательного продукта, считают, что могут адекватно представлять интересы предполагаемых покупателей. Тем не менее, мнение непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным методикам разработки ПО, например методики гибкого программирования (agile programming), представитель заказчика должен тесно взаимодействовать с командой разработчиков.
Без адекватного участия клиента в конце проекта неизбежно возникает разрыв ожиданий (expectation gap) – пробел между тем, что клиенту реально нужно, и тем, что предоставили разработчики, основываясь на том, что они знали в начале проекта (Карл Вигерс, 2014). Это показано на рисунке 3.3.
// Отметить важность взаимодействия с клиентом Разрыв ожиданий стр 28.
Рисунок 3.3 – Частое взаимодействие с клиентом сокращает разрыв ожиданий
Наилучший способ минимизации разрыва ожиданий – организация частых точек контакта с представителями клиента. Эти точки могут принимать форму интервью, собеседований, просмотра требований, просмотра дизайна пользовательского интерфейса, оценки прототипа и т.д. Каждая точка контакта предоставляет возможность закрыть разрыв ожиданий: создаваемое разработчиком ближе к тому, что требуется клиенту.
Естественно, что разрыв начинает снова увеличиваться сразу же после каждой точки контакта. Чем чаще такие точки, тем проще двигаться в правильном направлении. Как иллюстрируют маленькие серые треугольники на рис. 3.3, набор таких точек контакта позволяют в конце проекта получить намного меньший разрыв ожиданий и решение, которое намного лучше соответствует реальным потребностям клиента.
3.2 Роль бизнес-аналитика
Среди участников любого проекта по разработке ПО обязательно есть человек, явно или неявно выполняющий роль бизнес-аналитика. Стоит особенно отметить важность данной роли.
Бизнес-аналитик – это основное лицо, отвечающее за выявление, анализ, документирование и проверку требований к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков (рис. 3.4), хотя, конечно, не единственный: есть и другие. Аналитик отвечает за сбор и распространение информации о продукте, а руководитель проекта – за обмен информацией о проекте.
Рисунок 3.4 – Роль бизнес-аналитика
Аналитик – это посредник в общении, проясняющий смутные представления пользователей и обращающий их в четкие спецификации, которыми руководствуется команда разработчиков продукта.
Далее рассмотрим стандартные обязанности аналитика и необходимые ему навыки.
3.2.1 Задачи аналитика
Работа аналитика начинается с определения бизнес-требований. Аналитик помогаете куратору, менеджеру продукта или менеджеру по маркетингу определить бизнес-требования к проекту. Можно разработать шаблон документа о концепции и границах и, расспросив людей, имеющих представление о концепции системы, получить у них необходимую информацию.
Спланировать подход к работе с требованиями. Аналитик должен разработать планы выявления, анализа, документирования, проверки и управления требованиям на всем протяжении проекта и тесно сотрудничать с менеджером проекта над согласованием этих планов с общим планом проекта для достижения поставленных целей.
Определить заинтересованных лиц и классы пользователей. Совместно с кураторами следует выбрать соответствующих представителей каждого класса (см. главу 6), заручиться их поддержкой и согласовать обязанности. Запишите, какого именно сотрудничества вы ожидаете от пользователей и согласуйте уровень участия каждого из них.
Выявить требования. Профессиональный аналитик помогает пользователям четко обрисовать функции системы, необходимые им для достижения бизнес-целей, используя приемы сбора информации.
Анализировать требования. Аналитик должен искать производные требования, логически проистекающие из запросов клиентов, а также невысказанные ожидания, которые, как считают клиенты, и так будут реализованы. Он использует модели требований, чтобы выявить пробелы в требованиях, конфликтующие требования и убедиться, что все требования укладываются в границы проекта.
Документировать требования. Аналитик отвечает за создание хорошо организованного и написанного документа требований, который описывает решение, удовлетворяющее потребности клиента.
Доводить требования до заинтересованных лиц. Аналитик должен эффективно довести требования до всех участников. Аналитик должен определить, полезно ли представлять требования не текстовыми средствами, например с помощью разнообразных графических нотаций, таблиц, математических уравнений, раскадровок и прототипов. Доведение требований не ограничивается распечаткой схем и развешиванием их на стенах – это постоянное взаимодействие с командой, чтобы быть уверенным в правильности понимания доводимой аналитиком информации (Карл Вигерс, 2014).
Управлять проверкой требований. Аналитик должен гарантировать, что формулировки требований отвечают всем характеристикам, перечисленным выше, и что система, созданная на основе этих требований, устроит пользователей. Аналитики – ключевые участники рецензирования документов с требованиями. Им также следует изучить архитектуру, код и варианты тестирования, спроектированные на основе спецификаций требований, и убедиться, что требования интерпретированы правильно.
Обеспечить расстановку приоритетов требований. Аналитик обеспечивает общение и взаимодействие различных классов заинтересованных лиц с разработчиками, чтобы расставить приоритеты требований в соответствии с бизнес-целями.
Управлять требованиями. Бизнес-аналитик вовлечен во все этапы разработки ПО, его задача — помочь создать, обсудить и осуществить план управления требованиями к проекту. Определив базовую версию требований для текущего выпуска продукта или итерации разработки, бизнес-аналитик переходит к отслеживанию состояния этих требований, проверкой того, как они реализуются в продукте и управлением изменениями базовых требований. Расспрашивая коллег, аналитик собирает информацию о связях требований, сопоставляет их с прочими элементами системы.
3.2.2 Навыки, необходимые аналитику
Умение слушать.
Умение опрашивать и задавать вопросы (большая часть информации о
требованиях извлекается в ходе бесед с людьми).
Способность соображать на ходу (можно создать идеальный список вопросов для интервью, но всегда приходится задавать дополнительные вопросы.)
Навыки анализа (эффективный бизнес-аналитик способен думать на нескольких уровнях абстракции и знать, когда переходить между ними).
Навыки системного мышления (ориентируясь на детали, аналитик обязан не упускать общей картины).
Навыки обучения (аналитики должны быстро усваивать новый материал, будь то новые способы работы с требованиями или особенности предметной области. И конечно же аналитик должен честно признавать, что он чего-то не знает).
Навыки создания комфортных условий общения (умение организовывать дружескую атмосферу на семинарах для уточнения требований – один из необходимых навыков аналитика).
Лидерские качества (сильный аналитик может подталкивать группу заинтересованных лиц в определенном направлении для достижения общей цели).
Умение наблюдать.
Навыки общения (как письменной, так и устной форме).
Тестирование (Testing)
Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости. Для сопровождения системы особо значимым является выборочное регрессионное тестирование (см. тему Тестирование, пункт 6.2.2) системы или его компонент для проверки того, что внесенные изменения для привели к непреднамеренному изменению поведения программного обеспечения. Вопрос состоит в том, что часто сложно найти время для необходимого тестирования. Не меньшей проблемой является и координации в проведении тестов различными членами группы сопровождения, занимающимеся решением различных задач. Если же система выполняет критичные <для бизнеса> функции, временный вывод системы из эксплуатации (как говорят, перевод системы в offline) для выполнения тестов часто оказывается просто невозможен.
Процесс (Process)
Процесс (в общем случае, жизненный цикл, прим. автора) является набором работ (activities), методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов. На уровне процесса, деятельность по сопровождению программного обеспечения имеет очень много общего с разработкой, например, в части конфигурационного управления, являющегося критически важной составляющей обоих видов деятельности. В то же время, сопровождение включает работы, не представленные в процессе разработки (в пункте 7.3.2 представлено описание такого рода уникальных работ). Эта деятельность требует от менеджмента специального внимания.
Аутсоурсинг (Outsourcing)
Заимствованный термин “аутсоурсинг” уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону”. Крупные корпорации передают в управление другим организациям целые портфели программных систем, а, иногда, и целиком всю ИТ-инфраструктуру. В то же время, существенно более часто, сопровождение передается другим организациям только для “второстепенных” программных систем (или, как минимум, не критичных для выполнения бизнес-функций), так как владельцы таких систем не желают терять контроль над ассоциированными с этими системами данными и/или функциональностью. Отмечается, что некоторые передают работы по сопровождению “в аутсоурсинг” только в тех случаях, если убеждены в стратегическом контроле над сопровождением.
7.2.3 Оценка стоимости сопровождения (Maintenance Cost Estimation)
Как уже отмечалось, инженеры должны понимать разницу в различных категориях сопровождения. Это, в большой степени, необходимо для оценки соответствующих затрат. С точки зрения планирования, как составной части проектной и управленческой деятельности, оценка стоимости является важным аспектом деятельности по сопровождению программного обеспечения.
При обсуждении анализа влияния (см. 7.2.1.3) говорилось о том, что такой анализ помогает в оценке стоимости работ по сопровождению. На эти затраты оказывает влияние множество технических и других факторов. ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) определяет, что “существует два наиболее популярных метода оценки стоимости сопровождения – параметрическая модель и использование опыта”. Чаще всего, оба этих подхода комбинируются для повышения точности оценки.
7.2.4 Измерения в сопровождении программного обеспечения
(Software Maintenance Measurement)
Формы и данные измерений в процессе сопровождения могут объединяться в единую программу корпоративную программу количественных оценок, проводимых в отношении программного обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений (issue-driven measurement).
Существуют общие (для всего жизненного цикла) метрики и, соответственно, их категории, в частности, определяемые Институтом Программной Инженерии университета Карнеги-Меллон (Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, усилия, расписание и качество. Применение этих метрик является хорошей отправной точкой для оценки работ со стороны организации, отвечающей за сопровождение.
Более детальное обсуждение вопросов измерений в отношении продуктов и процессов представлено в области знаний “Процесс программной инженерии (Software Engineering Process). В свою очередь, вопросы организации программы измерений относятся к области знаний “Управление программной инженерией” (Software Engineering Management).
Ниже представлены типичные метрики оценки работ по сопровождению, соответствующих распространенной классификации эксплуатационных характеристик программного обеспечения:
Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы.
Изменяемость (Changeability): оценка усилий, необходимых для проведения заданных модификаций.
Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования.
Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.
7.3 Процесс сопровождения (Maintenance Processes)
Вопросы организации процесса сопровождения напрямую связаны с соответствующими стандартами и de facto практиками реализации такого процесса. Тема “Работы по сопровождению” (Maintenance Activities) различает вопросы сопровождения и разработки и показывает взаимосвязь c другими аспектами деятельности программной инженерии.
Типичные и распространенные потребности в процессах программной инженерии подробно описаны и документированы в различных источниках. Одна из наиболее детально проработанных и распространенных (на уровне стандарта de facto) процессных моделей, изначально созданных с ориентацией на программное обеспечение – CMMI (Capability Maturity Model Integration – интегрированная модель зрелости), разработанная в Институте программной инженерии университета Карнеги-Меллон (SEI CMU – см. подраздел 2.5). CMMI, в частности, уделяет специальное внимание процессам сопровождения.
7.3.1 Процессы сопровождения (Maintenance Processes)
Стандарт ISO/IEC 14764 уточняет положения, связанные с процессом сопровождения, стандарта жизненного цикла 12207. Работы по сопровождению, описанные в этом стандарте аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе (см. рисунок 3).
Рисунок 7.1 – Процесс сопровождения по стандарту ISO/IEC 14764
7.3.2 Работы по сопровождению (Maintenance Activities)
Работы по сопровождению в стандарте 14764 разбиты на задачи:
· реализация процесса (Process Implementation);
· анализ проблем и необходимых модификаций (Problem and Modification Analysis);
· реализация изменений (Modification Implementation);
· оценка и принятие проведенных работ при сопровождении (Maintenance Review/Acceptance);
· миграция <на модифицированную или новую версию программного обеспечения> (Migration);
· вывод из эксплуатации (Software Retirement).
Как уже отмечалось, многие работы по сопровождению похожи на аспекты деятельности по разработке. В обоих случаях необходимо проводить анализ, проектирование, кодирование, тестирование и документирование. Специалисты по сопровождению должны отслеживать требования так же, как и инженеры-разработчики и обновлять документацию по мере разработки и/или выпуска обновленных или новых релизов продукта. В то же время, деятельность по сопровождению обладает и определенными уникальными чертами, что приводит к необходимости использования специализированных процессов.
Уникальные работы
Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению. SWEBOK приводит следующие примеры такого рода уникальных характеристик:
Передача (Transition): контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей за дальнейшую поддержку;
Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection): запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по различным обоснованным причинам – объему и/или сложности требуемых изменений, а также необходимых для этого усилий.
Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk): функция поддержки конечных пользователей, инициирующая работы по оценке (assessment, подразумевая в том числе оценку необходимости), анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.
Анализ влияния (Impact Analysis): анализ возможных последствий изменений, вносимых в существующую систему - рассматривался выше в теме 7.2.1.3.
Поддержка программного обеспечения (Software Support): работы по консультированию пользователей, проводимые в ответ на их информационные запросы (request for information), например, касающиеся соответствующих бизнес-правил (см. область знаний “Требования к программному обеспечению”), проверки, содержания данных и специфических вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, непониманию аспектов работы с системой и т.п.).
Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса - Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.
7.3.2.2 Работы по планированию сопровождения
(Maintenance planning activity)
Планирование является более чем необходимым для адекватного проведения работ по сопровождению и должно касаться связанных с этим вопросов с нескольких точек зрения:
· бизнес-планирование (организационный уровень);
· планирование непосредственных работ по сопровождению (уровень передачи программного обеспечения);
· планирование выпусков/версий (уровень программного обеспечения);
· планирование обработки конкретных запросов на изменение (уровень запроса).
На уровне индивидуального запроса, работы по планированию проводятся вместе с проведением анализа влияния.
В свою очередь, планирование выпусков/версий требует от персонала сопровождения выполнения задач:
· получения и сбора информации о датах размещения индивидуальных запросов и отчетов;
· достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих выпусков/версий ПО;
· идентификации потенциальных конфликтов и возможных альтернатив
· оценки рисков для текущего выпуска и разработки плана отката на немодифицированный (текущий, до внесения изменений, касающихся рассматриваемого запроса) вариант системы, в случае возникновения проблем, связанных с модификацией;
· информирования всех заинтересованных лиц.
Несмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (что более типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) и активная эксплуатация систем занимает несколько лет, а то и более (5-10-...). Проведение оценки ресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть оценены и заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества.
Вначале необходимо определить концепцию сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) должен касаться следующих вопросов:
· содержания деятельности по сопровождению;
· адаптации процесса сопровождения;
· идентификации организации, которая будет заниматься сопровождением;
· оценки стоимости сопровождения.
После разработки концепции деятельности по сопровождению должен быть сформирован соответствующий план сопровождения. Этот план должен подготавливаться одновременно с разработкой программной системы. План должен определять как пользователи будут размещать свои запросы на модификацию (изменения) или сообщать об ошибках, сбоях и проблемах.
Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе, профильное, если речь идет о потребителях ИТ) подразделение организации/компании.
Инспекции (Inspections)
“Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Существует два серьезных отличия инспекций от оценок (управленческой и технической):
1. Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях.
2. Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования.
Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Команда инспектирования (как временная организационная единица) включает лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники к небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией инспекции и проверяет, что все члены команды подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами программного продукта, вызывающими интерес. Результирующий лист часто классифицирует аномалии и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:
1. Принятие <продукта> с отсутствием либо малой необходимостью переработки.
2. Принятие <продукта> с проверкой переработанных фрагментов.
3. Необходимость повторной инспекции.
Инспекционные встречи занимают, обычно, несколько часов, в отличие от технической оценки и аудита, предполагающих, в большинстве случаев, больший объем работ и, соответственно, длящиеся дольше.
Прогонки (Walk-throughs)
“Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью ознакомления (обучения) аудитории с программным продуктом.” - IEEE 1028-97 “IEEE Standard for Software Reviews”. Главные цели прогонки состоят (по IEEE 1028) в:
Поиске аномалий
Улучшении продукта
Обсуждении альтернативных путей реализации
Оценке соответствия стандартам и спецификациям
Прогонка похожа на инспекцию, однако, обычно проводится менее формальным образом. В основном, прогонка организуется инженерами для других членов команды с целью получения отклика от них на свою работу, как одного из элементов (техник) обеспечения качества.
Аудиты (Audits)
“Назначением аудита программного обеспечения является независимая оценка программных продуктов и процессов на предмет их соответствия применяемым регулирующим документам, стандартам, руководящим указаниям, планам и процедурам.” – IEEE 1028-97 “IEEE Standard for Software Reviews”. Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде разработки для принятия корректирующих действий.
При том, что существуют различные формальные названия (и классификации) оценок и аудита (например, как мы видели в стандарте IEEE 1028-97), важно отметить, что такого рода действия могут проводиться почти для любого продукта на любой стадии процесса разработки или сопровождения.
10.3 Практические соображения (Practical Considerations)
10.3.1 Требования к качеству программного обеспечения
(Software Quality Requirements)
Тестирование (Testing)
Процессы подтверждения качества, описанные в планах обеспечения качества (SQA) и валидации и верификации (V&V), исследуют и оценивают любой выходной продукт, связанный со спецификацией требований к программному обеспечению, на предмет трассируемости, согласованности, полноты/завершенности, корректности и непосредственно выполнения требований. Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. Деятельность по обеспечению качества ПО обеспечивает гарантию того, что соответствующие типы тестов спланированы, разработаны и реализованы, а валидация и верификация – разработку планов тестов, стратегий, сценариев и процедур тестирования.
10.3.4 Количественная оценка качества программного обеспечения (Software Quality Measurement)
Модели качества программных продуктов часто включают метрики для определения уровня каждой характеристики качества, присущей продукту.
Если характеристики качества выбраны правильно, такие измерения могут поддержать уровень качества многими способами. Метрики могут помочь в управлении процессом принятия решений. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах. Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях, определенных SQA, так и с точки зрения более долгосрочного процесса совершенствования достигаемого качества.
С увеличением внутренней сложности, изощренности программного обеспечения, вопросы качества выходят далеко за рамки констатации факта – работает или не работает программное обеспечение. Вопрос ставится – насколько хорошо достигаются количественно оцениваемые цели качества.
Стоимость процесса SQM является одним из проблемных вопросов, который всегда всплывает в процессе принятия решения о том, как будут организованы проектные работы. Часто, используются общие модели стоимости, основанные на определении того, когда именно дефект обнаружен и как много усилий необходимо затратить на его исправление по сравнению с ситуацией, если бы дефект был найден на более ранних этапах жизненного цикла. Проектные данные могут помочь в получении более четкой картины стоимости.
Наконец, сама по себе SQM-отчетность обладает полезной информацией не только о самих процессах, но и о том, как можно улучшить все процессы жизненного цикла. Обсуждение этой темы, в частности, представлено в стандарте IEEE 1012-98 “Software Verification and Validation”.
| Анализ Парето получил свое название по имени итальянского экономиста Вильфредо Парето, который в 1897 году сформулировал принцип «неправильного распределения благосостояния в обществе». Он утверждал, что большая часть капитала (80%) находится в руках у незначительного количества людей (20%). Парето разработал логарифмические математические модели, описывающие это неоднородное распределение. |
· Основанные на статистических методах (например, анализ Pareto, нормальное распределение и т.п.).
· Статистические тесты.
· Анализ тенденций.
· Предсказание (например, модели надежности).
Техники, основанные на статистических методах и статистические тесты часто предоставляют “снимок” наиболее проблемных областей исследуемого программного продукта (и, кстати, то же часто верно и в отношении процессов). Результирующие графики и диаграммы визуально помогают лицам, принимающим решения, в определении аспектов, на которых необходимо сфокусировать ресурсы <проекта>. Результаты анализа тенденций могут демонстрировать, что нарушается расписание, например, при тестировании; или что сбои определенных классов становятся все более частыми до тех пор, пока не предпринимаются корректирующие действия в процессе разработки. Техники предсказания помогают в планировании времени тестов и в предсказании сбоев.
SWEBOK предоставляет ссылки на источники, в которых более подробно рассматриваются аспекты анализа дефектов (defect analysis), количественной оценки возникновения дефектов и последующего применения статистических методов для формирования понимания типов наиболее часто встречающихся типов дефектов и отвечая на вопрос соответствующей оценки плотности дефектов <различных типов>. Они могут, также, помочь в понимании тенденций и оценке того, насколько хорошо работают техники обнаружения дефектов и насколько успешно развиваются (как в плане выполнения, так и в контексте совершенствования) процессы разработки и сопровождения.
Оценка покрытия тестами (test coverage) облегчает формирование ожиданий в отношении оставшегося объема тестирования и предсказании возможного количества дефектов, которые будут еще обнаружены <до окончания процесса тестирования>. На основе этих методов количественной оценки могут быть сформированы, так называемые профили дефектов (defect profiles) для конкретных прикладных областей (application domains). В дальнейшем, для будущих программных систем в данной организации, такие профили могут направлять процессы SQM, увеличивая усилия, направленные на наиболее вероятные источники проблем в создаваемых продуктах. Аналогично этому, результаты эталонных сравнений (benchmarks) или типовое для данной прикладной области количество дефектов могут служить в качестве вспомогательных средств для определения момента, когда продукт готов для передачи в эксплуатацию (помните обсуждение концепции “приемлемого качества”?).
11. Инструменты и методы
Перечень сокращений
ПО – программное обеспечение
ПС – программная система
ПИ – программная инженерия
ПП – программный продукт
ПС – программное средство
Список литературы
Бармин Александр Управление требованиями к IT-проектам [В Интернете] // Хабрахабр. - 2011 г.. - 2015 г.. - http://habrahabr.ru/post/114571/.
Батоврин В.К. Образование в системной инженерии – проблемы подготовки специалистов для создания конкурентоспособных систем [В Интернете] // http://www.e-joe.ru/. - 02 2010 г.. - 08 2015 г.. - http://www.e-joe.ru/i-joe/i-joe_02/files/batovrin.pdf.
ГОСТ Р ИСО/МЭК 12207-2010 – Системная и программная инженерия. Процессы жизненного цикла программных средств. - 2010 г..
Карл Вигерс Джой Битти Разработка требований к программному обеспечению [Книга]. - М. : Издательство "Русская редакция" ; СПб. : БХВ-Петербург, 2014. - 3-е изд., дополненное : стр. 736.
Липаев В. Программная инженерия. Методологические основы [Книга]. - М. : Издательство «Теис», 2006.
Липаев В.В. Проблемы образования в программной инженерии [Журнал] // Открытое образование. - 2010 г.. - 3 (80). - стр. 91-100.
Макконел Стив Совершенный код. Мастер-класс / Пер. с англ. [Книга]. - СПб. : Питер, 2005. - стр. 896.
Орлик Сергей Основы программной инженерии (по SWEBOK) [Книга]. - 2004.
Программная инженерия – Википедиа [В Интернете]. - 2015 г.. - 2015 г.. - https://ru.wikipedia.org/wiki/Программная_инженерия.
Рябикин В. Модель зрелости процессов разработки программного обеспечения - перевод стандарта [Книга]. - 2003.
Соммервилл Иан Инженерия программного обеспечения [Книга]. - М. : Издетельский дом "Вильямс", 2002. - 6-е издание : стр. 624.
Э. Гамма Р. Хелм, Р. Джонсон, Д. Влиссидес Приемы объектно-ориентированного проектирования. Паттерны проектирования [Книга]. - СПб. : Питер, 2010.
ISO/IEC 15939:2007 Systems and software engineering — Measurement process
Гради-Буч «Объектно-ориентированный анализ и проектирование»
Какие темы будут освещены?
| Тема | Рассматривается |
| 1. Назначение программной инженерии | Краткий обзор причин, истории возникновения и становления ПИ; Основные проблемы и ключевые понятия ПИ. |
| 2. Жизненный цикл и процессы разработки ПО | Понятия программный процесс, модель жизненного цикла и модель организации работ. Основные процессы программной инженерии, модели жизненного цикла ПО. Объясняется, что такое определение процесса и оценка процесса. Рассказывается об измерение в отношении процесса и продукта. На базовом уровне вводится понятие модели зрелости процессов |
| 3. Разработка и управление требованиями | Ключевые понятия, связанные с разработкой и управлением требованиями. Описываются ключевые процессы работы с требованиями: извлечение, анализ, создание спецификаций требований, их проверка и трассировка. |
| 4. Проектирование | Ключевые вопросы проектирования. Понятие архитектуры ПО, Анализ качества архитектуры Нотации проектирования. Стратегии и методы проектирования. |
| 5. Конструирование | (Конструирование – это область знаний (ОЗ), связанная с кодированием, низкоуровневым проектированием, отладкой и интеграцией ПО) В этой теме рассматриваются принципы управления сложностью и ожидания изменений, конструирования с возможностью проверки и повторного использования кода. Стандарты конструирования. Управление конструированием.. Интеграция. |
| 6. Тестирование | Основы тестирования ПО. Уровни тестирования. Техники тестирования. Измерение результатов тестирования. Процесс тестирования. |
| 7. Сопровождение | Технические и управленческие вопросы сопровождения. Оценка стоимости сопровождения. Измерения в сопровождении. Процессы сопровождения. Реинжиниринг. Обратный инжиниринг. |
| 8. Управление конфигурацией и изменениями | (Управление конфигурацией – это ОЗ, связанная с идентификации версий системы в определенные заданные моменты времени, с целью систематического контроля изменений, а также поддержки и сопровождения целостности и отслеживаемой конфигурации на протяжении всего жизненного цикла системы ). В данной теме рассматриваются: понятие программной конфигурации; организация управления конфигурацией и изменениями; план конфигурационного управления; идентификация, контроль и аудит программных конфигураций; управление выпуском и поставкой. |
| 9. Управление программной инженерией | Рассматриваются процессы инициирования, планирования, выполнения, оценки и закрытия программного проекта (в связи с дисциплиной управление проектами). Затрагиваются также аспекты измерений в программной инженерии. |
| 10. Управление качеством | Культура и этика программной инженерии; значение и стоимость качества; модели и характеристики качества; процессы повышения качества и управления качеством; требования к качеству. Классифицируются дефекты. Затрагивается тема количественная оценка качества ПО. |
| 11. Инструменты и методы | Инструменты работы с требованиями, проектирования, конструирования, тестирования, сопровождения, конфигурационного управления, управления инженерной деятельностью, поддержки процессов, обеспечения качества. |
1.2 Определение программной инженерии
Прежде чем дать определение непосредственно термину «инженерия программного обеспечения» рассмотрим понятия инженерия и программное обеспечение и программа.
Программное обеспечение (ПО) – совокупность компьютерных программ и программных документов, необходимых для эксплуатации этих программ.
Программа – данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
Инженерия (или инженерное дело) – область технической деятельности, включающая в себя целый ряд специализированных областей и дисциплин, направленная на практическое приложение и применение научных, экономических, социальных и практических знаний с целью обращения природных ресурсов на пользу человека. ИЛИ целенаправленное использование научных знаний в создании и эксплуатации инженерных технических устройств, являющихся результатом преобразовательной деятельности инженера.
Рассмотрим непосредственно определение программной инженерии:
Программная инженерия чаще всего определяется как системный подход к анализу, проектированию, оценке, реализации, тестированию, обслуживанию и модернизации программного обеспечения, то есть применение инженерии к разработке программного обеспечения.
Еще одно определение:
Программная инженерия – инженерная дисциплина, охватывающая все аспекты разработки ПО (Соммервилл, 2002).
Целью программной инженерии является эффективное создание программных систем.
ПИ связана с многими дисциплинами – прежде всего с информатикой, управлением проектами, инженерной психологией, экономикой предприятия и т.д.
Часто говорят, что ПИ является составной частью системной инженерии.
Системная инженерия – междисциплинарный подход и методика, определяющие полный набор технических и управленческих усилий, необходимых для того, чтобы преобразовать совокупность потребностей заказчика и других заинтересованных сторон, имеющихся ожиданий и ограничений в эффективное системное решение и поддержать это решение в течение его жизни.
| Какое определение имеет понятие «система»? |
1.3 Предпосылки развития программной инженерии
1.3.1 Что происходило во всем мире?
Можно сказать, что элементы программирования возникали еще до появления электронных вычислительных машин: уже в XIX в. были изобретены механические пианино, арифмометры, ткацкие станки, которые в определенной мере можно считать программируемыми.
В 1930-1940 гг. были разработаны первые математические абстракции, предназначенные для формализации алгоритмов: нормальные алгорифмы Маркова, машины Тьюринга, лямбда-исчисление Алонзо Чёрча…
В это же время, в 1940-е годы, появились электрические цифровые компьютеры и был разработан язык, который можно считать первым высокоуровневым языком программирования для ЭВМ.
До появления архитектуры фон Неймана в середине 40 г первые современные цифровые компьютеры имели встроенные в машину наборы исполняемых команд. Данный подход был не слишком удобен, что привело к разделению аппаратного и программного обеспечения (появлению архитектуры хранимых программ или архитектуры фон Неймана). Абстракция программы была призвана решить назревающую проблему сложности вычислений (2015).
Всего через несколько лет в начале 50 гг. Грейс Хоппер создала первый в мире компилятор и язык программирования MATH-MATIC, который стал прообразом Кобола и Фортрана.
Далее развитие программирования шло очень бурно. Волны миниатюризации ЭВМ сопровождались увеличением их вычислительных возможностей, что приводило к увеличению размера и сложности программ. Стоимость вычислительных систем постепенно снижалась, тогда, как стоимость ПО стремительно возрастала. Все это приводило к развитию приемов и парадигм, направленных на сокращение объема программ и повышение продуктивности труда разработчика ПО. Появление новых возможностей: более производительных средств вычислительной техники и продвинутых технологий программирования (например, структурного программирования) в свою очередь приводило к скачкообразному увеличению сложности ПО.
Подобный рост сложности разработки программного обеспечения привел к явлению, названному кризис программного обеспечения. Данный термин был введен Фридрихом Бауэром в 1968 г. в Германии на конференции стран НАТО «Инженерия программного обеспечения». Кризис проявлял себя самым различным образом:
- стоимость проектов превышает бюджет;
- в проектах превышаются сроки выполнения;
- ПО было слишком неэффективным;
- ПО имело слишком низкое качество;
- ПО зачастую не отвечало необходимым требованиям;
- проекты были неуправляемыми, и возникали трудности с поддержкой кода;
- программное обеспечение было непригодным для распространения и т.д.
Термин программная инженерия появился впервые на той же конференции в Германии в 1968 г. и предназначался, чтобы спровоцировать поиск решений для кризиса ПО. С тех пор это переросло в область исследований, посвященных созданию ПО, более качественного, доступного, лучше поддерживаемого и быстрее разрабатываемого.
Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда Компьютерное Общество IEEE подготовило стандарт IEEE Std 730 по качеству программного обеспечения. После 7 лет напряженной работы, в 1986 году IEEE выпустило IEEE Std 1002 ―Taxonomy of Software Engineering Standards‖.
Наконец, в 1990 году началось планирование всеобъемлющих международных стандартов. В 1995 году была выпущена первая версию международного стандарта ISO/IEC 12207 – Software Lifecycle Processes. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99 [ГОСТ 12207, 1999] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207.
Накопление в мире знаний, опыта разработки и применения огромного количества различных сложных программ для ЭВМ, способствовало систематизации и обобщению методов и технологий их разработки, сокращению дефектов и неопределенностей в характеристиках и качестве поставляемых и применяемых программных продуктов. В результате в 90-е годы в основном сформировалась современная методология и инженерная дисциплина обеспечения процессов жизненного цикла сложных программных продуктов – программная инженерия для различных областей применения.
1.3.2 Что же происходило у нас?
На протяжении нескольких десятилетий XX века в Советском Союзе происходило практически независимое от Запада, оригинальное развитие отечественной вычислительной техники и программирования, науки и техники в этой области. Созданные нашими учеными и инженерами сложные вычислительные системы и комплексы программ для различных сфер применения многие годы находились на уровне мировых достижений и не содержали зарубежных компонентов (Липаев, 2010).
Важнейшее направление составляли крупные комплексы программ реального времени для сложных систем управления и обработки информации, которые создавались большими коллективами специалистов преимущественно для оборонных систем и оформлялись в виде программных продуктов с гарантированным качеством. Методологии управления проектами ПС зависели от многих факторов: от персонала, технических, организационных и договорных требований и сложности функций программ. Организованная, контролируемая и слаженная коллективная разработка при строгом учете и контроле каждого изменения, являлась основой эффективного поступательного развития каждой крупной системы методами программной инженерии. Однако методологические и технологические достижения в этой области передовых предприятий оборонной промышленности оставались секретными, не отражались в открытых публикациях и были неизвестны даже специалистам близких по функциям и задачам предприятий.
Разработки комплексов программ для оборонных систем с самого начала отличались организованностью и тесным взаимодействием с заказчиками. При этом требования заказчиков к функциям и качеству программных продуктов хронически превышали возможности разработчиков и ресурсы доступных вычислительных машин. Это стимулировало совершенствование тех и других и необходимость формализации технологий применявшейся тогда программной инженерии. Одновременно повышалась производительность труда специалистов и качество программного продукта. Результатами этих усилий в разработке сложных комплексов программ для оборонных систем стало то, что в период 1960–90-х годов основные отечественные системы вооружения с использованием вычислительной техники имели функциональные характеристики и качество, практически адекватные аналогичным оборонным системам в США (Липаев, 2010).
Однако в 80-е годы государственная политика в области вычислительной техники и программирования круто изменилась в сторону копирования и массового нелегального заимствования программных средств западных фирм. Это привело к деградации и отставанию на десяток лет отечественной школы программной инженерии. Ориентация на программные продукты, поступающие на рынок с Запада, не могла удовлетворить многие специфические проблемы конкретного создания и применения программных продуктов в стране.
В 1990-е годы программная инженерия в стране (как и вся промышленность) переживала глубокий спад. До недавнего времени типичный способ разработки ПО в России был ориентирован на программистов-одиночек, программистов-кустарей. Интереса к индустриальному производству ПО почти не было из-за низкого платежеспособного спроса на сложные программные комплексы. Разработка программного обеспечения велась спонтанно, не уделялось особого внимания вопросам организации самого процесса: планированию, тестированию, межгрупповому взаимодействию, управлению конфигурацией (Рябикин, 2003).
Однако в последние годы наблюдается взросление экономики страны, а вслед за ней и технологий производства. Возросшая конкуренция на внутреннем рынке и попытки выхода на мировой резко повысили интерес к повышению производительности труда в экономике России, рост которой сейчас напрямую связывают с информатизацией. Возросла ценность программного обеспечения и, таким образом, интерес к постановке индустриального процесса разработки ПО заметно усилился. Отрасль производства программного обеспечения растет и переходит от кустарных разработок к промышленным методам, так как первые просто становятся невыгодны экономически. Кроме того, активно развивается отрасль “оффшорного” программирования, при которой непосредственно производство программ передается в страну, имеющую квалифицированных недорогих специалистов. Таким образом, конкуренция и работа с западными заказчиками стали подталкивать отечественных программистов к совершенствованию своих методов работы (Рябикин, 2003).
1.4 Основные проблемы программной инженерии
1. Объективная сложность создаваемых систем.
2. Кустарный подход к производству.
3. Незнание основ экономики в сфере производства ПП
4. Проблемы формализации ПИ.
5. Рост требований к качеству.
6. Проблемы профессиональной квалификации
7. Зависимость успеха проекта от индивидуальных особенностей исполнителей.
| «Есть два способа разработки проекта: сделать его настолько простым, чтобы было очевидно, что в нем нет недостатков, или сделать его настолько сложным, чтобы в нем не было очевидных недостатков» Хоар, Чарльз Энтони Ричард – английский учёный, специализирующийся в области информатики и вычислительной техники, лауреат премии Тьюринга, разработчик алгоритма быстрой сортировки и т.д. |
Массовое создание сложных программных продуктов промышленными методами и большими коллективами специалистов вызвало необходимость их четкой организации, планирования работ по требуемым ресурсам, этапам и срокам реализации. Индустриализация производства комплексов программ позволяет автоматизировать нетворческие, технические и рутинные операции и этапы, а также облегчить творческие процессы за счет селекции, обработки и отображения информации, необходимой для принятия творческих решений. Однако, с повышением инструментальной оснащенности технологии разработки ПО (опять-таки) растут также размеры и сложность программных продуктов (Липаев, 2010).
Американский психолог Джордж Миллер обнаружил закономерность, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7±2 элементов. Это существенное ограничение нашего сознания необходимо учитывать на всех этапах создания сложных систем.
|
Дейкстра, Э́дсгер Ви́бе (1930-2002) – нидерландский учёный в области информатики и программирования, один из разработчиков концепции структурного программирования, лауреат премии Тьюринга.
|
Кустарный подход к производству. На сегодняшний день на многих предприятиях и в вузах отношение к программам для ЭВМ исторически базируется на подходе как к «искусству и художественному творчеству» отдельных специалистов (программирование «в малом»). При этом считается, что невозможно применять какие-либо экономические характеристики для определения
| Что означает слово «кустарный»? Какой вид производства противопоставляется кустарному? Чем характеризуется «кустарное производство»? Чем характеризуется «массовое производство»? |
| В 1902 году, на Съезде деятелей кустарной промышленности участники съезда попытались дать определение кустарной и ремесленной промышленности, но после длительных дебатов отказались от этой попытки. |
Незнание основ экономики в сфере производства программных продуктов
В сложных технических устройствах стоимость ПО порой составляет большую часть стоимости. Более того, стоимостные показатели отраслей, занимающихся производством ПО, становятся определяющими для экономики – как национальной, так и международной (Соммервилл, 2002).
Массовое создание сложных и дорогих программных продуктов промышленными методами и большими коллективами специалистов определило проблему достоверного экономического анализа и оценки, четкой организации производства, планирования работ по затратам, этапам и срокам реализации. Для решения этих задач еще в 80-е годы начала формироваться новая область знаний и инженерная дисциплина − экономика производства крупных программных продуктов, как часть экономики промышленности и вычислительной техники в общей экономике предприятий и государства. Ее основной задачей является прогнозирование, эффективное управление, распределение ресурсов и экономное использование необходимых быстро возрастающих капиталовложений в производство сложных комплексов программ высокого качества и различного назначения (Липаев, 2010).
Развитие этой области экономики связано с большими трудностями, типичными для новых разделов науки и техники, появляющихся на стыке различных областей знания. В данном случае особенности состоят в том, что менеджеры и разработчики комплексов программ, часто, не знают даже основ экономики промышленного производства сложной продукции, а экономисты современного производства не представляют сущности и свойств объектов разработки − программных продуктов, а также особенностей экономики технологических процессов их проектирования, производства и применения. Объективно положение осложнено трудностью измерения экономических характеристик таких объектов. Широкий спектр количественных и качественных показателей, которые с различных сторон характеризуют содержание компонентов и комплексов программ, а также невысокая достоверность оценки их значений определяют значительную дисперсию при попытках описания и измерения свойств создаваемых сложных программных продуктов для их оценки и экономического прогнозирования.
Проблемы формализации программной инженерии. Основные концепции программной инженерии сконцентрированы в целостном комплексе международных стандартов, регламентирующих практически все процессы жизненного цикла сложных программных средств. Проблема состоит в их активном освоении и применении. Использование стандартов, сосредоточивших мировой опыт создания различных типов крупных комплексов программ, способствует значительному снижение стоимости, трудоемкости, длительности и улучшению других технико-экономических показателей проектов крупных программных продуктов, повышению производительности труда специалистов и качества создаваемых продуктов. Жизненный цикл крупных программных средств отражается в стандартах набором процессов, этапов, частных работ и операций в последовательности их выполнения и взаимосвязи, регламентирующим ведение разработки, сопровождение и эксплуатацию – от анализа и подготовки требований до завершения испытаний ряда версий программного продукта и прекращения их использования. Тем самым уровень достигаемого качества ПС становится предсказуемым и управляемым, непосредственно зависящим от ресурсов, выделяемых на его достижение, а главное, от системы качества и эффективности технологии, используемой на всех этапах жизненного цикла ПС. По мере возрастания размеров проектов и ответственности за качество и безопасность применения программных продуктов, совершенствуются технологии их создания, повышаются требования к полноте и корректности применения стандартов, так же как в любых других отраслях промышленного производства.
Рост требований к качеству. Очень быстро нарастает сложность и ответственность задач систем обработки информации и управления, что вызывает рост требований к качеству, надежности функционирования и безопасности применения программных продуктов.
Проблемы профессиональной квалификации. Проблемы личной профессиональной квалификации, психологических характеристик специалистов и организации крупного коллектива в основном определяют качество и трудоемкость при производстве программных продуктов. Специалистов необходимо обучать ряду важных для программной индустрии профессий, связанных с созданием крупных программных продуктов:
- организации и регламентированной работе больших профессиональных коллективов специалистов над целостным продуктом;
- распределению сотрудников разной профессиональной специализации по производственным этапам, компонентам и видам работ в жизненном цикле комплексов программ;
- планированию и методам работы в условиях ограниченных ресурсов, по графикам в реальном времени с заданными сроками, контролем качества и документированием результатов;
- тестированию, испытаниям и гарантии качества, надежности компонентов и программного продукта в целом.
Сюда же относят Зависимость успеха проекта от индивидуальных особенностей их исполнителей.
Как правило в незрелых организациях-разработчиках производительность зависит от возможностей отдельных сотрудников и изменяется в зависимости от присущих им навыков, знаний и мотивации, а производительность можно прогнозировать только на уровне отдельных сотрудников, но не для организации в целом. Данная проблема решается институализацией эффективных процессов разработки. Для этого стандартные процессы разработки и сопровождения ПО (включая как процессы программной инженерии, так и управления) в рамках организации должны быть интегрированы в единое целое и качественно документированы. При этом должно быть обеспечено их дисциплинированное соблюдение в рамках организации. Продуктивность такого подхода основана на общем для всей организации понимании работ, ролей и сфер ответственности.
1.5 Ключевые понятия
Проект
Определение по ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»:
Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
Определение по PMBOK:
Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Временный характер проекта означает, что у любого проекта есть определенное начало и завершение. Завершение наступает, когда достигнуты цели проекта; или признано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте. «Временный» не обязательно предполагает краткую длительность проекта. «Временный», как правило, не относится к создаваемому в ходе проекта продукту, услуге или результату. Большинство проектов предпринимается для достижения устойчивого, длительного результата. Каждый проект приводит к созданию уникального продукта, услуги или результата.
В итоге:
| Проект – это замысле, который характеризуется следующими факторами: - однократность условий в их совокупности – речь идет об особом замысле. Он отличается от повседневных работ и не повторяется; - наличие цели(ей) – ясных и измеримых, которые к концу проекта должны быть достигнуты; - ограничениями: o ограничение по времени – временной график выполнения проекта с обозначенным началом и концом выполнения работ; o ограничения финансового, персонального или другого рода – бюджет проекта, этапы; o ограничение от других замыслов – проект не повторяется и отличается от процессных работ; - специфичная для проекта организация – в проект подбираются разные люди с разными ролями, включаются разные отделы, разные поставщики. В каждом проекте эти составляющие разные. |
Процесс
Определение по ГОСТ Р 54869-2011:
Совокупность взаимосвязанных действий, направленных на достижение определенных результатов.
Ввиду особой важности понятий проект и процесс в рассматриваемой нами дисциплине, еще уточним отличия процесса от проекта:
| Процесс | Проект |
| ü Периодически повторяется; ü Описана деятельность по получению результата; ü Четко определены роли подразделений. | ü Уникальный замысел; ü Инновационный замысел; ü Междисциплинарный характер; ü Ограничен по срокам, бюджету. |
Жизненный цикл системы
Это непрерывный процесс, охватывающий различные состояния системы, начиная с момента возникновения необходимости в такой системе и заканчивая её полным выводом из эксплуатации.
// тут все просто
Проектирование системы
Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части.
Результатом проектирования является проект системы – целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.
Интерфейс вычислительной системы
Это совокупность логических и физических принципов взаимодействия компонентов технических средств системы, т. е. совокупность правил алгоритмов и временных соглашений по обмену данными между компонентами ВС (логический интерфейс), а также совокупность физических, механических и функциональных характеристик средств подключения, реализующих такое взаимодействие (физический интерфейс).
или
технические и программные средства, реализующие сопряжение между устройствами и узлами ВС.
Программное средство
Объект, состоящий из программ, процедур, правил, а также, если предусмотрено, сопутствующих им документации и данных, относящихся к функционированию системы обработки информации.
Требование
Требования это спецификация того, что должно быть реализовано.
В них описано поведение системы, свойства системы или ее атрибуты.
Они могут служить ограничениями в процессе разработки системы.
Качество программного обеспечения
Совокупность свойств ПО, которые обусловливают его пригодность удовлетворять заданные или подразумеваемые требования в соответствии с его назначением.
Надежность ПО
| Чем отличаются ошибка, дефект и сбой? Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья. Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом. Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ. Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! В системе произошел сбой — проявился ранее скрытый дефект. |
Ошибка, дефект, сбой
Ошибка – неправильность в действиях.
Дефект – результат ошибки.
Сбой – результат проявления дефекта.
1.6 Итоги занятия
ü Программная инженерия содержит свод общепринятых знаний и правил, накопленных в мире за последние 40-50 лет разработки ПО.
ü Основная проблема разработки ПО – сложность (под этим понимается как объективная сложность программируемых процессов или явления, так и сложность управления и организации процесса разработки);
ü Для успешного выполнения программного проекта (да впрочем и любого) требуется нечто большее, чем армия умных и технически грамотных людей.
ü Адекватное планирование, прогнозирование трудовых и временных затрат, оценка и контроль в процессе производства ПО возможны, но для этого необходимо наличие явно определенных рационально организованных производственных процессов и опыт их применения, что в совокупности называется зрелостью процессов организации.
Грубо говоря, основное содержание данной лекции – это «философские рассуждения», направленные на достижение одной цели: показать важность ПИ.
Остальные лекции напротив будут иметь вполне конкретное содержание, связанное с отдельными областями знаний ПИ, такими как: управление требований, проектирование или конструирование программных систем. Следующая лекция (одна из самых важных) является базовой и характеризует в целом процессный подход к управлению программным проектами.
Спасибо за внимание!
2. Жизненный цикл и процессы разработки ПО
4 часа
Цели данной лекции:
1. Раскрыть значения и связь понятий жизненный цикл и процесс программной инженерии;
2. Рассмотреть основные модели жизненного цикла программных продуктов;
3. Рассмотреть структуру процессов программной инженерии.
4. Рассмотреть (кратко) основные виды деятельности по управлению процессами: реализация, изменение, определение, оценка процессов, а также и измерение процессов и продуктов;
5. Рассмотреть модель зрелости процессов.
Сегодняшняя лекция показывает насколько все-таки справедливо слово «Введение» в названии нашего курса. Просто на то, чтобы структурировать (по сути перечислить) основные процессы программной инженерии у нас уйдет больше часа. Небольшая доля перечисленных процессов (самые основные) будут рассматриваться на обзорном уровне в оставшейся части курса лекций.
Вы также прочувствуете, почему настоящий сильно связан с управленческой деятельностью и управлением проектами.
Очень (очень!) кратко затронем общепринятые подходы к улучшению процессов, в частности на примере модели зрелости процессов (CMM-SW – Capability Maturity Model for Software) – стандартизованного пошагового подхода к повышению продуктивности деятельности в организациях-разработчиках ПО.
2.1 Основы жизненного цикла программных средств
Одними из основных понятий программной инженерии являются понятия жизненного цикла программного средства и программного процесса.
Жизненный цикл системы
Это непрерывный процесс, охватывающий различные состояния системы, начиная с момента возникновения необходимости в такой системе и заканчивая её полным выводом из эксплуатации.
Модель жизненного цикла
Это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
Иначе говоря, модель ЖЦ – это упрощенное описание жизненного цикла, представленное с некоторой точки зрения. В модели мы говорим, что и как мы будем делать – т.е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять.
Выбор модели жизненного цикла является первым шагом в создании ПО. Правильный выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор тяжелых процессов может утопить проект, а слишком легкое отношение к процессам – к потере контроля над ходом выполнения.
| Для понятий разработка требований, проектирование, конструирование, тестирование, документирование мы будем впредь использовать термин процессы, а не этапы, т.к. этапность подразумевает привязку ко времени и последовательное выполнение указанных действий, что справедливо только для каскадной (водопадной) модели. |
Процесс
Совокупность взаимосвязанных действий, направленных на достижение определенных результатов.
Процессы являются элементами жизненного цикла. Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит следующим образом:
Ø Категория процессов
v группа процессов
¨ процессы
· работы
ü задачи
Состав и степень определенности процессов программной инженерии непосредственно влияют на производительность труда и результат проекта.
Конечно, не только процессы непосредственно влияют на результат проекта. Существуют и другие факторы, играющие не менее важную роль, например, возможности инструментов и потенциал, знания и опыт специалистов. Когда оценивается влияние изменения процессов, такие факторы должны учитываться (например, попытка внедрения развитых процессов программной инженерии при отсутствии ресурсов или в неподготовленной организационной среде практически наверняка приведет к краху таких инициатив). Кроме того, важна степень институализации процессов (process institualization или process fidelity – следование заданным процессам как повседневная практика работы). Фактор институализации в большинстве случаев объясняет, почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге.
В общем случае процессы ЖЦ разнятся в разных организациях и зависят от принятой модели ЖЦ. Но можно выделить т.н. основные процессы ЖЦ.
Основными классическими процессами (этапами или фазами) жизненного цикла являются:
- разработка спецификации или разработка требований (результат - описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность;
- проектирование (результат — описание того, как программа будет работать);
- конструирование (результат - исходный код и файлы конфигурации);
- тестирование (результат - контроль соответствия программы требованиям);
- документирование (результат - документация к программе).
Примечание: На самом деле, современная программная инженерия (как мы увидим чуть дальше) рассматривает процессы разработки программных средств в контексте системной инженерии и кроме основных, выделяет много дополнительных и вспомогательных процессов, связанных не с созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, управления повторным использованием программ, разрешения противоречий, управление конфигурацией и т.д.
Дата: 2019-02-19, просмотров: 326.
