SEP - Software Engineering Process
SDP - Software Development Process
UP базируется на трех аксиомах. Он является:
• управляемым требованиями и риском;
• архитектуро-центричным;
• итеративным и инкрементным.
Прецеденты – это способ записи требований. Таким образом, можно с уверенностью утверждать, что UP является управляемым требованиями.
Риск – это еще один управляющий механизм UP, поскольку если не атаковать риски, они будут атаковать вас! Все, кто участвовал в проектах по разработке ПО, без сомнения, согласятся с этим утверждением. UP решает эту проблему, заложив анализ рисков в основу создания ПО.
Подход UP к разработке программных систем заключается в создании и развитии надежной архитектуры системы. Архитектура описывает стратегические аспекты разбиения системы на компоненты, а также взаимодействия и развертывания этих компонентов на аппаратных средствах. Очевидно, что качественно разработанная архитектура обеспечит создание работоспособной системы, а не просто наспех скомпонованного набора кустарного исходного кода.
Итеративный аспект UP означает, что проект разбивается на небольшие подпроекты (итерации), которые обеспечивают функциональность системы по час тям, или инкрементам, приводя к созданию полнофункциональной системы. Другими словами, ПО создается путем пошаговой детализации. Фактически к ключевым рабочим потокам UP, таким как анализ, мы возвращаемся по нескольку раз в течение проекта. этих «мини проектов» и есть итерация.
• Анализ и проектирование
• Построение
• Интеграция и тестирование
• Версия для внутреннего или внешнего использования
• анализ – уточнение и структурирование требований;
• проектирование – реализация требований в архитектуре системы;
• реализация – построение программного обеспечения;
• тестирование – проверяется, отвечает ли реализация предъявляемым требованиям.
• Разработка экономического обоснования для демонстрации того, что проект обеспечит выраженную в количественном отношении коммерческую выгоду.
• Определение основных требований для создания предметной области системы.
• Выявление наиболее опасных рисков.
• детализация оценки рисков;
• определение атрибутов качества (скорости выявления дефектов, приемлемые плотности дефектов и т. д.);
• выявление прецедентов, составляющих до 80% от функциональных требований;
• создание подробного плана фазы Построение;
• формулировка предложения, включающего ресурсы, время, оборудование, штат и стоимость.
• анализ – выяснение, что необходимо построить;
• проектирование – создание стабильной архитектуры;
• реализация – построение базовой версии архитектуры;
• тестирование – тестирование базовой версии архитектуры.
• анализ – завершение аналитической модели;
• проектирование – завершение модели проектируемой системы;
• реализация – создание базовой функциональности;
• тестирование – тестирование базовой функциональности.
• подготовка пользовательских мест под новое программное обеспечение;
• настройка работоспособности программного обеспечения на пользовательских местах;
• изменение программного обеспечения в случае возникновения непредвиденных проблем;
• создание руководств для пользователей и другой документации;
• предоставление пользователям консультаций;
• проведение послепроектного анализа.
• Анализ – не проводится.
• Проектирование – изменение конструкции в случае выявления проблем при бета тестировании.
• Реализация – настройка ПО под пользовательские места и исправление проблем, не выявленных при бета тестировании.
• Тестирование – бета тестирование и приёмочные испытания на пользовательских местах.
SDP - Software Development Process
UP базируется на трех аксиомах. Он является:
• управляемым требованиями и риском;
• архитектуро-центричным;
• итеративным и инкрементным.
Прецеденты – это способ записи требований. Таким образом, можно с уверенностью утверждать, что UP является управляемым требованиями.
Риск – это еще один управляющий механизм UP, поскольку если не атаковать риски, они будут атаковать вас! Все, кто участвовал в проектах по разработке ПО, без сомнения, согласятся с этим утверждением. UP решает эту проблему, заложив анализ рисков в основу создания ПО.
Подход UP к разработке программных систем заключается в создании и развитии надежной архитектуры системы. Архитектура описывает стратегические аспекты разбиения системы на компоненты, а также взаимодействия и развертывания этих компонентов на аппаратных средствах. Очевидно, что качественно разработанная архитектура обеспечит создание работоспособной системы, а не просто наспех скомпонованного набора кустарного исходного кода.
Итеративный аспект UP означает, что проект разбивается на небольшие подпроекты (итерации), которые обеспечивают функциональность системы по час тям, или инкрементам, приводя к созданию полнофункциональной системы. Другими словами, ПО создается путем пошаговой детализации. Фактически к ключевым рабочим потокам UP, таким как анализ, мы возвращаемся по нескольку раз в течение проекта. этих «мини проектов» и есть итерация.
Каждая итерация включает все элементы обычного проекта по разработке ПО
• Планирование• Анализ и проектирование
• Построение
• Интеграция и тестирование
• Версия для внутреннего или внешнего использования
Основные рабочие потоки
• определение требований – сбор данных о том, что должна делать система;• анализ – уточнение и структурирование требований;
• проектирование – реализация требований в архитектуре системы;
• реализация – построение программного обеспечения;
• тестирование – проверяется, отвечает ли реализация предъявляемым требованиям.
Структура UP
Начало
Цели
• Обоснование выполнимости – может включать разработку технического прототипа с целью проверки правильности технологических решений или концептуального прототипа для проверки бизнес требований.• Разработка экономического обоснования для демонстрации того, что проект обеспечит выраженную в количественном отношении коммерческую выгоду.
• Определение основных требований для создания предметной области системы.
• Выявление наиболее опасных рисков.
На что обращено внимание
В фазе Начало основное внимание обращено на определение требований и анализ. Однако если принято решение о создании технического или подтверждающего концепцию прототипа, может быть проведено некоторое проектирование и реализация. Тестирование обычно не применяется в данной фазе, поскольку единственными программными артефактами здесь являются прототипы, которые не будут больше нигде использоваться.Контрольная точка
Уточнение
Цели
• создание исполняемой базовой версии архитектуры;• детализация оценки рисков;
• определение атрибутов качества (скорости выявления дефектов, приемлемые плотности дефектов и т. д.);
• выявление прецедентов, составляющих до 80% от функциональных требований;
• создание подробного плана фазы Построение;
• формулировка предложения, включающего ресурсы, время, оборудование, штат и стоимость.
На что обращено внимание
• определение требований – детализация предметной области системы и требований;• анализ – выяснение, что необходимо построить;
• проектирование – создание стабильной архитектуры;
• реализация – построение базовой версии архитектуры;
• тестирование – тестирование базовой версии архитектуры.
Контрольная точка
Построение
Цели
Цель фазы Построение – завершить определение требований, анализ и проектирование и развить исполняемую базовую версию архитектуры, созданную в фазе Уточнение, в завершенную систему. Главная проблема Уточнения – поддержание целостности архитектуры системы.На что обращено внимание
• определение требований – выявление всех неучтенных требований;• анализ – завершение аналитической модели;
• проектирование – завершение модели проектируемой системы;
• реализация – создание базовой функциональности;
• тестирование – тестирование базовой функциональности.
Контрольная точка
Внедрение
Цели
• исправление дефектов;• подготовка пользовательских мест под новое программное обеспечение;
• настройка работоспособности программного обеспечения на пользовательских местах;
• изменение программного обеспечения в случае возникновения непредвиденных проблем;
• создание руководств для пользователей и другой документации;
• предоставление пользователям консультаций;
• проведение послепроектного анализа.
На что обращено внимание
• Определение требований – не проводится.• Анализ – не проводится.
• Проектирование – изменение конструкции в случае выявления проблем при бета тестировании.
• Реализация – настройка ПО под пользовательские места и исправление проблем, не выявленных при бета тестировании.
• Тестирование – бета тестирование и приёмочные испытания на пользовательских местах.
Контрольная точка
Комментариев нет:
Отправить комментарий