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

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

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

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

Добавлен: 04.12.2020

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

Скачиваний: 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.Требования к процедурам функционирования системы

Заключение

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

Пример функционального блока приведен на рисунке 3.18.

Frame3

Рис. 2.37. Функциональный блок IDEF0

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

Границы и связи

Чтобы быть полезным, описание любого блока должно, как минимум, включать в себя описание объектов, которые блок создает в результате своей работы ("выхода"), и Объектов, которые блок потребляет или преобразует ("вход").

В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения – объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.

Для отображения категорий информации, присутствующих на диаграммах IDEF0, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок:

I (Input) – вход – нечто, что потребляется в ходе выполнения процесса;

С (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;

О (Output) – выход – нечто, являющееся результатом выполнения процесса;

М (Mechanism) – исполняющий механизм – нечто, что используется для выполнения процесса, но не потребляется само по себе. Рис. 2 .38 показывает 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.

Рис. 2.38. Каждый тип стрелки соединяется со своей стороной функционального блока

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

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


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

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

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

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

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

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

Комбинированные стрелки. В IDEF0 существует пять основных видов комбинированных стрелок: выход – вход, выход – управление, выход – механизм исполнения, выход – обратная связь на управление и выход – обратная связь на вход.

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


Рис. 2.39. Комбинация стрелок выход – вход

Стрелка выход – управление отражает ситуацию преобладания одного блока над другим, когда один блок управляет работой другого. На рисунке 3.21 принципы формирования инвестиционного портфеля управляют поведением брокеров на бирже.

Рис. 2.40. Комбинированная стрелка выход – управление

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

Рис. 2.41. Комбинированная стрелка выход – механизм исполнения

Обратные связи на вход и на управление применяются в случаях, когда зависимые блоки формируют обратные связи для управляющих ими блоков. На рисунке 3.23 получаемая от брокеров информация о текущих биржевых курсах применяется для корректировки стратегии игры на бирже.

Рис. 2.42. Комбинированная стрелка выход – обратная связь на управление

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

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

Рис. 2.43. Комбинированная стрелка выход – обратная связь на вход

Рис. 2.44. Разбитая на две части и переименованная стрелка

Туннели

Понятие связанные стрелки используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущественности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем. На рисунке 3.26 , например, стрелка "корпоративная информационная система" – важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.


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

Рис. 2.45. Пример применения туннеля

Рис. 2.46. Еще один пример применения туннеля

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

В этом подразделе мы рассмотрим методику построения моделей IDEF0 более подробно.

Диаграммы

На рисунке 3.28 типовая диаграмма IDEF0 показана вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы заголовка используются для отслеживания процесса создания модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.

Рис. 2.47. IDEF0-диаграмма со служебной информацией на полях

Все элементы заголовка диаграммы перечислены в таблице 3.12.

Таблица 2.14

Элементы заголовка диаграммы IDEF0

Поле

Назначение

USED AT

Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)

Author, date, project

Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась

Notes 1 ... 10

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

Status

Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения

Working

Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы

Draft

Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение

Recommended

Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся

Publication

Диаграмма готова для окончательной печати и публикации

Reader

ФИО читателя

Date

Дата знакомства читателя с диаграммой

Context

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

Все элементы нижней строки диаграммы перечислены в таблице 3.13.

Таблица 2.15

Элементы нижней строки диаграммы IDEF0




Поле

Назначение

Node

Номер диаграммы, совпадающий с номером родительского функционального блока.

Title

Имя родительского функционального блока.

Number

Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели.



Цикл "эксперт-аналитик"

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

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

Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм, контроль истории изменений – полем Field (см. Таблица 2 .14).

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

Ни одна модель не должна строиться без ясного осознания объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:

  • Почему моделируется данный процесс?

  • Что выявит данная модель?

  • Как ознакомившиеся с этой моделью смогут ее применить?

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

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

  • Каковы задачи менеджера?

  • Каковы задачи клерка?

  • Кто контролирует работу?

  • Какая технология нужна для выполнения каждого шага? и т.п.

Точка зрения



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