Что было задумано

Изначально, у меня возник следующий замысел относительно книги (планировалась только «бумажная» версия). В начале, сделать обзор современных методологий разработки ПО. Затем высказать основную идею о том, что все методологии используют подмножество из общего пространства УПР (см. рис. 1).

Рис. 1 – Единое пространство УПР.

Х – ось этапов ЖЦ ПО;

Y – степень важности УПР для конкретного этапа;

1..9 – ЖЦ (1-фундамент проекта – «Управление»);

Круги – УПР, известные на данный момент;

Виды штриховок – различные методологии разработки ПО, включившие решение в перечень своих постулатов.

В середине – дать пятьдесят чистых листов. Каждый лист представлял бы собой форму для ввода удачного решения, найденного читателем (скорее писателем) в процессе разработки очередного проекта. Форма имела бы стандартную форму: название, код этапа ЖЦ, оценка эффективности, описание и дополнительные источники информации по решению.

Заканчивалась бы книга главами «Содержание» и «Библиография». Естественно, они бы тоже заполнялись вручную. У каждого есть свой «золотой набор», состоящий из книг, WEB-ресурсов и телефонов ближайших пиццерий.

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

Но затем я просмотрел свою домашнюю библиотеку, и обнаружил, что во многих из них идея о «дополнении» книги читателем уже реализована. Это так называемые листы «для заметок». Заметки у меня отсутствовали…

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

Также, в мои планы входит (в случае положительной оценки книги квалифицированными разработчиками и наличия у меня свободного времени) дальнейшее развитие теории «единого пространства УПР» в виде сайта в сети Интернет.

Сайт представлял бы собой информационный портал для обмена информацией между разработчиками ПО и пополнения БД УПР. Основные компоненты сайта – форум разработчиков, разбитый по темам (этапам ЖЦ, методологиям, продуктам и прочее), гостевая книга, профили пользователей сайта и самое главное – БД УПР, доступную для публичного доступа. Каждое новое УПР (или изменение описания уже существующего) оценивалось бы пользователями сайта, и в случае положительного результата, добавлялось бы в БД.

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

Кстати, по поводу Брукса. Вы заметили различия между посвящениями 1975 и 1995 годов? В первом упоминаются непосредственный и самый главный начальник. Во втором же – «Нэнси, Божьему дару для меня». Наконец-то в списке жизненных ценностей появляется семья и всё, что с этим связано. Не в этом ли заключается «сущность и акциденция программной инженерии»?

Благодарности

Итак, кто оказал на мое развитие наибольшее влияние и кому я за это благодарен:

– Мои родители – они меня родили ;-) Хотелось бы жить не во время победившего мирового терроризма, но ничего уж тут не поделаешь.

– Моя сестра – за поддержку.

– Технический Университет Молдовы – за получение не самого хорошего высшего технического образования, но лучшего из возможных в республике. Как сказано в книге [15] – «Поставь себе цель. Получи такое образование, какое только можешь, но затем, ради Бога, делай что-нибудь!».

– Стратан Виктор – за отличное объяснение в теории и практике паттернов проектирования, ООП и т.п. Первая версия Rational Rose 98, полученная мной – его заслуга.

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

– Смолов Александр – когда баланс между радостями и печалями профессии начинает сдвигаться в сторону последних (см. книгу [6]), я сажусь за компьютер и в течение месяца борюсь с пришельцами в старом добром XCOM (см. сайт [15]), принесенных мне Александром на трёх дискетах со слониками. Грустные мысли от этого проходят, но потом еще долго снятся зеленые человечки ;-)

– Драгонер В.В. – куратор моего диплома. Была поставлена амбициозная цель по созданию аналога Rational Rose. Я написал компилятор исходных текстов С++; Сердцев – графическую оболочку для браузера объектов и диаграмм; Смолов – озвучивание на русском языке результатов анализа текстов через движок MSTextToSpeech. Проект благополучно провалился (к сдаче диплома было готово не более 50% заявленных требований), но неудачи иногда более полезны, чем успехи. Был получен опыт работы с Розой, прочтены материалы о Rational и многое другое.

– Папроцкий И.Б. и Старащук А.И. – работа в ГП «Registru» (см. статью [1]) под их руководством имела огромное значение на мой профессиональный и карьерный уровень.

– Золотухина Е.Б. – за потрясающий курс по системному анализу и разработке ИС.

– Дурлештяну Эдуард (компания BitGenerator) – вместе работать было тяжело, но очень интересно. К большому моему сожалению, тяжесть «перевесила» интерес.

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

Методологии разработки ПО

RUP

Rational Unified Process – Рациональный Унифицированный процесс.

RUP был создан в 1996г. корпорацией Rational при участии Гради Буча, Айвара Якобсона и Джима Румбаха.

Это поистине фундаментальная работа по описанию успешных методик создания ПО. Жизненные циклы ПО, потоки работ, роли, деятельности, артефакты, продукты, поддерживающие большую часть этапов ЖЦ. Не зря эту методику называют «тяжеловесной». Поддержка языка UML. RUP в качестве самостоятельной базы знаний по объему и значению может сравниться разве что с MSDN.

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

Продукты, поддерживающие методику – в первую очередь, это продукты самой компании Rational. Основной продукт Rose (используется практически на всех этапах разработки), SoDA (автодокументирование), RequisitePro (управление требованиями), ClearQuest (запросы на изменения), ClearCase (версионность), Administrator (управление репозиторием проекта), WorkBrench (настройка корпоративных процессов), Quantify (тестирование скорости кода), Purify (определение утечек памяти), PureCoverage (тест охвата кода), Robot (автоматизированное тестирование), SiteLoad (нагрузочное тестирование), SiteCheck (проверка «мертвых» Web-ссылок). В настоящее время доступен RUP, интегрированный в среду разработки Microsoft .NET (под названием Rational XDE).

XP

Extreme Programming – Экстремальное программирование.

Рождением (а точнее датой «официальной» регистрации) можно считать 2001г., когда в США, штате Юта 17 сторонников «легковесных» процессов разработки выработали манифест с основными постулатами. Идеологами методики можно считать Кента Бека, Уорда Каннингема и Рона Джеффриса.

Основные принципы: тесная коммуникация, постоянное тестирование, минимум документации и максимум гибкости. Впрочем, лучше привести текст манифеста (см. книгу [4]):

«Мы открываем лучшие способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить:

Индивидуумов и взаимодействия выше процессов и инструментов

Работающее ПО выше всеобъемлющей документации

Сотрудничество с заказчиками выше согласований условий договора

Реагирование на изменения выше соблюдения плана

Это означает, что, хотя элементы в правой части также имеют свою ценность, но больше мы ценим элементы, расположенные слева».

Довольно краткие и понятные формулировки, делающие доступными высказанные идеи самым широким массам. ХР впервые озвучила некоторые совершенно революционные принципы разработки. «Это вам не понадобится», «Ищите самое простое решение, которое может сработать», «Любые сидящие рядом два разработчика могут поменять всё что угодно в системе», «Заказчик в любой момент может изменить требования» и др.

Однако я уже высказывал свою критику по поводу ХР. Большая часть претензий к ХР снимается, вследствие более детального знакомства с ней. Можно считать, что последние проекты, в которых я участвовал, были «в духе ХР».

Осталась следующая критика:

1. Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм документов по взаимодействию (ТЗ, ТП). Во-вторых, в более быстрых итерациях (нужно помочь заказчику сформулировать и откорректировать своё видение системы)

2. Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке сложных систем. Если приложение простое, зачем тратить на него своё время?». В сложном и интересном проекте, с «богатой» предметной областью было бы преступной халатностью не сформировать в самом начале каркас системы, основные принципы его функционирования. Конечно, «настоящие ХР-шники» стоически воспримут информацию в середине проекта о том, что обнаружился прецедент, заставляющий переделать большую часть кода (или ещё хуже выбросить его). Но я считаю это совершенно недопустимым.

3. Десятки userstory (бумажки с несколькими предложениями, характеризующими прецедент пользователя), оставшиеся после завершения проекта, не могут служить в качестве надежной документации. Получается, что ХР нацелена на быструю разработку ПО, но не на его сопровождение. Приведу цитату из книги [4] по поводу неудачи проекта 3C, выполненного посредством ХР (расчет зарплаты для Chrysler – могу подтвердить, что зарплата при своей внешней простоте одна из самых трудных областей бухгалтерии, в которой «утонула» не одна команда программистов). «Когда ушло достаточно много сотрудников, незаписанные сведения о проекте и групповая память были утрачены». Я думаю, что апологеты ХР переусердствовали с минимизацией документации. Что для студентов может выглядеть привлекательным, серьезных разработчиков должно насторожить.

Должен поделиться собственным ощущением от «работы в стиле ХР». В отличие от RUP (или любой другой методики с фиксированием