Статьи

Новый текст, рекомендуемый к прочтению перед моими презентациями про управление рисками в разработке ПО. Должен давать целостное понимание сути инженерной деятельности и основных присущих ей рисков. Является обобщением опыта проектов в области разработки корпоративных БД, кастомного ПО на С++, веб-разработки, микроэлектроники, ПЛИС, печатных плат, телеком-приложений, и конструкторских работ по разработке корпусов. В общем, всего достаточно разностороннего ПО, с которым я соприкасался.

Инженерная деятельность по своей сути - является разработкой детальной спецификации изделия, по которой ее могут изготовить некие «станки». В программной инженерии - «станками» являются средства компиляции и сборки, а детальной спецификацией - исходный текст программы.

Если бы мы не ошибались в процессе написания спецификации, мы бы печатали исходный текст со скоростью машинистки, и он сразу получался бы годным. И никаких рисков в разработке не было бы. Но мы ошибаемся, даже если печатаем не со скоростью машинистки. Ошибаемся во всем. Начиная с того, что допускаем мелкие огрехи и опечатки по невнимательности, продолжая ошибочным выбором подхода, и заканчивая тем - что мы подчас ошибочно полагаем, что то, что мы делаем, автоматически будет кому-то полезно, и решит чью-то проблему.

Иногда мы сразу понимаем, что написали ерунду, которая ни разу не годная. И переделываем ее, даже не отдав ее «станку» «на производство». Иногда мы это понимаем, только испытав результат. А иногда нам кажется, что все о’кэй, пока мы не покажем это пользователю.

Кому-то может показаться, что опытные инженеры не ошибаются, или ошибаются сильно реже. И тем, что они всегда правы, и редко ошибаются, они отличаются от начинающих. Это не так. Отличие опытного инженера в том, что при прочих равных он видит ошибки раньше, и ошибки обходится ему дешевле.

Мы, в общем, настолько регулярно и постоянно ошибаемся в процессе работы над спецификацией, что на это вполне можно закладываться. Исследования метрик плотности ошибок показывают удивительную стабильность данных метрик. Метрика Defects/KLOC показывает куда меньшие вариации, чем LOC/Hour.

Кому-то может показаться, что опытный инженер реже заваливает проекты, чем неопытный. Это, в общем, тоже не так. Ибо, опытной инженер может взять на себя (и берет) более сложную, серьезную, и рискованную проблему, чем неопытный. Поэтому, на практике - ошибаются опытные тоже достаточно часто, и более того - их ошибки, гхм, зачастую обходятся дороже

Все ровно то же самое касается «зрелых процессов», которые представляют собой не индивидуальный, а групповой инженерный опыт. Они, в целом, не уменьшают «уровень риска» проектов, и значимо не улучшают их статистики. Это отмечал еще Том ДеМарко в своем «Peopleware».

Итак, в результате инженерной деятельности у нас появляется детальная спецификация «изделия». Ее разработка, в процессе которой мы регулярно ошибаемся, является, безусловно, задачей инженерной деятельности - непрерывным процессом проектирования. Ага, проектирования, даже когда вы код пишете, это оно. Но не целью. Процесс не может являться целью, не так ли?

Целью инженерной деятельности является решение проблем. Начиная с главной - решения проблемы пользователя. Для ее решения мы и делаем «спецификацию изделия» - начиная с очень общей спецификации - «требований», заканчивая детальной - кодом.

И что происходит, если мы показываем пользователю изделие, а он мотает головой? Оно не решает его проблему. Мы, понимаете ли, ошиблись в гипотезе, что наше изделие ее решит.

Кто-то скажет - мы «ошиблись в требованиях, это не инженерная проблема, она за рамками процесса проектирования». Я скажу: процесс проектирования начинается с разработки самой общей спецификации решения, того, что вы привыкли называть «требования». Никто от вас ничего не «требует», на самом деле. Ситуация другая - это вы предлагаете некий вариант решения. Он - уже результат процесса решения проблем. И посему - вы вполне можете в нем ошибиться. И вы в нем обязательно больно ошибетесь, если отключите мозг, не будете считать это частью процесса проектирования/решения проблем, и поручите их составление левым людям - я гарантирую это. Ибо надо стараться делать лучше - а хуже само получится.

Это инженерная работа, предлагать решения, а не работа пользователя, или каких-то там абстрактных специалистов «по требованиям». Потому, что для предложения варианта решения, надо не только знать и понимать решаемую проблему. Для выбора решения - надо еще и понимать возможности и ограничения. А это - инженерная прерогатива.

Что же происходит, если мы не знаем возможностей и ограничений? А ведь такое бывает. Что, если мы в некотором проекте сталкиваемся с незнакомой нам технологией, возможности и ограничения которой наперед достоверно не известны? Вот, допустим, берем, и делаем свой первый проект на Java. Или впервые в своей практике вкручиваем в приложение Visual Basic for Applications, как в MS Word.

Или, скажем, так. Что, если мы опытные инженеры и заранее понимаем, что возможностей известных технологий нам для адекватного решения не хватит? И нам надо разрабатывать свою собственную?

Выбор базовых технологий, как и принятие решения о создании своих, определенно, является одной из важных проблем, которые должны быть решены в процессе проектирования. Что же будет, если мы как следует ошибемся в этом выборе? Да практически такая же катастрофа, как и ошибка в «требованиях». Базовые технологии задают принципиальные возможности и ограничения. Частенько ничего с ними сделаешь.

В чем мы еще можем больно ошибиться? В общих принципах построения системы - подходе к решению задачи. Это не структура системы - то, что часто называют «дизайном». Это принцип, по которому из требований, при использовании набора базовых технологий, у вас получается структура системы. Он определяет не только подход к подразбиению на крупные компоненты и сервисы, но и определенный способ использования базовых технологий.

Возможно, ваша базовая технология представляет собой некий фреймворк, или систему, в который уже заложен какой-то определенный принцип. Вот, взять 1С - он своими принципами связывает вас по рукам и ногам. А может быть - нет. Может быть, вам надо еще придумать принцип структурирования системы.

Главных проблемы, связанных с правильным выбором принципа, три:

1. Без согласия о принципе построения приложения, невозможно отпараллелить работу на группу, и получить вменяемый результат в конце.
2. Проверить принцип, найдя в нем ошибки, и устранив их, можно только спроектировав (и зачастую - закодировав) что-нибудь в его рамках.
3. Неверно выбранный принцип построения системы может радикально увеличить трудозатраты на разработку, катастрофически снизить устойчивость системы к изменению (или добавлению) требований, делая ее хрупкой, и увеличить стоимость правок в систему.

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

Надо ли говорить, что именно эти решения чаще всего принимаются кем попало и «с потолка»?