Макропроцесс разработки ПО. Назначение и характеристика основных этапов разработки ПО.
Традиционно, во всех стандартных моделях, выделяют следующие основные этапы ЖЦ: стратегическое планирование; анализ требований; проектирование (предварительное и детальное); кодирование (программирование); тестирование и отладка; эксплуатация и сопровождение. Каждому этапу соответствуют определенный результат и набор документации, которые в свою очередь являются исходными данными для последующих этапов. В заключение каждого этапа производится верификация документов и решений с целью проверки их соответствия первоначальным требованиям заказчика. Рассмотрим подробнее этапы ЖЦ ПО:
Этапы стратегического планирования и анализа используются для определения самых общих требований к программной системе.
На этапе проектирования создается структура будущей программой системы.
На этапе реализации выбирается язык программирования и составляется текст программы (кодирование).
Этап тестирования и отладки включает выполнение тестирования всей программной системы и исправление ошибок
На этапе сопровождения и эксплуатации программная система сдается в эксплуатацию, происходит обслуживание пользователей, возможно устранение незначительных ошибок.
Язык UML. История создания. Назначение. Место в процессе разработки ПО. CASE-средства c поддержкой UML.
Унифицированный язык моделирования UML (Unified Modeling Language)— это язык для определения, визуализации, конструирования и документирования артефактов программных систем, а также для моделирования экономических процессов и других не программных систем".
|
|
|
UML появился в 1994 году в результате совместных усилий Гради Буча и Румбаха по объединению их методов. Затем эти две методологии были объединены Якобсоном ("три товарища"). В разработку UML внесли свой вклад и другие специалисты. В 1997 году язык UML был принят в качестве стандартного языка моделирования.
UML поддерживает все стадии ЖЦ проекта, его применения достаточно для полной поддержки разработки приложения. Он оптимизирован для применения при разработке программных систем, что позволяет максимально ускорить разработку программных продуктов и заметно улучшить их качество. Описание предметной области с использованием UML хорошо воспринимается экспертам предметной области.
CASE-средства, поддерживающие UML (а именно, Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic и др.), дают возможность работать со множеством языков программирования, таких как C++, Java, Delphi, Power Builder, Visual Basic, Smalltalk и других, а также осуществлять генерацию БД. Разработчик Rational Rose - фирма Rational Software Corp., известная своими наработками в области о-о технологий, главной из которых является язык UML. Именно на поддержку UML, как основного языка проектирования ПО, и ориентированна данная CASE система. Данная система поддерживает все стадии ЖЦПО и предоставляет пользователю множество функций для анализа, проектирования, построения и сопровождения ПО. При этом используются о-о технологии и широко применяются графические модели. Имеется настройка на различные языки программирования и архитектуры программных систем, а также возможность "обратного проектирования" на основе исходных текстов, на различных языках программирования.
|
|
|
Опишите стадию планирования в разработке ПО.
На этапе планирования предусматривается выделение основных понятий, исследование альтернативных возможностей, спецификация требований и т.д.
В качестве современного метода принят итерационный процесс разработки, который основывается на успешной доработке и усложнении системы в процессе нескольких шагов анализа, проектирования, реализации, тестирования. Развитие системы обуславливается добавлением в каждом цикле новых функций. Т. е. решаются задачи удовлетворения небольшого количества требований системы.
Преимущества итерационного процесса: эффективность преодоления сложности поставленной задачи; быстрая обратная связь за счет коротких временных циклов разработки (2 нед. – 2 мес.)
|
|
|
Задачей на этапе планирования встает идентификация основных свойств системы в форме, удобной для заказчика и разработчика. Определение требований важно для выявления (идентификации) рисков.
Риск (risk) — это техническая сложность или другой фактор, например, отсутствие информации о необходимых затратах или ресурсах. Т. е. это своего рода текущая или предварительно выявленная проблема, которая может оказать неблагоприятное влияние на достижение основных контрольных точек.
Стадии определения требований: 1. общая формулировка заданий; 2. потребители системы; 3. основная цель; 4. функции системы (назначение). Функции системы разбиты на логические группы и ранжированы на категории: - очевидная функция (видима пользователю) – скрытая функция (базовые технические функции) – дополнительные функции (необязательные). 5. атрибуты системы (нефункциональная характеристика системы, относящаяся к определенным группам функций, либо к системе в целом; характеризуются набором допустимых значений)
На данном этапе определяются основные прецеденты и связи м/у ними, а также исполнители.
|
|
|
Требования (requirements) на стадии планирования. Понятие рисков, артефактов.
Требования (requirements) — это возможности или условия, которым должнасоответствовать система или проект. Основная задача этапа определения требований — найти, обсудить и отметить, что действительно требуется от системы. Требования должны постоянно корректироваться.
Требования делятся на следующие категории: функциональные требования; удобство; надежность; производительность; возможность поддержки; реализация; операции; пакетирование; юридические вопросы.
Обычно требования делят на две большие категории: функциональные (относящиеся к поведению) и нефункциональные (все остальные). Функциональные требования исследуются и формулируются в процессе разработки модели прецедентов. Остальные требования формулируются при более детальном описании прецедентов. Определение требований важно для выявления (идентификации) рисков. Риск (risk) — это техническая сложность или другой фактор, например, отсутствие информации о необходимых затратах или ресурсах. Т.е. это своего рода текущая или предварительно выявленная проблема, которая может оказать неблагоприятное влияние на достижение основных контрольных точек.
В контексте унифицированного процесса артефактом (artifact) называется любой результат работы: код, схема БД, текстовые документы, диаграммы, модели и т.д. Артефакт — это не документ или диаграмма, а процесс осмысления, анализа и разработки (с последующей записью результатов во избежание повторения или забывания). Артефакты лучше зафиксировать с помощью цифровой техники и в интерактивных документах.
Артефакты предыдущих проектов можно повторно использовать в последующих. Возможно, что м/у проектами будет много общего, в частности риски, методы управления проектом, тестирование. Во всех проектах артефакты должны иметь одинаковые имена (например, "Перечень документов" и т.д.). Это упрощает процесс поиска схожих артефактов и возможность их повторного использования в новых проектах.
Дата добавления: 2018-04-15; просмотров: 441; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!