Методология организации проектирования и разработки программного обеспечения Часть

Методология организации проектирования и разработки программного обеспечения Часть 2 LOGO

Стандарты в описании процессов жизненного цикла

Стандарты в описании процессов ЖЦ Единая система программной документации (ЕСПД, ГОСТ 19. *) Комплекс стандартов на автоматизированные системы (КСАС, ГОСТ 34. *) Стандарты ИСО/МЭК (ГОСТ Р ИСО/МЭК 12207) – действующая система Стандарты серии «Системная инженерия» (ISO/IEC 42010– 2007, IEEE 1471) основаны на ISO 12207 Корпоративные стандарты Пример – описание ЖЦ по стандарту Oracle Corporation: RD. 020 – RD. 030 – RD. 070 – BR. 020 – BR. 080 – – MD. 020 – MD. 060 – DO. 070 – TE. 110 – PM. 050 – – CV. 140 – PM. 080

Стандарт Cobi. T (1) Состав книг Cobi. T

Стандарт Cobi. T (2) Cobi. T в жизненном цикле ИТ

Стандарт Cobi. T (3) Процессы управления и аудита в Cobi. T

Стандарт Cobi. T (4) Разделение объектов управления и аудита

Управление требованиями

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

Классификация требований (2) ГОСТ Р 51904 -2002 : требование – характеристика того, чем система или ПО должны обладать, чтобы быть приемлемыми для заказчика; требования к ПО – описание того, что должно производить ПО, с заданием входных условий и ограничений; Требования к ПО включают в себя требования верхнего и нижнего уровня; требования верхнего уровня – требования к ПО, разработанные на основании анализа системных требований и требований, связанных с безопасностью системы; требования нижнего уровня – требования к ПО, разработанные на основании требований верхнего уровня, производных требований и ограничений проекта, по которым исходный код может быть реализован непосредственно, без какой-либо дополнительной информации.

Классификация требований (3) [Вигерс]

Классификация требований (4) FURPS+

Классификация требований (5) FURPS+ : функциональные требования (Functionality) требования удобства использования (Usability) требования надежности (Reliability) требования производительности (Performance) требования возможности сопровождения (Supportability) дополнительные условия: проектные ограничения требования управления системой требования к графическому интерфейсу пользователя физические требования юридические требования

Работа с требованиями (1) извлечение требваний интервьюрирование сценарии прототипы наблюдение разъясняющие встречи (facilitated meetings) раскадровка (storyboard) другие практики анализ требований классификация требований; концептуальное моделирование; архитектурное проектирование и распределение требований спецификация требований определение системы системные требования программные требования проверка (валидация) требований

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

Корпоративные решения для поддержки требований (1) Microsoft - "Введение в Управление требованиями с использованием Team Foundation Server"

Корпоративные решения для поддержки требований (2) LUXOFT - LUXproject

Корпоративные решения для поддержки требований (3) Confluence + Jira + SVN: • Confluence – простая, но мощная wiki-система которая позволяет создавать страницы и документы, обмениваться контентом между участниками команды и тем самым поддерживать совместную работу. • Atlassian JIRA – коммерческая система отслеживания ошибо предназначена для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. • Subversion, также известная как «SVN» – свободная распространяемая централизованная система управления версиями.

Корпоративные решения для поддержки требований (4) Confluence + Jira + SVN: Формирование структуры требований с произвольным уровнем

Корпоративные решения для поддержки требований (5) Confluence + Jira + SVN: Фиксирование исходных и возникающих требований

Корпоративные решения для поддержки требований (6) Confluence + Jira + SVN: Автоматическое связывание требований (трассировка), в том числе межпроектных

Корпоративные решения для поддержки требований (7) Confluence + Jira + SVN: Автоматическое связывание требований с заданиями на работы; контроль выполнения задач; отображение реализованных требований

Корпоративные решения для поддержки требований (8) Confluence + Jira + SVN: . Определение необходимых типов требований и атрибутов для них (приоритет, сложность, состояние, ответственный за реализацию и др. )

Корпоративные решения для поддержки требований (9) Confluence + Jira + SVN: Генерация актуального технического задания по текущей структуре требований

Корпоративные решения для поддержки требований (10) Confluence + Jira + SVN: Учет истории и авторства изменений требований

Теъническое задание Техническое задание (ТЗ) – документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. Регулируется требованиями стандартов (ГОСТ 34. 602 -89, ISO 9001: 2000 и др. ), а также отраслевыми стандартами Бриф – краткая письменная форма согласительного порядка между заказчиком и исполнителем, в которой прописываются основные параметры будущего проекта

Планирование в проекте

Планирование в проекте ГОСТ Р 51904– 2002: • • План сертификации в части ПО План разработки ПО План верификации ПО План квалификационного тестирования ПО План управления конфигурацией ПО План обеспечения качества ПО План установки ПО План передачи ПО

Календарное планирование (1)

Календарное планирование (2) Диаграмма Ганта График загруженности ресурсов

Инструментальная поддержка планирования Microsoft Office Project 2007

Управление информационными потоками в проекте

Управление информационными потоками (1) Датацентрическая парадигма (ISO 15926): • входные документы: парсируются до уровня «полей» , которые рассматриваются как «данные» ; • учетная система ориентирована на эти «данные» ; • выходные документы: генерируются из «данных» на момент их формирования; • стандарт полностью поддерживает предметную область документооборота – документы, шаблоны, процедуры, «передача с учета на учет» и т. д. Технологии - Semantic Web, XML, Excel Онтологии - OWL Язык запросов - SPARQL

Управление информационными потоками (2) Workflow-ориентированная парадигма

Управление информационными потоками (3) БП голосования по электронной почте в нотации BPMN

Управление конфигурацией

Управление конфигурацией ГОСТ Р 51904 -2002: • идентификация конфигурации • контроль изменений • определение базовой линии разработки • архивирование и получение документов, выпуск версии • аудит конфигурации • компоновка и поставка ПО Базовая линия (baseline) – официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени ЖЦ элемента конфигурации

Организация управления конфигурацией Пример - All. Fusion Harvest Change Manager Структура и иерархия объектов Одновременная разработка

Информационная поддержка управления конфигурацией • Visual Studio Team System • IBM Rational Clear. Case • другие решения

Управление качеством

Управление качеством ПО (1) Процессы управления качеством ПО ГОСТ 12207: обеспечение качества верификация аттестация совместный анализ аудит SWEBOK: верификация и валидация обзор и аудит управленческие оценки технические оценки инспекции прогонки аудиты

Управление качеством ПО (2) Типы дефектов: • ошибка • недостаток • сбой • человеческая (пользовательская) ошибка Техники управления качеством ПО: • Статические техники • Техники коллективной оценки • Аналитические техники • Динамические техники • Тестирование

Методология организации проектирования и разработки программного обеспечения Часть 2 LOGO