Psp/tsp
Одна из последних разработок Института программной инженерии Personal Software Process/Team Software Process. PSP определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:
учитывать время, затраченное на работу над проектом;
учитывать найденные дефекты;
классифицировать типы дефектов;
оценивать размер задачи;
осуществлять систематический подход к описанию результатов тестирования;
планировать программные задачи;
распределять их по времени и составлять график работы.
выполнять индивидуальную проверку проекта и архитектуры;
осуществлять индивидуальную проверку кода;
выполнять регрессионное тестирование.
Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:
установить собственные цели;
составить свой процесс и планы;
отслеживать работу;
поддерживать мотивацию и максимальную производительность.
Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.
Agile
Основная идея всех гибких моделей заключается в том, что применяемый в разработке ПО процесс должен быть адаптивным. Они декларируют своей высшей ценностью ориентированность на людей и их взаимодействие, а не на процессы и средства. По сути, так называемые, гибкие методологии это не методологии, а набор практик, которые могут позволить добиваться эффективной разработки ПО, основываясь на итеративности, инкрементальности, самоуправляемости команды и адаптивности процесса.
Модульное программирование
При написании сложного прикладного программного обеспечения стараются использовать модульное программирование. Данный принцип подразумевает разделение кода программы на отдельные части, которые называются модулями. Модули могут быть оформлены в виде отдельного файла с исходным кодом. Это позволяет уменьшить время перекомпиляции при внесении изменений в код, упрощает чтение кода программы, и упрощает групповую разработку. Т.к. модули могут быть оформлены в виде отдельных файлов, то есть возможность использования уже готовых модулей в своем проекте.
Независимость
В модульном программировании есть понятие независимости - каждый модуль не зависит от других. Каждый модуль можно изменить или модифицировать, не вызывая каких-либо последствий в других модулях. В идеале это позволяет не задумываться о последствиях для всей программы при изменении отдельного модуля, но независимость некоторого модуля нужно рассматривать по отношению к таким факторам, как:
Логическая структура программы, т.е. алгоритм, Если вся программа зависит от некоторого специального подхода, то в скольких модулях потребуется внести изменения при изменении алгоритма?
Аргументы, или параметры, модуля. В этом отношении зависимость модуля может быть довольно сильной: если изменяется число, тип или формат аргументов, то не следует слишком удивляться, если это потребует больших изменений в модуле.
Внутренние переменные таблиц и константы. Многие модули зависят от общих таблиц - если изменяется структура таких таблиц, то мы можем ожидать, что модули также изменятся.
Структура и формат базы данных. В большей степени эта зависимость аналогична зависимости от общих переменных и таблиц.
Модульная структура управления программой. Некоторые пишут модуль не особенно задумываясь над тем, каким образом он будет использоваться.
Предполагая эти факторы неизменными, мы могли бы установить независимость отдельных модулей программы. Если интерфейсы между модулями определены, то в этом случае можно было бы заменять модуль функционально ему эквивалентным, не вызывая при этом никаких последствий ни в каком другом модуле программы. В зависимости от того, насколько возможны такие замены, имеет смысл говорить о том, что мы имеем модульную программу. Таким образом, следующее условие модульности и составляющая часть независимости — условие “один вход — один выход”, т.е. модульная программа должна состоять из модулей, которые имеют одну точку входа и одну точку выхода.