Transcript 146200_lecture3

Методология
организации
проектирования
и разработки
программного
обеспечения
Часть 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
Стандарт CobiT (1)
РЕЗЮМЕ для РУКОВОДИТЕЛЯ
СТРУКТУРА Cobit
Включая Высокоуровневые Цели Контроля
ПРИНЦИПЫ
УПРАВЛЕНИЯ
ОБЪЕКТЫ
КОНТРОЛЯ
Модели Зрелости
ПРИНЦИПЫ
АУДИТА
Набор инструментов
для внедрения Cobit
Критические
Факторы Успеха
(КФУ)
Ключевые
Индикаторы Цели
(КИЦ)
Ключевые
Индикаторы
Результата (КИР)
Состав книг CobiT
Обзор
Практический опыт
FAQ’s
Презентации Power Point
Руководство по внедрению
Контроль понимания руководства
Диагностика ИТ Контроля
Стандарт CobiT (2)
Цели и задачи бизнеса
Управление информационными технологиями
Cobit
Мониторинг
Эффективность
Продуктивность
Безопасность
Целостность
Пригодность
Согласованность
Надежность
Определить стратегический план ИТ
Определить информационную архитектуру
Определить технологическое направление
Определить организацию и взаимоотношения ИТ
Управлять инвестициями в ИТ
Согласованно управлять целями и задачами
Управлять персоналом
Обеспечить согласование с внешними требованиями
Оценивать риски
Управлять проектами
Управлять качеством
Информация
Проводить мониторинг процессов
Оценивать адекватность
внутреннего контроля
Получать независимые гарантии
Обеспечивать независимый аудит
Люди
Приложения
Технологии
Оборудования
Данные
Определять уровни обслуживания и управлять ими
Управлять услугами сторонних организаций
Управлять производительностью и наращиваемостью
Обеспечивать непрерывность услуг
Обеспечивать безопасность системы
Определить и распределить затраты
Обучать пользователей
Эксплуатация и
Помогать пользователям консультировать их
сопровождение
Управлять конфигурацией
Управлять данными
Управлять оборудованием
Управлять операциями
Планирование и
организация
Ресурсы ИС
Проектирование и
внедрение
Определить решения по автоматизации
Приобрести и поддерживать
технологическую инфраструктуру
Разработать и поддерживать процедуры
Установить и аккредитовать системы
Управлять изменениями
CobiT в жизненном цикле ИТ
Стандарт CobiT (3)
«Лучшая практика» индустрии
Стратегия организации
Управление
2
Оптимизация
0
5
Описание
Повторение
Начало
1
Не существует
Требования международных
стандартов
4
Текущий статус организации
3
Легенда используемых символов
Домены Cobit
Планирование
и организация
Обеспечение
продаж
Высокоуровневые
объекты
контроля Cobit
ы
ект
Объ оля
р
т
н
ко
Оказание услуг
Производство
Планирование
Высокоуровневые и организация
цели управления
Cobit
Цели ия
влен
упра
Обеспечение
продаж
Менеджеры
среднего
звена
Оказание услуг
Производство
Процессы управления и аудита в CobiT
Стандарт CobiT (4)
Cobit
Топ менеджеры
Разделение
объектов
управления
и аудита
Аудиторы ИТ
Руководители ИТ служб
ITIL
Руководители ИТ подразделений
Администраторы ИС
я
ы
сс н и
це вле г
о
Пр оста слу
ед ИТ у
пр
Операторы
Диспетчеры
Программисты
сы ИТ
ес
оц ржки
р
П д е л уг
д ус
по
зн
Би
е
ро
сп
с
це
сы
Пользователи ИС
Легенда:
Управление Cobit
Аудит Cobit
Управление и
контроль ITIL
Стандарты бизнес
процессов
Управление требованиями
Классификация требований (1)
[SWEBOK]:
задача
управления
требованиями
–
обеспечить
корректное моделирование той области реального мира,
которую поддерживает проектируемое ПО, на уровне
заданных
практических
потребностей,
а
также
сформулировать соответствующие приемочные тесты.
Результатом
анализа
требований
должны
быть
однозначно интерпретируемые требования, реализация
которых проверяема, а стоимость и ресурсы –
предсказуемы.
Классификация требований (2)
ГОСТ Р 51904-2002 :
требование – характеристика того, чем система или ПО
должны обладать, чтобы быть приемлемыми для заказчика;
требования к ПО – описание того, что должно производить
ПО, с заданием входных условий и ограничений;
Требования к ПО включают в себя требования верхнего и
нижнего уровня;
требования верхнего уровня – требования к ПО,
разработанные на основании анализа системных
требований и требований, связанных с безопасностью
системы;
требования нижнего уровня – требования к ПО,
разработанные на основании требований верхнего уровня,
производных требований и ограничений проекта, по
которым исходный код может быть реализован
непосредственно, без какой-либо дополнительной
информации.
Классификация требований (3)
[Вигерс]
Классификация требований (4)
Производительность
20%
Форматы
20%
ввода/вывода
Требования
20%
GUI
Варианты
использования
20%
Бизнес правила
20%
Форматы
данных
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)
24+5=29
Max(10+5,10+6)=16
0+10=10
3
1
2
0
8
4
Max(16+7,16+8)=24
Max(29+10,29+5)=39
7
10
0+0=0
0+10=10
5
6
9
10+6=16
17-5=12
24+5=29
39-10=29
24-7=17
3
8
4
Min(12-10,10-10)=0
1
Min(29-5,34-5)=24
2
7
10
0-0=0
Min(17-6,16-6)=10
5
39-5=34
24-8=16
3
1
39-0=39
9
6
8
4
2
7
5
6
10
9
Календарное планирование (2)
Работы
1
Постановщик
2
Программист 1
3
Программист 1
4
Программист 2
Диаграмма Ганта
5
Программист 2
6
Программист 1
Программист 2
7
8
Программист 1
Программист 2
Постановщик
Постановщик
9
10
7.09.09
21.09.09
29.09.09
9.10.09
16.10.09
23.10.09
30.10.09
Программист 1
Загрузка %
200
100
Программист 2
График загруженности
ресурсов
200
100
Постановщик
200
100
28.09.09
7.09.09
21.09.09
29.09.09
8.10.09
9.10.09
16.10.09
23.10.09
30.10.09
Инструментальная поддержка
планирования
Microsoft Office Project 2007
Управление информационными
потоками в проекте
Управление информационными
потоками (1)
Датацентрическая парадигма (ISO 15926):
• входные документы: парсируются до уровня «полей»,
которые рассматриваются как «данные»;
• учетная система ориентирована на эти «данные»;
• выходные документы: генерируются из «данных»
на момент их формирования;
• стандарт полностью поддерживает
предметную область документооборота –
документы, шаблоны, процедуры,
«передача с учета на учет» и т.д.
Технологии - Semantic Web,XML, Excel
Онтологии - OWL
Язык запросов - SPARQL
Управление информационными
потоками (2)
Workflow-ориентированная парадигма
Управление информационными
потоками (3)
БП голосования по электронной почте в нотации BPMN
Управление конфигурацией
Управление конфигурацией
ГОСТ Р 51904-2002:
• идентификация конфигурации
• контроль изменений
• определение базовой линии разработки
• архивирование и получение документов, выпуск версии
• аудит конфигурации
• компоновка и поставка ПО
Базовая линия (baseline) – официально принятая версия
элемента конфигурации, независимая от среды,
формально обозначенная и зафиксированная
в конкретный момент времени ЖЦ элемента конфигурации
Организация управления
конфигурацией
Пример - AllFusion Harvest Change Manager
Структура и иерархия объектов
Одновременная разработка
Информационная поддержка
управления конфигурацией
• Visual Studio Team System
• IBM Rational ClearCase
• другие решения
Управление качеством
Управление качеством ПО (1)
Процессы управления качеством ПО
ГОСТ 12207:
обеспечение качества
верификация
аттестация
совместный анализ
аудит
SWEBOK:
верификация и валидация
обзор и аудит
управленческие оценки
технические оценки
инспекции
прогонки
аудиты
Управление качеством ПО (2)
•
•
•
•
Типы дефектов:
ошибка
недостаток
сбой
человеческая (пользовательская) ошибка
Техники управления качеством ПО:
• Статические техники
• Техники коллективной оценки
• Аналитические техники
• Динамические техники
• Тестирование
Методология
организации
проектирования
и разработки
программного
обеспечения
Часть 2
LOGO