11Подходы к созданию программных продуктов. Особенности и содержание «тяжелых» методологий

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

Характеристики тяжелой методологии:

Высокая стоимость внесения изменений в проект

Независимость от разработчика

Большие коллективы

Мобильность и возможность развития ПП

Длительный период планирования. Высокие требования к качеству планирования.

Высокая стоимость разработки

Большое время жизни ПП

Много времени на согласование.

Низка индивидуальная производительность разработчиков

Большое время между возникновением идеи и получением работающей версии системы

Совершенствование системы сопоставимо со временем существования организации

12Роль дисциплины при реализации сложных программных систем

При проектировании сложных программных систем в условиях неопределённости можно выделить 2 основных подхода: 1) Подход 1: руководителем проекта является человек, который хорошо разбирается в том, как создавать локальные проекты, но имеет мало опыта в разработке больших, многокомпонентных систем. В сложном проекте с большой неопределённостью он не знает, за что взяться и поэтому решает реализовывать то, что ему и его команде понятно на данный момент. В результате программируется множество блоков кода, для которых никто не определяет требования по входам и выходам. И в конечном итоге очень сложно или попросту невозможно объединить эти “кусочки” в единое целое и выпустить готовый программный продукт. 2) Подход 2: в начале тщательно планируется ход проекта и разрабатывается система управления, к каждому блоку предъявляются требования по входам и выходам. Тесты прогоняются от простого к сложному, т.е. сначала тестируем локальные блоки кода, а потом тестируются их взаимодействие на внешнем уровне. — Если “дисциплина” - трудовая дисциплина Таким образом, отсутствие дисциплины в разработке и планировании проекта, как это показано в первом подходе, порождает большое количество проблем, на решение которых может уйти куда больше времени, нежели если бы мы изначально всё продумали, проанализировали и спланировали. Спешка, неопытность и желание получить всё и сразу зачастую приводят к тому, что все недовольны: и заказчик, и сам разработчик, а результата как не было, так и нет, и поэтому приходится начинать разработку заново либо признать проект провальным и закрыть его. — Если “дисциплина” - предмет (оценка качества и тестирование ПО) Таким образом, можно сказать, что обеспечить качество разрабатываемого программного продукта можно только путём тщательного планирования и тестирования. При втором подходе руководитель определил систему управления, предъявил требования к оценке качества как каждого блока по отдельности, так и всей системы, чем не только упростил процесс отладки продукта, но и повысил надёжность своей разработки.Но также есть риск морально усторелого продукта, проект может гораздо быстрее пока ты придумаешь что-то. Хвататься за отдельные кусочки тоже плохо и думать долго тоже плохо.

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