Относительно моего неучастия в SEC(R) 2005 в качестве докладчика

Уважаемые, Коллеги

Как вы уже читали, 19 июля 2005 года я разместил две заявки на доклады на конференции Software Engineering Conference Russia - SEC(R) 2005 (см. http://sorlik.blogspot.com/2005/07/27-28-software-engineering-conference.html ):
1. IEEE Guide to the Software Engineering Body Of Knowledge (SWEBOK) - цели, содержание и значение для индустрии.
2. Жизненный цикл программного обеспечения: стандарты и модели.

Прошло более трех месяцев с момента размещения заявки (1) на доклад, посвященный SWEBOK, перевод областей знаний которого на русский язык (с замечаниями и комментариями) я сделал общедоступным (см. http://sorlik.blogspot.com и http://www.software-testing.ru/lib/se/ ) для русскоговорящего сообщества разработчиков, следуя духу IEEE SWEBOK.

Рад сообщить, что второй доклад был принят Программным комитетом.
Однако, вместо отклонения или принятия первого доклада (1) по SWEBOK, я был поставлен перед фактом объявления моего участия в круглом столе "Computing Curriculum, SWEBOK" [вместе с Андреем Тереховым (Microsoft), Владимиром Павловым (Microsoft) и Анатолием Шкредом (Intuit)], в качестве безусловной "альтернативы" моему выступлению с этим докладом.

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

Сформулированная позиция является моей персональной позицией и никак не ассоциирована с моей работой в компании Borland и ни в какой мере не выражает позиции Borland.

С уважением,
Сергей Орлик

Чего не хватает в SWEBOK или новые области знаний программной инженерии.

Краткое резюме, отражающее точку зрения* автора неофициального перевода SWEBOK на русский язык.

1. На пути трансформации сегодняшней типичной разработки программных систем в управляемый и предсказуемый бизнес-процесс – в производство, необходимо уделение специального внимания экономическим аспектам программной инженерии, включая концепции, методы, техники и практические соображения в этой области, включая вопросы аутсоурсинга и офшорной разработки. Назовем такую желаемую область - “Экономика программной инженерии”.

2. Производство и управление созданием любого продукта (и, особенно, являющегося результатом инженерных усилий) невозможно представить без планирования, контроля и предовращения рисков. Статистика индустрии программного обеспечения (например, знаменитый постоянно обновляемый отчет “Chaos Report”, The Standish Group) неумолимо свидетельствует о катастрофическе низком КПД совокупной деятельности в области программного обеспечения. Без уделения должного внимания рискам ни о какой экономике программного обеспечения не может быть и речи. Вполне естественно выделить общие положения в отношении рисков с учетом специфики программного обеспечения в самостоятельную область знаний “Риски в программной инженерии”.

3. Приходится признать, что наравне с достачно хаотичным процессом разработки приложений, к сожалению, встречающимся не только в небольших внутрикорпоративных отделах ИТ, но и у далеко не самых мелких производителей и независимых поставщиков программного обеспечения, просто катастрофические масштабы приняло пренебрежение элементарными аспектами информационной безопасности в создаваемых ими продуктах. Таким образом, необходимо выделение самостоятельной области знаний “Безопасность программного обеспечения”.

4. На протяжении многих лет, методы управления разработкой программного обеспечения, по-сути, игнорировали человеческий и творческий факторы программной инженерией. Бурное развитие и успешное применение Agile-методов и практик стало ответом на консерватизм в “официальной” программной инженерии (представленной в форме тех или иных стандартов). Вопросы взаимодействия внутри команды разработки и вовлечения заказчика (в лице конкретных его представителей) непосредственно в процесс разработки стали двумя из четырех ключевых положений The Agile Manifesto. Например, организация рабочего пространства, неформальные методы инженерной деятельности и многие другие концептуальные и практические аспекты демонстрируют явную тенденцию к первичному формированию области знаний “Коммуникации в программной инженерии”.

5. Стоимость создания, внедрения, изменения и сопровождения инфраструктуры разработки программного обеспечения (вне зависимости от того, идет ли речь о коммерческих продуктах или результатах open source проектов) – достаточно высока и связана со все возрастающей сложностью создаваемых систем, используемого инструментария и значимости информационных систем для нормального функционирования бизнес-процессов потребителей ИТ. При всей широте существующей области знаний “Инструменты и методы программной инженерии”, вопросы выбора (evaluation), использования, приобретения или внутренней разработки, а также внутрипроектной/внутрикорпоративной стандартизации средств автоматизации процессов управления, разработки и сопровождения, требуют, как минимум, введения отдельной секции “Выбор инструментов”, включающей аспекты формирования критериев, процессов и принятия решений об использовании инструментов. Как максимум – разделения на области знаний “Инструменты программной инженерии” и “Методы программной инженерии”.

6. Наконец, возможная новая область знаний “Управление человеческими ресурсами, занятыми в программной инженерии” обладает существенной спецификой, по сравнению, например, с PMI Guide to PMBOK (Project Management Body Of Knowledge), учитывая, что обсуждаемая нами инженерная дисциплина, при всей своей эвристической природе, требует специального внимания квалификационной оценке персонала, его обучению, профессиональной переподготовке (где еще технологии развиваются с такой же скоростью?!) и, конечно, найму на работу (где еще такая проблема с кадрами?!).

Это, конечно, лишь вопросы. Но, в правильно поставленном вопросе есть и доля ответа. Надеюсь, что и вы сочтете эти вопросы правильными.

* Данная точка зрения автора может измениться при появлении соответствующих аргументов ;-)

Завершающие главы SWEBOK на русском языке

Здравствуйте, Коллеги!

В продолжение публикации неофициального перевода* Руководства IEEE к Своду Знаний по Программной Инженерии (IEEE Guide to Software Engineering Body Of Knowledge - SWEBOK), стал доступен перевод области знаний SWEBOK "Качество программного обеспечения" ("Software Quality"), с замечаниями и комментариями.

Это завершающая глава по областям знаний SWEBOK, непосредственно касающаяся содержания предмета дисциплины программной инженерии. Также доступно краткое резюме по структуре и содержанию SWEBOK.

Отредактированный перевод (с замечаниями и комментариями) последней области знаний SWEBOK - "Related Disciplines of Software Engineering", связанный с аспектами применения других дисциплин к разработке программного обеспечения, будет выложен в ближайшие дни в публичный доступ (как это предполагается текущей версией оригинального издания SWEBOK), как и все опубликованные переводы* предыдущих глав, по адресу: http://sorlik.blogspot.com .

Также, я буду доступен для очного общения по этому переводу SWEBOK на протяжении всей работы конференции Software Engineering Conference Russia - SEC(R) 2005.

С уважением,
Сергей Орлик
Borland
mailto:sorlik@borland.ru
Персональный блог: http://sorlik.blogspot.com

* Данная работа является персональной профессиональной инициативой, не финансируется и не ассоциирована в какой-либо форме ни с какой компанией или организацией.

Практикум "Аспекты рисков в управлении требованиями"

Коллеги!

Рад пригласить вас на практикум "Аспекты рисков в управлении требованиями" ("Addressing Risks in Requirement Engineering"), который состоится 26-го октября в Москве в рамках конференции Software Engineering Conference (Russia) - SEC(R) 2005. Факультативная часть практикума будет посвящена иллюстрации аспектов управления требованиями и проектными ожиданиями с использованием Borland CaliberRM и Borland Estimate.

Практикум будет проводить ведущий консультант и авторизованный SCAMPI CMMI Lead Appraiser европейской штаб-квартиры Borland Роберт Фишер (Robert Fisher). Факультативную часть буду делать я и, надеюсь, что смогу показать обновленную версию CaliberRM, включая Estimate ;)

Вся информация и регистрационная форма доступны со страницы практикума .

Borland приобретает компанию Legadero

Это приобретение позволяет Borland расширить возможности решений в области управления жизненным циклом программного обеспечения (ALM) средствами IT Governance.

Сайт Legadero
Technology Governance Research Center
Официальный пресс-релиз о покупке Legadero

Интересные порталы IEEE Computer Society

Если вы еще не знаете - в IEEE Computer Society по-сути поднялась новая волна Web-проектов. При том, что наполнение этих проектов только началось, уже можно найти кое-что интересное:

1. IEEE Distributed Systems Online - вопросы, связанные с распределенными системами.
2. IEEE Software Engineering Online - onlin'изация материалов по программной инженерии.

Качество vs. программное обеспечение

Готовя к публикации перевод главы SWEBOK "Software Quality" (будет доступен в ближайшие дни) не смог удержаться чтобы не коснуться этой темы отдельно в блоге. Я получил ряд откликов на использование мной такого словосочетания как "приемлемое качество" (как положительных, так и, не буду скрывать, негативных). Хотел бы прояснить то, что я подразумеваю под приемлемым качеством и почему часто использую такой, если позволите, термин ;)

Описание упомянутой мной области знаний SWEBOK начинается с введения:
"Что такое качество и почему оно должно быть столь глубоко представлено (в виде самостоятельной области знаний, прим. автора) в SWEBOK? На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process, прим. автора) описывает качество как “достижение отличного уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями” (“market-driven quality”). Критерий Бэлдриджа (Baldrige) для организационного качества (см. NIST - National Institute of Standards and Technology, “Baldrige National Quality Program”, http://www.quality.nist.gov) использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качествя используется в соответствии с определением системы менеджмента качества ISO 9001 как “степень соответствия присущих характеристик требованиям” (именно так это сформулировано в официальном переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь”, прим. автора)."

Такое восприятие качества, как мне кажется, естественно перекликается с используемым мной приемлемым качеством, определяемым не только уровнем запросов конечных потребителей в отношении параметров создаваемого продукта, но и заданным контекстом/ограничениями проекта. Это не значит, что “приемлемое качество” противопоставляется “качеству, диктуемому заказчиком” (custom-driven). Конечно, не стоит и проводить параллель “приемлемого качества” с “продуктом второй свежести”. Введение категории “приемлемости” в отношении качества является лишь прагматичным взглядом на желаемую степень совершенства создаваемого продукта (услуги), способную удовлетворить пользователей и достижимую в рамках заданных проектных ограничений. Интересно, что и сама “степень приемлемости” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п. ). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества.

А что Вы думаете на этот счет?

Delphi 2006 or C++Builder 2006 or C#Builder 2006 = Borland Developer Studio 2006

Действительно, содержимое всех трех продуктов идентично - теперь это многоязыковая "студия" для Win32 (Delphi, C++) и .NET (Delphi, C#). Частью студии (кстати, даже в младшей редакции - Pro) стали и средства моделирования Together (аудит, метрики и некоторые другие возможности есть уже в старщих редакциях) и ECO - объектно-реляционный фреймворк для .NET.

Подробности - в моей обзорной презентации (~2.8 Mb) и, конечно, на borland.com, BDN (Borland Developers Network) и ALM Portal.

Творчество vs. “промышленная” разработка ПО

Программная инженерия – единственная инженерная дисциплина, в практике которой преобладают эвристические, а не формальные методы. Это подтверждено более чем 35-летней историей software engineering.

В предисловии к первому изданию (1974-75 г.) классического труда “Мифический человеко-месяц” Фред Брукс пишет: “Во многих отношениях управление большим проектом разработки программного обеспечения аналогично любому крупному начинанию – в большей мере, чем обычно считают программисты. Однако во многих отношениях имеются и отличия – в большей мере, чем обычно предполагают профессиональные менеджеры.” Эту точку зрения в отношении восприятия разработки программного обеспечения программистами Брукс отстаивает и, в определенной степени, уточняет во втором издании (1995 г.) “управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов.” Отсюда и столь большое внимание процессам разработки.

Говоря о необходимости индустриализации разработки програмного обеспечения, необходимо понимать, что такая индустриализация должна касаться, в первую очередь, технологий (в части их унификации, включая технологии моделирования, тестирования и т.п.) и методов организации производства программного обеспечения, применения управленческих практик и организационного структурирования коллективов разработки.

Многие менеджеры и, как следствие, разработчики воспринимают это в форме создания жестких условий (например, на основе тотального контроля – “большого брата”), в которых люди не могут не работать, т.е. потогонной - конвейерной системы. На самом деле, суть состоит в том, чтобы создать условия, в которых комфортно, а, значит, и хочется работать. Управление – менеджмент – предполагает высокую роль пресловутого “человеческого фактора”. Том Демарко и Тимоти Листер в не менее классической книге “Человеческий фактор: успешные проекты и команды” сформулировали то, что является одной из ключевых проблем индустрии программного обеспечения: “главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические.”

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

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

А “бантики” …. они тоже нужны, ведь действительно приятно работать с интуитивно понятным, красивым и, в тоже время, функциональным инструментом ;-)

А что Вы думаете на этот счет?

Опубликован перевод главы SWEBOK "Инструменты и методы"

Наверное, одна из наиболее спорных областей знаний SWEBOK, что и не скрывают ее авторы. Глава доступна для download:

• "Инструменты и методы программной инженерии"