Файл: Учебное пособие.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 04.12.2020

Просмотров: 6716

Скачиваний: 15

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Введение

1.Введение в технологии разработки программного обеспечения

1.1.Основные этапы развития технологии разработки

1.1.1.Первый этап – «стихийное» программирование.

1.1.2.Второй этап – структурный подход к программированию (60-70-е годы XX в)

1.1.3.Третий этап – объектный подход к программированию (с середины 80-х годов до нашего времени)

1.1.4.Четвертый этап – компонентный подход и CASE-технологии (с середины 90-х годов до нашего времени)

1.1.5.Пятый этап – разработка, ориентированная на архитектуру и CASE-технологии (с начала XXI в. до нашего времени)

1.2.Эволюция моделей жизненного цикла программного обеспечения

1.2.1.Каскадная модель

1.2.2.Спиральная модель

1.2.3.Макетирование

1.2.4.Быстрая разработка приложений

1.2.5.Компонентно-ориентированная модель

1.2.6.XP-процесс

1.3.Стандарты, регламентирующие процесс разработки программного обеспечения

1.3.1.ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь

1.3.1.1.Предисловие

1.3.1.2.Введение

1.3.1.3.Область применения

1.3.1.4.Основные положения систем менеджмента качества

1.3.2.ГОСТ Р ИСО/МЭК ТО 15504

1.3.2.1.Обзор

1.3.2.2.Область применения

1.3.2.3.Состав ИСО/МЭК ТО 15504

1.3.2.4.Связь с другими международными стандартами

1.3.3.ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств

1.3.3.1.Введение

1.3.3.2.Область применения

1.3.3.3.Прикладное применение настоящего стандарта

2.Анализ проблемы и постановка задачи

2.1.Введение в системный анализ

2.2.Системные ресурсы

2.3.Анализ проблемы и моделирование предметной области с использованием системного подхода

2.3.1.Основные положения

2.3.2.Этап 1. Достижение соглашения об определении проблемы

2.3.3.Этап 2. Выделение основных причин – проблем, стоящих за проблемой

2.3.3.1.Устранение корневых причин

2.3.4.Этап 3. Выявление заинтересованных лиц и пользователей

2.3.5.Этап 4. Определение границ системы-решения

2.3.6.Этап 5. Выявление ограничений, налагаемых на решение

2.4.Методология ARIS

2.4.1.Организационная модель

2.4.2.Диаграмма цепочки добавленного качества

2.4.3.Модели eEPC

2.5.Стандарты IDEF0 - IDEF3

2.5.1.Методология описания бизнес процессов IDEF3

2.5.1.1.Синтаксис и семантика моделей IDEF3

2.5.1.2.Требования IDEF3 к описанию бизнес-процессов

2.5.2.Методология функционального моделирования IDEF0

2.5.2.1.Синтаксис и семантика моделейIDEF0

2.5.2.2.Построение моделей IDEF0

3.Анализ требований и их формализация

3.1.Методы определения требований

3.1.1.Интервьюирование

3.1.1.1.Этапы проведения интервью

3.1.2.Мозговой штурм и отбор идей

3.1.2.1.Генерация идей

3.1.2.2.Отбор идей

3.1.3.Совместная разработка приложений (JAD – Joint application design)

3.1.3.1.Роли в сеансах JAD

3.1.3.2.Сеансы JAD

3.1.3.3.Результаты проведения сеанса JAD

3.1.3.4.Недостатки метода JAD

3.1.4.Раскадровка

3.1.4.1.Типы раскадровок

3.1.5.Обыгрывание ролей

3.1.5.1.Суть метода обыгрывания ролей

3.1.5.2.Сценарный просмотр

3.1.6.CRC-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)

3.1.7.Быстрое прототипирование

3.2.Формализация требований

3.2.1.Метод вариантов использования и его применение

3.2.1.1.Построение модели вариантов использования

3.2.1.2.Спецификация вариантов использования

3.2.1.3.Преимущества

3.2.2.Псевдокод

3.2.3.Конечные автоматы

3.2.4.Графические деревья решений

3.2.5.Диаграммы деятельности

3.3.Техническое задание (ГОСТ 34.602-89)

3.3.1. Общие сведения

3.3.2.Назначение и цели создания (развития) системы

3.3.2.1.Назначение системы

3.3.2.2.Цели создания системы

3.3.3.Характеристики объекта автоматизации

3.3.4.Требования к системе

3.3.4.1.Требования к системе в целом

3.3.4.2.Требования к функциям (задачам)

3.3.4.3.Требования к видам обеспечения

3.3.5.Состав и содержание работ по созданию системы

3.3.6.Порядок контроля и приемки системы

3.3.7.Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

3.3.8.Требования к документированию

3.3.9.Источники разработки

4.Архитектуры программных систем

4.1.Планирование архитектуры

4.1.1.Архитектурно-экономический цикл

4.1.2.Программный процесс и архитектурно-экономический цикл

4.1.2.1.Этапы разработки архитектуры

4.1.3.Суть программной архитектуры

4.1.3.1.Архитектурные образцы, эталонные модели и эталонные варианты архитектуры

4.1.3.2.Архитектурные структуры и представления

4.2.Проектирование архитектуры

4.2.1.Атрибутный метод проектирования

4.2.1.1.Этапы ADD

4.2.2.Создание макета системы

4.3.Документирование программной архитектуры

4.3.1.Варианты применения архитектурной документации

4.3.2.Представления

4.3.2.1.Выбор значимых представлений

4.3.3.Документирование представления

4.3.3.1.Документирование поведения

4.3.3.2.Документирование интерфейсов

4.4.Методы анализа архитектуры

4.4.1.Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры

4.4.1.1.Этапы АТАМ

4.4.2.Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений

4.4.2.1.Контекст принятия решений

4.4.2.2.Реализация СВАМ

5.Технология MDA.

5.1.Использование архитектуры, управляемой моделью

5.1.1.Концепция архитектуры, управляемой моделью

5.1.2.Модельные точки зрения и модели MDA

5.2.Язык объектных ограничений OCL

5.2.1.Типы данных и операции OCL

5.2.2.Инфиксная форма записи выражений OCL

5.2.3.Последовательности доступа к объектам в языке OCL

5.2.4.Операции над коллекциями

5.2.4.1.Стандартные операции

5.2.4.2.Операция select

5.2.4.3.Операция reject

5.2.4.4.Выделение элементов коллекции

5.2.4.5.Упорядочение набора

5.2.4.6.Логические итераторы

5.2.4.7.Операции для работы со строками

5.2.4.8.Работа с датами

5.3.Возможности технологии ECO

5.3.1.Введение в технологию ЕСО

5.3.2.Модель ЕСО

5.3.3.Пространство имен ЕСО

5.4.Разработка приложений на основе ECO

5.4.1.Этапы создания приложения по технологии ECO

5.4.2.Создание простого MDA-приложения

5.4.2.1.Создание модели UML

5.4.2.2.Создание интерфейса

5.4.2.3.Связывание интерфейса с моделью

5.4.2.4.Создание логики на OCL

6.Документирование программных систем в соответствии с ГОСТ

6.1.Управление документированием программного обеспечения

6.1.1.Предисловие

6.1.2.Область применения

6.1.3.Роль руководителей

6.1.4.Функции программной документации

6.1.4.1.Информация для управления

6.1.4.2.Связь между задачами

6.1.4.3.Обеспечение качества

6.1.4.4.Инструкции и справки

6.1.4.5.Сопровождение программного обеспечения

6.1.4.6.Исторические справки

6.1.5.Установление стратегии документирования

6.1.6.Определение стандартов и руководств по документированию

6.1.6.1.Выбор модели жизненного цикла программного обеспечения

6.1.6.2.Определение типов и содержания документов

6.1.6.3.Определение качества документов

6.1.6.4.Определение форматов документов

6.1.6.5.Определение системы обозначения документов

6.1.7.Установление процедуры документирования

6.1.8.Распределение ресурсов для документирования

6.1.8.1.Персонал

6.1.8.2.Средства

6.1.8.3.Финансирование

6.1.9.Планирование документирования

6.2.Требования к содержанию документов на автоматизированные системы

6.2.1.Общие положения

6.2.2.Требования к содержанию документов по общесистемным решениям

6.2.2.1.Ведомость эскизного (технического) проекта

6.2.2.2.Пояснительные записки к эскизному, техническому проектам

6.2.2.3.Схема функциональной структуры

6.2.2.4.Описание автоматизируемых функций

6.2.2.5.Описание постановки задачи (комплекса задач)

6.2.2.6.Локальная смета и локальный сметный расчет

6.2.2.7.Паспорт

6.2.2.8.Формуляр

6.2.2.9.Проектная оценка надежности системы

6.2.2.10.Общее описание системы

6.2.2.11.Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)

6.2.3.Требования к содержанию документов с решениями по организационному обеспечению

6.2.3.1.Описание организационной структуры

6.2.3.2.Методика (технология) автоматизированного проектирования

6.2.3.3.Технологическая инструкция

6.2.3.4.Руководство пользователя

6.2.3.5.Описание технологического процесса обработки данных

6.2.4.Требования к содержанию документов с решениями по программному обеспечению

6.2.4.1.Описание программного обеспечения

6.2.5.Другие разделы

6.3.Принципы разработки руководства программиста

6.3.1.Общие положения

6.3.2.Содержание разделов

6.4.Разработка руководства пользователя

6.4.1.Общие замечания

6.4.2.Содержание разделов руководства

6.4.2.1.Общие сведения

6.4.2.2.Описание применения

6.4.2.3.Требования к процедурам функционирования системы

Заключение

Библиографический список

Связи

Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и, хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организовываются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В таблице 3.9 приведены три возможных типа связей.

Таблица 2.11

Типы связей в модели IDEF3



Изображение

Название

Назначение

Временное предшествование (Temporal precedence)

Исходное действие должно завершиться прежде, чем конечное действие сможет начаться


Объектный поток (Object flow)

Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться прежде, чем конечное действие сможет начаться

Нечеткое отношение (Relationship)

Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения



Связь типа "Временное предшествование". Как видно из названия, связи этого типа отражают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь .должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого (Рис. 2 .28). В этом примере автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу.

Рис. 2.28. Связь типа "Предшествование" между действиями 1.1 и 1.2

Связь типа "Объектный поток". Одной из наиболее часто встречающихся причин использования связи типа "объектный поток" состоит в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Такая связь отличается от связи временного предшествования двойным концом обозначающей ее стрелки. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования. Это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие начнет выполняться (Рис. 2 .29). В приведенном примере счет на оплату услуг является результатом выполнения действия 1.1. Счет необходим для проведения оплаты услуг.

Рис. 2.29. Объектная связь между действиями 1.1 и 1.2

Связь типа "Нечеткое отношение". Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа "Нечеткое отношение" сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений – отображение взаимоотношений между параллельно выполняющимися действиями. Рис. 2 .30 иллюстрирует фрагмент процесса запуска бензопилы с водяным охлаждением и нечеткое отношение между действиями "Запустить двигатель" и "Запустить водяной насос". Название стрелки может быть использовано для описания природы отношения, более подробное объяснение может быть приведено в виде отдельной ссылки.


Рис. 2.30. Связь типа "Нечеткое отношение"

Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования. Альтернативная предшественной связи с Рис. 2 .28 связь нечеткого отношения представлена на Рис. 2 .31. В этом примере внесение исправлений начинается по мере получения замечаний от рецензентов, т.е. до непосредственного окончания действия по принятию замечаний.

Рис. 2.31. Альтернатива связи предшествования

Соединения

Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или, наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.

Разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других.

Сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.

В ниже приведённой таблице (Таблица 2 .12) объединены три типа соединений.

Таблица 2.12

Типы соединений в модели IDEF3



Графическое обозначение

Название

Вид

Правила инициации

&

Соединение

"И"

Разворачивающее

Каждое конечное действие обязательно инициируется

Сворачивающее

Каждое исходное действие обязательно должно завершиться

X

Соединение "Эксклюзивное ИЛИ"

Разворачивающее

Одно и только одно конечное действие инициируется

Сворачивающее

Одно и только одно исходное действие должно завершиться

О

Соединение

"ИЛИ"

Разворачивающее

Одно (или более) конечное действие инициируется

Сворачивающее

Одно (или более) исходное действие должно завершиться

Примеры разворачивающих и сворачивающих соединений приведены на рисунке (Рис. 2 .32).

"И"-соединения. Соединения этого типа инициируют выполнение всех своих конечных действий. Все действия, присоединенные к сворачивающему "И"-соединению, должны завершиться, прежде чем может начать выполняться следующее действие. После обнаружения пожара инициируются включение пожарной сигнализации (Рис. 2 .33), вызов пожарной охраны и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.

Рис. 2.32. Два вида соединений

Рис. 2.33. "И"-соединения

Соединение "Исключающее ИЛИ". Вне зависимости от количества действий, прицепленных к сворачивающему или разворачивающему соединению "Эксклюзивное ИЛИ", инициировано будет только одно из них, и поэтому только одно из них будет завершено перед тем, как любое действие, следующее за сворачивающим соединением "Эксклюзивное ИЛИ", сможет начаться.


Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения (Рис. 2 .34).

Соединение "Исключающее ИЛИ" используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.

Рис. 2.34. Соединение "Эксклюзивное ИЛИ"

Соединение "ИЛИ". Соединения этого типа предназначены для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение "ИЛИ" в основном определяется и описывается непосредственно системным аналитиком. Соединение J2 может активировать проверку данных чека и (или) проверку суммы наличных ( Рис. 2 .35). Проверка чека инициируется, если покупатель желает расплатиться чеком, проверка суммы наличных – при оплате наличными. И то, и другое действие инициируется при частичной оплате чеком и частичной – наличными.

Рис. 2.35. Соединение "ИЛИ"



Декомпозиция действий

Действия в IDEF3 могут быть декомпозированы, или разложены на составляющие, для более детального анализа. Декомпозировать действие можно несколько раз. Это позволяет документировать альтернативные потоки процесса в одной модели.

Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 – номер родительского действия, 2 – номер декомпозиции, 5 – номер действия.

2.5.1.2.Требования IDEF3 к описанию бизнес-процессов

В этом подразделе мы рассмотрим построение IDEF3-диаграммы на основе выраженного в текстовом виде описания процесса. Предполагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспертов предметной области, которые будут представлять нам описание процесса.

Определение сценария, границ моделирования, точки зрения

Перед тем как попросить экспертов предметной области подготовить описание моделируемого процесса, должны быть документированы границы моделирования, чтобы экспертам была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от обычной точки зрения для эксперта, это должно быть ясно и аккуратно описано.

Вполне возможно, что эксперты не смогут сделать приемлемое описание без применения формального опроса автором модели. В таком случае автор должен заранее приготовить набор вопросов таким же образом, как журналист заранее подготавливает вопросы для интервью.

Определение действий и объектов

Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может иметься письменная документация, позволяющая пролить свет на природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих а процессе.


В некоторых случаях возможно создание графической модели процесса в присутствии экспертов. Такая модель также может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.

Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий, что обеспечивает их независимость друг от друга. В Таблица 2 .13 номера действий выделяются каждому аналитику большими блоками. В этом примере Иван исчерпал данный ему вначале диапазон номеров и дополнительно получил второй.

Таблица 2.13

Распределение диапазонов номеров IDEF3 между аналитиками



Аналитик

Диапазон номеров IDEF3

Иван

1-99

Петр

100-199

Николай

200-299

Иван

300-399

Последовательность и параллельность

Если модель создается после проведения интервью, аналитик должен принять решения по построению иерархии участвующих в модели диаграмм, например, насколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или параллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черновых вариантов незаконченных диаграмм) для получения недостающей информации. Важно, однако, различать предполагаемую (появляющуюся из-за недостатка информации о связях) и явную (ясно указанную в описании эксперта) параллельности.

Итак, IDEF3 – это способ описания бизнес-процессов, который нужен для описания положения вещей как упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения структурного анализа системы. Кроме того, IDEF3 применяется при проведении стоимостного анализа поведения моделируемой системы.

2.5.2.Методология функционального моделирования IDEF0

Методология функционального моделирования IDEF0 – это технология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направленность IDEF0 – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. "Функциональная" точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации. На рисунке 3.17 приведен пример типовой диаграммы IDEF0.

Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта, до IDEF3 моделирования для сбора данных и моделирования процесса "как есть". Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.


Рис. 2.36. Пример диаграммы IDEF0

2.5.2.1.Синтаксис и семантика моделейIDEF0



Модели IDEF0



IDEF0 сочетает в себе небольшую по объему графическую нотацию (она содержит только два обозначения: блоки и стрелки) со строгими и четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.

Методология IDEF0 в некоторой степени напоминает рекомендации, существующие в книгоиздательском деле, часто набор напечатанных моделей IDEF0 организуется в брошюру (называемую в терминах IDEF0 комплект), имеющую содержание, глоссарий и другие элементы, характерные для законченной книги.

Первый шаг при построении модели IDEF0 заключается в определении назначения модели – набора вопросов, на которые должна отвечать модель. Набор вопросов можно сравнить с предисловием, в котором раскрывается назначение книги.

Границы моделирования предназначены для обозначения ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Как читающий модель, так и непосредственно ее автор должны понимать степень детальности ответов на поставленные в назначении модели вопросы.

Следующим шагом указывается предполагаемая целевая аудитория, для нужд которой создается модель. Зачастую от выбора целевой аудитории зависит уровень детализации, с которым должна создаваться модель. Перед построением модели необходимо иметь представление о том, какие сведения о предмете моделирования уже известны, какие дополнительные материалы и (или) техническая документация для понимания модели могут быть необходимы целевой аудитории, какие язык и стиль изложения являются наиболее подходящими.

Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже обозначенные границы моделирования и назначение модели. Однажды выбранная точка зрения остается неизменной для всех элементов модели. При необходимости могут быть созданы другие модели, отображающие систему с других точек зрения. Вот несколько примеров точек зрения при построении моделей: клиент, поставщик, владелец, редактор.

Действия

Действие, обычно в IDEF0 называемое функцией, обрабатывает или переводит входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом – контекстная функция. Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки. Имена функций в IDEF0 подбираются по сходным правилам с именами действий в IDEF3 – с использованием глаголов или отглагольных существительных. Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования.