Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Введение в программную инженерию. Учебное пособие-1
.pdf
Д.В. Кознов
Введение в программную инженерию
11
• Время жизни у ПО существенно длиннее, что обусловлено более
интенсивным и масштабным процессом использования.
Теперь рассмотрим так называемые характеристические свойства ПО,
которые отличают его от других видов систем, создаваемых
(созданных) человеком – механических, социальных, научных и пр. Эти
свойства сформулировал Фредерик Брукс в своей знаменитой статье
"Серебряной пули нет": сложность, согласуемость, изменчивость,
нематериальность
2
.
1. Сложность программного обеспечения существенно зависит от
его объёма. Как правило, большее ПО (большее количество
пользователей, больший объём обрабатываемых данных, более
жесткие требования по быстродействию и пр.) с аналогичной
функциональностью — это другое ПО. Классическая наука строит
простые модели сложных явлений, и это даёт свои плоды,
поскольку сложность не была характеристической чертой научных
явлений, как бы это не звучало парадоксально. С этим связана
избирательность науки – она намеренно не рассматривает объекты
и явления, которые выходят за пределы этой парадигмы. Более
того, всё усиливающаяся фрагментация науки связана с этой же
установкой. Разработка ПО не может позволить себе такой
избирательности, и приходится реализовывать ту или иную
функциональность безотносительно того, нашлось ли изящное
архитектурное решение, или нужно применять метод грубой силы,
порождая большое количество кода
3
.
2. Согласуемость — ПО основывается не на объективных посылках
(подобно тому, как различные системы в классической науке
основываются на постулатах и аксиомах), а должно быть
согласовано с большим количеством внешних интерфейсов, с
которыми впоследствии оно должно взаимодействовать, а также
удовлетворять разным соглашениям, правилам (в том числе и
неписанным), а также договорённостям. Всё это плохо поддаётся
стандартизации, поскольку основывается на многочисленных и
плохо формализуемых человеческих соглашениях и
обстоятельствах.
3. Изменяемость. Общеизвестно, что ПО легко изменить –
например, добавить в экранную форму новую кнопку или поле
ввода, реализовать новую функцию, изменить поведение
Д.В. Кознов
Введение в программную инженерию
12
существующей). Однако это создаёт много дополнительных
трудностей при его разработке и эволюции.
4. Нематериальность — ПО невозможно ощутить, потрогать,
обонять, а также нельзя увидеть. Оно виртуально. Поэтому,
например, трудно воспользоваться технологиями, основанными на
предварительном создании чертежей, успешно используемыми в
других промышленных областях (например, в строительстве,
машиностроении). Там, на чертежах, в схематичном виде
воспроизводятся геометрические формы создаваемых объектов.
Когда объект создан, эти формы можно увидеть. А на чем мы
основываемся, когда изображаем ПО?
1
В 70-х годах академик А.П.Ершов перевёл на русский язык термин software
engineering как «технология программирования». Программная инженерия —
более современный, но менее традиционный перевод этого же термина,
предложенный в конце 90-х проф. И.В. Поттосиным. В рамках данного курса
будем пользоваться именно этим вариантом перевода.
2
Здесь мы немного поправили классика — у него была незримость.
3
Сравнение программирования именно с наукой, а не с театром,
кинематографом, спортом и другими областями человеческой деятельности
оправдано, поскольку оно возникло, главным образом, из математики, а первые
его плоды предназначались для использования при научных расчетах. Кроме
того, большинство программистов до сих пор имеют естественнонаучное,
математическое или техническое образование, т.е. им (нам) близка парадигма
научного мышления.
Д.В. Кознов
Введение в программную инженерию
13
Лекция 2. Процесс разработки программного
обеспечения
Понятие процесса разработки ПО. Универсальный процесс. Текущий
процесс. Конкретный процесс. Стандартный процесс.
Совершенствование процесса. Pull/Push стратегии внедрения
инноваций. Классические модели процесса: водопадная модель,
спиральная модель. Фазы и виды деятельности.
Без процесса не понять….
Из деловой переписки менеджера программного проекта.
Процесс
Как мы работаем, какова последовательность наших шагов, каковы
нормы и правила, регулирующие нашу работу, каковы отношения в
команде между членами коллектива, как проект связан с внешним
миром? Ответы на эти вопросы, реализованные в коллективной работе
над проектом, мы склонны называть процессом разработки.
Выстраивание и осознание процесса — основа любой эффективной
групповой деятельности. Не случайно поэтому, что процесс оказался
одним из основных понятий программной инженерии. Неформально
говоря, процесс – это образование порядка их хаоса малоосмысленных,
случайных и непродуманных, а потому неэффективных действий.
Определение. Процессом разработки ПО называют множество
различных видов деятельности, методов, методик и шагов,
используемых для разработки и эволюции ПО и связанных с ним
продуктов (проектных планов, документации, программного кода,
тестов, пользовательской документации и пр.).
Отметим, что несмотря на многолетние усилия методологов и
практиков, на сегодняшний день не существует универсального
процесса разработки ПО — набора методик, правил и предписаний,
подходящих для разработки любого вида ПО, для любых компаний, для
команд любой национальности. Каждый текущий процесс,
осуществляемый некоторой командой в рамках определенного проекта,
имеет большое количество особенностей и индивидуальностей.
Д.В. Кознов
Введение в программную инженерию
14
Однако целесообразно перед началом проекта спланировать процесс
работы, определив роли и обязанности в команде, рабочие продукты
(промежуточные и финальные), порядок участия в их разработке
членов команды и т.д. Будем называть это предварительное описание
конкретным процессом, отличая его от плана работ, проектных
спецификаций и пр. Например, в системе Microsoft Visual Tem System
имеются разные шаблоны процесса, которые можно адаптировать под
особенности конкретной команды или контекста и тем самым создать
необходимый конкретный процесс.
В рамках компании возможна и полезна объединение и стандартизация
всех текущих процессов, которую будем называть стандартным
процессом. Последний, таким образом, оказывается некоторой базой
данных, содержащей следующее:
• правила использования, документацию и инсталляционные
пакеты средств разработки, используемых в проектах компании
— систем версионного контроля, средств контроля ошибок,
средств программирования (различных IDEs, СУБД и т.д.);
• описание практик разработки — проектного менеджмента, правил
работы с заказчиком и т.д.;
• шаблоны проектных документов, например, технических заданий,
проектных спецификаций, тестовых планов.
Также возможна стандартизация процедуры разработки конкретного
процесса как «вырезки» из стандартного. Основная идея стандартного
процесса — курсирование внутри компании передового опыта, а также
унификация средств разработки. Очень уж часто в компаниях
различные департаменты и проекты сильно отличаются по зрелости
процесса разработки, а также затруднено повторное использование
передового опыта. Кроме того, случаются, что компания в разных
проектах использует несколько параллельных средств разработки,
например, Java и .NET, MS SQL Server и Oracle. Иногда это бывает
оправдано, например, таковы требования заказчика. Но часто это
произвольный выбор самих разработчиков. В любом случае, такая
множественность существенно затрудняет миграцию специалистов из
проекта в проект, использование результатов одного проекта в другом
и т.д.
Д.В. Кознов
Введение в программную инженерию
15
Автору случилось участвовать в перепроектировании ИТ-ландшафта
одной крупной российской бизнес-корпорации. Обнаружилось, что эта
корпорация использует и сопровождает для собственных нужд более
1000 различных информационных систем, используя около 300
различных технологий разработки и исполнения — автор нашёл там
все известные ему варианты и сочетания, а также встретил изрядное
количество неизвестных. Очевидно, что сопровождение этого парка
систем оказывается весьма дорогостоящей деятельностью и стоит
естественная задача сокращения используемых в компании технологий
разработки. И это будет вкладом в стандартный процесс разработки и
сопровождения ПО в этой компании.
Возвращаясь к стандартному процессу необходимо отметить, что
следует следить, чтобы такой процесс не оказался всего лишь
формальной, бюрократической обёрткой (а такое стремительно
происходит с самыми, порой, передовыми идеями, и происходит в
самых разных областях человеческой деятельности). Понятие
стандартного процесса введено и подробно описано в подходе CMMI и
в полном виде, к настоящему моменту используется редко.
Но что-то, имеющие черты стандартного процесса разработки ПО, в
рамках всей компании весьма целесообразно иметь с тем, чтобы
упорядочить её процессы, используемые технологии и правила
разработки. Также заметим, что наличие в той или иной мере реального
стандартного процесса свидетельствует о наличии в компании «единой
воли», существующей именно на уровне процессов разработки ПО. На
уровне продаж, бухгалтерии и др. привычных для всех компаний
процессов и активов единство осуществить не трудно. А вот на уровне
процессов разработки очень часто каждый проект оказывается сам по
себе (особенно в торговых сетевых компаниях, где правит бал бизнес и
его срочные задания для ИТ-отдела); в итоге «текучка» захватывает,
архитектура систем постоянно нарушается, накапливается
архитектурный и технический долг, а разные проекты изолируются
друг от друга, не распространяя во всей компании успешные практики,
технологии и подходы, найденные и опробованные в одном из
проектов.
Д.В. Кознов
Введение в программную инженерию
16
Совершенствование процесса
Определение. Совершенствование процесса (software process
improvement) — это деятельность по изменению существующего
процесса (как текущего, в рамках одного проекта, так и стандартного,
для всей компании) с целью улучшения качества создаваемых продуктов
и/или снижения цены и времени их разработки.
Причины, по которым эта деятельность может быть актуальной для
компании-производителя ПО, заключаются в следующем.
1. Происходит быстрая смена технологий разработки ПО и требуется
изучение и внедрение новых, более современных и эффективных
средств.
2. Наблюдается быстрый рост компании и её выход на новые рынки,
что требует нового уровня организации работ.
3. Компания сталкивается с высокой конкуренцией, и требуются
более эффективные, более экономичные способы разработки.
4. Встаёт проблема импортозамещения и технологической
независимости, что влечет отказ от привычных продуктов и
технологий, покупку и освоение новых, а также, возможно,
самостоятельную разработку критичных технологий (последнее
характерно для больших компаний).
5. Инфраструктурные изменения компании могут требовать
изменения архитектуры систем и процессов разработки. В
качестве примера можно привести реструктуризацию большой
компании сетевой торговли на набор меньших, относительно
независимых компаний. Соответственно, ИТ-департаменты этих
небольших компаний должны быть усилены, а функции единого
ИТ-отдела головной компании — существенно пересмотрены.
Другой вариант – поглощение одной компании другой или
слияние двух компаний: Эти процессы также могут существенным
образом отразиться на процессы разработки ПО.
Посмотрим, что и каким образом можно улучшать в процессе разработки
программного обеспечения.
1. Переход на новые средства разработки и языки
Д.В. Кознов
Введение в программную инженерию
17
программирования.
2. Улучшение отдельных управленческих и инженерных практик
— например, тестирования, управления требованиями,
проектирования
3. Полная, комплексная перестройка всех процессов в проекте,
департаменте, компании (в соответствии, например, с CMMI).
4. Сертификация компании по стандартам CMM/CMMI, ISO 9000 и
др.
Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда
означает действительную созидательную работу по улучшению
процессов разработки ПО, а часто сводится к поддержанию
соответствующего документооборота, необходимого для получения
сертификации (создаётся так называемая «Потёмкинская деревня»).
Сертификат потом используется как средство, козырь в борьбе за
заказы.
Выделим две существенные трудности в совершенствовании процесса
разработки:
• изменение порядка действий людей, отделов и подразделений,
проектных команд и компании в целом;
• при совершенствовании процессов компания должна продолжать
свою главную деятельность, т.е. она не может, как, например,
магазин, «закрыться на переучёт».
Изменение порядка действия может оказаться непреодолимым
препятствием. Например, в компании нет тестирования. Некоторые
тесты (главным образом, модульные) создаются отдельными
разработчиками, имеется также интеграционное тестирование в самом
конце разработке, например, прямо на целевом железе. Но
планомерного, разнообразного тестирования на каждом этапе
разработки, при внесении отдельных изменений не выполняется. И к
этому все привыкли, именно на такой процесс ориентированы средства
разработки, архитектура системы и т.д. Так привыкли работать десятки,
а иногда и сотни людей. Изменить ситуацию может большая проблема
— например, могут возникнуть, накопиться такие проблемы с
качеством, которые уже влекут за собой судебные разбирательства
компании-подрядчика с компаниями-заказчиками. Именно такую
Д.В. Кознов
Введение в программную инженерию
18
историю как-то раз и наблюдал автор. При этом про проблемы с
качеством говорили очень долго и тщетно, но под угрозой суда
соответствующий процесс в компании-подрядчике был налажен быстро
и очень эффективно и потом исправно работал годами. Можно,
конечно, сослаться на русскую безалаберность (пока гром не грянет,
мужик не перекреститься), но сходные проблемы наблюдаются далеко
не только в российских компаниях.
Касаемо проблемы совмещения совершенствования процессов с
продолжением основной деятельности компании можно отметить
практику непрерывного улучшения процесса, так сказать, малыми
порциями, чтобы было не так болезненно. Это тем более разумно, что
новые технологии разработки, появляющиеся на рынке, а также
развитие уже существующих, нужно постоянно отслеживать. Эта
стратегия, в частности, отражена в стандарте совершенcтвования
процессов разработки CMMI на пятом уровне, однако она требует
большой зрелости компании — последняя должна вырваться из плена
текучки и иметь устойчивый драйвер процессов разработки ПО внутри
себя самой (а не только от внешних проблем).
Pull/Push стратегии внедрения инноваций
В контексте внедрения инноваций в производственные процессы
бизнес-компаний (не обязательно компаний по созданию ПО)
существуют две следующие парадигмы:
• organization pull и
• technology push.
Стратегия organization pull подразумевает, что инновации нацелены на
решение конкретных проблем компании. Компания имеет волю и
ресурсы для их разрешения, для этого закладываются определённые
бюджеты, привлекается необходимая экспертиза (внутри компании или
снаружи), компания определяет метрики, позволяющие измерить
прогресс, понять, наступило ли улучшение или нет. С последним всё
обстоит непросто — работать можно вдохновенно, денег на работу
потратить много, но вот польза для компании может быть сильно
неочевидна…
Стратегия technology push означает широкомасштабное внедрение
Д.В. Кознов
Введение в программную инженерию
19
инноваций в компанию из стратегических соображений, основываясь
на некоторой всеохватной технологии. При этом вместо конкретных
проблем, которые могут быть решены после внедрения такой
технологии, в этом случае рассматриваются показатели компании
(эффективность, производительность, годовой оборот средств,
увеличение стоимости акций публичной компании), которые в
результате будут увеличены, улучшены. При этом предполагается, что
будут автоматически решены многочисленные частные проблемы, в
том числе и те, о которых в данный момент ничего не известно. Как
правило, внедрение таких технологий основывается на «моде», на
«хайпе» или на крайней нужде (показатели компании находятся очень
низко и совет акционеров готов на системные, всеохватные изменения).
Тут важно понимать, что кроме очевидной пользы необходимы
дополнительные ресурсы, опоры — для преодоления инерции.
Примерами использования стратегии technology push может быть
переход с монолитной архитектуры основного продукта на
микросервисную, внедрение стандартов качества ISO 9000 или CMMI,
внедрение вместо универсального хранилища данных
(унифицированное хранение корпоративных данных, data lake)
технологии Data Mesh (коллективное владение данными). Во всех этих
случая компания не решает какую-то одну проблему или ряд проблем
— она хочет радикально изменить ситуацию, выйти на новые рубежи.
Еще одно различие обеих стратегий: в случае с organization pull, как
правило, возврат инвестиций от внедрения инноваций происходит
значительно быстрее, чем в случае с technology push.
Таким образом, использование стратегии organization pull менее
рискованно, чем technology push, вносимые ею изменения в процесс
менее глобальны, более локальны. Но и выгод такие инновации могут
принести значительно меньше по сравнению с удачными внедрениями
в соответствии со стратегией technology push. И если говорить о
переходе компании на качественно новый уровень, то следует внедрять
именно technology push инновации.
Однако отметим, что существуют проблемы, которые невозможно
устранить точечными переделками процесса, то есть необходима
глобальная перестройка (technology push).
Д.В. Кознов
Введение в программную инженерию
20
Приведем в качестве примера зашедший в тупик процесс
сопровождения и развития некоторого семейства программных
продуктов. Компания терпит большие убытки, сопровождая уже
поставленные клиентам продукты (каждый продукт сопровождается по
отдельности, а не все продукты — в рамках общей стратегии). При
этом инструментальные средства безнадежно устарели и находятся в
плачевном состоянии, менеджмент расстроен, все попытки руководства
изменить процесс наталкиваются на непонимание коллектива, ссоры и
конфликты. Компания-разработчик несёт убытки из-за непомерной
дороговизны поддержания таких процессов, а клиенты недовольны
качеством и скоростью реакций компании на запросы по изменению и
исправлению ошибок. Возможно, что в таком случае без “революции”
не обойтись.
Модель процесса
Имея в виду некоторый стандартный процесс в компании и
необходимость наладки многочисленных конкретных процессов,
требуется некоторое лекало, образец, схема. В качестве такого образца
может выступить модель процесса, которая несёт определённые
базовые идеи и которую можно доопределять и уточнять для каждой
конкретной ситуации.
Определение. Модель процесса (process model) — это определённая
последовательность шагов по разработке и сопровождению системы,
критерии перехода от одного шага к другому, а также разные виды
деятельности и экспертизы, требуемые для разных шагов разработки.
Модель является хорошей абстракцией различных методов разработки
ПО, позволяя лаконично, сжато и информативно их представить.
Кроме того, модель является идеальным предметом «продажи»
процесса. Дело в том, что много десятков лет длится противостояние
бизнеса и программистов. Первый хочет максимально дешёвого
процесса разработки (который, тем не менее, выдаёт необходимые
результат, но зачастую сиюминутный). Вторые хотят хорошую
архитектурпрограммных проектов у системы, налаженных базовых
видов деятельности (проектирования, управления требованиями,
тестирования, конфигурационного управления и т.д.). Таким образом,
менеджеры и программисты хотят хороших процессов разработки. Но
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]