КОНСПЕКТ ЛЕКЦИЙ ПО ДИСЦИПЛИНЕ “ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ”
КОНСПЕКТ ЛЕКЦИЙ ПО ДИСЦИПЛИНЕ “ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ” Для студентов очной и заочной форм обучения уровня квалификации "Специалист" и "Бакалавр" направления подготовки "Информатика и вычислительная техника" (230100 ГОС2 и ФГОС) специальность (ГОС2) и профиль (ФГОС) "Программное обеспечение вычислительной техники и автоматизированных систем" (ПО, ПОс, ПОзс, БПО) Уфа 2012 Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «УФИМСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЯНОЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» Кафедра вычислительной техники и инженерной кибернетики Разработал доцент кафедры ВТИК К.Э. Писаренко
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ ЛЕКЦИЯ 1 Технология разработки программного обеспечения
Технология разработки программного обеспечения (ТРПО) МЕТОДЫ СРЕДСТВА (утилиты) ПРОЦЕДУРЫ Включает … Обеспечивают решения определенных задач в разработке ПО: анализ требований, кодирование и т.п. Обеспечивают совместное применение методов разработки ПО и CASE-средств CASE – средства и системы автоматизированной поддержки методов разработки ПО
CASE - Computer Aided Software Engineering - программная инженерия с компьютерной поддержкой.
Процессы жизненного цикла ПО, обеспечения ресурсами и организации разработки ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 5.1 Заказ 5.2 Поставка 5.3 Разработка 5.4 Эксплуатация 5.5 Сопровождение 7.1 Управление 7.3 Усовершенствование 6.1 Документирование 6.2 Управление конфигурации 6.3 Обеспечение качества 6.4 Версия 6.5 Аттестация 6.6 Совместный анализ 6.7 Аудит 6.8 Решение проблем 7.2 Создание инфраструктуры 7.4 Обучение 5 Процессы жизненного цикла ПО 7 Процессы организации разработки ПО 6 Процессы обеспечения жизненного цикла ПО ресурсами
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Сайт Межотраслевого Совета Информационных технологий http://www.msovit.ru/
Модели процессов жизненного цикла программного обеспечения Международные стандарты ISO 12207, ISO/IEC 15288 Однократный подход Инкрементный подход (подход запланированных улучшений) Эволюционный подход (подход не запланированных улучшений) Модель классического жизненного цикла Инкрементная модель Модель быстрой разработки (RAD–модель) Спиральная модель Компонентно -ориентированная модель Подходы к организации процессов жизненного цикла ПО (подходы позволяют разными способами выполнить требования стандартов)
Модель классического жизненного цикла программного обеспечения
Модель классического жизненного цикла программного обеспечения 1 Определяет роль каждого элемента ПО и их взаимодействие в системе, в которой планируется применять ПО 2 Определяет технические требования к каждому элементу ПО 3 Определяются: архитектура, модульная структура, алгоритмическая структура, структуры данных, входной и выходной интерфейс 4 Результаты проектирования переводятся в текст языка программирования 6 Устранение ошибок и совершенствование ПО
Инкрементная модель процессов жизненного цикла программного обеспечения
Пример реализации инкрементной модели процессов жизненного цикла для программного обеспечения поддерживающего обработку слов Итерация 1 реализует функции: - базовой обработки файлов, редактирования документирования. Итерация 2 реализует функции: - проверки орфографии и грамматики. Итерация 3 реализует функции: - компоновки страницы .
Модель процессов жизненного цикла ПО - быстрой разработки ПО (RAD – модель)
Спиральная модель процессов жизненного цикла ПО 1 — начальный сбор требований и планирование проекта; 2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета; 8 — сконструированная система; 9 — оценивание заказчиком
Компонентно-ориентированная модель процессов жизненного цикла ПО
Модели процессов жизненного цикла программного обеспечения Международные стандарты ISO 12207, ISO/IEC 15288 Однократный подход Инкрементный подход (подход запланированных улучшений) Эволюционный подход (подход не запланированных улучшений) Модель классического жизненного цикла Инкрементная модель Модель быстрой разработки (RAD–модель) Спиральная модель Компонентно -ориентированная модель Подходы к организации процессов жизненного цикла ПО (подходы позволяют разными способами выполнить требования стандартов)
Жизненный цикл ПО с применением макетирования
Модели процессов жизненного цикла программного обеспечения Практическое задание 1 Выберете модель для разработки Вашего программного средства. 2 Укажите названия этапов его разработки
Подход к управлению качеством программного обеспечения КАЧЕСТВО СИСТЕМ И ПРОЦЕССОВ МЕНЕДЖМЕНТА КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Международные стандарты в области управления качеством КАЧЕСТВО СИСТЕМ И ПРОЦЕССОВ УПРАВЛЕНИЯ: МС “ISO 9001:2008 (2000). Системы менеджмента качества. Требования”; МС "ISO 9004:2009. Менеджмент в целях достижения устойчивого успеха организации; МС “ISO/IEC 90003-2004. Руководство по применению стандарта ISO 9001:2000 для программных средств”; МС “ISO/IEC 90005-2008. Руководство по применению стандарта ISO 9001:2000 к процессам жизненного цикла программных средств”; МС “ISO/IEС 20000-1:2005. ИТ. Сервис менеджмент. Спецификация” (предоставление ИТ услуг)”; стандарт “Корпоративное управление ИТ” (COBIT) международной Ассоциации аудита и контроля информационных систем (ISACA). КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА: МС “ISO 12207:95 (2008). Процессы жизненного цикла ПО”; МС “ISO/IEC 15288:2008 . Процессы жизненного цикла систем”; МС “ISO/IEC 15504:2004. Оценка процессов. КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: МС “ISO/IEC 9126 . Оценка программного продукта. Характеристики качества и руководство по их применению”; -МС “ISO/IEC 25051:2006. Требования для качества готового коммерческого программного продукта и инструкция для испытаний”; - МС “ISO/IEC 14598. Оценка программного продукта”.
Модель системы менеджмента МС ISO 9001:2008
Модель системы управления предоставления ИТ услуг МС ISO/IEC 20000-1:2005
Модель системы управления корпоративными ИТ ресурсами МС COBIT Процессы Процессы
PO1 Разработка стратегического плана развития ИТ PO2 Определение информационной архитектуры PO3 Определение направления технологического развития PO4 Определение организационной структуры и взаимосвязей PO5 Управление ИТ инвестициями PO6 Информирование о целях и направлениях развития ИТ PO7 Управление персоналом PO8 Управление качеством PO9 Оценка и управление ИТ рисками PO10 Управление проектами
Планирование развития ИТ- инфраструктуры осуществляется на основе стратегии развития организации в целом!!! Модель системы управления корпоративными ИТ ресурсами МС COBIT
О – ответственный, У – утверждающий, К – консультирующий, И - информированный
Для каждого процесса МС COBIT применяется 5-ти уровневая шкала зрелости
AI1 Выбор решений по автоматизации AI2 Приобретение и поддержка программных приложений AI3 Приобретение и обслуживание технологической инфраструктуры AI4 Обеспечение выполнения операций AI5 Поставки ИТ ресурсов AI6 Управление внесением изменений AI7 Внедрение и приемка решений и изменений На основании плана развития IT-инфраструктуры приобретается, разрабатывается и внедряется программное обеспечение и аппаратные средства
DS1 Определение и управление уровнем обслуживания DS2 Управление услугами сторонних организаций DS3 Управление производительностью и мощностями DS4 Обеспечение непрерывности ИТ сервисов DS5 Обеспечение безопасности систем DS6 Определение и распределение затрат DS7 Обучение и подготовка пользователей DS8 Управление службой технической поддержки и инцидентами DS9 Управление конфигурацией DS10 Управление проблемами DS11 Управление данными DS12 Управление физической безопасностью и защитой от воздействия окружающей среды DS13 Управление операциями по эксплуатации систем Закупленные и внедренные программное обеспечение и аппаратные средства затем эксплуатируются и сопровождаются
ME1 Мониторинг и оценка эффективности ИТ ME2 Мониторинг и оценка системы внутреннего контроля ME3 Обеспечение соответствия внешним требованиям ME4 Обеспечение корпоративного управления ИТ Информационная инфраструктура: программное обеспечение и аппаратные средства периодические оцениваются на результативность, эффективность и соответствие установленным требованиям
Результаты оценки результативности, эффективности и соответствия установленным требованиям информационной инфраструктуры служат основой для пересмотра планов ее развития
В МС COBIT выделяются следующие ресурсы информационной инфраструктуры: 1 Приложения 2 Информация 3 Инфраструктура 4 Персонал
Куб COBIT
Модель зрелости процесса конструирования ПО Института программной инженерии при американском университете Карнеги-Меллон, предлагаемая МС COBIT
1 ISO 9001:2008. Системы менеджмента качества 2 ISO 9004:2004. Менеджмент в целях достижения устойчивого успеха организации 3 Модель Совершенства Европейского фонда менеджмента качества (EFQM) 4 Прочие стандарты и модели систем менеджмента
09.12.2017 40 Модель системы менеджмента МС ISO 9004:2009. Менеджмент в целях достижения устойчивого успеха организации
Критерии и примитивы качества ПС согласно МС ISO/IEC 9126
Практическое задание Определите уровень развития информационной инфраструктуры в компании для которой Вы разрабатываете программное средства (или любой известной Вам организации).
ВНЕШНЕЕ ОПИСАНИЕ (СПЕЦИФИКАЦИЯ) ПРОГРАММНОГО СРЕДСТВА ЛЕКЦИЯ 2 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС НЕ СЛЕДУЕТ ПУТАТЬ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ С ТРЕБОВАНИЯМИ К ПРОЦЕССАМ ЕГО РАЗРАБОТКИ Внешнее описание ПС – спецификации ПС: играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС; должно содержать всю информацию, которую необходимо знать пользователю для применения ПС.
ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС Внешнее описание ПС – спецификации ПС является исходным документом для всех последующих после анализа требований этапов разработки ПС
ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС Ошибки и неточности во внешнем описании трансформируются в ошибки самой ПС и обходятся особенно дорого поскольку распространяются на все последующие этапы разработки ПС
Причиной тому является… ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС ОСНОВНЫЕ ТРУДНОСТИ В РАЗРАБТКЕ ВНЕШЕНЕГО ОПИСАНИЯ ПС: - пользователи часто плохо представляют, что им на самом деле нужно; - проблемы, которые необходимо отразить в определении требований, могут не иметь определенной формулировки, что приводит к постепенному изменению понимания разработчиками этих проблем. РАЗРАБОТКА ПС МОЖЕТ ПОТРЕБОВАТЬ ПРИНЦИПИАЛЬНОГО ИЗМЕНЕНИЯ ВСЕЙ ТЕХНОЛОГИИ ДЕЯТЕЛЬНОСТИ ПОЛЬЗОВАТЕЛЕЙ (О ЧЕМ ПОЛЬЗОВАТЕЛИ, КАК ПРАВИЛО НЕ ДОГАДЫВАЮТСЯ)
2 1 Для помощи пользователям в определении их требований к ПС “анализу требований” предшествует “системный анализ”
ВНЕШНЕЕ ОПИСАНИЕ – СПЕЦИФИКАЦИЯ ПС Функциональную спецификацию Спецификацию качества Включает… Определяет содержание функций для реализации в ПС Определяет планируемые значения всех критериев качества ПС, включая приоритетность реализации функций ПС Определяет…
Внешнее описание не отвечает на вопросы, как должно быть устроено ПС. 1 Определяет, что должно делать ПС 2 Определяет какими внешними свойствами должно обладать ПС 3 Должно быть понято пользователем, в степени достаточной для принятия окончательного решения о заключении договора на разработку ПС 4 Ставит для разработчиков ПС ориентиры, управляющие выбором приемлемых решений при реализации функций.
Существуют также… 1 Спецификация архитектуры ПС 2 Спецификации программных модулей ПС Можно рассматривать, как детализации внешнего описания ПС
Структура международного стандарта “IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению (SRS)” 1.Краткий обзор 1.1 Область действия 2. Публикации 3. Определения 4. Критерии получения качественной SRS 4.1 Сущность SRS 4.2 Среда SRS 4.3 Характеристики качественной SRS 4.4 Совместная подготовка SRS 4.5 Развитие SRS 4.6 Макетирование 4.7 Встраивание структуры в SRS 4.8 Встраивание требований проекта в SRS 5. Разделы SRS 5.1 Введение (Раздел 1 SRS) 5.2 Общее описание (Раздел 2 SRS) 5.3 Специфические требования (Раздел 3 SRS) 5.4 Дополнительная информация Приложение А (информационное) Шаблоны SRS Приложение Б (информационное) Указания по соответствию стандарту IEEE/EIA 12207/1-1997
Структура спецификации ПС по требованиям МС IEEE 830-1998
Подраздел "1.1 Назначение": а) назначение спецификации; б) пользователи спецификации. Подраздел 1.2 "Область действия“. этот подраздел должен: а) идентифицировать ПС, например, “Генератор отчетов” и т.п.; б) объяснять, что ПС будет и, в случае необходимости, не будет делать; в) описывать применение задаваемого ПС, включая связанные с ним выгоды, цели и задачи; г) согласовываться с аналогичными формулировками в спецификациях более высокого уровня (например, со спецификацией системных требований), если они существуют.
Подраздел 1.4 "Публикации”.Этот подраздел должен: а) представить полный список всех документов, на которые делаются ссылки в других местах спецификации; б) идентифицировать каждый документ по заголовку, номеру отчета (если применяется), дате и издательской организации; в) определить источники, из которых могут быть получены ссылки. Эту информацию можно обеспечить ссылкой на приложение или другой документ. Подраздел 1.5 "Краткий обзор". Этот подраздел должен: а) описать, какие оставшиеся части содержатся в спецификации; б) объяснить, как организована спецификация.
Этот раздел спецификации описывает общие факторы, которые влияют на ПС и требования, предъявляемые к нему. Этот раздел не устанавливает конкретные требования. Он обеспечивает предварительные сведения о тех требованиях, которые подробно определяются в разделе 3 спецификации, и делает их более простыми для понимания.
Подраздел 2.1 “Перспектива изделия” 1 Этот подраздел спецификации оценивает ПС в перспективе взаимодействия с другими ПС. Если ПС является независимым и полностью автономным, это должно быть отражено в спецификации. 2 В подразделе описываются различные ограничения ПС во взаимодействии с внешним окружением.
ПОДРАЗДЕЛ 2.1 “ПЕРСПЕКТИВА ИЗДЕЛИЯ” 1 Этот подраздел спецификации оценивает ПС в перспективе взаимодействия с другими ПС. Если ПС является независимым и полностью автономным, это должно быть отражено в спецификации. 2 В подразделе описываются различные ограничения ПС во взаимодействии с внешним окружением. а) Системные интерфейсы б) Интерфейсы пользователя в) Аппаратные интерфейсы г) Интерфейсы программного обеспечения д) Интерфейсы связи (сетевые интерфейсы) е) Память ж) Операции и) Требования к адаптации места использования Возможные ограничения во взаимодействии с внешней средой…
Подраздел 2.2 "Функции ПС" Сводка основных функций, выполняемых программным обеспечением. Подраздел 2.3 "Характеристики пользователя" Описание общих характеристик пользователей ПС, включая образовательный уровень, опыт и специальные технические знания. Подраздел 2.5 "Допущения и зависимости" Перечисление факторов, влияющих на требования, сформулированные в спецификации. Подраздел 2.6 "Распределение требований" Идентификация требований, которые могут быть отложены до появления будущих версий ПС.
Подраздел 2.4 "Ограничения” (за исключением ограничений во взаимодействии с внешней средой, описываемых в разделе 2.1) Этот подраздел спецификации обеспечивает общее описание любых других позиций, которые будут ограничивать возможности разработчика. Они включают: а) регулирующие политики; б) аппаратные ограничения (например, требования к синхронизации сигналов); в) интерфейсы с другими приложениями; г) параллельные операции; д) функции контроля; е) функции управления; ж) требования к языку более высокого порядка; з) протоколы квитирования сигналов (например, XON-XOFF..ACK-NACK); и) требования к надежности; к) критичность применения; л) критерии безопасности и защиты.
Этот раздел спецификации содержит все требования к ПС на уровне детализации, достаточной, чтобы дать проектировщикам возможность разработать ПС, а испытателям - убедиться, что ПС удовлетворяет заданным требованиям. 1 Описание каждого входного воздействия на ПС. 2 Описание каждого выходного сигнала (отклика) ПС и всех функций, выполняемых ПС в ответ на входное воздействие или для поддержания выходного сигнала. Для этого необходимо …
Подраздел 3.1 "Внешние интерфейсы". Этот раздел представляет детализированное описание всех входных и выходных данных ПС, включая: а) наименование позиции; б) описание назначения; в) источник (для входных данных) или адресат (для выходных данных); г) допустимый диапазон, точность и/или допуск значений; д) единицы измерения; е) синхронизация (с другими данными); ж) cвязи с другими входами/выходами; и) форматы/организация экрана; к) форматы/организация окна; л) форматы данных; м) форматы команд и др.
Подраздел 3.3 "Требования к рабочим характеристикам". В этом подразделе определяются требования к статическим и динамическим числовым характеристикам ПС, таким, как: а) число поддерживаемых терминалов; б) число одновременно поддерживаемых пользователей; в) количество и тип обрабатываемой информации; г) количество групповых операций и задач; д) количество данных, которые будут обрабатываться в пределах определенных периодов времени для нормальных и пиковых условий рабочей нагрузки. Подраздел 3.4 "Логические требования к базе данных“. В этом подразделе описываются логические требования для любой информации, которая должна размещаться в базе данных. Она может включать следующее: а) Типы информации, используемой различными функциями; б) Частота использования; в) Возможности доступа; г) Информационные объекты и их связи; д) Ограничения целостности; е) Требования к сохранности данных.
Структура спецификации ПС по требованиям МС IEEE 830-1998 Определяет … Определяет …
Структура спецификации ПС по требованиям МС IEEE 830-1998 1 Стандарт IEEE 830-1998 не требует в точности повторять описанную структуру спецификации и описанные наименования разделов спецификации. 2 Важным является отразить всю информацию предусмотренную IEEE 830-1998 . 3 Разделы спецификации требуемые IEEE 830-1998 могут содержаться в разных документах, с названиями отличными от слова “спецификация”. Например часть или вся требуемая IEEE 830-1998 информация может быть отражена документе с названием “Концепции программного продукта”.
Практическое задание Определите разделы которые Вы бы включили во внешнее описание: в спецификацию качества и функциональную спецификацию Вашего программного средства.
Показатели и критерии качества описания ПС согласно IEEE 830-1998
Показатели и критерии качества описания ПС согласно IEEE 830-1998
Способы определения требований к ПС Определение требований к ПС Управляемое пользователем Контролируемое пользователем Независимое от пользователя
Инструменты составления требований к ПС Инструменты составления требований к ПС Объектно-ориентированные Процессно-ориентированные Ориентированные на представление поведенческих характеристик Унифицированный процесс разработки объектно-ориентированных систем (RUP) и унифицированный язык моделирования (UML) Метод структурного анализа и моделирования (SADT) и диаграммы в формате IDEF0 Математические функции и конечные автоматы
Функциональная спецификация ПС Функциональная спецификация ПС Описание внешней информационной среды Определение функций ПС Описание нежелательных (исключительных) ситуаций используемые каналы ввода и вывода; информационные объекты; существенные связи между информационными объектами обозначения всех определяемых функций; спецификации всех входных данных и результатов выполнения каждой функции; семантика каждой функции все существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию
Методы контроля внешнего описания ПС Методы контроля внешнего описания ПС Статический просмотр Смежный контроль Пользовательский контроль Ручная имитация
АРХИТЕКТУРА ПРОГРАММНЫХ СРЕДСТВ ЛЕКЦИЯ 3 Технология разработки программного обеспечения
Архитектура программного обеспечения — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Архитектура ПО определяет глобальные ограничения, накладываемые на проектирование системы, такие как: выбор парадигмы программирования стандарты разработки ПО, принципы проектирования и ограничения, накладываемые государственным законодательством. Проектирование ПО высокого уровня (концептуальное проектирование) – архитектурное проектирование. НЕ РЕШАЕТ ЗАДАЧУ КАКИМ ОБРАЗОМ РЕАЛИЗОВАТЬ ТРЕБУЕМЫЕ ОТ ПО ФУНКЦИИ Проектирование ПО низкого уровня – детальное проектирование. РЕШАТЕТ ЗАДАЧУ РЕАЛИЗАЦИИ ФУНКЦИЙ ПО В РАМКАХ СОЗДАННОЙ АРХИТЕКТУРЫ – т.е. в рамках накладываемых ею ограничений.
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Критерии и примитивы качества ПС согласно МС ISO/IEC 9126 Разработка архитектуры – это способ борьбы со сложность ПО
Представления архитектуры в унифицированном процессе разработки программного обеспечения Для пользователей Для кодировщиков ПС Для проектировщиков ПС Для сетевых администраторов
Представления архитектуры интегрированных информационных систем (ARIS – Architecture of Integrated Information Systems) компании IDS Scheer AG
Представления архитектуры ARIS Первый шаг при создании архитектуры интегрированных информационных системы (ARIS) - разработка модели бизнес-процесса, для улучшения организации которого разрабатывается ПС События Функции Исполнитель функции Состояния окружения функций Ресурсы
Представления архитектуры ARIS Для упрощения модель бизнес-процесса делится на отдельные типы моделей Состояния и события Функции и их взаимосвязи Орг. единицы и их взаимосвязи Ресурсы
Представления архитектуры ARIS Декомпозиция бизнес-процесса на отдельные типы моделей уменьшает степень его сложности за счет исключения из рассмотрения взаимосвязей между компонентами процесса, относящихся к другому типу моделей. В связи с этим вводится дополнительный тип модели – управляющая модель, в которой описываются взаимосвязи между моделями различных типов.
Представления архитектуры интегрированных информационных систем (ARIS – Architecture of Integrated Information Systems) компании IDS Scheer AG Управляющая модель – важнейшая компонента архитектуры ARIS, отличающая ее от архитектур, предлагаемых другими авторами.
Модель жизненного цикла программного обеспечения ARIS Каждое представление архитектуры ARIS (каждая модель ARIS) делится на уровни представления, соответствующие каждому из этапов жизненного цикла ПО
Модели отражают цели пользователей в работе с ПО и их язык Модели отражают требования пользователей и других заинтересованных сторон к ПО в их терминах Модели отражают требования пользователей и других заинтересованных сторон к ПО в терминах информационных технологий Модели отражает конкретные программные и аппаратные компоненты на которых реализуется ПО
Диаграмма процесса – описание текущих проблем бизнеса
Функциональное дерево – формулировка требований
Привязка экранов и списков – спецификация проекта
Привязка типов ПС, типов программных элементов и программных элементов – описание реализации
Представления архитектуры унифицированного процесса разработки ПО (RUP) IBM Rational 1 Бизнес-модель. Определяет абстракцию организации, для которой создается система. 2 Модель области определения. Фиксирует контекстное окружение системы. 3 Модель Use Case – вариантов использования. Определяет функциональные требования к системе. 4 Модель анализа. Интерпретирует требования к системе в терминах проектной модели. 5 Проектная модель. Определяет словарь проблемы и ее решение. 6 Модель размещения. Определяет аппаратную топологию, в которой исполняется система. 7 Модель реализации. Определяет части, которые используются для сборки и реализации физической системы. 8 Тестовая модель. Определяет тестовые варианты для проверки системы. 9 Модель процессов. Определяет параллелизм в системе и механизмы синхронизации. В отличие от ARIS каждое представление архитектуры RUP: 1 Ориентировано на определенную группу заинтересованных сторон. 2 Описывается с помощью разных моделей предназначенных для определенных групп заинтересованных сторон. 3 Каждое представление не делиться на уровни.
Представления архитектуры унифицированного процесса разработки ПО (RUP) IBM Rational В отличие от RUP каждое представление архитектуры ARIS: 1 Ориентировано на все группы заинтересованных сторон. 2 Описывается с помощью одной модели. 3 Каждое представление – модель делиться на уровни ориентированные на определенные группы заинтересованных сторон. Представления архитектуры интегрированных информационных систем (ARIS) IDS Sheer AG
Представления архитектуры интегрированных информационных систем (ARIS) IDS Sheer AG Представления архитектуры унифицированного процесса разработки ПО (RUP) IBM Rational
Архитектурный подход в проектах Электронного Правительства РФ Пронизывают
Архитектурный подход в проектах Электронного Правительства РФ Пронизывают Аспект: информации и данных УРОВЕНЬ ДЕЯТЕЛЬНОСТИ: состав информации, необходимой для поддержания административных процессов (например процессов взаимодействия между разными ведомствами УРОВЕНЬ ПРИКЛАДНЫХ СИСТЕМ: информационные объекты (сущности) для реализации на уровне отдельных прикладных систем УРОВЕНЬ ТЕХНОЛОГИЧЕСКОЙ ПЛАТФОРМЫ: информационные объекты (сущности) для реализации на уровне информационной системы в целом ОПРЕДЕЛЯЕТ
Архитектурный подход в проектах Электронного Правительства РФ Пронизывают Аспект: эффективности и результативности УРОВЕНЬ ДЕЯТЕЛЬНОСТИ: показатели эффективности работы органов государственной власти в результате внедрения информационной системы УРОВЕНЬ ПРИКЛАДНЫХ СИСТЕМ: показатели эффективности работы отдельных прикладных систем УРОВЕНЬ ТЕХНОЛОГИЧЕСКОЙ ПЛАТФОРМЫ: показатели эффективности информационной системы ОПРЕДЕЛЯЕТ
Элементы (перспективы) производственной архитектуры Microsoft Solution Framework (MSF) Концептуальное, логическое и физическое представления
Практическое задание 1 Определите точки зрения каких заинтересованных сторон и почему должна отражать архитектура Вашего программного средства. 2 Какая из рассмотренных моделей архитектур наиболее приемлема для Вашего программного средства. Архитектура программного обеспечения
Основные модели структурирования ПС Модели структурирования ПС на подсистемы Модели управления связями между подсистемами ПС Модели декомпозиции подсистем ПС на модули - Модель хранилища данных; - модель клиент-сервер; - трехуровневая модель; - модель абстрактной машины. - Модель централизованного управления; - модель событийного управления. - Модель потока данных; - модель объектов.
Модель структурирования программного средства на подсистемы - Модель хранилища данных Данные хранятся в общей памяти Подсистемы
Модель структурирования программного средства на подсистемы - Модель клиент-сервер Разные типы данных распределены по разным серверам Подсистемы
Модель структурирования программного средства на подсистемы - Трехуровневая модель Разные типы данных распределены по разным серверам Подсистемы – программные приложения расположены на отдельном сервере
Модель структурирования программного средства на подсистемы - Модель абстрактной машины Каждый текущий слой реализуется с использованием средств, обеспечиваемых слоем-фундаментом
Основные модели структурирования ПС Модели структурирования ПС на подсистемы Модели управления связями между подсистемами ПС Модели декомпозиции подсистем ПС на модули - Модель хранилища данных; - модель клиент-сервер; - трехуровневая модель; - модель абстрактной машины. - Модель централизованного управления; - модель событийного управления. - Модель потока данных; - модель объектов.
Модель управления связями между подсистемами ПС – Модель вызов-возврат Системный контролер – руководит работой остальных подсистем Модель исключает параллельную работу подсистем
Модель управления связями между подсистемами ПС – Модель менеджера Модель предусматривает параллельную работу подсистем Системный контролер – руководит работой остальных подсистем
Модель управления связями между подсистемами ПС – Широковещательная модель Каждая подсистема уведомляет обработчик об интересе к тому или иному событию Обработчик передает событие подсистеме для обработки Функции управления в обработчике событий отсутствуют
Модель управления связями между подсистемами ПС – Модель, управляемая прерываниями Каждый обработчик обрабатывает определенный тип прерывания Прерывания порождаются определенными событиями. Все прерывания разбиты на типы, образующие вектор прерываний Каждый процесс – подсистема запускается определенным обработчиком
Основные модели структурирования ПС Модели структурирования ПС на подсистемы Модели управления связями между подсистемами ПС Модели декомпозиции подсистем ПС на модули - Модель хранилища данных; - модель клиент-сервер; - трехуровневая модель; - модель абстрактной машины. - Модель централизованного управления; - модель событийного управления. - Модель потока данных; - модель объектов. Разбиение по функциям Разбиение по наборам данных, состояниям и наборам операций
Информационная закрытость модуля 1 Все модули независимы, обмениваются только информацией, необходимой для работы 2 Доступ к операциям и структурам данных модуля ограничен Означает Благодаря этому 1 Обеспечивается возможность разработки программных модулей различными, независимыми коллективами разработчиков 2 Обеспечивается легкая модификация ПО
Идеальный программный модуль играет роль "черного ящика", содержимое которого невидимо клиентам – другим программным модулям. Он прост в использовании — количество "ручек и органов управления" им невелико Следовательно Сцепление – внешняя характеристика программного модуля Связанность – внутренняя характеристика программного модуля Определяют "черноты" программного модуля
1 Мера сложности внешних связей (между модулями) – "сцепление" 2 Мера сложности внутренних связей (внутри модулей) – "связность" Учитывается
Состав задач проектирования архитектуры программного средства согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) Трансформация требований к ПС в архитектуру Описание структуры и компонент ПС Разработка эскизного проекта баз данных, внешних интерфейсов ПС и интерфейсов между его компонентами Разработка предварительных требований к тестированию ПС Оценка архитектуры ПС
а) учет требований к программному ПС; б) внешняя согласованность с требованиями к ПС; с) внутренняя согласованность между компонентами (подсистемами) ПС; д) соответствие методов проектирования ПС и используемых стандартов; е) возможность технического проектирования ПС; ж) возможность эксплуатации и сопровождения ПС, при этом разработчик должен провести совместный с заказчиком анализ архитектуры ПС. Проводится по следующим критериям
Содержание МС “ISO ISO/IEC 42010:2007 (IEEE 1471). Технология систем и программного обеспечения. Рекомендуемая практика архитектурного описания программно-интенсивных систем 1 Обзор области применения стандарта 2 Ссылки на родственные стандарты 3 Практика архитектурных описаний: - документирование архитектуры; - идентификация заинтересованных лиц и их интересов; селекция архитектурных точек зрения; архитектурные виды; обоснование выбора архитектур; - образцы использования архитектур. 4 Приложения - библиография; - замечания по терминологии; - образцы точек зрения; - отношения с другими стандартами.
Модель проектирования архитектуры программного средства МС “ISO ISO/IEC 42010:2007 (IEEE 1471) Представлена в виде семантической сети, связывающей основные понятия архитектуры с помощью некоторых отношений Отношения: 1 Различается; 2 Различается; 3 Выбирается; 4 Агрегируется, 5 Состоит из видов; 6 Имеет; 7 Адресуется; 8 Реализуется; 9 Покрывает; 10 Устанавливает форму; 11 Состоит из моделей; 12 Содержит; 13 Убеждает; 14 Представляет; 15 Использует; 16 Имеет; 17 Размещена; 18 Обеспечивает)
а) лица приобретающие ПС; б) эксперты-консультанты, проверяющие целесообразность приобретения; в) пропагандисты, распространяющие сведения о ПС через документы и обучение; г) разработчики, создающие ПС; д) лица сопровождающие, внедряющие и развивающие ПС; е) снабженцы, поставляющие "комплектующие части"; ж) пользователи, обеспечивающие использование системы по назначению; и) администраторы, обеспечивающие функционирование ПС; к) тестировщики, проверяющие корректность работы ПС. МС “ISO ISO/IEC 42010:2007 (IEEE 1471) Различается Использует Имеет Адресуется
"Интерес к тем функциям, которые исполнимы в ПС, а значит к поведению ПС" "Интерес к защищенности ПС по отношению к несанкционированному доступу" "Интерес к позитивным эффектам, достижимым при использовании ПС" МС “ISO ISO/IEC 42010:2007 (IEEE 1471) Различается Покрывает Имеет Например
РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ ЛЕКЦИИ 4 - 5 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Информационная закрытость модуля
Информационная закрытость модуля
ПРОГРАММНЫЕ МОДУЛИ: 1 “Вычислять синус угла” 2 “Проверять орфографию” 3 “Читать запись файла” 4 “Вычислять координаты цели” 5 “Вычислять зарплату сотрудника” 6 “Определять место пассажира” В КАЖДОМ МОДУЛЕ ВЫПОЛНЯЕТСЯ ТОЛЬКО ОДНА ФУНКЦИЯ
Модуль "Прием и проверка записи”, включает следующие элементы: - 1 - Прочитать запись из файла; - 2 - Проверить контрольные данные в записи; - 3 - Удалить контрольные поля в записи; - 4 - Вернуть обработанную запись; Конец модуля. В ОДНОМ МОДУЛЕ ВЫПОЛНЯЕТСЯ НЕСКОЛЬКО ФУНКЦИЙ (ВЫПОЛНЯЮТСЯ ВСЕ ОБЯЗАТЕЛЬНО), СЛЕДУЮЩИХ СТРОГО ОДНА ЗА ДРУГОЙ И ИСПОЛЬЗУЮЩИХ ОДИН НАБОР ДАННЫХ
Модуль "Отчет и средняя зарплата" использует "Таблицу зарплаты служащих" и включает следующие элементы: - Сгенерировать "Отчет по зарплате"; - Вычислить параметр "Средняя зарплата"; - Вернуть отчет по зарплате "Средняя зарплата"; Конец модуля МОДУЛЬ ВКЛЮЧАЕТ НЕСКОЛКО ФУНКЦИЙ КОТОРЫЕ МОГУТ ВЫПОЛНЯТСЯ ОДНОВРЕМЕННО, В РАЗНОЙ ПОСЛЕДОВАТЕЛЬНОСТИ, МОГУТ ВЫПОЛНЯТСЯ ВСЕ ФУНКЦИИ ИЛИ ТОЛЬКО ЧАСТЬ ИЗ НИХ , ПРИ ЭТОМ ВСЕ ОНИ ИСПОЛЬЗУЮТ ОДНИ И ТЕ ЖЕ НАБОРЫ ДАННЫХ
Модуль “Вычисление средних значений” использует Таблицы данных “А” и “В” суммаТабл-А:= 0 суммаТабл-В:= 0 для i := 1 до 300 суммаТабл-А := суммаТабл-А + Таблица-А(i) суммаТабл-В :- суммаТабл-В + Таблица-В(i) конец для среднееТабл-А := суммаТабл-А / 300 среднееТабл-В := суммаТабл-В / 300 вернуть среднееТабл-А, среднееТабл-В Конец модуля ФУНКЦИИ МОДУЛЯ ВЫПОЛНЯЮТСЯ В РАМКАХ ОДНОЙ ПРОЦЕДУРЫ. При этом могут выполняться с использованием разных наборов данных, но строго последовательно
Модуль “Инициализировать Систему”: - 1 - Перемотать магнитную ленту “№1”; - 2 - Счетчик магнитной ленты “№1”:= 0; - 3 - Перемотать магнитную ленту “№2”; - 4 - Счетчик магнитной ленты “№2”:= 0; - 5 - Таблица тек. записей: = пробел .. пробел; - 6 - Таблица количества записей:= 0 .. 0; - 7 - Переключатель №1: = “Выкл.”; - 8 - Переключатель №2:= “Вкл.” Конец модуля ВСЕ ФУНКЦИИ НЕОБХОДИМО ВЫПОЛНИТЬ ОДНОВРЕМЕННО При этом они могут использовать разные наборы данных и выполняться в разной последовательности
Модуль “Пересылка сообщения” - Переслать по электронной почте - Переслать по факсу - Послать в телеконференцию - Переслать по ftp-протоколу Конец модуля ФУНКЦИИ СВЯЗАНЫ МЕЖДУ СОБОЙ СМЫСЛУ. При этом функции модуля могут использовать разные наборы данных, могут выполняться все или часть из них в зависимости от запроса пользователя или другого модуля
Модуль “Разные функции” Поздравить с Новым годом (...) Проверить исправность аппаратуры (...) Заполнить анкету (...) Измерить температуру (...) Вывести собаку на прогулку (...) Запастись продуктами (...) Приобрести автомобиль (...) Конец модуля ФУНКЦИИ НИКАКИМ ОБРАЗОМ НЕ СВЯЗАНЫ МЕЖДУ СОБОЙ ПО СМЫСЛУ, ВРЕМЕНИ ВЫПОЛНЕНИЯ И ИСПОЛЬЗУЕМЫМ НАБОРАМ ДАННЫХ
Алгоритм определения уровня связности модуля программного средства
ПРОГРАММНЫЕ МОДУЛИ: 1 “Вычислять синус угла” 2 “Проверять орфографию” 3 “Читать запись файла” 4 “Вычислять координаты цели” 5 “Вычислять зарплату сотрудника” 6 “Определять место пассажира”
Модуль "Прием и проверка записи”, включает следующие элементы: - 1 - Прочитать запись из файла; - 2 - Проверить контрольные данные в записи; - 3 - Удалить контрольные поля в записи; - 4 - Вернуть обработанную запись;
Модуль "Отчет и средняя зарплата" использует "Таблицу зарплаты служащих" и включает следующие элементы: - Сгенерировать "Отчет по зарплате"; - Вычислить параметр "Средняя зарплата"; - Вернуть отчет по зарплате "Средняя зарплата";
Модуль “Вычисление средних значений” использует Таблицы данных “А” и “В” суммаТабл-А:= 0 суммаТабл-В:= 0 для i := 1 до 300 суммаТабл-А := суммаТабл-А + Таблица-А(i) суммаТабл-В :- суммаТабл-В + Таблица-В(i) конец для среднееТабл-А := суммаТабл-А / 300 среднееТабл-В := суммаТабл-В / 300 вернуть среднееТабл-А, среднееТабл-В
Модуль “Инициализировать Систему”: - 1 - Перемотать магнитную ленту “№1”; - 2 - Счетчик магнитной ленты “№1”:= 0; - 3 - Перемотать магнитную ленту “№2”; - 4 - Счетчик магнитной ленты “№2”:= 0; - 5 - Таблица тек. записей: = пробел .. пробел; - 6 - Таблица количества записей:= 0 .. 0; - 7 - Переключатель №1: = “Выкл.”; - 8 - Переключатель №2:= “Вкл.”
Модуль “Пересылка сообщения” - Переслать по электронной почте - Переслать по факсу - Послать в телеконференцию - Переслать по ftp-протоколу Конец модуля
Модуль “Разные функции” Поздравить с Новым годом (...) Проверить исправность аппаратуры (...) Заполнить анкету (...) Измерить температуру (...) Вывести собаку на прогулку (...) Запастись продуктами (...) Приобрести автомобиль (...) Конец модуля
Практическое задание 1 Опишите функции (действия) нескольких программных модулей Вашего программного средства. 2 Определите уровень их внутренней связанности.
Виды сцеплений модулей программных средств Сцепление по данным Сцепление по образцу Сцепление по управлению Сцепление по содержанию Сцепление по общей области
Сцепление по данным Все входные и выходные параметры вызываемого модуля — простые элементы данных (числа, текст и т.п.) НАИЛУЧШИЙ КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=1
Недостаток заключается в том, что конкретные передаваемые данные “спрятаны” в структуры, и потому уменьшается “прозрачность” связи между модулями В качестве параметров используются структуры данных (массивы, матрицы, таблицы и т.п. Сцепление по образцу КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=3
Сцепление по управлению Модуль А явно управляет функционированием модуля В посылая ему информационный объект (флаг, переключатель) для управления внутренней логикой работы модуля (ПЕРЕКЛЮЧАТЕЛЬ=0, тогда выполнить один набор вычислений, ЕСЛИ ПЕРЕКЛЮЧАТЕЛЬ=1, тогда выполнить другой набор вычислений и т.п.) КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=4
Сцепление по внешним ссылкам Модули А и В ссылаются на один и тот же глобальный элемент данных КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=5 A B Элемент данных (текст, число и т.д.)
Модули разделяют одну и ту же глобальную структуру данных (массив, матрицу, таблицу и т.п.) КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=7 Сцепление по общей области
Один модуль прямо ссылается на содержание другого модуля (из программного модуля идет ссылка на необходимость выполнения действия описанного в другом программном модуле и т.п.) КОЭФИЦИЕНТ СЦЕПЛЕНИЯ , СЦ=9 Сцепление по содержимому
Практическое задание 1 Нарисуйте схему взаимодействия программных модулей Вашего программного средства. 2 Определите тип их сцепления.
Рутинность модуля — это его независимость от предыстории обращений к нему. Модуль называется рутинным, если результат обращения к нему зависит только от значений его параметров и не зависит от результатов предыдущих обращений к нему.
Метод восходящей разработки программного средства Разработка модульной структуры программы в виде дерева Программирование модулей программы, начиная с модулей самого нижнего уровня Поочередное тестирование и отладка модулей в восходящем порядке – от нижнего уровня к высшему
Метод нисходящей разработки программного средства Разработка модульной структуры программы в виде дерева Программирование модулей программы, начиная с модулей самого верхнего уровня Поочередное тестирование и отладка модулей в нисходящем порядке – от верхнего уровня к низшему
Формирование модульной структуры программы при конструктивном подходе ШАГ 1 Формируется дерево верхнего уровня программы и программируются его программные модули
ШАГ 2 Формируются деревья (поддеревья) нижних уровней программы и программируются их программные модули
Классификация методов разработки структуры программных модулей (программ)
РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ ЛЕКЦИЯ 6 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Порядок разработки программного модуля 1 Изучение и проверка спецификации модуля, выбор языка программирования 2 Выбор алгоритма и структуры данных 3 Программирование (кодирование) модуля 4 “Шлифовка” текста модуля 5 Проверка модуля 6 Компиляция модуля
Основные управляющие конструкции – структуры структурного программирования где S, S1, S2 - обобщенные операторы - узлы обработки; P – условие.
Порядок пошаговой детализации программного кода программного модуля 1 Описание общей схемы работы модуля с использованием неформализованных терминов 2 Уточнение и детализация терминов, до тех пор, пока каждый из них не будет описан на базовом языке программирования 3 Получение текста модуля на базовом языке программирования
Головное описание программного модуля на псевдокоде 1 Начало модуля на базовом языке программирования 2 Внешнее описание процедур и функций на базовом языке программирования 3 Неформальное описание последовательности операторов, функций и процедур программного модуля 4 Конец модуля на базовом языке программирования
Основные конструкции структурного программирования на псевдокоде
Частные случаи оператора перехода в качестве обобщенного оператора
Пример одного шага детализации на псевдокоде
Методы контроля программного модуля Методы контроля программного модуля Статическая проверка текста модуля Сквозное прослеживание Доказательство свойств программного модуля
ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ ЛЕКЦИЯ 7 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Концепция формального обоснования программы - Триада Хоора {n=0} n:= n+1{n=1}, (9.1) {n
Свойства простых операторов ТЕОРЕМА 9.1 Пусть P предикат – утверждение над информационной средой, тогда имеет место свойство {P}{P}.
Свойства простых операторов IS = (X, RIS) Информационная среда Переменная IS без X Свойство, выполняемое при заданном условии: {Q(F(X, RIS), RIS)} X:= F(X, RIS) {Q(X, RIS)}, где F(X, RIS) некоторая однозначная функция, Q предикат. ТЕОРЕМА 9.2 Условие: Пример свойства: {n=0} n:= n+1{n=1}, (9.1)
Свойства конструкции “Следование” структурного программирования {P}S1{Q} и {Q}S2{R} Предикаты – утверждения Операторы Свойство, выполняемое при заданном условии: {P} S1; S2 {R} ТЕОРЕМА 9.3 Условие: Пример: поскольку выполняются свойства: {n
Свойства конструкции “Разветвление” стр. программирования {P,Q}S1{Q} и { P,Q}S2{R} Предикаты – утверждения Операторы Свойство, выполняемое при заданном условии для условного оператора ЕСЛИ P ТО S1 ИНАЧЕ S2 ВСЕ ЕСЛИ : {Q} ЕСЛИ P ТО S1 ИНАЧЕ S2 ВСЕ ЕСЛИ {R}. ТЕОРЕМА 9.4 Условие:
Свойства конструкции “Разветвление” стр. программирования {P}S{Q}, P1 P, Q Q1 Предикаты – утверждения Оператор Свойство, выполняемое при заданном условии: {P1}S{Q1}. ТЕОРЕМА 9.5 Условие:
Свойства конструкции “Повторение” структурного программирования {I}S{I}, P I, (I, Q ) R Предикаты – утверждения Оператор Свойство, выполняемое при заданном условии для оператора цикла: {P} ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА {R}. ТЕОРЕМА 9.6 Условие: Пример: {n>0; p:=1; m:=1} ПОКА m <> n ДЕЛАТЬ m:=m+1; p:=pm (9.4) ВСЕ ПОКА {p= n!}.
Завершимость выполнения программы ТЕОРЕМА 9.7 Условие: F целочисленная функция, зависящая от состояния информационной среды и удовлетворяющая следующим условиям: – 1 – если для данного состояния информационной среды истинен предикат Q, то ее значение положительно; – 2 – она убывает при изменении состояния информационной среды в результате выполнения оператора S. Свойство, выполняемое при заданных условиях: выполнение оператора цикла ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА завершается. Пример: {m:=1} ПОКА n – m > 0 ДЕЛАТЬ f: = nm; ВСЕ ПОКА {n:=0}
Пример доказательство свойства программы Программа: {n>0; p:=1; m:=1} ПОКА m <> n ДЕЛАТЬ m:=m+1; p:=pm (9.4) ВСЕ ПОКА {p= n!}. Шаг 1). n>0 (n>0, p любое, m любое). (Шаг 2). По теореме 9.2 выполняется следующее свойство {n>0, p любое, m любое} p:=1 {n>0, p=1, m любое}. (Шаг 3). По теореме 9.2 верно следующее свойство {n>0, p=1, m любое} m:=1 {n>0, p=1, m=1}.
Пример доказательство свойства программы Программа: {n>0; p:=1; m:=1} ПОКА m <> n ДЕЛАТЬ m:=m+1; p:=pm (9.4) ВСЕ ПОКА {p= n!}. (Шаг 4). По теореме 9.3 в силу результатов шагов 2 и 3 выполняется следующее свойство {n>0, p любое, m любое} p:=1; m:=1 {n>0, p=1, m=1}. Необходимо доказать, что предикат p= m! является инвариантом цикла, т.е. {p=m!} m:=m+1; p:=pm {p=m!}.
Пример доказательство свойства программы (Шаг 5). По теореме 9.2 выполняется следующее свойство {p= m!} m:= m+1 {p= (m1)!}, при этом предусловие представляется в виде {p= ((m+1)1)!}. (Шаг 6). По теореме 9.2 выполняется следующее свойство {p= (m1)!} p:= pm {p= m!}, при этом предусловие представляется в виде {pm= m!}. (Шаг 7). По теореме 9.2, в силу результатов шагов 5 и 6 выполняется следующее свойство {p= m!} m:= m+1; p:= pm {p= m!}.
Пример доказательство свойства программы (Шаг 8). По теореме 9.6 в силу результата шага 7 выполняется следующее свойство {n>0, p=1, m=1} ПОКА m <> n ДЕЛАТЬ m:= m+1; p:= pm ВСЕ ПОКА {p= n!}, при этом учитывается, что (n>0, p=1, m= 1) p= m!; (p= m!, m= n) p= n!.
Пример доказательство свойства программы (Шаг 9). По теореме 9.3 в силу результатов шагов 3 и 8 выполняется следующее свойство {n>0, p любое, m любое} p:=1; m:=1; ПОКА m <> n ДЕЛАТЬ m:= m+1; p:= pm ВСЕ ПОКА {p= n!}. (Шаг 10). По теореме 9.5 в силу результатов шагов 1 и 9 выполняется свойство (9.4)
ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА ЛЕКЦИЯ 8 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Состав задач тестирования ПС согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) Разработка процедуры испытаний (тестирования) и данных для тестирования каждого программного модуля и базы данных Тестирование каждого программного модуля и базы данных Уточнение документации пользователя (при необходимости) Уточнение требований к тестированию Оценка программных модулей и результатов их тестирования по следующим критериям: a) учет требований к программному модулю и проекту объекта в целом; b) внешнее соответствие требованиям и проекту программного модуля; c) внутреннее соответствие между требованиями к программным модулям; d) тестовое покрытие всех модулей; e) соответствие методов программирования и используемых для них стандартов; f) возможность сборки и тестирования; g) возможность эксплуатации и сопровождения.
Основные определения тестирования и отладки ПС Отладка = Тестирование + Поиск ошибок + Редактирование Проверка соответствия полученных результатов работы ПС ожидаемым Проверка и устранение несоответствий Выполняется в случае, несовпадения результатов тестирования с ожидаемыми результатами Устранение выявленных ошибок Тестирование также является частью аттестации ПС
Основные определения тестирования и отладки ПС Тестирование всегда выполняется с помощью некоторого набора данных, который называется тестовым или тестом Хорошим считают тест с высокой вероятностью обнаружения еще не раскрытой ошибки При этом … Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку
Основные определения тестирования и отладки ПС Тестирование не может показать отсутствия дефектов оно может показывать только присутствие дефектов ВАЖНО ПОМНИТЬ! Следовательно … 1 Если тесты не обнаруживают ошибок, необходимо проверить достаточно ли продуманы тесты и что в ПО нет скрытых ошибок 2 Ошибки не выявленные с помощью тестов будут обнаруживаться на стадии эксплуатации ПО, когда стоимость их устранения возрастет в 60 – 100 раз
Стоимость устранения ошибок в программном обеспечении на разных стадиях его жизненного цикла
Виды тестирования ПО
Принципы и виды отладки программного обеспечения Успех отладки ПС в значительной степени предопределяет рациональная организация тестирования Для рациональной организации отладки ПО необходимо решить следующие задачи … 1 Подготовить такой набор тестов, чтобы обнаружить в ПС по возможности большее число ошибок. 2 Определить момент окончания отладки ПС (или отдельной его компоненты) Для оптимизации набора тестов необходимо 1 Заранее планировать этот набор 2 Использовать рациональную стратегию планирования (проектирования) тестов
Принципы и виды отладки программного обеспечения Успех отладки ПС в значительной степени предопределяет рациональная организация тестирования Для рациональной организации отладки ПО необходимо решить следующие задачи … 1 Подготовить такой набор тестов, чтобы обнаружить в ПС по возможности большее число ошибок. 2 Определить момент окончания отладки ПС (или отдельной его компоненты) При этом, важно помнить! Чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС. 1 Полнота охвата выполненными тестами множества различных ситуаций, возникающих при выполнении ПС 2 Относительно редкое проявление ошибок в ПС на последнем отрезке процесса тестирования Признаки окончания отладки
Выбор оптимальной стратегии находится между двумя крайними подходами Тесты проектируются только на основании изучения спецификации ПС. Строение модулей при этом никак не учитывается, т.е. они рассматриваются как "Черные ящики" Тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Т.е. программные модули рассматриваются, как "Белые ящики".
Тесты проектируются только на основании изучения спецификации ПС. Строение модулей при этом никак не учитывается, т.е. они рассматриваются как "Черные ящики" Тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Т.е. программные модули рассматриваются, как "Белые ящики". Полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, а это значит, что содержащиеся в них ошибки не будут проявляться. Такое тестирование практически неосуществимо Подход требует Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться также чрезвычайно много, так что их тестирование будет практически неосуществимо При этом
Тестирование ПС по отношению к спецификациям – тестирование “Черного ящика” 1 Известны: функции программы. 2 Исследуется: работа каждой функции на всей области определения. При тестировании "Черного ящика" рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Полное или исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 10^10 тестовых вариантов.
Подходы к тестированию программных средств Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. Обычно анализируются управляющие связи элементов, реже — информационные связи. Исчерпывающее тестирование, как правило, невозможно. 1 Известна: внутренняя структура программы. 2 Исследуются: внутренние элементы программы и связи между ними.
Подходы к тестированию программных средств Тестирование базового пути. В этом способе тесты разрабатываются для проверки базового множества путей – маршрутов в программе. Они гарантируют однократное выполнение каждого оператора программы при тестировании. Тестирования условий позволяет строить тесты для проверки логических условий программы. При этом желательно обеспечить охват операторов из всех ветвей программы. Тестирование ветвей и операторов отношений обнаруживает ошибки ветвления и операторов отношения. Тестирования потоков данных. В данном способе анализу подвергается информационная структура программы. Тестирование циклов. В этом способе особое внимание уделяется проверке правильности конструкций циклов.
Подходы к тестированию программных средств и выбор оптимальной стратегии тестирования Тестирование “Черного ящика” Тестирование “Белого ящика” Хотя бы один тест на каждую: - используемую функцию; - область и границу изменения какой-либо входной величины; - особую (исключительную) ситуацию. Хотя бы один тест на каждую команду в каждом программном модуле ПС. Оптимальная стратегия тестирования расположена внутри интервала между крайними подходами, но ближе к левому краю!
Подходы к тестированию программных средств и выбор оптимальной стратегии тестирования Оптимальную стратегию проектирования тестов можно конкретизировать на основании следующего принципа: – для каждого программного документа (включая тексты программ), входящего в состав ПС, должны проектироваться свои тесты с целью выявления в них ошибок 1 Результаты каждой стадии разработки ПО отражаются в соответствующих документах 2 Набор и содержание тестов дополняется и уточняется на каждой стадии разработки ПО
Феномен роста вероятности существования ошибок в ПС По мере роста числа обнаруженных и исправленных ошибок в ПС растет также вероятность существования в нем необнаруженных ошибок.
Заповеди по организации отладки программного средства Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу. Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы. Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных. Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить. Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование. Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).
Практическое задание 1 Опишите графически оптимальную стратегию тестирования Вашего программного средства. 2 Напишите комментарии к графику, поясняющие Ваш выбор. Тестирование “Черного ящика” Тестирование “Белого ящика” Тесты проектируются только на основании изучения спецификации ПС. Строение модулей при этом никак не учитывается, т.е. они рассматриваются как "Черные ящики" Полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, а это значит, что содержащиеся в них ошибки не будут проявляться. Подход требует Тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Т.е. программные модули рассматриваются, как "Белые ящики". Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться чрезвычайно много. При этом
Виды отладки программного средства Автономная отладка Комплексная отладка Отладка каждого программного модуля и его окружения (сопряженных модулей) Тестирование ПС в целом Восходящее тестирование Нисходящее тестирование Один отладочный модуль – головной в тестируемой программе Множество отладочных модулей – отладочных имитаторов (заглушек)
Модули нижнего уровня объединяются в кластеры, отлаживаемые впервую очередь Отладочные модули (драйверы) для отлаживаемых кластеров Модули объединяются в кластеры по функциям, которые они выполняют, для возможности протестировать их с помощью одного набора тестов Отладочный модуль готовит состояние информационной среды необходимое для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и после окончания его работы выдает необходимые сообщения
Модули объединяются в кластеры по функциям, которые они выполняют, для возможности протестировать их с помощью одного набора тестов Отладочный модуль готовит состояние информационной среды необходимое для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и после окончания его работы выдает необходимые сообщения Отладочные модули (драйверы) для отлаживаемых кластеров Информационная среда отлаживаемых модулей Модули нижнего уровня объединяются в кластеры, отлаживаемые впервую очередь
Вызывает подчиненный модуль Посылает элемент данных (параметр) из внутренней таблицы Отображает параметр из подчиненного модуля Является комбинацией драйверов В и С Очередность тестирования модулей 1 2 3 4
Очередность тестирования модулей 1 2 3 4 Отлаживаемый модуль Отладочные имитаторы (заглушки) – имитируют работу неотлаженных модулей Отображает трассируемое сообщение Отображает проходящий параметр Возвращает величину из таблицы Выполняет табличный поиск по ключу (входному параметру) и возвращает связанный с ним выходной параметр
На практике часто применяется смешанная форма отладки ПС Достоинства: – простота подготовки тестов; – можно составить полный план тестирования перед его началом. Недостатками: – тестовые данные готовятся, как правило, в форме, непонятной пользователю; – большой объем отладочного программирования; – необходимость специального тестирования сопряжения модулей. Достоинства: – большинство тестов готовится в форме, рассчитанной на пользователя; – во многих случаях относительно небольшой объем отладочного программирования; – отпадает необходимость тестирования сопряжения модулей. Недостатки: – невозможность или сильное затруднение подготовки полного плана перед началом тестирования.
Этапы автономного тестирования – Шаг 1 – На основании спецификации отлаживаемого модуля, подготовка тестов для каждой: а) возможной ситуации, б) границы областей допустимых значений всех входных данных, в) областей изменения данных, недопустимых значений всех входных данных и каждого недопустимого условия. – Шаг 2 – Проверка текста модуля, с целью убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавление недостающих тестов. – Шаг 3 – Проверка текста модуля, с целью убедиться, что для каждого цикла – повторения, существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: а) тело цикла не выполняется ни разу; б) тело цикла выполняется один раз в) тело цикла выполняется максимальное число раз. Добавление недостающих тестов. – Шаг 4 – Проверка текста модуля, с целью убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавление недостающих тестов. Тестирование “черного ящика” Тестирование “черного ящика” Тестирование “белого ящика”
Поиск несоответствий между описанием архитектуры, структурой и взаимодействием программных модулей и подсистем ПС. Поиск расхождений между функциональной спецификацией и функциями программных модулей и подсистем ПС Поиск нарушений требований качества, сформулированных в спецификации качества ПС Поиск несоответствий документации заданным требованиям, ее несогласованности с содержанием и функциями ПО Поиск несоответствий ПО установленным требованиям самим заказчиком 1 1 2 3 4 5 2 3 4 5
СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ HP QTP AutomatedQA TestComplete Rational Functional Tester Borland SilkTest Microsoft VS Selenium Watir Canoo WebTest Jemmy TestPartner Worksoft Certify и др.
ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА ЛЕКЦИИ 9 - 10 Технология разработки программного обеспечения
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Критерии и примитивы качества ПС согласно МС ISO/IEC 9126
Международные стандарты в области управления качеством КАЧЕСТВО ПРОЦЕССОВ УПРАВЛЕНИЯ: МС “ISO 9001:2008 (2000). Системы менеджмента качества. Требования”; МС “ISO/IEC 90003-2004. Руководство по применению стандарта ISO 9001:2000 для программных средств”; МС “ISO/IEC 90005-2008. Руководство по применению стандарта ISO 9001:2000 к процессам жизненного цикла программных средств”; МС “ISO/IEС 20000-1:2005. ИТ. Сервис менеджмент. Спецификация” (предоставление ИТ услуг)”; стандарт “Корпоративное управление ИТ” (COBIT) международной Ассоциации аудита и контроля информационных систем (ISACA). КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА: МС “ISO 12207:95 (2008). Процессы жизненного цикла ПО”; МС “ISO/IEC 15288:2008 . Процессы жизненного цикла систем”; МС “ISO/IEC 15504:2004. Оценка процессов. КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: МС “ISO/IEC 9126 . Оценка программного продукта. Характеристики качества и руководство по их применению”; -МС “ISO/IEC 25051:2006. Требования для качества готового коммерческого программного продукта и инструкция для испытаний”; - МС “ISO/IEC 14598. Оценка программного продукта”.
Модель классического жизненного цикла программного обеспечения
Завершенность - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих функций. Точность - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах. Автономность - свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других ПС. Устойчивость - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание некорректных входных данных. Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным действиям пользователя.
Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным действиям пользователя. Защита от сбоев аппаратуры Защита от влияния "чужой" программы Защита от отказов "своей" программы Защита от ошибок пользователя Защита от несанкци-онированного доступа
Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным действиям пользователя. Защита от сбоев аппаратуры Защита от влияния "чужой" программы Защита от отказов "своей" программы Защита от ошибок пользователя Защита от несанкци-онированного доступа Простая защита Защита от взлома защиты Предполагается, что пользователь, получив отказ в доступе к интересующим ему ресурсам, не будет предпринимать попыток обойти или преодолеть эту защиту. Разновидность защиты, существенно затрудняющая ее преодоление.
П-документированность - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС. Информативность - свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования. Коммуникабельность - свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием;
Временная эффективность - мера, характеризующая способность ПС выполнять возложенные на него функции в течение определенного отрезка времени. Эффективность по ресурсам - мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память). Эффективность по устройствам - мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
Принципы обеспечения эффективности программного средства 1 Разработать надежное ПС с точки зрения требуемой эффективности ПС 2 Довести эффективность ПС до требуемого спецификацией качества уровня 3 Если эффективность ПС не удовлетворяет спецификации качества, то найти самые критические модули (устройства) и оптимизировать их в первую очередь Не следует заниматься оптимизацией модуля, если этого не требуется для достижения требуемой эффективности ПС!
С-документировапнность - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данной ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование. Понятность - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Структурированность - свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определенным образом. Удобочитаемость - свойство, характеризующее легкость восприятия текста программ ПС. Расширяемость - свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент. Модифицируемость - мера, характеризующая ПС с точки зрения простоты внесения необходимых изменений и доработок на всех этапах и стадиях жизненного цикла ПС. Модульность - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств - свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ). Автономность - свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других ПС. Структурированность - свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определенным образом. Модульность - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Подход к управлению качеством программного обеспечения Этап 1. Разработка спецификации качества ПС, включая критерии и примитивы (показатели) качества основанные на требованиях заказчика ПС Этап 3. Выбор модели процессов разработки (жизненного цикла) ПС, включая показатели и критерии их качества процессов Этап 4. Создание проекта разработки ПС - процессов разработки ПС Этап 2. Разработка спецификаций качества программных модулей (подсистем) ПС, включая критерии и примитивы их качества, основанных на спецификации ПС в целом Этап 1. Разработка показателей и критериев качества продукции и услуг на основе требования потребителей Этап 3. Разработка показателей и критериев качества процессов жизненного цикла продукции и услуг, обеспечения их ресурсами и управления Этап 4. Разработка процессов жизненного цикла продукции и услуг, обеспечения их ресурсами и управления Этап 2. Разработка показателей и критериев качества компонентов продукции и услуг на основе показателей и критериев качества продукции и услуг в целом Технология разработки ПО Технология структурирования функций качества, универсальная для всех отраслей экономики
Практическое задание 1 Выпишите в порядке приоритетности критерии качества которым должно удовлетворять Ваше программное средство. 2 Напротив каждого критерия, дайте комментарии поясняющие Ваш выбор уровня приоритетности.
ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ ЛЕКЦИЯ 11 Технология разработки программного обеспечения
Процессы жизненного цикла ПО, обеспечения ресурсами и управления по МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Назначение документации программного средства Отчет по системному анализу: модели “как есть” и “как должно быть” 1 Концепция ПС 2 Тестовые наборы 1 Архитектура ПС 2 Модели ПС Текст программы Отчеты по тестированию
Модели – документы создаваемые на разных стадиях унифицированного процесса разработки (RUP) ПО
Документация программного средства Управления разработкой ПС Входящая в состав ПС 1 Планы, оценки, расписания 2 Отчеты об использовании ресурсов в процессе разработки 3 Стандарты 4 Рабочие документы 5 Заметки и переписка Пользовательская Сопровождающая 1 Общее функциональное описание ПС 2 Руководство по инсталляции ПС 3 Инструкция по применению ПС 4 Справочник по применению ПС руководство по управлению ПС 1 Внешнее описание ПС 2 Описание архитектуры ПС 3 Описание структуры программных модулей 4 Модели программного ПС (функциональные, объектные, информационные и т.п.) 5 Тексты программных модулей 6 Документы установления достоверности ПС 7 Руководство по сопровождению ПС
П-документированность - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС. Информативность - свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования. Коммуникабельность - свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием. Понятность - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Удобочитаемость - свойство, характеризующее легкость восприятия текста программ ПС. С-документировапнность - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данной ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.
Процесс “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010) 7.2.1.1 Цель Цель процесса менеджмента документации программных средств заключается в разработке и сопровождении зарегистрированной информации по программным средствам, созданной некоторым процессом.
Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010) 1 ПОДГОТОВКА ПРОЦЕССА 2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА 3 ВЫПУСК (ПРОИЗВОДСТВО) 4 СОПРОВОЖДЕНИЕ
1 ПОДГОТОВКА ПРОЦЕССА заголовок или наименование; b) назначение; c) пользователи документа; d) процедуры и обязанности по подготовке исходных материалов, разработке, проверке, изменению, утверждению, выпуску, хранению, распространению, сопровождению и управлению конфигурацией; e) сроки выпуска промежуточных и окончательных редакций. Для каждого издаваемого документа должны быть определены: Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА 2.1 Каждый конкретный документ должен быть спроектирован в соответствии с используемыми стандартами на документацию, в части а) формата; б) состава и содержания разделов; в) нумерации страниц; г) расположения и оформления рисунков и таблиц; д) отметок об авторских правах, правах доступа; е) брошюровки и других элементов представления информации. 2.2 Должны быть подтверждены источник и соответствие исходных материалов для документов 2.3 Подготовленные документы должны быть проверены и отредактированы в соответствии с используемыми стандартами на документацию. Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
3 ВЫПУСК (ПРОИЗВОДСТВО) 3.1 Документы должны быть изданы и распространены в соответствии с планом издания 3.2 Средства управления документированием должны быть определены в соответствии с процессом управления конфигурацией ПС Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
Базовые стандарты в области документирования ПС – ISO/IEC/IEEE 26511:2011. Разработка программного обеспечения и проектирование систем. Требования к менеджерам по документации пользователя. – ГОСТ Р ИСО/МЭК ТО 9294-93. Руководство по управлению документированием программного обеспечения (аутентичен ISO/IEC ТR 9294-90. Действующий международный стандарт ISO/IEC 9294-2005). – ГОСТ 19.001-77 – единая система программной документации. – ГОСТ 19.101-77 – виды программ и программных документов. – ГОСТ 19.102-77 – стадии разработки программ и программной документации. – ГОСТ 19.105-78 – требования к оформлению программных документов, комплексов и систем независимо от их назначения и области применения. (содержит полный перечень документации, которая должна сопровождать законченный программный продукт).
Национальные стандарты в области документирования ПС ГОСТ Р ИСО/МЭК 15910-2002. Процесс создания документации пользователя программного средства. ГОСТ 19.201-78 – порядок построения и оформления технического задания на разработку программы или программного изделия. ГОСТ 19.202-78 – форма и порядок составления спецификации на программные продукты, определяемые в ГОСТ 19.101-77. ГОСТ 19.301-79 – программа и методика испытаний программных продуктов. ГОСТ 19.401-78 – порядок построения и оформления текста программы при разработке программных продуктов. ГОСТ 19.402-78 – описание программы. ГОСТ 19.403-79 – форма заполнения и содержание ведомости держателей подлинников, определяемой в ГОСТ 19.105-78. ГОСТ 19.404-79 – форма заполнения и содержание пояснительной записки, определяемой в ГОСТ 19.105-78. ГОСТ 19.501-78 – форма заполнения и содержание формуляра на программный продукт, определяемый в ГОСТ 19.105-78.
Национальные стандарты в области документирования ПС ГОСТ 19.502-78 – форма заполнения и содержание описания применения, определяемого в ГОСТ 19.105-78. ГОСТ 19.503-79 – форма заполнения и содержание руководства системного программиста, определяемого в ГОСТ 19.105-78. ГОСТ 19.504-79 – форма заполнения и содержание руководства программиста, определяемого в ГОСТ 19.105-78. ГОСТ 19.505-79 – форма заполнения и содержание руководства оператора, определяемого в ГОСТ 19.105-78. ГОСТ 19.506-79 – форма заполнения и содержание описания языка, определяемого в ГОСТ 19.105-78. ГОСТ 19.507-79 – форма заполнения и содержание ведомости эксплуатационных документов, определяемой в ГОСТ 19.105-78. ГОСТ 19.508-79 – форма заполнения и содержание руководства по техническому обслуживанию, определяемому в ГОСТ 19.105-78. ГОСТ 19.701-90 – схемы алгоритмов, программ, данных и систем.
Содержание ISO/IEC ТО 9294-90. Руководство по управлению документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
Содержание ISO/IEC ТО 9294-90. Руководство по управлению документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93) Стратегия должна поддерживать основные элементы эффективного документирования: 1) требования документации охватывают весь жизненный цикл программного обеспечения. 2) документирование должно быть управляемым. 3) документация должна соответствовать ее читательской аудитории. 4) работы по документированию должны быть объединены в общий процесс разработки программного обеспечения. 5) должны быть определены и использованы стандарты по документированию. 6) должны быть определены средства поддержки.
Содержание ISO/IEC ТО 9294-90. Руководство по управлению документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93) Внутри организации должны быть приняты стандарты и руководства для: 1) модели жизненного цикла программного обеспечения; 2) типов и взаимосвязей документов; 3) содержания документа; 4) качества документа; 5) форматов документа; 6) обозначения документа.
Содержание ISO/IEC ТО 9294-90. Руководство по управлению документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93)
Содержание ISO/IEC ТО 9294-90. Руководство по управлению документированием программного обеспечения (ГОСТ Р ИСО/МЭК ТО 9294-93) Процедура управления документацией ПО: Шаг 1 - Планирование; Шаг 2 - Подготовка; Шаг 3 - Конфигурационное управление; Шаг 4 - Проверка; Шаг 5 - Утверждение; Шаг 6 - Производство; Шаг 7 - Хранение; Шаг 8 - Дублирование; Шаг 9 - Распространение и модернизация; Шаг 10 - Продажа.
Контрольные таблицы для управления документацией ПС ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93) А.1. КОНТРОЛЬНАЯ ТАБЛИЦА СТРАТЕГИИ а) Будут ли решения направлены на: 1) создание соответствующей программной документации? 2) применение стандартов и руководств по документированию? 3) установление процедур документирования? 4) создание ресурсов, пригодных для документирования? 5) использование средств автоматизированного документирования? 6) определение штата с ответственностями за: обеспечение стандартами и процедурами по документированию? контроль качества документации? б) Будет ли опубликован стратегический отчет?
Контрольные таблицы для управления документацией ПС ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93) А.2. КОНТРОЛЬНАЯ ТАБЛИЦА СТАНДАРТОВ Будут ли приняты или определены стандарты для: а) модели жизненного цикла программного обеспечения? б) типов и содержания документов? в) уровней качества документов? г) форматов документов? д) обозначения документов?
Контрольные таблицы для управления документацией ПС ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93) А.3. КОНТРОЛЬНАЯ ТАБЛИЦА ПРОЦЕДУР Будут ли установлены для документирования процедуры: а) планирования? б) контроля? в) производства? г) проверок и утверждений? д) распространения? е) хранения оригинала и дубликата? ж) актуализации? и) продажи (распространения)?
Контрольные таблицы для управления документацией ПС ISO/IEC ТО 9294-90 (ГОСТ Р ИСО/МЭК ТО 9294-93) А.4. КОНТРОЛЬНАЯ ТАБЛИЦА ПЛАНИРОВАНИЯ ПРОЕКТА а) Будет ли создан план документирования, который включает в себя: типы, содержание, качество, форматы, условия для перевода документов? 2) графики документов? 3) ассигнования на документы? б) Будут ли определены ответственности за: подготовку документов? 2) проверку и утверждение документов? в) Будет ли штат обеспечен соответствующими средствами для задач документирования?
Практическое задание 1 Укажите документы управляющие каждым этапом разработки Вашего ПС и документы планируемые для создания по результатам каждого этапа (результаты одного этапа могут быть управляющими документами для другого). 2 Укажите критерии качества каждого получаемого в результате разработки Вашего ПС документа. Документирование программных средств
УПРАВЛЕНИЕ РАЗРАБОТКОЙ И АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА ЛЕКЦИЯ 12 Технология разработки программного обеспечения
Процессы жизненного цикла ПО, обеспечения ресурсами и управления по МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
Управление проектом разработки программного обеспечения по технологии IBM Rational Unified Process Предлагает 1 Структуру управления проектами 2 Практические рекомендации по планированию, укомплектованию персоналом, выполнению и мониторингу проектов 3 Структуру управления рисками
Включает следующие действия
Поток работ IBM Rational Unified Process: Управление проектом 1 Распределяет ресурсы 2 Определяет приоритеты 3 Координирует взаимодействие заказчиков с разработчиками 4 Руководит группой разработчиков и устанавливает регламенты работ
Поток работ IBM Rational Unified Process: Управление проектом 1 Общее описание ПС 2 Определение контекста предметной области для которой создается ПС 3 Определение цели создания ПС 4 Разработка финансового прогноза 5 Описание проектных ограничений (по имеющимся ресурсам)
Поток работ IBM Rational Unified Process: Управление проектом 1 Идентификация рисков 2 Группировка и сортировка рисков 3 Идентификация стратегий предотвращения рисков 4 Идентификация стратегий уменьшения рисков 5 Идентификация стратегий локализации рисков
Поток работ IBM Rational Unified Process: Управление проектом 1 Определение вех проекта 2 Определение целей вех 3 Определение количества и длины итераций в пределах стадий 4 Уточнение сроков вех и контекста предметной области создания ПС 5 Определение плана измерений Вехи – временные точки перехода от одной стадии разработки ПО к другой. Для перехода к новой стадии необходимо достигнуть все запланированные цели вех
Поток работ IBM Rational Unified Process: Управление проектом 1 Распределение потребностей в персонале по временным стадиям 2 Распределение обязанностей среди работников 3 Формирование групп разработчиков 4 Обучение персонала
Поток работ IBM Rational Unified Process: Управление проектом В RUP работник это не конкретная личность, работник – это понятие описывающее виды работ, которые личности могут выполнять
Поток работ IBM Rational Unified Process: Управление проектом 1 Определение рамок итерации 2 Определение критериев оценки итерации 3 Определение действий итерации 4 Распределение ответственности
Поток работ IBM Rational Unified Process: Управление проектом Выполнение плана итерации
Поток работ IBM Rational Unified Process: Управление проектом 1 Документирование результатов итерации 2 Оценка степени достижения запланированных результатов (оценочных показателей) 3 Документирование полученных уроков 4 Документирование изменений, которые необходимо выполнить в следующих итерациях
Оценка итерации заключается в определении успеха или неудачи итерации и в изучении собранных данных с целью изменения проекта или улучшения процессов разработки ПО
Поток работ IBM Rational Unified Process: Управление проектом Ревизия рисков
Поток работ IBM Rational Unified Process: Управление проектом
Поток работ IBM Rational Unified Process: Управление проектом Артефакты (документально оформляемые результаты) потока работ "Управление проектом"
Поток работ IBM Rational Unified Process: Управление проектом Rational Unified Process рекомендует разрабатывать два вида планов: 1 План проекта – разрабатывается один раз в начале всего проекта 2 Планы итераций – разрабатываются перед началом каждой итерации
Поток работ IBM Rational Unified Process: Управление проектом Вехи – временные точки перехода от одной стадии разработки ПО к другой. Для перехода к новой стадии необходимо достигнуть все запланированные цели вех Примерное соотношение времени по стадиям проекта
Поток работ IBM Rational Unified Process: Управление проектом Вехи – временные точки перехода от одной стадии разработки ПО к другой. Для перехода к новой стадии необходимо достигнуть все запланированные цели вех Определение целей вех один из результатов планирования проекта
Планирование итерации в стадии "Начало"
Планирование итерации в стадии "Уточнение"
Планирование итерации в стадии "Конструирование"
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ ОБЛАСТИ УПРАВЛЕНИЯ 2 ПЛАНИРОВАНИЕ 3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ 4 ПРОВЕРКА И ОЦЕНКА 5 ЗАВЕРШЕНИЕ Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ ОБЛАСТИ УПРАВЛЕНИЯ 2 ПЛАНИРОВАНИЕ 3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ 4 ПРОВЕРКА И ОЦЕНКА 5 ЗАВЕРШЕНИЕ Состав работ процесса “Менеджмент документации ПС” согласно МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
1 ПОДГОТОВКА И ОПРЕДЕЛЕНИЕ ОБЛАСТИ УПРАВЛЕНИЯ 1.1 Установление требований к управляемому процессу. 1.2 Определение возможностей реализации управляемого процесса, включая проверку наличия, соответствие и применимость ресурсов, для выполнения и управления процессом (персонал, материалы, технологии и условия), а также реальность сроков реализации процесса. 1.3 Изменение требований к управляемому процессу, при необходимости и по согласованию со всеми заинтересованными сторонами. Состав работ процесса “Управление” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
1 ПЛАНИРОВАНИЕ 1.1 Подготовка планов управляемого процесса. Состав работ процесса “Управление” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) При этом планы должны охватывать следующие вопросы: а) установление графиков своевременного решения задач; б) оценка необходимых трудозатрат; в) определение ресурсов, необходимых для выполнения задач; г) распределение задач по исполнителям; д) определение обязанностей исполнителей; е) определение критических ситуаций, связанных с задачами или самим процессом; ж) установление используемых в процессе критериев управления качеством; и) определение затрат, связанных с реализацией процесса; к) обеспечение условий и определение инфраструктуры и выполнения процесса.
3 ВЫПОЛНЕНИЕ И КОНТРОЛЬ Состав работ процесса “Управление” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 3.1 Начало реализации плана управляемого процесса. 3.2 Текущий надзор за выполнением плана управляемого процесса. 3.3 Исследование, анализ и решение проблем, обнаруженных при выполнении управляемого процесса. 3.4 Подготовка отчетов о реализации управляемого процесса.
4 ПРОВЕРКА И ОЦЕНКА Состав работ процесса “Управление” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 4.1 Оценка программных продуктов и планов процессов на соответствие установленным требованиям. 4.2 Проверка результатов оценок программных продуктов, работ и задач, реализуемых в ходе управляемого процесса, на соответствие поставленным целям и на выполнение утвержденных планов.
5 ЗАВЕРШЕНИЕ Состав работ процесса “Управление” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 5.1 Оценка степени соответствия всех программных продуктов созданных в результате выполнения управляемого процесса, а также всех работа и задач управляемого процесса критериям, установленным в договоре или организационной процедуре 5.2 Контроль результатов и полноты документации созданных программных продуктов и выполненных работ.
Практическое задание 1 Опишите в виде контекстной диаграммы IDEF0 входные и выходные данные, руководящие документы и инструменты необходимые для управления разработкой Вашего программного средства. 2 Укажите процессы и лица (должности) - поставщики входных данных, а также процессы и лица (должности) - потребители выходных данных. Управление разработкой программного средства Процессы-поставщики Лица - поставщики Процессы-потребители Лица - потребители
МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”
МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”
МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”
МЕЖДУНАРОДНЫЙ СТАНДАРТ “ISO 10006:2006. РУКОВОДСТВО ПО МЕНЕДЖМЕНТУ КАЧЕСТВА ПРИ ПРОЕКТИРОВАНИИ”
Подход к управлению качеством программного обеспечения КАЧЕСТВО ПРОЦЕССОВ УПРАВЛЕНИЯ КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Международные стандарты в области управления качеством КАЧЕСТВО ПРОЦЕССОВ УПРАВЛЕНИЯ: МС “ISO 9001:2008 (2000). Системы менеджмента качества. Требования”; МС “ISO/IEC 90003-2004. Руководство по применению стандарта ISO 9001:2000 для программных средств”; МС “ISO/IEC 90005-2008. Руководство по применению стандарта ISO 9001:2000 к процессам жизненного цикла программных средств”; МС “ISO/IEС 20000-1:2005. ИТ. Сервис менеджмент. Спецификация” (предоставление ИТ услуг)”; стандарт “Корпоративное управление ИТ” (COBIT) международной Ассоциации аудита и контроля информационных систем (ISACA). КАЧЕСТВО ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА: МС “ISO 12207:95 (2008). Процессы жизненного цикла ПО”; МС “ISO/IEC 15288:2008 . Процессы жизненного цикла систем”; МС “ISO/IEC 15504:2004. Оценка процессов. КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: МС “ISO/IEC 9126 . Оценка программного продукта. Характеристики качества и руководство по их применению”; -МС “ISO/IEC 25051:2006. Требования для качества готового коммерческого программного продукта и инструкция для испытаний”; - МС “ISO/IEC 14598. Оценка программного продукта”.
Модель системы менеджмента МС ISO 9001:2008
МС “ISO 9001:2008. СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА. ТРЕБОВАНИЯ”
Традиционная структура управления разработкой программных средств
Подходы к организации бригад разработчиков Неформальные демократические бригады Обычные бригады Бригады ведущего программиста Старший программист непосредственно руководит работой младших программистов Поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно Главная задача рядовых членов такой бригады - создать условия для наиболее продуктивной работы ведущего программиста
Методы оценки примитивов качества ПС Тестирование программ ПС Экспертная оценка на основании изучения программ и документации ПС Непосредственное измерение примитивов качества ПС Проверки соответствия документации, включая отчеты по результатам тестирований проведенных разработчиками Измерения времени работы различных устройств и используемых ресурсов при выполнении контрольных (тестовых) задач Тесты составляются, если у комиссии возникают определенные сомнения в полноте тестирования, проведенного разработчиками Полевые и промышленные испытания ПС Оценка требуемого примитива качества ПС устанавливается голосованием членов экспертной группы
Состав работ процесса “Аттестация” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ 2 АТТЕСТАЦИЯ
1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ Состав работ процесса “Аттестация” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 1.1 Определение необходимости аттестации и степень организационной независимости при проведении данных работ. 1.2 Если проект разработки ПО предусматривает работы по аттестации, должен быть установлен процесс аттестации для программного продукта. 1.3 Если проект разработки ПО предусматривает работы по независимой аттестации, должна быть выбрана квалифицированная организация, ответственная за проведение аттестации. 1.4 Разработка и документальное оформление план проведения аттестации. 1.5 Реализация плана проведения аттестации. Проблемы и несоответствия, обнаруженные при проведении аттестации, должны быть введены в процесс решения проблем.
1 ПОДГОТОВКА ПРОЦЕССА АТТЕСТАЦИИ Состав работ процесса “Аттестация” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) План проведения аттестации должен определять (но не ограничиваться): а) объекты, подлежащие аттестации; б) задачи, решаемые при аттестации; в) ресурсы, обязанности и график при проведении аттестации; г) процедуры передачи отчетов об аттестации заказчику и другим сторонам.
2 АТТЕСТАЦИЯ Состав работ процесса “Аттестация” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) 2.1 Подготовка выбранных требований к испытаниям (тестированию), контрольных примеров и технических условий испытаний к анализу результатов испытаний. 2.2 Обеспечение того, чтобы требования к испытаниям (тестированию), контрольные примеры и технические условия испытаний отражали конкретные требования к конкретным объектам аттестации. 2.3 Проведение испытаний, включая:
2 АТТЕСТАЦИЯ Состав работ процесса “Аттестация” согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99) Проведение испытаний, включает: а) испытания при критических, граничных и особых значениях исходных данных; б) испытание программного продукта на способность изолировать и минимизировать эффект ошибок с постепенным понижением влияния сбоев и запросом помощи оператора при критических, граничных и особых условиях; в) испытание при участии репрезентативно выбранных пользователей, могущих успешно решать свои задачи при использовании данного программного продукта; г) подтверждение того, что программный продукт удовлетворяет заявленным возможностям; д) испытание программного продукта в выбранных областях среды эксплуатации.
ОБЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНЫХ СРЕДСТВ ЛЕКЦИЯ 13 Технология разработки программного обеспечения
ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС 1 Объект – это воплощение некоторой сущности, которая имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с ним в каких-либо отношениях. 2 Объект может иметь внутреннюю структуру: состоять из других объектов, также находящихся между собой в некоторых отношениях. Можно построить иерархическое строение мира из объектов Исходя из этого
ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС Объект - сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса или копирования прототипа (например, после запуска результатов компиляции и связывания исходного кода на выполнение).
Пример объекта с именем “Стул” Состояние объекта ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Окружающий нас мир состоит из объектов и отношений между ними Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным) Объекты, которые могут быть связаны одним и тем же отношением называются объектами одного класса Свойства объектов можно определять по отношениям, в которых они могут участвовать Окружающий нас мир, можно рассматривать как иерархическую структуру модельных миров – миров различных объектов и классов объектов, из которых он состоит. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Представление объекта с именем Стул Простые свойства объекта (отношение связано с одним объектом “Стулом”) Ассоциативные свойства объекта (отношения связывают объект “Стул” с другими объектами: покупателями, продавцами и т.д.) Состояние объекта может быть изучено по значению его простых или ассоциативных свойств. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Неделимые ОБЪЕКТЫ Могут рассматривать, в зависимости от целей моделирования, как … Делимые Объект может иметь внутреннюю структуру: состоять из других объектов, находящихся между собой в некоторых отношениях ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС основывается на принципах: – абстрагирования; – инкапсуляции; – модульности; – иерархической организации. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС основывается на принципах: – абстрагирования; – инкапсуляции; – модульности; – иерархической организации. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС Абстрагирование — удобный инструмент для борьбы со сложностью ПС - рассмотрение только существенных для достижения целей разработки ПС характеристик объектов. ПРИМЕР: изучение в объекте - абстракции “часы” характеристики “показывать время”, и игнорировать характеристики: форма, цвет, материал, цена, изготовитель.
Пример абстракции Физический объект — датчик скорости, устанавливаемый на борту летательного аппарата. Обязанности датчика: – знать проекцию скорости летательного аппарата в заданном направлении; – показывать текущую скорость; – подвергаться настройке. Скорость и Направление — вспомогательные подтипы, обеспечивающие задание абстракции датчика состоящей из функции показывающих его основное назначения для пользователя: ДатчикСкорости { function НовыйДатчик (Направление) function ТекущаяСкорость (ДатчикСкорости) function Настраивать(Скорость)} ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Объектно-ориентированное представление ПС основывается на принципах: – абстрагирования; – инкапсуляции; – модульности; – иерархической организации. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС Инкапсуляция и абстракция — взаимодополняющие понятия: - абстракция выделяет внешнее поведение объекта; - инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение.
Объектно-ориентированное представление ПС основывается на принципах: – абстрагирования; – инкапсуляции; – модульности; – иерархической организации. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС Модульность определяет способность системы подвергаться декомпозиции на ряд сильно связанных и слабо сцепленных модулей.
Объектно-ориентированное представление ПС основывается на принципах: – абстрагирования; – инкапсуляции; – модульности; – иерархической организации. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС Иерархическая организация задает размещение абстракций на различных уровнях описания системы. Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются: – структура из классов; – структура из объектов.
Окружающий нас мир, можно рассматривать как иерархическую структуру модельных миров – миров различных объектов и классов объектов, из которых он состоит. Каждый объект информационно может быть представлен некоторой структурой данных, отображающей его состояние Для получение информации об отдельных свойствах объектов или результаты какого-либо взаимодействия между объектами модельного мира Для получения информации об изменении состояний объектов модельного мира в результате их взаимодействий Функциональный подход к разработке ПС Объектно-ориентированные подход к разработке ПС ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Каждый объект информационно может быть представлен некоторой структурой данных, отображающей его состояние Для получения информации об изменении состояний объектов модельного мира в результате их взаимодействий Объектно-ориентированные подход к разработке ПС Его сущность состоит в систематическом использовании декомпозиции объектов при описании и построении ПС. При этом функции, выполняемые ПС, выражаются через отношения объектов разных уровней. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Категории объектов Объекты модельного – вещественного мира Информационные модели объектов реального мира – пользовательские объекты Объекты процесса выполнения программ Объекты процесса разработки ПС – технологические объекты программирования Пассивные объекты Активные объекты Внутренняя активная сила Внешняя активная сила ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Категории объектов ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Специфические – "объектные" черты процессов разработки ПС: – использование системы понятий, позволяющих описывать объекты и их классы; – декомпозиция объектов является основным средством упрощения ПС; – использование внепрограммных абстракций для упрощения процессов разработки; – предпочтение разработки структуры данных перед реализацией функций. ОСНОВНАЯ ИДЕЯ ОБЪЕКТНОГО ПОДХОДА К РАЗРАБОТКЕ ПС
Классический жизненный цикл программного обеспечения 1 Определяет роль каждого элемента ПО и их взаимодействие в системе, в которой планируется применять ПО 2 Определяет технические требования к каждому элементу ПО 3 Определяются: архитектура, модульная структура, алгоритмическая структура, структуры данных, входной и выходной интерфейс 4 Результаты проектирования переводятся в текст языка программирования 6 Устранение ошибок и совершенствование ПО
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Исходные данные и результаты описания ПС Определение требований к ПС Описание требований ПС: функции (функциональная спецификация); свойства (спецификация качества). Кодирование ПС Документация по применению ПС Тесты для ПС
Структура спецификации ПС по требованиям МС IEEE 830-1998
Инструменты составления требований к ПС Инструменты составления требований к ПС Объектно-ориентированные Процессно-ориентированные Ориентированные на представление поведенческих характеристик Унифицированный процесс разработки объектно-ориентированных систем (RUP) и унифицированный язык моделирования (UML) Метод структурного анализа и моделирования (SADT) и диаграммы в формате IDEF0 Математические функции и конечные автоматы
Функциональная спецификация ПС при объектном подходе к его разработке Формальное описание модельного мира, состоящее из трех частей Объектной модели (статической модели) Динамической модели Функциональной модели Определяет то, что с чем-то случится Определяет, когда что-то случится Определяет то, что случилось Классы объектов и отношений между этими классами Объекты классов и отношения между объектами Имя класса/объекта Список атрибутов класса/объекта Список операций класса/объекта Связи объекта Ассоциации классов Взаимодействия Агрегирования Абстрагирования
Функциональная спецификация ПС при объектном подходе к его разработке Пример операций класса/ объекта
Функциональная спецификация ПС при объектном подходе к его разработке Связь агрегации
Примет Ассоциации “взаимодействия” Имеет столицу Примет Ассоциации “агрегирования”
Функциональная спецификация ПС при объектном подходе к его разработке Формальное описание модельного мира, состоящее из трех частей Объектной модели Динамической модели Функциональной модели Определяет то, что с чем-то случится Определяет, когда что-то случится Определяет то, что случилось События объектов Состояния объектов Диаграмма состояний
Диаграмма состояний системы охранной сигнализации Переход в начальное состояние Переход в конечное состояние Событие Операция Состояния
Диаграмма деятельности покупателя в интернет магазине
Диаграмма сотрудничества системы управления полетом
Диаграмма последовательности системы управления полетом
Диаграмма вариантов использования для обслуживания заказчика
Функциональная спецификация ПС при объектном подходе к его разработке Формальное описание модельного мира, состоящее из трех частей Объектной модели Динамической модели Функциональной модели Определяет то, что с чем-то случится Определяет, когда что-то случится Определяет то, что случилось Процессы Объекты Потоки данных Диаграммы потоков данных Функциональная модель показывает, как вычисляются выходные значения из входных без указания порядка, в котором эти значения вычисляются.
Процессы жизненного цикла ПО согласно МС ISO/IEC 12207:95 (ГОСТ Р ИСО/МЭК 12207:99)
Отношения: 1 Различается; 2 Различается; 3 Выбирается; 4 Агрегируется, 5 Состоит из видов; 6 Имеет; 7 Адресуется; 8 Реализуется; 9 Покрывает; 10 Устанавливает форму; 11 Состоит из моделей; 12 Содержит; 13 Убеждает; 14 Представляет; 15 Использует; 16 Имеет; 17 Размещена; 18 Обеспечивает) Модель разработки архитектуры программного средства МС “ISO ISO/IEC 42010:2007 (IEEE 1471)
Пример компонентой диаграммы
Представление интерфейса
Моделирование реализации системы
Моделирование реализации системы
Особенности объектно-ориентированного тестирования Программный модуль = Класс объектов Тестирование классов осуществляется путем тестирования экземпляров классов Тестовый драйвер Создает экземпляры классов и имитирует их окружение, посылая сообщения и обрабатывая получаемые данные Тестовые драйверы восходящем и заглушки применяемые при нисходящем тестировании Тестирование программных модулей
Особенности объектно-ориентированного тестирования Программный модуль = Класс объектов тестирование традиционных модулей ориентировано на поток управления внутри модуля и поток данных через интерфейс модуля тестирование классов ориентировано на операции, инкапсулированные в классе, и состояния в пространстве поведения класса Каждая операция выполняемая в программном модуле тестируется отдельно Каждая операция выполняемая в классе (программном модуле) тестируется с учетом особенностей ее применения подклассами
КОМПЬЮТЕРНАЯ ПОДДЕРЖКА РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ ЛЕКЦИЯ 14 Технология разработки программного обеспечения
Инструменты разработки ПС - Редакторы - Анализаторы - Преобразователи - Инструменты, поддерживающие процесс выполнения программ Программный инструмент – ПС предназначенное для поддержки разработки других ПС Аппаратный инструмент - устройство компьютера, специально предназначенное для поддержки разработки ПС Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов.
Инструменты разработки ПС - Редакторы - Анализаторы - Преобразователи - Инструменты, поддерживающие процесс выполнения программ Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов. Редакторы поддерживают конструирование (формирование) тех или иных программных документов (спецификаций ПС, функциональных и др. моделей, отчетов по тестированию и т.п.) на различных этапах жизненного цикла: - универсальные текстовые редакторы (MS Word и т.п.); - специализированные редакторы для каждого вида документов (например графические средства описания диаграмм, синтаксически управляемые редакторы ориентированные на используемый язык программирования и т.п.).
Редакторы поддерживают конструирование (формирование) тех или иных программных документов (спецификаций ПС, функциональных и др. моделей, отчетов по тестированию и т.п.) на различных этапах жизненного цикла: - универсальные текстовые редакторы (MS Word и т.п.); - специализированные редакторы для каждого вида документов (например графические средства описания диаграмм, синтаксически управляемые редакторы ориентированные на используемый язык программирования и т.п.).
Инструменты разработки ПС - Редакторы - Анализаторы - Преобразователи - Инструменты, поддерживающие процесс выполнения программ Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов. Анализаторы производят: статическую обработку документов, осуществляя различные виды их контроля, выявление определенных их свойств и накопление статистических данных (например, проверку соответствия документов указанным стандартам), - динамический анализ программ (например, с целью выявление распределения времени работы программы по программным модулям).
Инструменты разработки ПС - Редакторы - Анализаторы - Преобразователи - Инструменты, поддерживающие процесс выполнения программ Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов. Преобразователи позволяют автоматически: приводить документы к определенной форме представления (например, форматеры); переводить документ одного вида к документу другого вида (например, конверторы или компиляторы); - синтезировать какой-либо документ из отдельных частей и т.п.
Инструменты разработки ПС - Редакторы - Анализаторы - Преобразователи - Инструменты, поддерживающие процесс выполнения программ Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов. Инструменты, поддерживающие процесс выполнения программ, позволяют: выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода; выполнять машинный код с дополнительными возможностями его интерпретации: а) эмуляторы кода другого компьютера; б) отладчики.
Инструменты разработки ПС Компьютерная поддержка процессов разработки и сопровождения ПС может производиться не только за счет использования отдельных инструментов (редакторов, анализаторов, преобразователей и т.п.), но и за счет использования некоторой логически связанной совокупности программных и аппаратных инструментов. Инструментальная среда разработки и сопровождения ПС - логически связанная совокупность программных и аппаратных инструментов. Такая совокупность называется …
Инструментальные среды разработки и сопровождения ПС Разработка ПС производится на том же компьютере, на котором оно будет применяться Инструментально - объектный подход ПС разрабатывается компьютере, называемым инструментальным Применяется на компьютере, называемым целевым – Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС:
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Глобальная ориентированность: среда разработки ориентирована на один конкретный язык программирования, за счет этого обеспечивается полный (глобальный) охват всех операций языка программирования; Локальная ориентированность: среда разработки ориентирована на несколько языков программирования, но при этом охватывает только некоторые из их операций – операции общие для них всех языков охваченных средой разработки.
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Специализированность среды разработки для предметной области: инструменты разработки ПС существенно используют знание об определенной предметной области, в силу чего они оказываются более удобными для использования или предоставляют дополнительные возможности при разработке ПС для этой предметной области. Отсутствие специализации среды разработки для разных предметных областей: - инструменты разработки ПС поддерживают лишь самые общие операции для разных предметных областей.
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Степень охвата процессов разработки ПС
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Ориентированность среды разработки на определенную технологию программирования: - содержание информационной среды, а также набор инструментов существенно зависит от выбранной технологии (например, Rational Unified Process, Microsoft Solution Framework, Oracle и т.п.). Не ориентированность среды разработки на определенную технологию программирования: - инструментальная среда поддерживает самые общие операции разработки ПС, не зависящие от выбранной технологии программирования.
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Инструментальная среда считается интегрированной, если взаимодействие пользователя с разными инструментами разработки ПС подчиняется единообразным правилам, а сами инструменты действуют по заранее заданной информационной схеме, связаны по управлению или имеют общие части.
– Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную технологию программирования – Ориентированность на коллективную разработку – Интегрированность Признаки инструментальных сред разработки и сопровождения ПС: Интегрированность по пользовательскому интерфейсу означает, что все инструменты объединены единым пользовательским интерфейсом. Интегрированность по данным означает, что инструменты действуют в соответствии с установленной моделью системы, определяющей зависимость друг от друга различных модулей системы. Интегрированность по действиям означает, что: в системе имеются общие части всех инструментов; - одни инструменты при выполнении своих функций могут обращаться к другим инструментам.
Признаки инструментальных сред разработки и сопровождения ПС – Ориентированность на конкретный язык программирования – Специализированность – Комплексность – Ориентированность на конкретную ТРПО – Ориентированность на коллективную разработку – Интегрированность Глобальная ориентированность Локальная ориентированность Среда ориентирована или нет на предметную область Среда поддерживает все или нет процессы разработки и сопровождения ПС Среда ориентированана фиксированную ТРПО или нет Среда поддерживает или нет управление (management) коллективом Интегрированность по: пользовательскому интерфейсу; данным (предполагает наличие репозитария); - действиям. Инструментальная система - инструментальная среда, интегрированная по данным или по действиям
Классы инструментальных сред программирования Инструментальные среды разработки и сопровождения ПС Инструментальные среды программирования Инструментальные системы технологии программирования Рабочие места компьютерной технологии
Предназначены для … – кодирования; – тестирования; – отладки ПС. Могут обладать следующими признаками …
Предназначены для … – системного анализа; – спецификации ПС; – автоматической генерации программ по спецификациям. Могут обладать следующими признаками …
Инструменты разработки ПС… Рабочие места компьютерной технологии Конструкторы пользовательских интерфейсов Инструмент работы со словарем именованных сущностей Графические и тестовые редакторы спецификаций Анализаторы спецификаций Генератор программ Документаторы Системный анализ Спецификации ПС; Автоматическая генерация программ по спецификациям
Предназначены для … поддержки всех процессов разработки и сопровождения в течение всего жизненного цикла ПС и ориентирована на коллективную разработку больших программных систем с продолжительным жизненным циклом Обязательно обладают следующими признаками …
Инструментальные системы технологии программирования
Предназначены для … – кодирования; – тестирования; – отладки ПС. Инструментальные среды программирования Общего назначения (не ориент. на яз. прогр.) Ориентированные на конкретный язык программирования Интерпретирующие Синтаксически -управляемые
Инструментальные среды программирования Общего назначения (не ориент. на яз. прогр.) Ориентированные на конкретный язык программирования Интерпретирующие Синтаксически -управляемые Интерпретирующая инструментальная среда программирования обеспечивает интерпретацию программ на языке программирования, т.е. содержит, прежде всего, интерпретатор языка программирования, на который эта среда ориентирована. Такая среда необходима для языков программирования интерпретирующего типа (таких, как Лисп), но может использоваться и для других языков (например, на инструментальном компьютере).
Инструментальные среды программирования Общего назначения (не ориент. на яз. прогр.) Ориентированные на конкретный язык программирования Интерпретирующие Синтаксически -управляемые Синтаксически-управляемая инструментальная среда программирования базируется на знании синтаксиса языка программирования, на который она ориентирована. В такой среде вместо текстового используется синтаксически-управляемый редактор, позволяющий пользователю использовать различные шаблоны синтаксических конструкций (в результате этого разрабатываемая программа всегда будет синтаксически правильной). Одновременно с программой такой редактор формирует (в памяти компьютера) ее синтаксическое дерево, которое может использоваться другими инструментами.
CASE - Computer Aided Software Engineering - программная инженерия с компьютерной поддержкой. Основные усилия в разработке программного обеспечения до внедрения CASE-технологий … после внедрения CASE-технологий …
Изменения основных усилий в разработке программного обеспечения после внедрения CASE-технологий МС ISO/IEC 12207:95 МС ISO/IEC 12207:95
Изменения основных усилий в разработке программного обеспечения после внедрения CASE-технологий Появилась возможность: формирования формальных функциональных спецификаций программ с возможностью автоматической генерации кода; - формирования формальных спецификаций архитектуры ПС с возможность автоматической генерации программ; автоматической генерации части документации, необходимой разработчикам и пользователям; автоматической генерации тестов по формальным спецификациям для комплексной – системной отладки ПС; - автоматического изменения содержания программ по изменениям в спецификациях.
Жизненный цикл ПС при применении CASE-технологий
Критерии выбора CASE-средств
Технологии разработки программного обеспечения ведущих IT-компаний ЛЕКЦИИ 15 - 16 Технология разработки программного обеспечения
Унифицированный процесс разработки программного обеспечения и разработка в стиле экстремального программирования
Спиральная модель процессов жизненного цикла ПО 1 — начальный сбор требований и планирование проекта; 2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета; 8 — сконструированная система; 9 — оценивание заказчиком
Типовая итерация унифицированного процесса разработки программного обеспечения
Два измерения унифицированного процесса разработки
Модели – документы создаваемые на разных стадиях унифицированного процесса разработки (RUP) ПО
Модели унифицированного процесса разработки программного обеспечения – бизнес-модель. Определяет абстракцию организации, для которой создается система; – модель области определения. Фиксирует контекстное окружение системы; – модель Use Case – вариантов использования. Определяет функциональные требования к системе; – модель анализа. Интерпретирует требования к системе в терминах проектной модели; – проектная модель. Определяет словарь проблемы и ее решение; – модель размещения. Определяет аппаратную топологию, в которой исполняется система; – модель реализации. Определяет части, которые используются для сборки и реализации физической системы; – тестовая модель. Определяет тестовые варианты для проверки системы; – модель процессов. Определяет параллелизм в системе и механизмы синхронизации.
Технические артефакты унифицированного процесса разработки программного обеспечения – набор требований. Описывает, что должно делать система; – набор проектирования. Описывает, как должна быть спроектирована система; – набор реализации. Описывает сборку разработанных программных компонентов; – набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.
Архитектура RUP
Управление рисками в унифицированном процессе разработки ПО где: – RE — показатель риска (Risk Exposure — подверженность риску); – P(UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome); – L(UO) — потеря при неудовлетворительном результате. RE = P(UO) x L(UO), УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ: оценивание риска: – идентификация риска — выявление элементов риска в проекте; – анализ риска — оценка вероятности и величины потери по каждому элементу риска; – ранжирование риска — упорядочение элементов риска по степени их влияния; контроль риска: – планирование управления риском — подготовка к работе с каждым элементом риска; – разрешение риска — устранение или разрешение элементов риска; – наблюдение риска — отслеживание динамики элементов риска, выполнение корректирующих действий.
Управление рисками в унифицированном процессе разработки ПО Выделяют три категории источников риска: – проектный риск; – технический риск; – коммерческий риск.
Управление рисками в унифицированном процессе разработки ПО Пример, проверочного списка десяти главных элементов программного риска: – дефицит персонала; – нереальные расписание и бюджет; – разработка неправильных функций и характеристик; – разработка неправильного пользовательского интерфейса; – слишком дорогое обрамление; – интенсивный поток изменения требований; – дефицит поставляемых компонентов; – недостатки в задачах, разрабатываемых смежниками; – дефицит производительности при работе в реальном времени; – деформирование научных возможностей.
Управление рисками в унифицированном процессе разработки ПО где: – RE — показатель риска (Risk Exposure — подверженность риску); – P(UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome); – L(UO) — потеря при неудовлетворительном результате. RE = P(UO) x L(UO), УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ: оценивание риска: – идентификация риска — выявление элементов риска в проекте; – анализ риска — оценка вероятности и величины потери по каждому элементу риска; – ранжирование риска — упорядочение элементов риска по степени их влияния; контроль риска: – планирование управления риском — подготовка к работе с каждым элементом риска; – разрешение риска — устранение или разрешение элементов риска; – наблюдение риска — отслеживание динамики элементов риска, выполнение корректирующих действий.
Управление рисками в унифицированном процессе разработки ПО RE = P(UO)xL(UO) P(UO) L(UO)
Управление рисками в унифицированном процессе разработки ПО где: – RE — показатель риска (Risk Exposure — подверженность риску); – P(UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome); – L(UO) — потеря при неудовлетворительном результате. RE = P(UO) x L(UO), УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ: оценивание риска: – идентификация риска — выявление элементов риска в проекте; – анализ риска — оценка вероятности и величины потери по каждому элементу риска; – ранжирование риска — упорядочение элементов риска по степени их влияния; контроль риска: – планирование управления риском — подготовка к работе с каждым элементом риска; – разрешение риска — устранение или разрешение элементов риска; – наблюдение риска — отслеживание динамики элементов риска, выполнение корректирующих действий.
Управление рисками в унифицированном процессе разработки ПО RE = P(UO)xL(UO) P(UO) L(UO)
Управление рисками в унифицированном процессе разработки ПО где: – RE — показатель риска (Risk Exposure — подверженность риску); – P(UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome); – L(UO) — потеря при неудовлетворительном результате. RE = P(UO) x L(UO), УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ: оценивание риска: – идентификация риска — выявление элементов риска в проекте; – анализ риска — оценка вероятности и величины потери по каждому элементу риска; – ранжирование риска — упорядочение элементов риска по степени их влияния; контроль риска: – планирование управления риском — подготовка к работе с каждым элементом риска; – разрешение риска — устранение или разрешение элементов риска; – наблюдение риска — отслеживание динамики элементов риска, выполнение корректирующих действий.
Управление рисками в унифицированном процессе разработки ПО где: – RE — показатель риска (Risk Exposure — подверженность риску); – P(UO) — вероятность неудовлетворительного результата (Unsatisfactory Outcome); – L(UO) — потеря при неудовлетворительном результате. RE = P(UO) x L(UO), УПРАВЛЕНИЕ РИСКОМ ВКЛЮЧАЕТ ШЕСТЬ ДЕЙСТВИЙ: оценивание риска: – идентификация риска — выявление элементов риска в проекте; – анализ риска — оценка вероятности и величины потери по каждому элементу риска; – ранжирование риска — упорядочение элементов риска по степени их влияния; контроль риска: – планирование управления риском — подготовка к работе с каждым элементом риска; – разрешение риска — устранение или разрешение элементов риска; – наблюдение риска — отслеживание динамики элементов риска, выполнение корректирующих действий.
Практическое задание 1 Определите два-три основных риска в разработке Вашего программного средства. 2 Определите критерии разрешения рисков. Выделяют три категории источников риска: – проектный риск; – технический риск; – коммерческий риск. Унифицированный процесс разработки программного обеспечения (RUP)
Два измерения унифицированного процесса разработки
Цели этапа НАЧАЛО: – определить область применения проектируемой системы: а) предназначение; б) границы; в) интерфейсы с внешней средой; г) критерий признания — приемки; – определить элементы Use Case – диаграмм вариантов использования, критические для системы: а) основные сценарии поведения, задающие ее функциональность и покрывающие главные проектные решения; – определить общие черты архитектуры, обеспечивающей основные сценарии, создать демонстрационный макет; – определить общую стоимость и план всего проекта и обеспечить детализированные оценки для этапа развития; – идентифицировать основные элементы риска. Два измерения унифицированного процесса разработки
Два измерения унифицированного процесса разработки Основные действия этапа НАЧАЛО: – формулировка области применения результатов проекта разработки ПС; – планирование и подготовка начального бизнес-плана проекта разработки ПС и альтернатив его развития; – определение персонала, необходимого для реализации плана проекта разработки ПС; – выявление зависимостей между стоимостью, планированием и полезностью ПС; – получение предварительной архитектуры ПС – развитие компромиссных решений проектирования, определение решений: разработки, покупки и повторного использования ПС.
Два измерения унифицированного процесса разработки Результаты этапа НАЧАЛО - следующие артефакты: – спецификация представления основных проектных требований, ключевых характеристик и главных ограничений; – начальная модель Use Case (20% от полного представления) и начальный словарь проекта; – начальный бизнес-план проекта, включающий: а) содержание бизнеса, б) критерий успеха — прогноз дохода, прогноз рынка, финансовый прогноз; – начальное оценивание рисков проекта; – план проекта разработки ПС, в котором показаны этапы и итерации.
Два измерения унифицированного процесса разработки
Два измерения унифицированного процесса разработки Цели этапа РАЗВИТИЕ: – определить оставшиеся требования; – определить архитектуру ПС; – отслеживать риски и устранять источники наибольших из них; – разработать план итераций этапа КОНСТРУИРОВАНИЕ. В итоге этапа РАЗВИТИЕ создаются следующие артефакты: – модель Use Case (80% от полного представления); – описание архитектуры ПС; – выполняемый макет ПС; – пересмотренный список элементов риска и пересмотренный бизнес-вариант; - план этапа КОНСТРУИРОВАНИЕ.
Два измерения унифицированного процесса разработки
Два измерения унифицированного процесса разработки Цели этапа КОНСТРУИРОВАНИЕ: – минимизировать стоимость разработки путем оптимизации ресурсов и устранения необходимости доработок; – добиться быстрого получения приемлемого качества; – добиться быстрого получения контрольных версий (альфа, бета и т. д.). Основные действия этапа КОНСТРУИРОВАНИЕ: – управление ресурсами, контроль ресурсов, оптимизация процессов; – полная разработка компонентов и их тестирование; – оценивание реализаций продукта по критериям качества. В итоге этапа КОНСТРУИРОВАНИЕ создаются следующие артефакты: – программный продукт, готовый для передачи в руки конечных пользователей; – описание текущей реализации; – руководство пользователя.
Два измерения унифицированного процесса разработки
Два измерения унифицированного процесса разработки Главное назначение этапа ПЕРЕХОД — применить программный продукт в среде пользователей и завершить реализацию ПС. Этап начинается с предъявления пользователям: - бета-реализации продукта; - в ней обнаруживаются ошибки, которые затем корректируются; - параллельно решаются вопросы размещения, упаковки и сопровождения ПС; - после завершения периода тестирования продукт считается реализованным.
Практическое задание Определите критерии (вехи) перехода разработки Вашего программного средства между разными временными этапами RUP.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап НАЧАЛО Разрабатывается Оконный интерфейс пользователя(WUI) - представляет из себя среду, управляемую событиями Действия в среде инициируются функциями обратного вызова, которые вызываются в ответ на событие — пользовательский ввод Ядром WUI является цикл обработки событий, который организуется МЕНЕДЖЕРОМ ВВОДА. WUI должен обеспечивать следующие типы неперекрывающихся окон: – простое окно, в которое может быть выведен текст; – окно меню, в котором пользователь может задать вариант действий; — выбор подменю или функции обратного вызова. Общее описание ПС
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап НАЧАЛО Идентификация актеров
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап НАЧАЛО Идентификация элементов Use Case Описание элемента Use Case Управление окнами. Действия начинаются администратором системы. Администратор может создать, удалить или модифицировать окно. Описание элемента Use Case Использование окон. Действия начинаются пользователем прикладной программы. Обеспечивается возможность работы с меню и простыми окнами.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case; – диаграммы последовательности (формализующие текстовые представления сценариев); – классы и диаграммы классов; – планы следующих этапов разработки.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case. – первый сценарий – Создание окна: Шаг1 – устанавливаются координаты окна на экране и стиль рамки окна; Шаг2 – образ окна сохраняется в памяти; Шаг3 – окно выводится на экран; Шаг4 – если создается окно меню, содержащее обращение к функции обратного вызова, то происходит установка этой функции; Шаг5 – менеджер окон добавляет окно в список управляемых окон WUI.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case. – второй сценарий – Изменение стиля рамки: Шаг1 – указывается символ, с помощью которого будет изображаться рамка; Шаг2 – образ окна сохраняется в памяти; Шаг3 – окно перерисовывается на экране.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case. – третий сценарий – Сценарий Уничтожение окна: Шаг1 – менеджер окон получает указание удалить окно; Шаг2 – менеджер окон снимает окно с регистрации (в массиве управляемых окон WUI); Шаг3 – окно снимает отображение с экрана.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case. – четвертый сценарий – Использование окна Шаг1 – символ воспринимается менеджером ввода; Шаг2 – в зависимости от значения введенного символа выполняется один из следующих вариантов: а) при значении ENTER – вариант ОКОНЧАНИЯ ВВОДА; б) при переключающем значении – вариант ПЕРЕКЛЮЧЕНИЯ; г) при обычном значении – символ выводится в активное окно.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case; – диаграммы последовательности (формализующие текстовые представления сценариев); – классы и диаграммы классов; – планы следующих этапов разработки.
Этап РАЗВИТИЕ Пример разработки в рамках унифицированного процесса разработки ПО – первый сценарий – Создание окна: Шаг1 – устанавливаются координаты окна на экране и стиль рамки окна; Шаг2 – образ окна сохраняется в памяти; Шаг3 – окно выводится на экран; Шаг4 – если создается окно меню, содержащее обращение к функции обратного вызова, то происходит установка этой функции; Шаг5 – менеджер окон добавляет окно в список управляемых окон WUI. – значащие существительные превращаются в объекты, – значащие глаголы превращаются в сообщения, пересылаемые между объектами.
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ – второй сценарий – Изменение стиля рамки: Шаг1 – указывается символ, с помощью которого будет изображаться рамка; Шаг2 – образ окна сохраняется в памяти; Шаг3 – окно перерисовывается на экране.
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ – третий сценарий – Сценарий Уничтожение окна: Шаг1 – менеджер окон получает указание удалить окно; Шаг2 – менеджер окон снимает окно с регистрации (в массиве управляемых окон WUI); Шаг3 – окно снимает отображение с экрана.
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ Диаграмма последовательности сценария “Использование простого окна”
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ Диаграмма последовательности сценария “Использование окна меню”
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case; – диаграммы последовательности (формализующие текстовые представления сценариев); – классы и диаграммы классов На первом этапе выявляются и именуются классы. На втором этапе выявляются операции классов. На третьем этапе определяются отношения ассоциации между классами
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ Создание классов и диаграмм классов На первом этапе выявляются и именуются классы. Класс: Window_Manager
Пример разработки в рамках унифицированного процесса разработки ПО Этап РАЗВИТИЕ Создание классов и диаграмм классов Класс: Window_Manager На втором этапе выявляются операции классов. Операция класса Window_Manager: add_to_list()
Этап РАЗВИТИЕ Пример разработки в рамках унифицированного процесса разработки ПО Иерархия классов Оконного интерфейса пользователя (WUI) – Window — класс, объектами которого являются простые окна; – Menu — класс, объектами которого являются окна меню. Этот класс является потомком класса Window; – Menu_title — класс, объектом которого является окно главного меню. Класс является потомком класса Menu; – Screen — класс, объектом которого является экран. Этот класс обеспечивает позиционирование курсора, вывод изображения на экран дисплея, очистку экрана; – Input_Manager — объект этого класса управляет взаимодействием между пользователем и окнами интерфейса. Его обязанности: начальные установки среды WUI, запуск цикла обработки событий, закрытие среды WUI; – Window_Manager — осуществляет общее управление окнами, отображаемыми на экране. Используется менеджером ввода для получения доступа к конкретному окну.
Этап РАЗВИТИЕ Пример разработки в рамках унифицированного процесса разработки ПО Иерархия классов Оконного интерфейса пользователя (WUI) На третьем этапе определяются отношения ассоциации между классами Создание классов и диаграмм классов
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ На этом этапе создаются: – текстовые сценарии для элементов Use Case; – диаграммы последовательности (формализующие текстовые представления сценариев); – классы и диаграммы классов; – планы следующих этапов разработки.
Пример разработки в рамках унифицированного процесса разработки программного обеспечения Этап РАЗВИТИЕ Итерация 1 — реализация сценариев элемента Use Case Управление окнами: – Шаг1 – Создание окна; – Шаг2 – Уничтожение окна; – Шаг3 – Изменение стиля рамки. Итерация 2 — реализация сценариев элемента Use Case Использование окон: – Шаг1 -Использование простого окна; – Шаг2 -Использование окна меню. Реализация элемента Use Case несущая максимальный риск для ПС Плана итераций этапа КОНСТРУИРОВАНИЕ
Два измерения унифицированного процесса разработки
CASE-средства RUP IBM Rational Rose – Моделирование (поддержка прямой и обратной разработки) IBM Rational Requisite Pro – Управление требованиями (фиксация, организация, ранжирование и прослеживаемость) IBM Rational SoDA – Управление документацией IBM Rational Apex/Ada, IBM Rational C++/Java – Программирование Microsoft Project, IBM Rational ClearQuest – Управление разработкой IBM Rational ClearCase – Управление конфигурацией IBM Rational SQA Suite, IBM Rational TestMate, IBM Rational Visual Test – Тестирование
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process Цель Обеспечить разработчиков соответствующей средой – процессами и инструментальными средствами
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process ДЕЙСТВИЯ ПОТОКА РАБОТ “СРЕДА”
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
Управление СРЕДОЙ разработки программного обеспечения по технологии IBM Rational Unified Process
XP – процесс разработки программного обеспечения
XP – процесс разработки программного обеспечения Цель XP -процесса Подход не запланированных улучшений. Возможные значительные потери вызванные пересмотром требований к ПС после каждой итерации Предполагает Сократить потери вызванные применением эволюционной модели при использовании ее преимуществ
XP – процесс разработки программного обеспечения Цель XP -процесса Сократить потери вызванные применением эволюционной модели при использовании ее преимуществ Для достижения такого эффекта применяются … ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА Тестирование Непрерывная интеграция Надежность кода Синхронность работы разработчиков Дает… Дает…
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА Тестирование Непрерывная интеграция Заключается в … Интеграция кода разных частей программы по нескольку раз в день Успешное прохождение тестов Быстрое выявление проблем в работе программного средства, как цельной системы Позволяет… Заключается в … Тестирование всех разрабатываемых частей программного кода по нескольку раз в день, часто с привлечением заказчиков Позволяет… Является условием …
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА Тестирование Непрерывная интеграция Позволяет применять… РЕФРАКТОРИНГ (переработка кода) Непрерывное улучшение программного кода, без изменения его функционального назначения Еще одна ПРАКТИКА (ПРИЕМ, МЕТОД) XP-процесса
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА ТЕСТИРОВАНИЕ НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ РЕФРАКТОРИНГ (переработка кода) Позволяют применять… ПРОСТОТА ПРОЕКТИРОВАНИЯ 1 ПС не следует проектировать заблаговременно целиком и полностью. 2 Проектирование необходимо выполнять постоянно в течение всего времени работы над созданием ПС. 3 В каждый момент времени необходимо использовать наиболее простые решения, которые подходит для решения текущих задач Еще одна ПРАКТИКА (ПРИЕМ, МЕТОД) XP-процесса
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА ТЕСТИРОВАНИЕ НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ РЕФРАКТОРИНГ (переработка кода) Позволяют применять… ИГРА В ПЛАНИРОВАНИЕ Быстрое формирование приблизительных планов работ по выпуску следующих одной или нескольких небольших версий ПС Еще одна ПРАКТИКА (ПРИЕМ, МЕТОД) XP-процесса Отвечает за принятие бизнес -решений Отвечает за принятие технических решений Заказчик Команда разработчиков При этом требуется соблюдение следующих условий … ЗАКАЗЧИК-ПОЛЬЗОВАТЕЛЬ ВСЕГДА РЯДОМ Позволяет применять…
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА ТЕСТИРОВАНИЕ НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ РЕФРАКТОРИНГ (переработка кода) Позволяют применять… ПРОСТОТА ПРОЕКТИРОВАНИЯ ИГРА ПЛАНИРОВАНИЯ ЗАКАЗЧИК-ПОЛЬЗОВАТЕЛЬ ВСЕГДА РЯДОМ ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ 1 Версии продукта должны поступать в эксплуатацию как можно чаще. 2 Чем раньше мы выпустим первую рабочую версию продукта, тем раньше заказчик начнет получать за счет нее дополнительную прибыль. 3 Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует его требованиям, а что — нет.
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА ТЕСТИРОВАНИЕ НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ РЕФРАКТОРИНГ (переработка кода) Позволяют применять… ПРОСТОТА ПРОЕКТИРОВАНИЯ ИГРА ПЛАНИРОВАНИЯ ЗАКАЗЧИК-ПОЛЬЗОВАТЕЛЬ ВСЕГДА РЯДОМ МЕТАФОРА ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ 1 Аналог того, что в большинстве методик называется архитектурой. 2 Метафора системы дает команде разработчиков представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты и какую форму они должны принять. 3 Представляется в виде небольшой истории работы ПС.
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА ТЕСТИРОВАНИЕ НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ РЕФРАКТОРИНГ (переработка кода) Позволяют применять… ПРОСТОТА ПРОЕКТИРОВАНИЯ ИГРА ПЛАНИРОВАНИЯ ЗАКАЗЧИК-ПОЛЬЗОВАТЕЛЬ ВСЕГДА РЯДОМ МЕТАФОРА ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ ЕДИНЫЕ СТАНДАРТЫ КОДИРОВАНИЯ КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ КОДОМ 1 Каждый член команды несёт ответственность за весь исходный код. 2 Таким образом, каждый вправе вносить изменения в любой участок программы. 40 -ЧАСОВАЯ РАБОЧАЯ НЕДЕЛЯ
ПРАКТИКИ (ПРИЕМЫ, МЕТОДЫ) XP - ПРОЦЕССА 1 Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. 2 Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. 3 В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды. ПАРНОЕ ПРОГРАММИРОВАНИЕ
4 ПАРНОЕ ПРОГРАММИРОВАНИЕ 8 ПРОСТОТА ПРОЕКТИРОВАНИЯ 2 ИГРА ПЛАНИРОВАНИЯ 3 ЗАКАЗЧИК-ПОЛЬЗОВАТЕЛЬ ВСЕГДА РЯДОМ 9 МЕТАФОРА 7 ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ 10 ЕДИНЫЕ СТАНДАРТЫ КОДИРОВАНИЯ 11 КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ КОДОМ 12 40-ЧАСОВАЯ РАБОЧАЯ НЕДЕЛЯ 1 ТЕСТИРОВАНИЕ 5 НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ 6 РЕФРАКТОРИНГ Короткий цикл обратной связи Непрерывный, а не пакетный процесс Понимание разделяемое всеми Социальная защита Структуры XP-реализации
XP – процесс разработки программного обеспечения Основные особенности XP-процесса Структуры XP-итерация
XP – процесс разработки программного обеспечения Основные особенности XP-процесса Структура элемента XP-разработки
XP – процесс разработки программного обеспечения Основные особенности XP-процесса Организация коллективного владения кодом
Практическое задание Выпишите в один столбик достоинства XP-процесса в сравнении со Спиральной моделью разработки ПО, а в другой недостатки.
SCRUM – процесс разработки программного обеспечения
Технология SCRUM Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Технология SCRUM СПРИНТ - итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель На протяжении СПРИНТА никто не имеет права менять список требований к работе, внесенном в резерв проекта
Технология SCRUM РЕЗЕРВ ПРОЕКТА — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items) Резерв проекта открыт для редактирования для всех участников SCRUM процесса
Технология SCRUM Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта РЕЗЕРВ СПРИНТА — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте. Диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).
Технология SCRUM По технологии SCRUM в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур». Эти названия были использованы из-за шутки: Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»
Технология SCRUM Основные роли в методологии СКРАМ («СВИНЬИ») «СВИНЬИ» ПОЛНОСТЬЮ ВКЛЮЧЕНЫ В ПРОЕКТ И В СКРАМ-ПРОЦЕСС. СКРАМ-МАСТЕР — проводит совещания, следит за соблюдением всех принципов СКРАМ, разрешает противоречия и защищает команду от отвлекающих факторов. Владелец проекта — представляет интересы конечных пользователей и других заинтересованных в продукте сторон. СКРАМ-КОМАНДА — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое.
Технология SCRUM Дополнительные роли в СКРАМ («КУРЫ») Пользователи (Users) Клиенты, Продавцы — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту. Управляющие (Managers) — люди, которые управляют персоналом. Эксперты-консультанты (Consulting Experts)
Технология SCRUM Средства управления проектами поддерживающие СКРАМ: Banana Scrum CollabNet ScrumWorks Pro Hansoft en:IBM Rational Team Concert Ice Scrum Kunagi JetBrains YouTrack JIRA с использованием плагина Green Hopper Mingle, ThoughtWorks Studios OneDesk PangoScrum Pivotal Tracker Rally Software Redmine and ChiliProject с использованием плагинов ScrumDo ScrumPad Pro Scrumwise Scrumy Sprintometer TargetProcess Tinypm VersionOne Visual Studio 2010, Microsoft Team Foundation Server Yodiz
Технология разработки программного обеспечения ORACLE
Метод разработки прикладного ПО (CDM - Custom Development Method) Метод управления проектами (PJM - Project Management Method) Метод внедрения прикладного ПО (AIM - Application Implementation Method) Библиотека стандартов и руководств по разработке ПО Технология разработки программного обеспечения ORACLE Включает комплекс методов Метод реинжиниринга бизнес-процессов (BPR - Business Process Reengineering) Метод управления изменениями (OCM - Organizational Change Management) Содержит стандарты и руководства по применению всех остальных методов ORACLE
Метод разработки прикладного ПО (CDM - Custom Development Method) Технология разработки программного обеспечения ORACLE Включает … Определяет следующую модель процессов жизненного цикла ПО
Модель процессов жизненного цикла ПО ORACLE 1 Цели создания ПС 2 Приоритеты и ограничения 3 Архитектура ПС 4 План разработки ПС Определяются и разрабатываются
Модель процессов жизненного цикла ПО ORACLE 1 Модель информационных потребностей (диаграмма "сущность-связь") 2 Диаграмма функциональной иерархии (на основе функциональной декомпозиции системы) 3 Матрица перекрестных ссылок 4 Диаграмма потоков данных Строятся
Модель процессов жизненного цикла ПО ORACLE 1 Подробная архитектура ПС 2 Схема реляционной БД 3 Программные модули 4 Перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями Разрабатываются и проектируются
Модель процессов жизненного цикла ПО ORACLE 1 Прикладные системы 2 Тестирование ПС 3 Проверка качества и соответствия ПС требованиям пользователей 4 Системная документация, материалы для обучения и руководства пользователей. Строятся, выполняются и создаются
Модель процессов жизненного цикла ПО ORACLE 1 Производительность и целостность ПС 2 Поддержка и, при необходимости, модификация ПС Анализируется и выполняется
Модель процессов жизненного цикла ПО ORACLE Выделяется два основных подхода к реализации процессов жизненного цикла Классический (по аналогии с классическим подходом к разработке ПО) Быстрой разработки (итерационный подход) При этом остается 4-е этапа разработки
Oracle Developer Suite включает в себя: 1 Oracle Designer – средство моделирования и генерации приложений; 2 Oracle Forms - средство быстрой разработки приложений; 3 Oracle Reports - визуальное средство разработки отчетов; 4 Oracle JDeveloper - средство визуального программирования на языке Java; 5 Oracle Discoverer - средство для разработки аналитических приложений; 6 Oracle Warehouse Builder - система для построения хранилищ данных; 7 Oracle Portal - средство разработки информационного портала организации.
Модель процессов жизненного цикла ПО ORACLE Процессы жизненного цикла унифицированного процесса разработки ПО IBM Rational (RUP) Процессы жизненного цикла ПО ORACLE
Технология разработки программного обеспечения MICROSOFT SOLUTION FRAMEWORK (MSF)
Технология разработки программного обеспечения MSF Включает … Модель процессов жизненного цикла ПО Контрольные точки Этапы
Общие сведения о технологии разработки программного обеспечения MSF 1 Модель процессов MSF представляет собой сочетание водопадной и спиральной моделей. 2 В модели процессов МSF объединены контрольные точки и итерационный метод. 3 В модели команд MSF определены шесть ролей: - Менеджер решения; Менеджер программы; Разработчик; Тестировщик; Менеджер по выпуску; Специалист по удобству использования продукта. 4 Область действия проекта определяется в процессе управления компромиссами. 5 В MSF рекомендован итерационный подход к проектированию решений. 6 Итерации в жизненном цикле разработки реализуются в виде регулярных версий или за счет поддержки обновляемых документов.
Технология разработки программного обеспечения BORLAND
Технология разработки программного обеспечения BORLAND Включает Модель процессов жизненного цикла программного обеспечения BORLAND и CASE-средства их поддержки
Менеджмент модели жизненного цикла программного обеспечения по требованиям ISO\IEC 12207-2008
Процессы жизненного цикла ПО, обеспечения ресурсами и управления по МС ISO/IEC 12207:2008 (ГОСТ Р ИСО/МЭК 12207-2010)
Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008 6.2.1.1 Цель Цель процесса менеджмента модели жизненного цикла заключается в определении, сопровождении и обеспечении гарантии наличия политик, процессов жизненного цикла, моделей жизненного цикла и процедур для использования организацией в пределах области применения настоящего стандарта. Данный процесс предусматривает политики, процессы и процедуры жизненного цикла, согласованные с целями организации, которые определяются, адаптируются, совершенствуются и сопровождаются для поддержки отдельных потребностей проекта в пределах задач и функций организации и которые готовы к применению с использованием эффективных испытанных методов и инструментария.
6.2.1.2 Выходы В результате успешного осуществления процесса менеджмента модели жизненного цикла: a) предоставляются политики и процедуры менеджмента и развертывания моделей и процессов жизненного цикла; b) определяются обязанности, ответственность и полномочия менеджмента жизненного цикла; c) определяются, сопровождаются и совершенствуются процессы, модели и процедуры жизненного цикла для применения организацией; d) осуществляется процесс усовершенствований в порядке установленных приоритетов. Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008
Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008 6.2.1.3 Виды деятельности и задачи Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента модели жизненного цикла. 6.2.1.3.1 Учреждение процессов 6.2.1.3.2 Оценка процессов 6.2.1.3.3 Совершенствование процессов
Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008 6.2.1.3 Виды деятельности и задачи Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента модели жизненного цикла. 6.2.1.3.1 Учреждение процессов 6.2.1.3.1.1 Организация должна учредить совокупность организационных процессов для всех процессов и моделей жизненного цикла программных средств, используемых в деловой деятельности. Эти процессы и их применение в конкретных случаях должны документироваться в публикациях организации. При необходимости следует установить механизм управления процессами при разработке, мониторинге, управлении и совершенствовании процессов.
Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008 6.2.1.3 Виды деятельности и задачи Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента модели жизненного цикла. 6.2.1.3.2 Оценка процессов 6.2.1.3.2.1 Организации следует разработать, документировать и применять процедуру оценки процессов. Записи об оценках необходимо осуществлять и поддерживать. 6.2.1.3.2.2 Организация должна планировать и осуществлять ревизии процессов через определенные интервалы времени для гарантии того, что процессы остаются пригодными и результативными в свете результатов проведения оценок.
Процесс менеджмента процессов жизненного цикла ПО в соответствии с ISO\IEC 12207:2008 6.2.1.3 Виды деятельности и задачи 6.2.1.3.3 Совершенствование процессов 6.2.1.3.3.1 Организация должна проводить такие улучшения своих процессов, какие она посчитает необходимыми по результатам оценки и ревизии процессов. Процесс документирования следует также обновлять для отражения улучшений в организационных процессах. 6.2.1.3.3.2 Исторические, технические данные, а также данные оценивания следует накапливать и анализировать для усиления понимания сильных и слабых сторон применяемых процессов. Этот анализ следует использовать в качестве обратной связи для совершенствования процессов, выработки рекомендаций по изменениям в текущих или последующих проектах и определения потребностей в передовых технологиях. 6.2.1.3.3.3 Данные о затратах на качество следует накапливать, сопровождать и использовать для совершенствования процессов организации, обусловленных действиями ее руководства. Эти данные должны служить цели установления затрат как на предупреждение, так и на разрешение проблем и несоответствий в программных продуктах и услугах.
15062-01_04_2012_var2_pka_trpo.ppt
- Количество слайдов: 488