1 / 43

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

Методология организации проектирования и разработки программного обеспечения Часть 2. LOGO. Стандарты в описании процессов жизненного цикла. Стандарты в описании процессов ЖЦ. Единая система программной документации (ЕСПД, ГОСТ 19.*)

carter
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Стандарты в описании процессов ЖЦ Единая система программной документации (ЕСПД, ГОСТ 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related