Судя по всему, многое может прийти только с опытом,
но всегда можно улучшить ситуацию.
Давайте посмотрим, каким бы мог быть хороший учебник (или свод знаний) по разработке и
внедрению ПО.
Во-первых, нужен хороший глоссарий, который мог бы не просто дать еще одно к десятку
имеющихся определений термина, но и сопоставить термины из разных уже имеющихся
сводов знаний и методологий
(учитывая множество переводов, в разных книгах часто одно и тоже называют разными словами, а иногда
одним словом - разные вещи).
Во вторых нужны следующие вещи:
- описание моделей, применяемых при проектировании и анализе,
что составляет множество инструментов ИТ аналитика, программиста, проектировщика и менеджера;
- описание преобразований на этих моделях: как из известной информации получается неизвестная
информация;
- методы сопоставления моделей с реальностью, как информация извлекается из реальности и помещается
в модели, и как результирующие модели приживляются обратно в реальность.
Из всего перечисленного самый большой объем информации - это конкретные инструменты проектирования,
разработки и управления, но ее и легче всего достать, с методами преобразования моделей
дела обстоят хуже, но и здесь есть достаточно хорошие источники информации, однако они разрознены
и слабо обобщены.
Методы извлечения моделей из реальности и интерпретации результатов - это самое сложное и неуловимое,
толковых учебников или мало или нет вообще.
Эта ситуация неудивительна и существует в любой инженерной дисциплине. Учитывая существующие
недостатки в хорошем учебнике должны быть следующие темы (в порядке важности):
1) Глоссарий и базовые абстрактные принципы анализа и разработки;
2) конкретные методы преобразования моделей;
3) конкретные шаблоны и примеры мелкой россыпью.
Структура учебника может быть нанизана на цикл создания системы, показанный (чуть выше) на рисунке.
Если детализировать то, что происходит в реальности, добавить смежные элементы,
то получится модель на следующем рисунке.
Таким образом, из элементов, подлежащих описанию до "перехода", мы выделили исходную информацию:
- пользу, порождающую цели проекта и вытекающую из интересов заинтересованных сторон;
- потребителя;
- заказчика;
- разработчика;
- жизнь потребителей без системы.
На основе исходной информации мы совершаем "переход", на выходе которого должны получить
описания следующих элементов, образующих прогноз (или план) будущих процессов достижения целей:
- программный продукт (комплект поставки);
- описание развернутого и функционирующего программного продукта;
- описание жизненного цикла системы:
-- описание разработки;
-- описание внедрения;
-- описание процесса эксплуатации;
-- описание процесса вывода системы из эксплуатации.
После "перехода" остается "реализовать" планы разработки и внедрения и измерить достигнутую пользу
относительно запланированной в процессе эксплуатации.
Разобрав элементы окружающей реальности, попадающие в наше поле зрения в связи с разработкой
и внедрением ПО, следует обратиться к дисциплинам, помогающим нам достигать целей.
Во-первых, следует изучить методы и способы извлечения исходных данных, а также тот минимальный
информационный набор (по сути, перечень вопросов - суть исходной информации),
который необходим нам для успешного достижения целей проекта.
Во-вторых, следует изучить способы описания (языки, нотации, шаблоны) исходных данных
и способы представления планов и прогнозов - это набор моделей, на которых производятся дальнейшие
формальные преобразования, синтез и расчеты.
В-третьих, следует изучить методы "перехода" - набор более или менее формальных алгоритмов
по преобразованию исходных данных в результирующие планы (преобразование одних моделей в другие),
а также методы полуформального
синтеза систем с последующей формальной проверкой на работоспособность.
В-четвертых, следует изучить методы "реализации" - набор методов превращения моделей
в продукт (установочный пакет) и методов превращения жизни без системы в жизнь
с системой, то есть, методы реализации и проведения организационно-технических планов в жизнь.
Ну и что? ^
Можно видеть, что по каждому разделу достаточно много информации уже давно есть
и, с первого взгляда,
получается масло масляное... Но это не так. Обилие информации по разработке ПО, в том числе
и переводной, рождает такое состояние, в котором большинство начинающих разработчиков, аналитиков
и менеджеров за деревьями не видят леса. Например, многие ли из нас понимают, что самый
близкий аналог ТЗ по ГОСТ 34.602 в западных методологиях - это план проекта, со всеми вытекающими
последствиями (в частности, написание плана - удел менеджеров, а не аналитиков).
Другой пример: такое модное нынче слово "требования" есть ничто иное, как часть исходных
данных для реализации системы, другие части - это цели проекта, описание жизни без системы
и некоторая другая информация. Трагическая разница в расстановке акцентов и приоритетов:
требования служат для установления контрактных отношений с заказчиком и формальной
приемки системы или внутреннего тестирования (и специфика этого процесса
отличается у нас), для успешной же разработки и внедрения системы нужны ВСЕ ИСХОДНЫЕ ДАННЫЕ.
Точно так же
для успешной реализации системы (получения комплекта поставки) нужна не архитектура,
а ПОЛНЫЙ ПЛАН РАЗРАБОТКИ.
Тонкости перевода совместно с отличиями западной деловой традиции (отраженной в методологиях)
от нашей родной делают дословное приживление некоторых методик мучительным процессом,
в котором одной из главных проблем является необходимость построения в голове
нового понятийного набора, а потом согласования этих понятий с коллегами, заказчиками и смежниками,
которые или читали другие переводы или придерживаются старой советской (и местами
достаточно эффективной) управленческой школы, с ее устоявшимися понятиями, терминами и методами.
Как результат мы видим вавилонское столпотворение и массу вопросов начинающих, на которые
нет ответа. Мало описать последовательность разработки софта, важно показать смысл и цель
каждого элемента, чтобы в другом проекте из имеющихся кусочков можно было собрать новый процесс
перехода и реализации, таким образом первый вопрос для каждого обсуждаемого элемента
должен быть "зачем он нужен", ни «что с ним делают дальше», ни «откуда он берется», а именно, каков его
смысл и суть.
Итого ^
Итого, предлагаемая структура учебника следующая
1. Введение в разработку и внедрение
1.1 Глоссарий (основные термины, с учетом разницы в переводах и методологиях)
1.2 Общие принципы инженерного дела
1.3 Общие принципы менеджмента
1.4 Общие принципы системного анализа и моделирования
1.5 Общие принципы сбора информации (исходных данных и измерения результатов)
2. Исходные данные (описание элементов действительности, отражаемых в исходных данных, их типология,
демонстрация, как они ложатся в модели разных видов)
3. Планы и прогнозы (описание элементов действительности, отражаемых в планах и прогнозах,
их типология,
демонстрация, как они ложатся в модели разных видов)
4. Переход (набор алгоритмов формального перехода и алгоритмов синтеза-верификации, выполняемых
на моделях)
5. Реализация
5.1 Реализация установочного пакета согласно плану (методы - краткий обзор, так как технологии
плодятся слишком быстро, с другой стороны по ним достаточно информации)
5.2 Организационно-техническое внедрение (методы проведения планов в жизнь - краткий пересказ
постулатов проектного управления)
6. Справочник моделей (наборы шаблонов из разных методологий, покрывающих различные элементы
исходных данных, планов и алгоритмов преобразования при переходе)
Пока есть запал, я начинаю детализировать содержание,
писать вводные разделы и фрагменты других разделов. Приглашаю всех желающих в соавторы,
также требуются корректоры-редакторы для улучшения качества материала, оппоненты
для обсуждения идей и постановки новых вопросов. Предлагаю всем желающим
связаться со мной по адресу
haron@ru.ru.