Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2008-02-19 04:26    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Здесь своду быть

   В чем проблема
   Что делать
   Ну и что?
   Итого

В чем проблема  ^

Многие существующие своды знаний, учебники или методологии по разработке и внедрению софта страдают одной из нескольких проблем:
- или это кривые переводы, в которых черт ногу сломит,
- или это куча шаблонов, в которой непонятно, за что хвататься,
- или некий набор общих соображений, которые непонятно, как приложить к реальной ситуации.
Причины существования такого бедлама объяснил, в частности, Алистер Коберн в статье Каждому проекту своя методология Если пересказать коротко, то Коберн вводит 2 характеристики проекта: критичность и число задействованных людей, а так же 2 характеристики методологии: объем (число ролей) и плотность (относительный объем информации, фиксируемой на носителях, что коррелирует с количеством артефактов методологии). В качестве методологии понимается 3-хмерная раскладка роли-виды работ - фазы проекта (время) с указанием, кто когда и что должен делать и над какими артефактами, что порождает более или менее детализированное описание процесса разработки. Согласно Коберну, плотность и объем методологии должны зависеть от критичности и числа задействованных людей в проекте, тогда как критичность и число людей напрямую зависят от назначения разрабатываемой системы и ее сложности (функционального объема). Обобщить выводы Коберна можно следующей короткой фразой: процесс разработки (и внедрения) автоматизированной системы должен строиться в каждом проекте исходя из ее назначения и сложности.
Если обобщить еще немножко, то мы получим (например) изречение Сунь-Цзы записанное за сотни лет до появления компьютеров: Поэтому сказано, что тот, кто знает врага и знает себя, не окажется в опасности и в ста сражениях. Тот, кто не знает врага, но знает себя, будет то побеждать, то проигрывать. Тот, кто не знает ни врага, ни себя, неизбежно будет разбит в каждом сражении. То есть, начиная сражение (разработку или внедрение системы) надо знать и ситуацию, которую необходимо преодолеть (что и над чем/кем требуется сделать), и собственные возможности, и только из этого строить стратегию и тактику проекта (то есть план или процесс).
Сегодняшняя ситуация с литературой по разработке софта такова:
1) имеются неплохие сборники тактических приемов: руководства по программированию на конкретных языках, по применению методов и инструментов проектирования, анализа и управления проектами, которые потенциально могут дать тактические возможности, к ним же относятся и своды знаний;
2) имеются обширные описания методологий, представляющие собой более или менее обобщенные шаблонные процессы, связывающие тактические инструменты в единое целое.
3) очень редко встречаются руководства по стратегии и философии - книги, показывающие, как связать "знание врага" со "знанием себя" - как определить необходимость и масштабы применения каждого инструмента, что выкинуть из шаблонных процессов, а что добавить, как натянуть предлагаемые шаблоны на имеющиеся ресурсы.
И проблемой для начинающих и продолжающих русскоязычных разработчиков является не недостаток информации, а, во-первых, ее противоречивость, и, во-вторых, отсутствие информации, как приложить модели к окружающей действительности.

Что делать  ^

Судя по всему, многое может прийти только с опытом, но всегда можно улучшить ситуацию. Давайте посмотрим, каким бы мог быть хороший учебник (или свод знаний) по разработке и внедрению ПО.
Во-первых, нужен хороший глоссарий, который мог бы не просто дать еще одно к десятку имеющихся определений термина, но и сопоставить термины из разных уже имеющихся сводов знаний и методологий (учитывая множество переводов, в разных книгах часто одно и тоже называют разными словами, а иногда одним словом - разные вещи). Во вторых нужны следующие вещи:
- описание моделей, применяемых при проектировании и анализе, что составляет множество инструментов ИТ аналитика, программиста, проектировщика и менеджера;
- описание преобразований на этих моделях: как из известной информации получается неизвестная информация;
- методы сопоставления моделей с реальностью, как информация извлекается из реальности и помещается в модели, и как результирующие модели приживляются обратно в реальность.
Из всего перечисленного самый большой объем информации - это конкретные инструменты проектирования, разработки и управления, но ее и легче всего достать, с методами преобразования моделей дела обстоят хуже, но и здесь есть достаточно хорошие источники информации, однако они разрознены и слабо обобщены. Методы извлечения моделей из реальности и интерпретации результатов - это самое сложное и неуловимое, толковых учебников или мало или нет вообще.
Эта ситуация неудивительна и существует в любой инженерной дисциплине. Учитывая существующие недостатки в хорошем учебнике должны быть следующие темы (в порядке важности):
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.