ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.12.2020
Просмотров: 6699
Скачиваний: 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.Содержание разделов руководства
8) Процесс решения проблемы (подраздел 6.8). Определяет процесс анализа и устранения проблем (включая несоответствия), независимо от их характера и источника, которые были обнаружены во время осуществления разработки, эксплуатации, сопровождения или других процессов.
Организационные процессы жизненного цикла
Организационные процессы жизненного цикла (раздел 7) состоят из четырех процессов. Они применяются в какой-либо организации для создания и реализации основной структуры, охватывающей взаимосвязанные процессы жизненного цикла и соответствующий персонал, а также для постоянного совершенствования данной структуры и процессов. Эти процессы, как правило, являются типовыми, независимо от области реализации конкретных проектов и договоров; однако уроки, извлеченные из таких проектов и договоров, способствуют совершенствованию организационных вопросов. Организационными процессами являются:
1) Процесс управления (подраздел 7.1). Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.
2) Процесс создания инфраструктуры (подраздел 7.2). Определяет основные работы по созданию основной структуры процесса жизненного цикла.
3) Процесс усовершенствования (подраздел 7.3). Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.
4) Процесс обучения (подраздел 7.4). Определяет работы по соответствующему обучению персонала.
2.Анализ проблемы и постановка задачи
2.1.Введение в системный анализ
Системный анализ - система понятий, методов (среди которых должен быть метод декомпозиции) и технологий для изучения, описания, реализации систем различной природы и характера, междисциплинарных проблем; это система общих законов, методов, приемов исследования таких систем.
Любую предметную область также можно определить как системную.
Предметная область - раздел науки, изучающий предметные аспекты системных процессов и системные аспекты предметных процессов и явлений. Это определение можно считать системным определением предметной области.
Пример. Информатика - наука, изучающая информационные аспекты системных процессов и системные аспекты информационных процессов. Это определение можно считать системным определением информатики.
Системный анализ тесно связан с синергетикой.
Синергетика - междисциплинарная наука, изучающая общие идеи, методы и закономерности организации (изменения структуры, ее пространственно-временного усложнения) различных объектов и процессов, инварианты этих процессов. "Синергетика" в переводе – совместный, согласованно действующий.
Системный анализ тесно связан и с философией. Философия дает общие методы содержательного анализа, а системный анализ даёт общие методы формального, межпредметного анализа предметных областей, выявления и описания, изучения их системных инвариантов.
Можно дать и философское определение системного анализа: системный анализ - это прикладная диалектика.
Системный анализ предоставляет к использованию в различных науках, системах следующие методы и процедуры:
-
абстрагирование и конкретизация;
-
анализ и синтез;
-
индукция и дедукция;
-
формализация;
-
структурирование;
-
макетирование;
-
алгоритмизация;
-
моделирование;
-
программное управление;
-
распознавание, классификация и идентификация образов;
-
экспертное оценивание и тестирование и другие методы и процедуры.
2.2.Системные ресурсы
Имеются следующие основные типы ресурсов в природе и в обществе.
Вещество - наиболее хорошо изученный ресурс, который в основном, представлен таблицей Д. И. Менделеева достаточно полно и пополняется не так часто. Вещество выступает как отражение постоянства материи в природе, как мера однородности материи.
Энергия - не полностью изученный тип ресурсов, например, мы не владеем управляемой термоядерной реакцией. Энергия выступает как отражение изменчивости материи, переходов из одного вида в другой, как мера необратимости материи.
Информация - мало изученный тип ресурсов. Информация выступает как отражение порядка, структурированности материи, как мера порядка, самоорганизации материи (и социума). Сейчас это понятие мы будем понимать как некоторые сообщения; ниже этому понятию мы посвятим более детальное обсуждение.
Человек - выступает как носитель интеллекта высшего уровня и является в экономическом, социальном, гуманитарном смысле важнейшим и уникальным ресурсом общества, выступает как мера разума, интеллекта и целенаправленного действия, мера социального начала, высшей формы отражения материи (сознания).
Организация (или организованность) выступает как форма ресурсов в социуме, группе которая определяет его структуру, включая институты человеческого общества и его надстройки, выступает как мера упорядоченности ресурсов. Организация системы связана с наличием некоторых причинно-следственных связей в этой системе. Организация системы может иметь различные формы, например, биологическую, информационную, экологическую, экономическую, социальную, временную, пространственную и она определяется причинно-следственными связями в материи и социуме.
Пространство - мера протяженности материи (события), распределения её (его) в окружающей среде.
Время - мера обратимости (необратимости) материи, событий. Время неразрывно связано с изменениями действительности.
Можно говорить о различных полях, в которые "помещен" любой человек: материальном, энергетическом, информационном, социальном, их пространственных и временных характеристиках.
Пример. Рассмотрим простую задачу - пойти утром на занятия в вуз. Эта часто решаемая студентом задача имеет все аспекты:
-
материальный, физический аспект - студенту необходимо переместить некоторую массу, например, учебников и тетрадей на нужное расстояние;
-
энергетический аспект - студенту необходимо иметь и затратить нужное количество энергии на перемещение;
-
информационный аспект - необходима информация о маршруте движения и месторасположении вуза и нужно обрабатывать по пути своего движения информацию;
-
человеческий аспект - перемещение, в частности, переезд на автобусе невозможен без человека, например, без водителя автобуса;
-
организационный аспект - необходимы подходящие транспортные сети и маршруты, остановки и т.д.;
-
пространственный аспект - перемещение на определённое расстояние;
-
временной аспект - на данное перемещение будет затрачено время (за которое произойдут соответствующие необратимые изменения в среде, в отношениях, в связях).
Все типы ресурсов тесно связаны и сплетены. Более того, они невозможны друг без друга, актуализация одного из них ведет к актуализации другого.
Пример. При сжигании дров в печке выделяется тепловая энергия, тепловая энергия используется для приготовления пищи, пища используется для получения биологической энергии организма, биологическая энергия используется для получения информации (например, решения некоторой задачи), перемещения во времени и в пространстве. Человек и во время сна расходует свою биологическую энергию на поддержание информационных процессов в организме; более того, сон - продукт таких процессов.
Социальная организация и активность людей совершенствуют информационные ресурсы, процессы в обществе, последние, в свою очередь, совершенствуют производственные отношения.
Если классическое естествознание объясняет мир исходя из движения, взаимопревращений вещества и энергии, то сейчас реальный мир, объективная реальность могут быть объяснены лишь с учётом сопутствующих системных, особенно, системно-информационных процессов.
2.3.Анализ проблемы и моделирование предметной области с использованием системного подхода
2.3.1.Основные положения
Анализ проблем – это процесс осознания реальных проблем и потребностей пользователей и предложения решений, позволяющих удовлетворить эти потребности.
Цель анализа проблемы состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки.
Чтобы выявить причины (или проблемы, стоящие за проблемой), необходимо опросить людей, которых непосредственно затрагивает данная проблема. Выявление актантов системы является ключевым шагом в анализе проблемы.
При этом необходимо проанализировать и понять область проблемы и исследовать разнообразные области решений. Как правило, возможных решений множество, и нам необходимо найти то, которое наиболее соответствует решаемой проблеме.
Чтобы иметь возможность провести анализ проблемы, полезно определить, что же собой представляет проблема. По определению Гауса и Вайнберга (Cause, Weinberg, 1989) проблема - это разница между желаемым и воспринимаемым.
Это определение достаточно разумно, по крайней мере, оно устранит часто встречающееся среди разработчиков заблуждение, что подлинная проблема заключается в том, что пользователь не понимает, в чем состоит проблема! Согласно данному определению, если пользователь ощущает нечто как проблему, это и есть настоящая проблема, и она достойна внимания.
При анализе проблемы необходимо осуществить следующие пять этапов.
-
Достигнуть соглашения об определении проблемы.
-
Выделить основные причины – проблемы, стоящие за проблемой.
-
Выявить заинтересованных лиц и пользователей.
-
Определить границу системы решения.
-
Выявить ограничения, которые необходимо наложить на решение.
2.3.2.Этап 1. Достижение соглашения об определении проблемы
Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой (Таблица 2 .3).
В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая с точки зрения клиента эти преимущества, мы также достигаем лучшего понимания их взгляда на проблему в целом.
Таблица 2.3
Стандартная форма постановки проблемы
Элемент
|
Описание
|
Проблема воздействует на
результатом чего является Выигрыш от может состоять в следующем |
[Описание проблемы] [Указание лиц, на которых оказывает влияние данная проблема] [Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность] [Указание предлагаемого решения] [Список основных предоставляемых решением преимуществ] |
2.3.3.Этап 2. Выделение основных причин – проблем, стоящих за проблемой
Для понимания реальной проблемы и ее причин можно использовать множество методов. Одним из них является метод анализа корневых причин, представляющий собой семантический способ нахождения причин, лежащих в основе рассматриваемой проблемы или ее проявления.
Рассмотрим реальный пример. Компания GoodsAreUs, занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных наименований. Решив заняться проблемой недостаточной прибыльности, компания использует рекомендуемую ее программой обеспечения качества методику "качество – во всем" (total quality management, TQM). Применив данный подход, компания практически сразу обратила внимание на ущерб от несоответствия (cost of nonconformance), который представляет собой стоимость всего, что идет не так, как надо, и приводит к бесполезным затратам. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущерб от несоответствия, компания заподозрила, что наибольший вклад в него вносят "остатки".
Следующим шагом должно стать определение того, какие факторы оказывают влияние на величину остатков. TQM советует для обнаружения проблем, стоящих за проблемой, использовать диаграмму в форме рыбного скелета (Рис. 2 .20). В нашем случае компания выявила много источников, вносящих свой вклад в остатки. Каждый источник указан как одна из "косточек" на диаграмме.
Рис. 2.20. Диаграмма в форме рыбного скелета для отображения корневых причин
Способ выявления корневых причин зависит от конкретного случая. Существует несколько способов выявления причин:
-
опрос сотрудников, непосредственно занимающихся этим делом;
-
"мозговой штурм" с участием тех, кто знаком с данной областью;
-
метод упрощенной спецификации приложений
-
совместная разработка приложений
-
пользовательский сценарий и сеансы разработки схем выбора
2.3.3.1.Устранение корневых причин
Качественные данные свидетельствуют, что многие корневые причины просто не стоят того, чтобы их устранять, поскольку затраты на их устранение превысят причиняемый проблемой ущерб.
Предложение заменить существующую систему или разработать новую, должно быть хорошо аргументированным. Для этого нужно предоставить стоимостное обоснование такой системы, оценив затраты на разработку и дивиденды от эксплуатации этой системы.
Продолжая анализ, можно применить новую диаграмму в виде "рыбного скелета" для определения того, какие типы ошибок вносят наибольший вклад в проблему неправильности заказов. Полученные данные можно затем использовать для определения функций новой системы программного обеспечения, которая призвана устранить эти ошибки. Раз мы приняли решение, что проблема неправильных заказов на покупку достойна решения, можно создать для нее формальную постановку (Таблица 2 .4).
Таблица 2.4
Постановка проблемы ввода заказов на покупку
Элементы
|
Описание
|
Проблема воздействует на
результатом чего является выигрыш от может состоять в следующем |
выполнение неправильных заказов на покупку, выполняющий заказы персонал, клиентов, производство, продажи и обслуживание клиентов увеличение остатков, повышение производственных затрат, неудовлетворенность клиентов, уменьшение прибыли новой системы, направленной на решение данной проблемы,
В конечном счете – увеличение прибыли.
|
После написания постановки проблемы, ее следует передать для ознакомления заказчикам и заинтересованным лицам, чтобы они внесли свои комментарии. Затем постановка проблемы доводится до сведения всех членов команды разработчиков с тем, чтобы все работали в направлении достижения общей цели.