Этой книгой мне хотелось доказать (в первую очередь самому себе), что мир проще, чем кажется на первый взгляд и добиться в нём успеха действительно реально, независимо от тех препятствий, которые постоянно возникают на нашем пути.
Есть такая байка про миллионера, который сказал: «Я могу рассказать вам, каким образом я заработал каждый свой миллион. Кроме первого». Действительно, если воспринимать то, что называется «жизненным успехом» в качестве восхождения наверх по бесконечной лестнице, то наиболее трудно сделать именно первый шаг. Я постарался сделать для себя эту книгу «экзаменом» на право подняться на первую ступень.
Ну и, наконец, это на самом деле огромный кайф писать книгу. Аналогично сочинению музыки, рисованию картины или вырезанию скульптуры. Красота на самом деле «спасёт мир, меня и программные проекты». Когда ты видишь, как обрывки мыслей и фраз, после терпеливой обработки (мучительного поиска синонимов и выделения деепричастных оборотов) превращаются в связный текст с логичным сюжетом, испытываешь ни с чем не сравнимое удовольствие.
Программирование тоже дает такое ощущение. Это связано с тем моментом, когда разрозненная информация, требования, приказы, инструкции, слухи и досужие домыслы, относящиеся к системе, как огромные неповоротливые булыжники вдруг складываются у тебя в голове в единую скульптуру. Каждый пазл становится на своё место и остаётся только брызнуть на них живой водой. Каменная статуя просыпается и рукотворное существо начинает делать свои первые шаги. Это одна из самых больших радостей нашей профессии.
Что было задумано
Изначально, у меня возник следующий замысел относительно книги (планировалась только «бумажная» версия). В начале, сделать обзор современных методологий разработки ПО. Затем высказать основную идею о том, что все методологии используют подмножество из общего пространства УПР (см. рис. 1).
Рис. 1 Единое пространство УПР.
Х ось этапов ЖЦ ПО;
Y степень важности УПР для конкретного этапа;
1..9 ЖЦ (1-фундамент проекта «Управление»);
Круги УПР, известные на данный момент;
Виды штриховок различные методологии разработки ПО, включившие решение в перечень своих постулатов.
В середине дать пятьдесят чистых листов. Каждый лист представлял бы собой форму для ввода удачного решения, найденного читателем (скорее писателем) в процессе разработки очередного проекта. Форма имела бы стандартную форму: название, код этапа ЖЦ, оценка эффективности, описание и дополнительные источники информации по решению.
Заканчивалась бы книга главами «Содержание» и «Библиография». Естественно, они бы тоже заполнялись вручную. У каждого есть свой «золотой набор», состоящий из книг, WEB-ресурсов и телефонов ближайших пиццерий.
Идея была в том, чтобы каждый написал свою собственную книгу и даже вписал свои инициалы на обложку.
Но затем я просмотрел свою домашнюю библиотеку, и обнаружил, что во многих из них идея о «дополнении» книги читателем уже реализована. Это так называемые листы «для заметок». Заметки у меня отсутствовали
Поэтому, я решил подойти к творческому процессу более профессионально, и таким образом, книга обрела настоящий вид.
Также, в мои планы входит (в случае положительной оценки книги квалифицированными разработчиками и наличия у меня свободного времени) дальнейшее развитие теории «единого пространства УПР» в виде сайта в сети Интернет.
Сайт представлял бы собой информационный портал для обмена информацией между разработчиками ПО и пополнения БД УПР. Основные компоненты сайта форум разработчиков, разбитый по темам (этапам ЖЦ, методологиям, продуктам и прочее), гостевая книга, профили пользователей сайта и самое главное БД УПР, доступную для публичного доступа. Каждое новое УПР (или изменение описания уже существующего) оценивалось бы пользователями сайта, и в случае положительного результата, добавлялось бы в БД.
Однако получилось то, что получилось. Что касается продолжения книги, то я думаю, что оно будет написано в тот момент, когда мои профессиональные познания выйдут на качественно новый уровень. Может быть, на это понадобиться лет двадцать (как у Брукса), а может раньше.
Кстати, по поводу Брукса. Вы заметили различия между посвящениями 1975 и 1995 годов? В первом упоминаются непосредственный и самый главный начальник. Во втором же «Нэнси, Божьему дару для меня». Наконец-то в списке жизненных ценностей появляется семья и всё, что с этим связано. Не в этом ли заключается «сущность и акциденция программной инженерии»?
Однако получилось то, что получилось. Что касается продолжения книги, то я думаю, что оно будет написано в тот момент, когда мои профессиональные познания выйдут на качественно новый уровень. Может быть, на это понадобиться лет двадцать (как у Брукса), а может раньше.
Кстати, по поводу Брукса. Вы заметили различия между посвящениями 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 максимально четко распределить работу каждого участника процесса разработки. Самая большая проблема, по моему мнению, заключается в том, что трудно (или даже невозможно) найти таких людей, которые будут делать только то, что им сказано. Как скоро им надоест заниматься одним и тем же? Не теряется ли чувство ответственности (и как следствие удовлетворение от результата) за выполненную работу при жестком фиксировании участков работ? Служит ли наличие согласованных интерфейсов по обмену информацией гарантией качества и эффективности работы?