Шпаргалка по "Технологии программирования и UML"

Боэм формулирует перечень наиболее распространенных (по приоритетам) рисков [SWEBOK]:

• Дефицит специалистов. 
• Нереалистичные сроки и бюджет.
• Реализация несоответствующей функциональности.
• Разработка неправильного пользовательского интерфейса.
• “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
• Непрекращающийся поток изменений.
• Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
• Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
• Недостаточная производительность получаемой системы.
• “Разрыв” в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана  с организационными и процессными  аспектами взаимодействия специалистов в проектной команде.

 

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму 

В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE – Model-Based (System) Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик, обеспечивающих успешное применение спиральной модели:

1. Параллельное, а не последовательное определение артефактов (активов) проекта
2. Согласие в том, что на каждом цикле уделяется внимание:
• целям и ограничениям, важным для заказчика
• альтернативам организации процесса и технологических решений, закладываемых в продукт
• идентификации и разрешению рисков
• оценки со стороны заинтересованных лиц (в первую очередь заказчика)
• достижению согласия в том, что можно и необходимо двигаться дальше
3. Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.
4. Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
5. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:

• Life Cycle Objectives (LCO)

• Life Cycle Architecture (LCA)
• Initial Operational Capability (IOC)

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

Эволюционирование спиральной модели, таким образом, связано с вопросами детализации работ. Особенно стоит выделить акцент на большем внимании вопросам уточнения – требований, дизайна и кода, т.е. придание большей важности вопросам итеративности, в том числе, увеличения их количества при сокращении длительности каждой итерации.

В результате, можно определить общий  набор контрольных точек в  сегодняшней спиральной модели:

• Concept of Operations (COO) – концепция <использования> системы;
• Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
• Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
• Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
• FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Достоинства:

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

Недостатки:

• высокая нагрузка на заказчика, который становится, по сути, участником разработки;
• большая сложность в прогнозировании окончания проектных работ;
• наличие риска снижения качества финальной версии ПС по причине отказа от последних итераций для снижения сроков разработки.

Сфера применения:

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

 

Следует отметить, что с позиций  отечественных стандартов существует только каскадная модель жизненного цикла, регламентированная в ГОСТ 19.102-77.  Однако форма изложения стандарта  позволяет с некоторыми уточнениями  использовать его и для других моделей жизненного цикла.

 

16. Документ "Техническое задание на программное средство". Содержание и сфера.

 

техническое задание –  документ, в котором излагаются назначение и область применения  программы,  требования  к ПС, стадии и сроки разработки, виды испытаний;

Содержание программного документа: Назначение и область применения программы, технические, технико-экономические  и специальные требования, предъявляемые  к программе, необходимые стадии и сроки разработки, виды испытаний

Чтобы требования, выявленные и описанные приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ "Техническое задание", ТЗ, в западной - "Software Requirements Specification", SRS (спецификация программных требований).

Отечественные госты 
ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

ГОСТ 19.201-78. Единая система программной  документации. Техническое задание. Требования к содержанию и оформлению.

 

 

 

 

 

 
17. Жизненный цикл ПС (общие сведения).

 

Жизненный цикл (ЖЦ) программного средства (ПС) определяется как период времени, который начинается с момента  принятия решения о необходимости  создания ПС и заканчивается в  момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим состав процессов  ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 “Information Technology - Software    Life Cycle Processes” (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПС.

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

Основные процессы:

• приобретение;
• поставка;
• разработка;
• эксплуатация;
• сопровождение.

Вспомогательные процессы:

• документирование;
• управление конфигурацией;
• обеспечение качества;
• верификация;
• аттестация;
• совместная оценка;
• аудит;
• разрешение проблем.

Организационные процессы:

• управление;
• усовершенствование;
• создание инфраструктуры;
• обучение.

 
   18. Приёмка и сопровождение ПС.

 

Приемка ПС предусматривает оценку результатов квалификационного тестирования ПС и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.

Процесс сопровождения  (maintenance process) предусматривает действия и задачи, выполняемые сопровождающей организацией (службой сопровождения). Данный процесс активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации либо адаптации ПС. В соответствии со стандартом IEEE-90 под сопровождением понимается внесение изменений в ПС в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

Изменения, вносимые в существующее ПС, не должны нарушать его целостность. Процесс сопровождения включает перенос ПС в другую среду (миграцию) и заканчивается снятием ПС с эксплуатации (рис. 2.6).

 

 

Подготовительная работа службы сопровождения включает следующие задачи:

• планирование действий и работ, выполняемых в процессе со 
  провождения;
• определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

Анализ проблем и  запросов на модификацию ПС, выполняемый службой сопровождения, включает следующие задачи:

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

 

 
   19. Интеграция и установка ПС.

 

Интеграция ПС предусматривает сборку разработанных компонентов ПС в соответствии с планом интеграции и тестирование агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование — это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий своим спецификациям и готовый к использованию в условиях эксплуатации.

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

Установка ПС осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПС и баз данных. Если устанавливаемое ПС заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором.

 

 
  20. Детальное проектирование, кодирование и тестирование ПС.

Детальное проектирование ПС включает следующие задачи:

• описание компонентов ПС и интерфейсов между ними на более 
  низком уровне, достаточном для их последующего самостоятельного кодирования и тестирования;
• разработку  и  документирование  детального  проекта  базы данных;
• обновление (при необходимости) пользовательской документации;
• разработку и<span class="Normal__Char" style=" font-family: 'Times New Roman', 'Arial'; letter-spacing: 0p