Часть 2. Сравнение методологий разработки по
Алексей Закис
Как получится…
Структурные методологии
Гибкие методологии
eXtreme Programming, или XP (экстремальное программирование)
Crystal Clear
Feature Driven Development
Общие черты
ГОСТы
Модели зрелости процесса разработки (CMM, CMMI)
RUP
В первой части мы выбрали для сравнения методологий разработки ПО такие показатели, как отношение методологии к итеративной разработке и степень формальности в оформлении рабочих материалов и вообще в проведении разработки. В этой части мы используем названные показатели для сравнения наиболее известных методик разработки ПО.
Как получится…
Увы, это самая сложная для описания категория — ведь в нее входят как продукт судорожных метаний новичка, пытающегося любой ценой выполнить свой первый проект, так и вполне зрелые и устоявшиеся методологии, вобравшие в себя многолетний и разнообразный опыт конкретных команд разработчиков и даже описанные во внутренних регламентах. Поскольку люди, способные разработать собственную методологию, как правило, могут сами оценить ее в плане итеративности и формализованности, будем ориентироваться на новичков. Увы, чаще всего это означает, что правил ведения разработки либо не существует вообще, либо они разработаны и приняты, но не выполняются. Естественным в таких условиях является крайне низкий уровень формализма разработки. Так что с этим все понятно.
Разработка «Как получится»
А как обстоит дело с применением итеративного подхода? Увы, как правило, он в таких проектах не используется. Прежде всего потому, что он бы позволил еще на первых итерациях оценить проект как крайне сомнительный и требующий срочного вмешательства более высокого руководства для наведения порядка. Ведь в итеративном проекте традиционный ответ программиста, что у него уже все на 90% готово, проходит только до момента завершения первой итерации…
Структурные методологии
Структурные методологии
Структурные методы — это группа методологий, разработанных, как правило, еще до широкого распространения объектно-ориентированных языков. Все они предполагают каскадную разработку. Хотя, как выяснилось, еще в той статье, которую часто цитируют как первое изложение каскадного подхода, было сказано, что желательно начинать проект с разработки прототипа, то есть выполнять как минимум две итерации.
Тем не менее основу этих методологий составляют последовательный переход от работы к работе и передача результатов (документов) очередного этапа участникам последующего.
Также все эти методологии предполагают высокоформализованный подход, хотя высказывания о разумном количестве документации можно найти и в них. Одним из неочевидных примеров того, что методологии разработки ПО развивались не только на Западе, является цитата из изданной в нашей стране в начале 1980-х годов книги, гласящая, что степень формализации задания на программирование должна определяться исходя из того, насколько хорошо сработались аналитик и программист. И это при том, что тематика книги предполагала разработку достаточно критических, как их теперь называют, систем, ошибки в которых ведут к серьезным потерям или даже к катастрофам.