Текст книги "Программная инженерия. Теория и практика"

Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО определяет некоторую динамику развертывания тех или иных видов деятельности, т.е. модель процесса (process model).

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

Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

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

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

Вид деятельности (activity) – это определенный тип работы, выполняемый в процессе создания ПО. Разные виды деятельности часто требуют разных профессиональных навыков и выполняются разными специалистами. Например, управление проектом осуществляется менеджером проекта, кодирование – программистом, тестирование – тестировщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами – например, кодирование и проектирование (особенно в небольшом проекте) часто проводят одни и те же люди.

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

Виды деятельности фактически присутствуют под разными названиями в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

Водопадная модель. Была предложена в 1970 г. Винстоном Ройсом. Фактически впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о создании ПО в виде анализа системы и ее кодирования.

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование (рис. 2).

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

Рис. 2. Водопадная модель процесса разработки ПО

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

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

• отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности трудности поддержки итеративного процесса разработки;

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

• интеграция всех результатов разработки происходит в конце процесса, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;

• невозможность ознакомления пользователей и заказчика с вариантами системы во время разработки. Тем самым они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;

• неустойчивость модели к сбоям в финансировании проекта или перераспределению денежных средств (начатая разработка фактически не имеет альтернатив «по ходу дела»).

Однако данная модель продолжает использоваться на практике для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в офшорных проектах (от англ. offshore – вне берега, в расширенном толковании – вне одной страны) с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другие модели и методологии, например в MSF.

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

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

Каждый виток имеет следующую структуру (секторы):

• определение целей, ограничений и альтернатив проекта;

• оценка альтернатив, оценка и разрешение рисков – возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций, фокусировка на самых рисковых частях проекта;

• разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;

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

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

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

Спиральная модель не нашла широкого применения в индустрии и важна скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО.

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

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

Таким результатом является рабочий продукт (work product) – любой артефакт, произведенный в процессе разработки ПО, например, файл или набор файлов, документы, составные части продукта, сервисы, процессы, спецификации, счета и т.д. (рис. 3).

Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем (not to be engineered), хотя может быть таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный процесс – промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д.

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

Рис. 3. Рабочий продукт

Многие методологии включают в себя описание специфичных рабочих продуктов, используемых в процессе – CMMI, MSF, RUP и др. Например, в MSF это программный код, диаграммы приложений и классов (application diagrams и class diagrams), план итераций (iteration plan), модульный тест (unit test) и др. Для каждого из них точно описано содержание, ответственные за разработку, место в процессе и другие аспекты.

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

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

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

Основой этой формы отношений являются обязательства, которые должны:

• быть добровольными;

• не даваться легко – работа, ресурсы, расписание должны быть тщательно учтены;

• заключаться между сторонами и включать в себя то, что будет сделано, кем и в какие сроки;

• быть открыто и публично сформулированы (т.е. это не «тайное знание»).

Кроме того, ответственная сторона стремится выполнить обязательства, даже если нужна помощь. До наступления deadline, как только становится очевидно, что работа не может быть закончена в срок, обсуждаются новые обязательства.

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

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

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

Дисциплине обязательств уделяется много внимания в рамках MSF, поскольку там в модели команды нет лидера, начальника. Эта дисциплина реализована также в Scrum: Scrum-команда имеет много свобод и в силу этого большую ответственность. Регламентируются также правила действий, когда обязательства не могут быть выполнены такой командой.

Проект. Классическое операционное разделение труда идет еще от Адама Смита и является сутью массового индустриального производства. То есть существует четко налаженный процесс работы и имеются области специализации: один цех точит, другой – строгает, третий – собирает, четвертый – красит и т.д. Пропускная способность такого производства намного превосходит выполнение всей работы одним человеком или одной группой. Таким образом, в XIX в. операционное разделение труда стало основой мануфактур, вытеснивших индивидуальное, ремесленное производство. В начале XX в. эту структуру работ перенесли и на управление, т.е. многочисленные менеджеры контролировали отдельные участки работ.

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

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

В частности, разработка программного обеспечения является преимущественно проектной областью.

Необходимо различать проекты промышленные и проекты творческие. У них разные принципы управления. Сложность промышленных проектов заключается в большом количестве разных организаций, компаний и относительной уникальности самих работ. Пример – строительство многоэтажного дома. Сюда же относятся различные международные проекты (не только промышленные, но и образовательные, культурные и пр.). Задача в управлении такими проектами – все охватить, проконтролировать, ничего не забыть, все свести воедино, добиться движения, причем движения согласованного.

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

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

Управление проектами (project management). Это область деятельности в ходе которой, в рамках проектов определяются и достигаются четкие цели при нахождении компромисса между объемом работ, ресурсами (такими, как время, деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками.

Таблица 3

Области управления проектами

Отметим несколько важных аспектов управления проектами.

Stakeholders – это люди со стороны, которые не участвуют непосредственно в проекте, но влияют на него и/или заинтересованы в его результатах. Это могут быть будущие пользователи системы (например, в ситуации, когда они и заказчик – это не одно и то же), высшее руководство компании-разработчика и т.д. Идентификация всех stakeholders и грамотная работа с ними – важная составляющая успешного проектного менеджмента.

Project scope – это границы проекта. Это очень важное понятие для программных проектов в виду изменчивости требований. Часто бывает, что разработчики начинают создавать одну систему, а после постепенно она превращается в другую. Причем для менеджеров по продажам, а также заказчика ничего радикально не произошло, а с точки зрения внутреннего устройства ПО, технологий, алгоритмов реализации, архитектуры все радикально меняется. За подобными тенденциями должен следить и грамотно с ними разбираться проектный менеджмент.

Компромиссы – важнейший аспект управления программными проектами в силу их согласовываемости. Необходимо не потерять все согласуемые параметры и стороны и найти приемлемый компромисс. Одна из техник управления компромиссами будет рассмотрена в контексте изучения методологии MSF.

При разработке программных проектов, следуя MSF 3.1, важны области управления (табл. 3).

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

Контрольные вопросы

1. Дайте определение процесса создания ПО.

2. Расскажите о причинах отсутствия универсального процесса разработки ПО.

3. Почему возможно и целесообразно стандартизировать процесс на уровне компании?

4. Раскройте понятия «стандартный» и «конкретный» процессы. Как они соотносятся?

5. Чем отличаются между собой текущий и конкретный процессы? Какие методологии разработки ПО поддерживают понятие конкретного процесса и какими средcтвами?

6. Дайте определение деятельности по совершенствованию процесса.

7. В чем заключается главная трудность совершенствования процессов в компаниях?

8. Перечислите основные направления улучшения процесса.

9. Расскажите о стратегии organization pull к внедрению инноваций. Приведите примеры.

10. Расскажите о стратегии technology push к внедрению инноваций. Приведите примеры.

11. Расскажите о достоинствах, недостатках, а также возможных рисках этих стратегий.

12. Дайте определение модели процесса.

13. Что понимают под фазой процесса?

14. Что подразумевают под видом деятельности?

15. Почему нельзя отождествлять фазы и виды деятельности? Когда и по каким причинам это все-таки происходит на практике?

16. В чем заключаются достоинства водопадной модели? Какова ее историческая роль? Перечислите ее недостатки.

17. Как в рамках водопадной модели предполагается работать с рисками?

18. Почему водопадная модель до сих пор используется? Объясните, почему эту модель удобно использовать в офшорных проектах с почасовой оплатой.

19. Чем виток спиральной модели отличается от фазы в водопадной модели? Приведите пример последовательности витков спиральной модели. Опишите условия, при которых спираль завершается.

20. Расскажите про второе и третье измерение спиральной модели. Опишите различные секторы витка спирали.

21. В чем заключаются достоинства и недостатки спиральной модели? Каковы ограничения этой модели?

22. Как в рамках этой модели предполагается работать с рисками?

23. Дайте определение рабочего продукта. Приведите примеры.

24. Чем отличается рабочий продукт от компоненты ПО?

25. Раскройте понятие «нематериальный рабочий продукт».

26. Опишите, как «работает» дисциплина обязательств. Приведите примеры других видов отношений между людьми.

27. Расскажите о границах применения дисциплины обязательств.

28. Дайте определение проекта. Чем он отличается от других форм организации бизнеса и производства?

Задания

1. Нарисуйте с помощью карт памяти взаимосвязь различных определений процесса.

2. Нарисуйте с помощью карт памяти взаимосвязь рабочего продукта и дисциплины обязательств.

3. Нарисуйте с помощью карт памяти информацию об использовании рабочего продукта и дисциплины обязательств в разных методологиях разработки ПО.

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

5. Соедините в одну карту памяти результаты выполнения заданий 2–4.