Программа по формированию навыков безопасного поведения на дорогах и улицах «Добрая дорога детства» 2
Скачать 1.39 Mb.
|
23 терфейса преследует цель выделить и сконцентрировать внимание разработчика на важных аспектах интерфейса и абстрагироваться (не учитывать) второстепенные или несущественные стороны разрабатываемого интерфейса. Поэтому набор состояний интерфейса выбирает сам разработчик и это он делает интуитивно, исходя из своего опыта разработки. Над параметрами интерфейса могут совершаться некоторые действия, в частности, перевод интерфейса из одного состояния в другое. Множество всех возможных действий обозначим {£}. Поведение интерфейса описывается множеством событий {е^}. События делятся на временные и условные события. Временное событие представляет собой пару (tj,fj), где t; - время выполнения действия fj. Условное событие представляет собой пару (Cj,fj), где с, - условие над параметрами интерфейса (например, параметр «Форма Ф1 активна» = «истина»). Действия пользователя (нажатие кнопки, активизация окна и т.д.) ведут к изменению параметров интерфейса и рассматриваются, соответственно, как условия в условных событиях. Таким образом, выделяя параметры и задавая им значения, мы определяем внешний вид интерфейса в статике, а, определяя события, мы описываем поведение интерфейса в динамике. База данных интерфейсов  Диалог по выбору и настройке макета интерфейса База данных элементов интерфейсов Модель прикладной программы Программируемый имитатор внешней среды (ПИВС) Рис. 4. Функционально-структурная схема технологического программного комплекса для макетирования интерфейсов прикладных программных систем. 24 Построив макет интерфейса прикладной программной системы, можно приступить к анализу и сбору замечаний и предложений по его развитию. После доведения макета интерфейса до приемлемого для всех заинтересованных сторон (как правило, это представители заказчика, разработчики и, возможно, сторонние эксперты) уровня он может быть использован в качестве основы для разработки интерфейсной подсистемы создаваемой программы. При этом разработанный макет интерфейса выступает в роли прототипа. Это сокращает сроки и трудоемкость создания интерфейсных подсистем и, соответственно, прикладных программ в целом. 3.2.4 Пример интерфейса и имитационной модели для построения его макета Рассмотрим интерфейс, состоящий из трех форм. Форма «Ф-1» имеет в нижней части три кнопки: «Закрыть», «Ф-2», «Ф-3». Через пять секунд после ее открытия по центру формы появляется надпись о значении времени в момент ее открытия. Формы «Ф-2» и «Ф-3» имеют в нижней части кнопку «Ф-1». При нажатии на кнопку «Закрыть» форма «Ф-1» закрывается. При нажатии кнопки «Ф-2» на форме «Ф-1» появляется форма «Ф-2», форма «Ф-1» при этом убирается с экрана. При нажатии кнопки «Ф-3» на форме «Ф-1» открывается форма «Ф-3», форма «Ф-1» при этом закрывается. При нажатии кнопки «Ф-1» на форме «Ф-2» (или на форме «Ф-3») появляется форма «Ф-1», форма «Ф-2» (или форма «Ф-3») при этом исчезает с экрана. Этот интерфейс в статике можно описать следующими параметрами: р! - значение сообщения на форме «Ф-1»; р2 - размер формы «Ф-1»; рЗ - размер формы «Ф-2»; р4 - размер формы «Ф-3»; р5 - текущее значение времени; рб - размер кнопки «Закрыть» на форме «Ф-1» и т.д. Выделим следующие состояния интерфейса: si - форма «Ф-1» открыта, формы «Ф-2» и «Ф-3» закрыты; s2 - форма «Ф-2» открыта, формы «Ф-1» и «Ф-3» закрыты; s3 - форма «Ф-3» открыта, формы «Ф-1» и «Ф-2» закрыты; s4 - формы «Ф-1», «Ф-2» и «Ф-3» закрыты. Текущее время будем обозначать t Интервал времени в пять секунд обозначим как At 1. Выделим следующие условия: cl - «начало работы?»; 25 с2 - «нажата кнопка «Закрыть» на форме «Ф-1»?»; сЗ - «нажата кнопка «Ф-2» на форме «Ф-1»?»; с4 - «нажата кнопка «Ф-3» на форме «Ф-1»?»; с5 - «нажата кнопка «Ф-1» на форме «Ф-2»?»; сб - «нажата кнопка «Ф-1» на форме «Ф-3»?». Выделим следующие действия; fl - переход в состояние si, pl=p5, установка временного события (t+Atl, f5); f2 - переход в состояние s2; f3 - переход в состояние s3; f4 - переход в состояние s4; f5 - печать значения параметра р! на форме «Ф-1». Зададим множество событий, описывающих интерфейс в динамике: (cl, fl) - открытие формы «Ф-1» при запуске программы-макета интерфейса, установка временного события (t+Atl, f5); (с2, f4) - закрытие формы «Ф-1» и окончание работы программы-макета интерфейса; (сЗ, f2) - закрытие формы «Ф-1» и открытие формы «Ф-2»; (с4, f3) - закрытие формы «Ф-1» и открытие формы «Ф-3»; (с5, fl) - открытие формы «Ф-1», закрытие формы «Ф-2», установка временного события (t+Atl, f5); (сб, fl) - открытие формы «Ф-1», закрытие формы «Ф-3», установка временного события (t+Atl, f5). 3.2.5 Функционально-структурная схема прикладной программы Каждая прикладная программа имеет собственную архитектуру. Функционально-структурная схема один из способов представления архитектуры программы. Функционально-структурная схема - это перечень подсистем и (или) модулей, из которых состоит программа с указанием выполняемых ими функций и связей между ними и описанием взаимодействия этих модулей и подсистем в процессе работы программы. Для большей наглядности, обычно, функционально-структурная схема иллюстрируется графическим рисунком. На рисунке каждый модуль и подсистема изображаются в виде прямоугольников, внутри которых помещают их названия, а связи - направленными линиями. 3.2.6 Книга «Справочное руководство» Составление информационной части (аннотации и оглавления) является обязательным. Справочное руководство должно содержать следующие разделы: 26
В зависимости от особенностей программы допускается объединять отдельные разделы или вводить новые. Подробнее о разработке справочного руководства см. в разделе 12.2.2.5. 3.2.7 Книга «Руководство пользователя» Составление информационной части (аннотации и оглавления) является обязательным. Руководство пользователя должно содержать следующие разделы:
В зависимости от особенностей программы допускается объединять отдельные разделы или вводить новые. Подробнее о разработке руководства пользователя см. в разделе 12.2.2.7. 3.2.8 Сопровождение прикладной программы В технологии Оберон-2000 сопровождение прикладной программы осуществляется с помощью специально разработанной для этой цели программы управления запросами на изменение разрабатываемых прикладных программ Oberon-Improvement. Программа Oberon-Improvement представляет собой специализированную базу данных, в которой фиксируются все замечания и пожелания к разрабатываемым программам. Эти замечания и пожелания высказывают в первую очередь пользователи этих программ. Но в формировании требований на изменение прикладных программ также принимают участие и разработчики, и тестировщики и руководство и владельцы компаний. Каждое замечание, будем называть его запросом, записывается в базу данных в виде отдельной строки и имеет следующие реквизиты:
27 Для управления поступившими запросами существует понятие состояние запроса. При поступлении запроса он переходит в состояние «Зарегистрирован». Затем его рассматривает руководитель группы сопровождения прикладных программ, и запрос переходит либо в состояние «Назначен на исполнение», либо «Отложен». Также имеются и другие состояния запроса: «Выполнен», «Требуется дополнительное рассмотрение», «Требуется уточнение», «В архив». Для отслеживания процесса сопровождения прикладных программ ежедневно, еженедельно и ежемесячно формируются отчеты, в которых отражается следующая информация:
С программой Oberon-Improvement можно познакомиться на сайте научно-исследовательской группы «Оберон» www.OberonCo.da.Ru. Учебный вариант программы Oberon-Improvement приведен на лазерном диске, прилагаемом к данному учебному пособию (Приложение 3). 3.3 Особенности применения экстремальных технологий При использовании экстремальных методологий ключевой становится роль менеджера проекта. Опытный руководитель нередко интуитивно чувствует неполадки в ходе работ. Подобная интуиция основана на подсознательном анализе различных факторов в процессе создания программы. К ним относятся следующие показатели:
Перед использованием экстремальных методологий надо постараться определить, будет ли сам проект экстремальным или же можно обойтись классическим подходом. Проект может считаться экстремальным, например, в случае, если сроки очень сжаты, а требования сформулированы неточно. 28 4. Оценка и аттестация процессов создания и сопровождения прикладных программ В начале 1990-х годов американский институт по программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model). Эта модель определила уровни технологической зрелости и их отличительные черты. К настоящему времени СММ прошла апробацию в целом ряде организаций. Ее эффективность и достоверность проверили заказывающие организации, поставщики готовых тиражируемых программных средств и компании, разрабатывающие заказное программное обеспечение, компании, занимающиеся аутсорсингом и оффшорным программированием. Сегодня компания-разработчик испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что по способу работы исполнитель не может оказать некачественную услугу. Оценка технологической зрелости компаний может использоваться:
4.1 Аттестация организаций-разработчиков прикладных программ Основой для аттестации процессов разработки и сопровождения прикладного программного обеспечения является международный стандарт ИСО/МЭК ТО 15504. 4.1.1 Стандарт ИСО/МЭК ТО 15504 Стандарт ИСО/МЭК ТО 15504 состоит из девяти частей. Первая часть (информационная) является отправной точкой стандарта ИСО/МЭК ТО 15504. Она описывает взаимодействие частей и содержит руководство по их выбору и использованию. Она разъясняет требования, содержащиеся в стандарте ИСО/МЭК ТО 15504 и их применимость к проведению аттестаций. Вторая часть (нормативная) стандарта ИСО/МЭК ТО 15504 определяет двухмерную эталонную модель для описания процессов и их зре- 29 4. Оценка и аттестация процессов создания и сопровождения прикладных программ В начале 1990-х годов американский институт по программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model). Эта модель определила уровни технологической зрелости и их отличительные черты. К настоящему времени СММ прошла апробацию в целом ряде организаций. Ее эффективность и достоверность проверили заказывающие организации, поставщики готовых тиражируемых программных средств и компании, разрабатывающие заказное программное обеспечение, компании, занимающиеся аутсорсингом и оффшорным программированием. Сегодня компания-разработчик испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что по способу работы исполнитель не может оказать некачественную услугу. Оценка технологической зрелости компаний может использоваться:
4.1 Аттестация организаций-разработчиков прикладных программ Основой для аттестации процессов разработки и сопровождения прикладного программного обеспечения является международный стандарт ИСО/МЭК ТО 15504. 4.1.1 Стандарт ИСО/МЭК ТО 15504 Стандарт ИСО/МЭК ТО 15504 состоит из девяти частей. Первая часть (информационная) является отправной точкой стандарта ИСО/МЭК ТО 15504. Она описывает взаимодействие частей и содержит руководство по их выбору и использованию. Она разъясняет требования, содержащиеся в стандарте ИСО/МЭК ТО 15504 и их применимость к проведению аттестаций. Вторая часть (нормативная) стандарта ИСО/МЭК ТО 15504 определяет двухмерную эталонную модель для описания процессов и их зре- 29 лости, использующуюся при аттестации процессов. Эталонная модель определяет ряд процессов, определенных в терминах их назначения и итогов, а также основу для оценивания зрелости процессов посредством аттестации атрибутов процессов, структурированных по уровням зрелости. Также в ней определены требования для установления совместимости различных аттестационных моделей с эталонной моделью. Третья часть (нормативная) стандарта ИСО/МЭК ТО 15504 определяет требования для проведения аттестации таким образом, чтобы результаты были воспроизводимыми, надежными и согласующимися. Четвертая часть (информационная) стандарта ИСО/МЭК ТО 15504 содержит руководство по проведению аттестаций процессов жизненного цикла программных средств, по интерпретации требований стандарта ИСО/МЭК ТО 15504-2 для различных контекстов аттестации. Пятая часть (информационная) стандарта ИСО/МЭК ТО 15504 содержит пример модели для проведения аттестации процесса. |
