- •Тюменский государственный университет
- •Предисловие 7 методические материалы 9
- •Теоретические материалы 27 Глава 1. Методология разработки и стандартизации 27
- •Глава 2. Создание модели процессов в bpWin 95
- •Глава 3. Создание модели данных в erWin 121
- •Предисловие
- •Методические материалы Рабочая программа дисциплины Пояснительная записка
- •Содержание дисциплины
- •Рекомендации по самостоятельной работе Календарно-тематический план самостоятельной работы
- •Методические рекомендации по отдельным видам самостоятельной работы
- •Указания по самостоятельному изучению теоретической части дисциплины
- •Указания по выполнению контрольной работы
- •Указания по выполнению курсовой работы
- •Указания к промежуточной аттестации с применением балльно-рейтинговой системы оценки знаний
- •1.1.2. Классы программ
- •1.1.3. Архитектура программных средств
- •1.2. Стандартизация жизненного цикла программных средств
- •1.2.1. Уровни стандартизации
- •1.2.2. Основные модели жизненного цикла
- •1.2.2.1. Каскадная модель
- •1.2.2.2. Каскадная модель с промежуточным контролем
- •1.2.2.3. Модель разработки программных средств на основе ранее созданных компонентов
- •1.2.2.4. Эволюционная модель
- •1.2.2.5. Модель пошаговой разработки программных средств
- •1.2.2.6. Спиральная модель
- •1.2.2.7. Спиральная модель с ограничением версий
- •1.2.3. Структурное программирование
- •1.2.4. Организация человеко-машинного интерфейса
- •1.2.4.1. Принципы разработки
- •2. Учет возможностей аппаратных и программных средств разработчика и пользователя.
- •1.2.4.2. Рекомендации разработчику
- •1.3. Оценка стоимости и планирование разработки программных средств
- •1.3.1. Оценка стоимости разработки
- •1.3.2. Планирование разработки
- •1.4. Качество программных средств
- •1.4.1. Стандарты качества
- •1.4.2. Основные показатели качества
- •1.4.3. Методы достижения качества
- •1.4.4. Сертификация и аттестация
- •1.4.5. Конфигурационное управление версиями
- •1.4.6. Регламентирование тестирования для обеспечения качества
- •1.4.6.1. Цели и этапы тестирования программ
- •1.4.6.2. Основные тестируемые элементы
- •1.4.6.3. Восходящее и нисходящее тестирование
- •1.5. Методология быстрой разработки приложений (rad)
- •1.6. Структурный подход к проектированию информационных систем
- •1.6.1. Сущность структурного подхода
- •1.6.2. Моделирование потоков данных (бизнес-процессов) dfd
- •Отчет о продажах
- •1.6.3. Функциональное моделирование sadt (idef0)
- •1.6.3.1. Состав функциональной модели
- •1.6.3.2. Иерархия диаграмм
- •1.6.4. Моделирование данных
- •1.6.4.1. Основные понятия
- •1.6.4.2. Методология idef1
- •1.7. Общая характеристика и классификация case-средств
- •1. Компонентный состав:
- •2. Функциональная полнота:
- •3. Степень зависимости от субд:
- •4. Тип используемой модели:
- •1.8. Интеллектуализация вычислительных систем
- •1.9. Рынок программных продуктов
- •Структура рынка программных продуктов и услуг
- •1.10. Классификация систем защиты программных средств
- •1.10.1. Методы установки
- •1.10.2. Методы защиты
- •1.10.3. Принципы функционирования
- •1.10.4. Показатели оценки систем защиты
- •В опросы для контроля
- •Глава 2. Создание модели процессов в bpWin
- •2.1. Среда разработки
- •2.2. Функциональная модель (idef0)
- •2.2.1. Принципы построения модели
- •2.2.2. Работы
- •2.2.3. Стрелки
- •2.2.4. Нумерация работ и диаграмм
- •2.2.5. Диаграммы дерева узлов и экспозиций (feo)
- •2.2.6. Слияние моделей
- •2.2.7. Разделение моделей
- •2.2.8. Отчеты по модели
- •2.2.9. Экспертиза и согласование модели
- •2.3. Оценка модели
- •2.3.1. Стоимостной анализ (abc)
- •2.3.2. Анализ свойств, определенных пользователем (udp)
- •2.4. Дополнительные модели
- •2.4.1. Диаграммы потоков данных (dfd)
- •2.4.2. Диаграммы информационных процессов (idef3)
- •2.4.3. Имитационное моделирование
- •Вопросы для контроля
- •Глава 3. Создание модели данных в erWin
- •3.1. Отображение модели данных
- •3.1.1. Модели представления данных
- •3.1.2. Среда разработки
- •3.1.3. Подмодели и сохраняемые отображения
- •3.2. Создание логической модели данных
- •3.2.1. Уровни логической модели
- •3.2.2. Сущности и атрибуты
- •3.2.3. Связи
- •3.2.4. Типы сущностей и иерархия наследования (супертипы, подтипы)
- •3.2.5. Ключи
- •3.2.6. Методы нормализации и денормализации отношений
- •3.2.7. Домены
- •3.3. Создание физической модели данных
- •3.3.1. Уровни физической модели
- •3.3.2. Выбор субд
- •3.3.3. Таблицы и представления
- •3.3.4. Правила проверки значений и значения по умолчанию
- •3.3.5. Индексы
- •3.3.6. Объекты физической памяти
- •3.3.7. Триггеры и хранимые процедуры
- •3.3.8. Хранилища данных
- •3.3.9. Определение размера базы данных
- •3.3.10. Прямое и обратное проектирование
- •3.4. Создание отчетов в erWin
- •3.5. Связывание моделей процессов и модели данных
- •3.5.1. Экспорт данных из erWin в bpWin
- •3.5.2. Создание сущностей и атрибутов bpWin и их экспорт в erWin
- •В опросы для контроля
- •Глава 4. Генератор отчетов rptWin
- •4.1. Создание нового отчета
- •4.2. Среда конструктора отчетов
- •4.3. Размещение объектов отчета
- •4.4. Группировка и сортировка данных отчета
- •4.5. Изменение файла данных отчета
- •4.6. Изменение свойств отчета
- •4.7. Формирование формул
- •4.8. Пример формирования отчета
- •В опросы для контроля
- •Заключение
- •Практикум
- •Задания для контроля Тесты для самоконтроля
- •Ключи к тестам для самоконтроля
- •Пример выполнения контрольной работы
- •Темы контрольных и курсовых работ
- •1. Учет успеваемости студентов.
- •2. Учет обмена валюты.
- •3. Учет объектов строительства.
- •4. Учет выдачи и возврата книг.
- •5. Учет авиапассажиров.
- •6. Учет производства сельскохозяйственных культур.
- •7. Учет выпуска изделий.
- •8. Учет платежей налогов.
- •9. Учет поставок товаров.
- •10. Учет сбросов отравляющих веществ в окружающую среду.
- •11. Учет уволившихся с предприятия.
- •12. Учет призеров Олимпийских игр.
- •14. Учет участников олимпиады.
- •15. Учет проданных товаров.
- •16. Учет малых предприятий.
- •17. Учет больных в больнице.
- •18. Учет движения общественного транспорта.
- •19. Учет дорожно-транспортных происшествий.
- •20. Учет платежных поручений в банке.
- •21. Учет договоров займа.
- •22. Учет проданных ценных бумаг.
- •23. Учет кадров.
- •24. Учет очередников на получение жилья.
- •25. Учет исполнительской дисциплины.
- •26. Учет книг в библиотеке.
- •27. Учет переселенцев.
- •28. Учет успеваемости школьников.
- •29. Учет нарушителей трудовой дисциплины на предприятии.
- •30. Учет вакцинации населения.
- •Вопросы для подготовки к экзамену
- •Список источников информации
- •Приложения Приложение 1. Стандарты Приложение 1.1. Международный стандарт жизненного цикла
- •1. Процесс приобретения
- •2. Разработка системы и программного средства
- •3. Эксплуатация системы и программного средства
- •4. Сопровождение и развитие системы и программного средства
- •5. Управление проектом и обеспечение качества системы и программного средства
- •6. Интегральные процессы поддержки разработки программных средств
- •Приложение 1.2. Стандарты качества
- •Приложение 1.3. Стандарты по тестированию программ
- •Приложение 1.4. Государственные стандарты рф
- •Приложение 1.5. Единая система программной документации (гост 19)
- •2. Эскизный проект
- •3. Технический проект
- •4. Рабочий проект
- •5. Внедрение
- •Приложение 1.6. Автоматизированные системы управления (гост 24)
- •Приложение 1.7. Автоматизированные системы (гост 34)
- •Приложение 2. Список макрокоманд erWin
- •Приложение 3. Список макрокоманд erWin
1.4.2. Основные показатели качества
Существуют множество различных классификаций показателей качества, задаваемых различными стандартами. Для примера приведем следующую классификацию.
Функциональная пригодность – степень соответствия комплекса реализованных программ исходным требованиям контракта, технического задания (назначение, номенклатура, задач и функций) и спецификаций на программное средство и его компоненты. Путем верификации должно быть определено соответствие исходным требованиям всей совокупности компонентов комплекса программ, вплоть до модулей и текстов программ и описаний данных. В наибольшей степени функциональная пригодность проявляется в корректности и надежности ПС.
Рассмотрим основные показатели.
Функциональная корректность ПС. Зависит от функциональной корректности применяемых компонент, методов их достижения и оценивания: детерминировано, стохастические и в реальном времени.
Корректность структуры программ определяется корректностью структуры модулей и корректностью структуры групп программ, построенных из модулей. Для оценки корректности структуры программ используется несколько частных показателей, различающихся степенью охвата тестами структурных компонент программы при отладке. Проверка корректности структурных компонент производится статистически по исходным текстам программ.
Корректность обработки данных определяется степенью отладки процесса обработки представительной выборки значений переменных в диапазонах их изменения.
Корректность межмодульных связей и взаимодействия компонент. Взаимодействие программ определяется двумя видами связей между модулями: по управлению и по информации.
Связи по управлению составляют вызовы программных модулей и возвраты в вызывавшие. Каждая связь модуля по управлению может содержать ошибку и являться причиной одного из видов некорректностей:
отсутствие вызова необходимого взаимодействующего модуля;
вызов модуля, не подлежащего исполнению при данном вызове;
возврат управления от вызванного к вызывающему модулю в точку, не предназначенную для возврата управления.
Ошибки при взаимодействии модулей по управлению в ПС приводят к пропуску выполнения отдельных функций или к их значительным искажениям. Такие некорректности влияют на результаты функционирования ПС и полностью должны быть устранены.
Взаимодействие модулей по информации может происходить через обменные переменные, непосредственно подготавливаемые и используемые соседними модулями, или через глобальные переменные. Связи каждого модуля через глобальные переменные могут осуществляться с большим числом модулей, каждый из которых может рассчитывать или использовать некоторую переменную.
Детерминированная корректность программ определяется по частоте отклонения конкретных вычисляемых результатов от эталонных значений, заданных в техническом задании или в иных исходных документах.
Стохастическая корректность характеризуется величиной статистического отклонения распределений и их параметров (средних значений, среднеквадратических отклонений) от заданных эталонов. При этом не оценивается каждый результат тестирования, а они обобщаются и оцениваются интегрально по некоторой достаточно представительной выборке.
Корректность в реальном времени определяется величиной максимального или усредненного отклонения траектории выходных параметров от заданной эталонной траектории обработки тестовых исходных данных. Результаты тестирования оцениваются интегрально на некотором временном интервале или по наибольшему отклонению от эталонной траектории.
Для подтверждения абсолютной корректности программ достаточным в пределе является полный перебор всех входных и выходных тестовых значений переменных во всех их сочетаниях, что представляет только теоретический интерес. Достаточный объем тестирования реально никогда не оценивается, а процессы отладки строятся с позиции необходимого минимума тестов, обеспечивающих корректность в предполагаемых наиболее активных режимах эксплуатации программ.
Мобильность или переносимость программ в иную операционную среду или в иную среду по архитектуре компьютера. Может оцениваться объемом необходимых доработок ПС, которые следует выполнить для обеспечения полноценного функционирования ПС после переноса. Мобильность может оцениваться на уровне исходных текстов программ или на уровне объектного кода.
Надежность программ – это способность выполнять заданные функции в различных условиях. Надежность является внутренним свойством систем, проявляющимся только во времени. Причиной нарушения работоспособности программ при безотказности аппаратуры всегда является наличие ошибок в программе и/или конфликт между реальными исходными данными, подлежащими обработке, и программой, осуществляющей эту обработку. Для оценки числа ошибок в программе сущеcтвуют различные модели. Приведем две модели оценки числа ошибок в программе (N), в которых вероятность обнаружения ошибок одинаковы и не зависит от времени и сложности причин, вызвавших ошибки. В модели Миллса вносятся S искусственных ошибок. Тогда, n/N=s/S (где n и s число реальных и искусственных найденных ошибок при тестировании соответственно) и N=n*S/s. В простой интуитивной модели программу тестируют две группы тестировщиков. Тогда n1/N=n2/N=n12/n1 (где, n1, n2, n12 – число всех ошибок обнаруженных первой и второй группами и обеими группами соответственно) и N=n1*n2/n12. Работоспособность ПС можно гарантировать при исходных данных, которые использовались при отладке и испытаниях. Реальные исходные данные могут иметь значения, отличающиеся от заданных техническим заданием и от использованных при тестировании. При таких исходных данных функционирование программ трудно предсказать заранее, и поэтому весьма вероятны различные аномалии, завершающиеся отказами.
Рассмотрим основные показатели надежности.
Устойчивость наиболее широко характеризует способность к безотказному функционированию после произошедших сбоев. Она зависит от уровня неустраненных ошибок и способности ПС реагировать на проявления ошибок так, чтобы это не отражалось на показателях надежности. Последнее определяется эффективностью контроля за доступом к данным, степенью обеспечения их секретности и сохранности, а также селекцией достоверных данных, поступающих из внешней среды (живучесть), и средствами обнаружения аномалий функционирования ПС.
Восстанавливаемость характеризуется полнотой восстановления функционирования программ после перезапуска-рестарта. Перезапуск должен обеспечивать возобновление нормального функционирования ПС, на что требуются ресурсы компьютера и время. Поэтому полнота и длительность восстановления функционирования после сбоев отражают качество ПС и возможность его использования по прямому назначению.
Коэффициент готовности – отражает вероятность иметь восстанавливаемую систему в работоспособном состоянии в произвольный момент времени. Значение коэффициента готовности соответствует времени полезной работы системы на достаточно большом интервале, содержащем как отказы, так и восстановления.
Защищенность ПС включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы (ISO 15408:1999-1-3)
Эффективность использования ресурсов. Перечислим основные показатели эффективности.
Временная экономичность ПС. Определяется длительностью выполнения заданных функций.
Время реакции (отклика) ПС на запросы для полного решения основных функциональных задач.
Пропускная способность системы ПС и компьютера. Отражает число сообщений или запросов на решение определенных задач, обрабатываемых в единицу времени, зависящую от некоторого показателя внешней среды.
Ресурсная экономия отражает количество и степень занятости ресурсов центрального процессора, оперативной, внешней и виртуальной памяти, каналов ввода-вывода, терминалов и каналов локальной сети. Для корректного определения предельной пропускной способности информационной системы с данным программным средством нужно измерить экстремальные и средние значения длительностей исполнения функциональных групп программ и маршруты, на которых они достигаются.
Способность к взаимодействию состоит в определении качества совместной работы компонентов программных средств и баз данных с другими прикладными системами и компонентами на различных вычислительных платформах, а также взаимодействия с пользователями в стиле, удобном для перехода от одной вычислительной системы к другой с подобными функциями.
Удобство использования ПС – группа показателей, отражающих понятность, обучаемость и простоту (комфортность) использования.
Понятность ПС можно описать четкостью концепции, широтой демонстрационных возможностей и наглядностью представления возможных функций.
Обучаемость можно оценить длительностью подготовки пользователя к полноценной эксплуатации ПС. Это время зависит от возможности предварительного обучения и совершенствования в процессе эксплуатации, от возможной оперативной помощи и подсказки при использовании ПС, а также от доступности и удобства пользования руководствами и инструкциями по эксплуатации.
Комфортность эксплуатации ПС отражает простоту и удобство его использования и оценивается степенью учета физических и психологических характеристик пользователей. Они характеризуют: легкость управления ПС и объем параметров управления, реализуемых по умолчанию; информативность сообщений пользователю и унифицированность управления экраном; степень доступности изменения функций в соответствии с квалификацией пользователя; число операций, необходимых для запуска определенного задания. Кроме того, удобство использования характеризуется рядом динамических параметров: временем ввода и отклика на задание, длительностью решения типовых задач, временем на регистрацию результатов. В основном это качественная и субъективная оценка в баллах, однако, некоторые атрибуты можно оценить количественно по трудоемкости и длительности выполнения операций при использовании программного средства, а также по объему документации, необходимой для их изучения.
Сопровождаемость можно оценивать полнотой и достоверностью документации о состояниях программного средства и его компонентов, всех предполагаемых и выполненных изменениях, позволяющей установить текущее состояние версий программ в любой момент времени и историю их развития. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов на программы и данные.
Мобильности - качественное определение экспертами адаптируемости, простоты установки, совместимости и замещаемости программ, выражаемое в баллах. Количественно эту характеристику программного средства и совокупность ее атрибутов можно оценить в экономических показателях: стоимости, трудоемкости и длительности реализации процедур переноса на иные платформы определенной совокупности программ и данных.