ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.12.2020
Просмотров: 6758
Скачиваний: 15
СОДЕРЖАНИЕ
1.Введение в технологии разработки программного обеспечения
1.1.Основные этапы развития технологии разработки
1.1.1.Первый этап – «стихийное» программирование.
1.1.2.Второй этап – структурный подход к программированию (60-70-е годы XX в)
1.1.3.Третий этап – объектный подход к программированию (с середины 80-х годов до нашего времени)
1.2.Эволюция моделей жизненного цикла программного обеспечения
1.2.4.Быстрая разработка приложений
1.2.5.Компонентно-ориентированная модель
1.3.Стандарты, регламентирующие процесс разработки программного обеспечения
1.3.1.ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь
1.3.1.4.Основные положения систем менеджмента качества
1.3.2.3.Состав ИСО/МЭК ТО 15504
1.3.2.4.Связь с другими международными стандартами
1.3.3.3.Прикладное применение настоящего стандарта
2.Анализ проблемы и постановка задачи
2.1.Введение в системный анализ
2.3.Анализ проблемы и моделирование предметной области с использованием системного подхода
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.2.Диаграмма цепочки добавленного качества
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.1.Этапы проведения интервью
3.1.2.Мозговой штурм и отбор идей
3.1.3.Совместная разработка приложений (JAD – Joint application design)
3.1.3.3.Результаты проведения сеанса JAD
3.1.5.1.Суть метода обыгрывания ролей
3.1.6.CRC-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)
3.1.7.Быстрое прототипирование
3.2.1.Метод вариантов использования и его применение
3.2.1.1.Построение модели вариантов использования
3.2.1.2.Спецификация вариантов использования
3.2.4.Графические деревья решений
3.3.Техническое задание (ГОСТ 34.602-89)
3.3.2.Назначение и цели создания (развития) системы
3.3.3.Характеристики объекта автоматизации
3.3.4.1.Требования к системе в целом
3.3.4.2.Требования к функциям (задачам)
3.3.4.3.Требования к видам обеспечения
3.3.5.Состав и содержание работ по созданию системы
3.3.6.Порядок контроля и приемки системы
3.3.8.Требования к документированию
4.Архитектуры программных систем
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.3.Документирование программной архитектуры
4.3.1.Варианты применения архитектурной документации
4.3.2.1.Выбор значимых представлений
4.3.3.Документирование представления
4.3.3.1.Документирование поведения
4.3.3.2.Документирование интерфейсов
4.4.Методы анализа архитектуры
4.4.1.Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры
4.4.2.1.Контекст принятия решений
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.4.Выделение элементов коллекции
5.2.4.7.Операции для работы со строками
5.3.Возможности технологии ECO
5.3.1.Введение в технологию ЕСО
5.4.Разработка приложений на основе ECO
5.4.1.Этапы создания приложения по технологии ECO
5.4.2.Создание простого MDA-приложения
5.4.2.3.Связывание интерфейса с моделью
5.4.2.4.Создание логики на OCL
6.Документирование программных систем в соответствии с ГОСТ
6.1.Управление документированием программного обеспечения
6.1.4.Функции программной документации
6.1.4.1.Информация для управления
6.1.4.5.Сопровождение программного обеспечения
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.9.Планирование документирования
6.2.Требования к содержанию документов на автоматизированные системы
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.9.Проектная оценка надежности системы
6.2.2.10.Общее описание системы
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.3.Принципы разработки руководства программиста
6.4.Разработка руководства пользователя
6.4.2.Содержание разделов руководства
Рис. 2.22. Здание ARIS. Представления
2.4.1.Организационная модель
Организационная диаграмма позволяет всесторонне описать организационно-штатную структуру предприятия. Организационные диаграммы показывают имеющиеся организационные подразделения (как исполнители функций) и их взаимозависимости в соответствии с выбранными критериями структурирования. Отдельные организационные единицы соединяются связями для указания иерархии.
Модель организационной структуры предприятия может содержать следующие структурные элементы: Организационная единица, Должность или позиция, Личность, Группа и др. (Таблица 2 .8).
Таблица 2.8
Элементы организационной диаграммы
№ |
Графическая нотация |
Наименование |
Описание |
1. |
|
Организационная единица (Organizational unit) |
Элемент организационной структуры (структурное подразделение), который отвечает за выполнение определенных задач и преследует определенные цели. |
2. |
|
Позиция или должность (Position) |
Наиболее мелкий организационный элемент на предприятии. Обязанности и административные полномочия такого элемента задаются должностными инструкциями. |
3. |
|
Группа (Group) |
Несколько сотрудников, которые вместе работают над конкретной задачей в определенный период времени (например: группа проектирования). |
4. |
|
Внешний сотрудник (External person) |
Лицо, выполняющее определенные функции в компании, но не являющееся служащим этой компании. Он может назначаться к организационным единицам или функциям, к выполнению которых он привлекается со стороны или за которые он отвечает. |
5. |
|
Сотрудник (Internal person) |
Является служащим компании и может назначаться к организационным единицам или функциям, которые он выполняет или за которые несет ответственность. |
6. |
|
Тип сотрудника (Person type) |
Обобщает индивидуальных лиц, имеющих одинаковые характеристики. Эти характеристики могут иметь отношение, например, к одним и тем же полномочиям. Начальники отделов или бригадиры, например, должны следовать определенным правилам и выполнять определенные обязанности, которые достаточно описать только один раз. |
7. |
|
Местонахождение (Location) |
Определяет физическое положение (местонахождение) организационных единиц, рабочих мест, образцов аппаратных компонентов и технических ресурсов компании. Местонахождение может ссылаться на область, город, предприятие, здание и т.д. |
При построении модели организационной структуры между структурными элементами могут устанавливаться следующие типы связей: Имеет в подчинении (Is superior), Связан с (Is assigned to), Принадлежит (Belongs to), Является организационным управляющим (Is Organization Manager for), Имеет в своем составе (Has member), Состоит из (Is composed of), Располагает (Is located at), Взаимодействует с (Cooperates with), Содержит (Subsumes), Занимает (Occupies).
Пример организационной диаграммы приведен на рисунке 3.4.
Рис. 2.23. Часть организационной диаграммы КГТУ
2.4.2.Диаграмма цепочки добавленного качества
Для уменьшения сложности описания деятельности организации необходимо разработать иерархию моделей БП организации, начиная с самого верхнего уровня и до моделей отдельных БП на нижнем уровне. Для описания модели верхнего уровня используется диаграмма типа Value-added chain diagram (VAD), название которой можно перевести как Модель цепочки добавленного качества (стоимости).
Диаграмма цепочек добавленного качества описывает функции организации, которые непосредственно влияют на реальный выход ее продукции. Эти функции создают последовательность действий, формируя добавленные значения: стоимость, количество, качество и т.д.
Диаграмма цепочек добавленной стоимости может содержать следующие структурные элементы: Организационная единица, Должность или позиция, функция и др. (Таблица 2 .9).
Таблица 2.9
Элементы диаграммы цепочки добавленного качества
№ |
Графическая нотация |
Наименование |
Описание |
1. |
|
Функция |
Действие или набор действий, выполняемых над исходным объектом (документом, материалом и т.п.) с целью получения заданного результата. |
2. |
|
Технический термин |
|
3. |
|
Организационная единица (Organizational unit) |
Элемент организационной структуры (структурное подразделение), который отвечает за выполнение определенных задач и преследует определенные цели. |
4. |
|
Кластер (экземпляр) |
Экземпляр объекта данных. Он представляет собой логический взгляд на набор объектов данных или структур |
Пример диаграммы цепочек добавленной стоимости представлен на рисунке 3.5.
Маленьким значком в нижнем правом углу элемента модели помечаются те функции, для которых существуют модели, раскрывающие эту функцию. Таким механизмом реализуется принцип декомпозиции.
Рис. 2.24. Основные процессы учета успеваемости студентов в системе кредитов
2.4.3.Модели eEPC
Цепочка процесса, управляемая событиями — Extended event driven process chain (eEPC).
С помощью диаграмм EPC процедуры БП представляются как логические последовательности событий. События определяют, какое состояние или отношение будет переключать функцию и какое состояние наступит после ее выполнения. Поэтому модель EPC должна всегда иметь запускающие и завершающие события.
Одно событие может инициировать выполнение одновременно нескольких функций, и, наоборот, функция может быть результатом наступления нескольких событий. Объединения нескольких событий или функций отображаются на диаграмме EPC с помощью соединителей в виде небольшого кружка. Эти соединители не только отображают графические связи между объектами модели, но и определяют логические связи между ними. Различают два типа связи логических операторов – связи событий и связи функций.
Диаграмма цепочек, управляемых событиями кроме элементов организационной диаграммы и диаграммы данных может содержать следующие структурные элементы: функция, событие и др. (Таблица 2 .10).
Таблица 2.10
Элементы диаграммы цепочек, управляемых событиями
№ |
Графическая нотация |
Наименование |
Описание |
1. |
|
Функция |
Действие или набор действий, выполняемых над исходным объектом (документом, материалом и т.п.) с целью получения заданного результата. |
|
|
Событие |
Состояние, которое является существенным для управления БП и которое оказывает влияние или контролирует дальнейшее развитие одного или более БП. Изменения состояния отражаются с помощью информационных объектов |
|
|
Правило |
Представляет собой правило разветвления и слияния веток БП. Если перейти к рассмотрению каждой отдельной функции БП, то можно сказать, что правило отражает логическое соотношение между несколькими исходными для функции событиями и несколькими результирующими. |
|
|
Интерфейс функции |
Используется для обозначения функции внешнего БП, который либо не описывается в данной модели, либо является БП другой предметной области. |
|
|
Носитель информации |
Представляет собой средство хранения информации. Оно может быть реализовано, к примеру, в виде картотеки или компьютерных файлов или БД. |
|
|
Документ |
Обозначает любой вид документов. |
Пример диаграммы цепочек, управляемых событиями представлен на рисунке 3.6.
Рис. 2.25. Согласование нагрузки и ответственности на кафедрах
2.5.Стандарты IDEF0 - IDEF3
2.5.1.Методология описания бизнес процессов IDEF3
IDEF3 – способ описания процессов, основной целью которого является обеспечение структурированного метода, используя который эксперт в предметной области может описать положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
Технология IDEF3 хорошо приспособлена для сбора данных, требующихся для проведения структурного анализа системы. В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. На рисунке 3.7 изображен пример описания процесса с использованием методологии IDEF3.
Рис. 2.26. Описание процесса в методологии IDEF3
Технология IDEF3 также может быть использована как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта IDEF0. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы, более подробно методы имитационного анализа будут рассмотрены позднее.
2.5.1.1.Синтаксис и семантика моделей IDEF3
Модели IDEF3
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных. Например, "Обработать заказ клиента" или "Применить новый дизайн" – вполне подходящие названия сценариев.
Точка зрения для большинства моделей должна быть явным образом документирована. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Для системного аналитика также важно понимание цели моделирования – набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель).
Диаграммы
Главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной читателю.
Единица работы. Действие
Аналогично другим технологиям моделирования действие, или в терминах IDEF3 "единица работы" (Unit of Work – UOW) – другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (Рис. 2 .27).
Рис. 2.27. Изображение и нумерация действия в диаграмме IDEF3