- или это кривые переводы, в которых черт ногу сломит,
- или это куча шаблонов, в которой непонятно, за что хвататься,
- или некий набор общих соображений, которые непонятно, как приложить к реальной ситуации.
Причины существования такого бедлама объяснил, в частности, Алистер Коберн в статье Каждому проекту своя методология Если пересказать коротко, то Коберн вводит 2 характеристики проекта: критичность и число задействованных людей, а так же 2 характеристики методологии: объем (число ролей) и плотность (относительный объем информации, фиксируемой на носителях, что коррелирует с количеством артефактов методологии). В качестве методологии понимается 3-хмерная раскладка роли-виды работ - фазы проекта (время) с указанием, кто когда и что должен делать и над какими артефактами, что порождает более или менее детализированное описание процесса разработки. Согласно Коберну, плотность и объем методологии должны зависеть от критичности и числа задействованных людей в проекте, тогда как критичность и число людей напрямую зависят от назначения разрабатываемой системы и ее сложности (функционального объема). Обобщить выводы Коберна можно следующей короткой фразой: процесс разработки (и внедрения) автоматизированной системы должен строиться в каждом проекте исходя из ее назначения и сложности.
Если обобщить еще немножко, то мы получим (например) изречение Сунь-Цзы записанное за сотни лет
до появления компьютеров: Поэтому сказано, что тот, кто знает врага и знает себя, не
окажется в опасности и в ста сражениях. Тот, кто не знает врага, но
знает себя, будет то побеждать, то проигрывать. Тот, кто не знает ни
врага, ни себя, неизбежно будет разбит в каждом сражении.
То есть, начиная сражение (разработку или внедрение системы) надо знать и ситуацию, которую
необходимо преодолеть (что и над чем/кем требуется сделать),
и собственные возможности, и только из этого строить стратегию и тактику
проекта (то есть план или процесс).
Сегодняшняя ситуация с литературой по разработке софта такова:
1) имеются неплохие сборники тактических приемов: руководства по программированию на конкретных языках, по применению методов и инструментов проектирования, анализа и управления проектами, которые потенциально могут дать тактические возможности, к ним же относятся и своды знаний;
2) имеются обширные описания методологий, представляющие собой более или менее обобщенные шаблонные процессы, связывающие тактические инструменты в единое целое.
3) очень редко встречаются руководства по стратегии и философии - книги, показывающие, как связать "знание врага" со "знанием себя" - как определить необходимость и масштабы применения каждого инструмента, что выкинуть из шаблонных процессов, а что добавить, как натянуть предлагаемые шаблоны на имеющиеся ресурсы.
1) имеются неплохие сборники тактических приемов: руководства по программированию на конкретных языках, по применению методов и инструментов проектирования, анализа и управления проектами, которые потенциально могут дать тактические возможности, к ним же относятся и своды знаний;
2) имеются обширные описания методологий, представляющие собой более или менее обобщенные шаблонные процессы, связывающие тактические инструменты в единое целое.
3) очень редко встречаются руководства по стратегии и философии - книги, показывающие, как связать "знание врага" со "знанием себя" - как определить необходимость и масштабы применения каждого инструмента, что выкинуть из шаблонных процессов, а что добавить, как натянуть предлагаемые шаблоны на имеющиеся ресурсы.
И проблемой для начинающих и продолжающих русскоязычных разработчиков является не
недостаток информации, а, во-первых, ее противоречивость, и, во-вторых, отсутствие информации, как
приложить модели к окружающей действительности.
Что делать ^
Судя по всему, многое может прийти только с опытом,
но всегда можно улучшить ситуацию.
Давайте посмотрим, каким бы мог быть хороший учебник (или свод знаний) по разработке и
внедрению ПО.
Во-первых, нужен хороший глоссарий, который мог бы не просто дать еще одно к десятку
имеющихся определений термина, но и сопоставить термины из разных уже имеющихся
сводов знаний и методологий
(учитывая множество переводов, в разных книгах часто одно и тоже называют разными словами, а иногда
одним словом - разные вещи).
Во вторых нужны следующие вещи:
- описание моделей, применяемых при проектировании и анализе, что составляет множество инструментов ИТ аналитика, программиста, проектировщика и менеджера;
- описание преобразований на этих моделях: как из известной информации получается неизвестная информация;
- методы сопоставления моделей с реальностью, как информация извлекается из реальности и помещается в модели, и как результирующие модели приживляются обратно в реальность.
- описание моделей, применяемых при проектировании и анализе, что составляет множество инструментов ИТ аналитика, программиста, проектировщика и менеджера;
- описание преобразований на этих моделях: как из известной информации получается неизвестная информация;
- методы сопоставления моделей с реальностью, как информация извлекается из реальности и помещается в модели, и как результирующие модели приживляются обратно в реальность.
Из всего перечисленного самый большой объем информации - это конкретные инструменты проектирования,
разработки и управления, но ее и легче всего достать, с методами преобразования моделей
дела обстоят хуже, но и здесь есть достаточно хорошие источники информации, однако они разрознены
и слабо обобщены.
Методы извлечения моделей из реальности и интерпретации результатов - это самое сложное и неуловимое,
толковых учебников или мало или нет вообще.
Эта ситуация неудивительна и существует в любой инженерной дисциплине. Учитывая существующие
недостатки в хорошем учебнике должны быть следующие темы (в порядке важности):
1) Глоссарий и базовые абстрактные принципы анализа и разработки;
2) конкретные методы преобразования моделей;
3) конкретные шаблоны и примеры мелкой россыпью.
1) Глоссарий и базовые абстрактные принципы анализа и разработки;
2) конкретные методы преобразования моделей;
3) конкретные шаблоны и примеры мелкой россыпью.
Структура учебника может быть нанизана на цикл создания системы, показанный (чуть выше) на рисунке.
Если детализировать то, что происходит в реальности, добавить смежные элементы,
то получится модель на следующем рисунке.
Таким образом, из элементов, подлежащих описанию до "перехода", мы выделили исходную информацию:
- пользу, порождающую цели проекта и вытекающую из интересов заинтересованных сторон;
- потребителя;
- заказчика;
- разработчика;
- жизнь потребителей без системы.
- пользу, порождающую цели проекта и вытекающую из интересов заинтересованных сторон;
- потребителя;
- заказчика;
- разработчика;
- жизнь потребителей без системы.
На основе исходной информации мы совершаем "переход", на выходе которого должны получить
описания следующих элементов, образующих прогноз (или план) будущих процессов достижения целей:
- программный продукт (комплект поставки);
- описание развернутого и функционирующего программного продукта;
- описание жизненного цикла системы:
-- описание разработки;
-- описание внедрения;
-- описание процесса эксплуатации;
-- описание процесса вывода системы из эксплуатации.
- программный продукт (комплект поставки);
- описание развернутого и функционирующего программного продукта;
- описание жизненного цикла системы:
-- описание разработки;
-- описание внедрения;
-- описание процесса эксплуатации;
-- описание процесса вывода системы из эксплуатации.
После "перехода" остается "реализовать" планы разработки и внедрения и измерить достигнутую пользу
относительно запланированной в процессе эксплуатации.
Разобрав элементы окружающей реальности, попадающие в наше поле зрения в связи с разработкой
и внедрением ПО, следует обратиться к дисциплинам, помогающим нам достигать целей.
Во-первых, следует изучить методы и способы извлечения исходных данных, а также тот минимальный
информационный набор (по сути, перечень вопросов - суть исходной информации),
который необходим нам для успешного достижения целей проекта.
Во-вторых, следует изучить способы описания (языки, нотации, шаблоны) исходных данных
и способы представления планов и прогнозов - это набор моделей, на которых производятся дальнейшие
формальные преобразования, синтез и расчеты.
В-третьих, следует изучить методы "перехода" - набор более или менее формальных алгоритмов
по преобразованию исходных данных в результирующие планы (преобразование одних моделей в другие),
а также методы полуформального
синтеза систем с последующей формальной проверкой на работоспособность.
В-четвертых, следует изучить методы "реализации" - набор методов превращения моделей
в продукт (установочный пакет) и методов превращения жизни без системы в жизнь
с системой, то есть, методы реализации и проведения организационно-технических планов в жизнь.
1. Введение в разработку и внедрение
1.1 Глоссарий (основные термины, с учетом разницы в переводах и методологиях)
1.2 Общие принципы инженерного дела
1.3 Общие принципы менеджмента
1.4 Общие принципы системного анализа и моделирования
1.5 Общие принципы сбора информации (исходных данных и измерения результатов)
2. Исходные данные (описание элементов действительности, отражаемых в исходных данных, их типология, демонстрация, как они ложатся в модели разных видов)
3. Планы и прогнозы (описание элементов действительности, отражаемых в планах и прогнозах, их типология, демонстрация, как они ложатся в модели разных видов)
4. Переход (набор алгоритмов формального перехода и алгоритмов синтеза-верификации, выполняемых на моделях)
5. Реализация
5.1 Реализация установочного пакета согласно плану (методы - краткий обзор, так как технологии плодятся слишком быстро, с другой стороны по ним достаточно информации)
5.2 Организационно-техническое внедрение (методы проведения планов в жизнь - краткий пересказ постулатов проектного управления)
6. Справочник моделей (наборы шаблонов из разных методологий, покрывающих различные элементы исходных данных, планов и алгоритмов преобразования при переходе)
Ну и что? ^
Можно видеть, что по каждому разделу достаточно много информации уже давно есть и, с первого взгляда, получается масло масляное... Но это не так. Обилие информации по разработке ПО, в том числе и переводной, рождает такое состояние, в котором большинство начинающих разработчиков, аналитиков и менеджеров за деревьями не видят леса. Например, многие ли из нас понимают, что самый близкий аналог ТЗ по ГОСТ 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.
| Copyright © 2007-2013 Сергей Александрович Нужненко (aka Boatman) | ^ О сайте Главная Новости Карта |