пятница, октября 21, 2005

Чего не хватает в 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), учитывая, что обсуждаемая нами инженерная дисциплина, при всей своей эвристической природе, требует специального внимания квалификационной оценке персонала, его обучению, профессиональной переподготовке (где еще технологии развиваются с такой же скоростью?!) и, конечно, найму на работу (где еще такая проблема с кадрами?!).

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


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

Ярлыки: ,

Комментарии: 2:

Blogger Gusakov Vladimir сказал(а)...

Идея с добавлением "Экономики программной инженерии" весьма интересна. Хотя примеры имхо не очень удачные - вопросы аутсорсинга и оффшорного аутсорсинга имеют не такое уж большое отношение к собственно программной инженерии. На мой взгляд интересно вовлечение экономики в следующие области:

1. Разработка стратегии и собственно архитектуры.

См. например, Rick Kazman, Jai Asundi, Mark Klein "Making Architecture Design Decisions: An Economic Approach": http://www.sei.cmu.edu/publications/documents/02.reports/02tr035.html?si

Charlie Alfred "Value-Driven Architecture: Linking Product Strategy with Architecture":

http://msdn.microsoft.com/architecture/journ/default.aspx?pull=/library/en-us/dnmaj/html/Jour5Value.asp

и многие другие.

2. Выбор методологии разработки waterfall/agile(XP, SCRUM, Crystal).

Здесь очень интересная статья есть у Alistair Cockburn "Process: the Fourth Dimension (Tricking the Iron Triangle)":

http://alistair.cockburn.us/crystal/articles/ptfd/processthefourthdimension.htm

имеется даже ее перевод на русский язык:
http://maxkir.com/sd/IronTriangle_RUS.html

вс дек. 04, 01:36:00 ПП  
Blogger Sergey Orlik сказал(а)...

Спасибо за очень дельный комментарий! Я бы уделил серьезное внимание в "экономике" разработки ПО вопросам стоимостной/временной оценки работ и методам повышения качества/точности таких оценок.

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

пн дек. 12, 05:38:00 ПП  

Отправить комментарий

Подпишитесь на каналы Комментарии к сообщению [Atom]

Ссылки на это сообщение:

Создать ссылку

<< Главная страница