Процесс разработки ПО

Программная инженерия
В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом.
Он содержит следующее:
• информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования - различных IDE, СУБД и т.д.);
• описание практик разработки - проектного менеджмента, правил работы с заказчиком и т.д.;
• шаблоны проектных документов - технических заданий, проектных спецификаций, планов тестирования и пр.
Основная идея стандартного процесса - курсирование внутри компании передового опыта, а также унификация средств разработки.

Программная инженерия
Совершенствование процесса (software process improvement) – это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки.
Что и каким образом можно улучшать:
1. Переход на новые средства разработки, языки программирования и т.д.
2. Улучшение отдельных управленческих и инженерных практик - тестирования, управления требованиями и пр.
3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI).
4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.).

Pull/Push-стратегии.
В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две парадигмы:
• organization pull - внедрение инноваций, нацеленных на решение конкретных проблем компании;
• technology push - широкомасштабное внедрение инноваций из стратегических соображений. Вместо конкретных проблем, которые будут решены после внедрения инновации, в этом случае рассматриваются показатели компании (эффективность, производительность, годовой оборот средств, увеличение стоимости акций публичной компании), которые будут увеличены, улучшены после внедрения инновации. При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которых в данный момент ничего не известно.

Классические модели процесса
Модель - абстракция различных методов разработки ПО, позволяющая лаконично, сжато и информативно их представить.
Фаза (phase) - это определенный этап процесса, имеющий начало, конец и выходной результат. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и выплатой денег за выполненную часть работы.
Вид деятельности (activity) - это определенный тип работы, выполняемый в процессе создания ПО. Разные виды деятельности часто требуют разных профессиональных навыков и выполняются разными специалистами.

Каскадная модель (водопад)
В дальнейшем в связи с развитием программной инженерии и осознанием итеративного характера процесса разработки ПО эта модель активно критиковалась в соответствующих статьях и учебниках.
Была предложена
в 1970 г. Винстоном
Ройсом
(американский ученый
в области информатики, директор центра Lockheed Software Technology Center компании Lockheed в г.Остин, шт. Техас).
В 70-80-е гг. прошлого века эта модель укоренилась в разработке ПО благодаря простоте и сходности с моделями разработки иных, не программных систем.

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

Каскадная модель (водопад)
Преимущества:
проста и понятна заказчикам, так как часто используется другими организациями для отслеживания проектов, не связанных с разработкой ПО;
проста и удобна в применении;
процесс разработки выполняется поэтапно;
ее структурой может руководствоваться даже слабо подготовленный в техническом плане или неопытный персонал;
способствует осуществлению строгого контроля менеджмента проекта;
каждую стадию могут выполнять независимые команды (все документировано);
позволяет достаточно точно планировать сроки и затраты.

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

Каскадная модель (водопад)
Применимость.
В семидесятых-восьмидесятых годах XX века модель была принята как стандарт министерства обороны США. Со временем недостатки каскадной модели стали проявляться все чаще.
Каскадная модель не утратила своей актуальности при решении следующих типов задач:
требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики;
повторная разработка типового продукта;
выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы.