Проблемы, которые часто приходится решать программистам, чрезвычайно сложны. Понимание природы проблем может быть очень трудным, особенно если система новая.
Следовательно, трудно точно определить, что должна делать система. Описания услуг и ограничений - это требования к системе, а процесс обнаружения, анализа, документирования и проверки этих услуг и ограничений называется разработкой требований. Многие проблемы разработки программного обеспечения проистекают из неточности в спецификации требований. Для системного разработчика естественно дать интерпретации неоднозначного требования, чтобы упростить его реализацию. Однако зачастую это не то, что хочет клиент. Необходимо установить новые требования и внести изменения в систему. Конечно, это задерживает доставку и увеличивает расходы.
Пользовательские требования к системе описывают функциональные и нефункциональные требования таким образом, что они понятны пользователям системы, которые не обладают подробными техническими знаниями. Они только определяют внешнее поведение системы и максимально избегают конструктивных особенностей системы. Поэтому пользовательские требования не должны определяться с использованием модели реализации. Они должны быть написаны с использованием естественного языка, простых диаграмм и представлений.
Когда пользовательские требования включают в себя слишком много информации, они ограничивают свободу разработчика системы предоставлять инновационные решения пользовательских проблем и затрудняют понимание требований. Пользовательские требования должны просто сосредоточиться на основных ресурсах, которые будут предоставлены.
Программный процесс представляет собой набор действий и связанных с ними результатов, которые приводят к созданию программного продукта. Это может состоять из разработки программного обеспечения с нуля, хотя новое программное обеспечение все чаще разрабатывается путем расширения и модификации существующих систем. Одной из причин, по которой ограниченное внимание уделяется процессу автоматизации, является огромное разнообразие программных процессов. Идеального процесса не существует, и разные организации разработали совершенно разные подходы к разработке программного обеспечения. Процессы развивались, чтобы использовать возможности людей в организации, а также конкретные характеристики систем, которые разрабатываются. Поэтому даже в рамках одной организации может быть много разных процессов для разработки программного обеспечения.
Унифицированный процесс разработки (RUP) методология Контуры очень конкретные рекомендации по разработке программных проектов, определенных в очень совместном, эволюционном и гибком подходе к изменениям ассимилировать в требованиях к программному обеспечению в динамичной бизнес - среде. Точно так же в нем четко определены этапы, когда необходимы официальные проверки проекта, включая одобрение клиента. На диаграмме ниже показан жизненный цикл программного проекта на основе RUP:
Его эволюционный подход включает в себя итеративное и поэтапное развитие. Итеративный характер присутствует в действиях, расположенных в левой части диаграммы (требования, анализ, дизайн и т. Д.); в то время как поэтапное развитие осуществляется путем прототипирования с течением времени, разработанного на протяжении жизненного цикла, один раз для каждого прототипа. На этапе разработки разрабатывается прототип с архитектурой, которая включает варианты использования с большим техническим риском. В свою очередь, программное обеспечение также создается в конце каждой итерации на этапе строительства, так же, как на этапе разработки, оно может использоваться для целей тестирования или демонстрационного программного обеспечения для клиента. Каждый раз, когда итерация заканчивается, она знаменует собой веху, когда требуется проверка клиента,где анализируется выполнение требований, ход выполнения проекта, анализ реальных и плановых затрат. В случае последней итерации, соответствующей каждой фазе проекта, клиент должен создать подтверждающий документ, в котором клиент предлагает свое согласие с разработками, достигнутыми проектом, принимая, таким образом, финансовый и технический смысл программного обеспечения. что развивается.
На начальном этапе разработки (Concepción) создаются основы проекта. Объем, первоначальный план, видение бизнеса с целями и обоснование проекта определены, эти артефакты уточняются на протяжении всего развития проекта. Первоначальные требования отражаются в сценариях использования.
На этом этапе вы начинаете задумываться о первоначальной архитектуре системы с точки зрения бизнеса и с технической точки зрения. Этот процесс включает в себя создание концептуальной модели и модели развертывания, как на высоком уровне на этом этапе.
План проекта высокого уровня определяется и затем уточняется в более подробный план на последующих итерациях. План высокого уровня обрабатывает основные зависимости и общую стратегию, в то время как более тонкие планы (соответствующие более подробным итерациям) обрабатывают тактику, соответствующую ситуациям, имеющимся в каждой итерации. Долгосрочные действия, такие как операции, поддержка и постоянное улучшение, должны быть приняты во внимание при планировании проекта.
Эта фаза проектирования заканчивается обеспечением наличия определенной области, плана развития, анализа рисков, когда клиенты соглашаются с вышеизложенным и имеют жизнеспособную стратегию для построения хранилища данных.
На этом этапе допускаются некоторые распространенные ошибки, которых следует избегать:
- Подумайте, что это этап определения требований традиционным способом. Подумайте, что вам нужно иметь идеальные модели и планы. Постарайтесь создать полную модель данных в начале проекта.
Сгенерированные артефакты:
- Концепция проекта Схема вариантов использования Схема развертывания Схема утверждения клиента
Причины, по которым организации используют RUP для разработки программных проектов:
- RUP контролирует масштабный риск: RUP признает факт изменения требований при разработке проекта и определяет гибкий подход к управлению этими требованиями. Попытка полностью определить требования в начале проекта - очень рискованное решение: RUP смотрит за пределы данных: одна из причин, по которой программные проекты терпят неудачу, не обеспечивает достаточную ценность для бизнеса. Выявив и сфокусировавшись на ценности для бизнеса через варианты использования, RUP получает представление о требованиях, предпочтительном подходе к подходу, ориентированному на данные. RUP контролирует технические риски на раннем этапе: многие программные проекты терпят неудачу из-за уверенности в том, что Они предоставляют подробные модели, созданные ранее. Если модель данных очень подробная,Он отражает «единственную правду», и они потратили месяцы, работая над этим, проблема в том, что любая архитектура хорошо работает на бумаге, пока архитектура не протестирована с кодом, вы не можете быть уверены в ее правильной работе. RUP контролирует риск Финансовый: итеративное и поэтапное развитие, которое вначале управляет критическими компонентами проекта, гарантирует, что сначала гарантируется высочайшая функциональность, максимизируя окупаемость инвестиций. RUP обеспечивает гибкость дисциплинированным образом: Программное обеспечение сложное, необходима гибкость, но в то же время необходимо поддерживать уровень контроля, чтобы сделать разработку эффективной.Пока архитектура не протестирована с кодом, вы не можете быть уверены, что она работает правильно. RUP контролирует финансовый риск: итеративная и поэтапная разработка, которая ранним образом управляет критическими компонентами проекта, гарантирует, что сначала гарантируется самое высокое значение функциональности Максимальная окупаемость инвестиций. RUP обеспечивает гибкость дисциплинированным образом: программные проекты сложны, необходима гибкость, но в то же время поддерживается уровень контроля для повышения эффективности разработки.Пока архитектура не протестирована с кодом, вы не можете быть уверены, что она работает правильно. RUP контролирует финансовый риск: итеративная и поэтапная разработка, которая ранним образом управляет критическими компонентами проекта, гарантирует, что сначала гарантируется самое высокое значение функциональности Максимальная окупаемость инвестиций. RUP обеспечивает гибкость дисциплинированным образом: программные проекты сложны, необходима гибкость, но в то же время поддерживается уровень контроля для повышения эффективности разработки.Постоянная максимальная окупаемость инвестиций. RUP обеспечивает гибкость дисциплинированным образом: программные проекты сложны, необходима гибкость, но в то же время поддерживается уровень контроля для повышения эффективности разработки.Постоянная максимальная окупаемость инвестиций. RUP обеспечивает гибкость дисциплинированным образом: программные проекты сложны, необходима гибкость, но в то же время поддерживается уровень контроля для повышения эффективности разработки.
Изменения в требованиях требуют эволюционного и гибкого подхода к высокому уровню сотрудничества, который определяет единый процесс разработки (RUP).
Библиография
Ян Соммервиль, « Разработка программного обеспечения », 6-е издание. Образование Пирсона, 2002.
И. Арчер Пупо, «Фазы единого процесса развития».
