ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.12.2020
Просмотров: 6710
Скачиваний: 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.3.4.Этап 3. Выявление заинтересованных лиц и пользователей
При решении любой сложной проблемы, как правило, приходится удовлетворять потребности различных групп заинтересованных лиц. Эти группы обычно имеют различные точки зрения на проблему и различные потребности, которые должны быть учтены в решении.
Заинтересованные лица – это все, на кого реализация новой системы или приложения может оказать материальное воздействие.
Понимание потребностей пользователей и других заинтересованных лиц является ключевым фактором в выработке успешного решения.
Первая категория заинтересованных лиц – это пользователи системы. Их потребности легко учесть, поскольку они будут непосредственно привлекаться к определению и использованию системы. Вторую категорию составляют непрямые пользователи, а также те, на кого воздействуют только бизнес-последствия разработки и те, кто воздействует на разработку. Потребности заинтересованных лиц, не являющихся пользователями, также необходимо выявить и учесть.
В зависимости от того, в какой предметной области работает команда, выявление заинтересованных лиц может оказаться как тривиальным, так и нетривиальным этапом анализа проблемы. Часто достаточно провести простой опрос среди тех, кто принимает решения, а также опросить потенциальных пользователей и другие заинтересованные стороны. В этом процессе могут оказаться полезными следующие вопросы.
-
Кто является пользователями системы?
-
Кто является заказчиком (экономическим покупателем) системы?
-
На кого еще окажут влияние результаты работы системы?
-
Кто будет оценивать и принимать систему, когда она будет представлена и развернута?
-
Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?
-
Кто будет заниматься сопровождением новой системы?
-
Не забыли ли мы кого-нибудь?
В нашем примере замены системы заказов на покупку основными и наиболее очевидными пользователями являются служащие, занимающиеся вводом заказов на покупку. Они определенно являются заинтересованными лицами, так как их производительность, удобство, комфорт, выполнение работы и ее результаты зависят от системы. Кого еще из заинтересованных лиц можно выделить?
На руководителя отдела приема заказов система также оказывает непосредственное воздействие, но он взаимодействует с системой не напрямую, а посредством различных интерфейсов пользователя и форм отчетов. Главный финансист компании также, очевидно, принадлежит к заинтересованным лицам, так как ожидается, что система повлияет на производительность, качество предоставляемых услуг и прибыльность компании. Наконец, администратор информационной системы и члены команды, разрабатывающей приложение, также являются заинтересованными лицами, так как они будут отвечать за разработку и сопровождение системы. Они также, как и пользователи, будут зависеть от поведения системы. Результаты выявления пользователей и заинтересованных лиц новой системы ввода заказов на покупку представлены в таблице 3.3.
Таблица 2.5
Пользователи и лица, заинтересованные в новой системе
|
Пользователи |
Другие заинтересованные лица |
|
Служащие, занимающиеся вводом заказов |
Администратор информационной системы и команда разработчиков |
|
Руководитель отдела приёма заказов |
Главный финансист |
|
Контроль производства |
Управляющий производством |
|
Служащий, выписывающий счета |
|
2.3.5.Этап 4. Определение границ системы-решения
После того как согласована постановка проблемы и выявлены пользователи и заинтересованные лица, можно перейти к определению системы, разрабатываемой для решения данной проблемы. Это важный момент, когда необходимо постоянно помнить как о понимании проблемы, так и о свойствах потенциального решения.
Граница системы описывает оболочку, в которой заключена система (Рис. 2 .21.). Информация в виде ввода и вывода передается от находящихся вне системы пользователей системе и обратно. Все взаимодействия с системой осуществляются посредством интерфейсов между системой и внешним миром.
Рис. 2.21. Отношение ввод/система/вывод
Другими словами, если мы собираемся нечто создать или модифицировать – это часть нашего решения, которая находится внутри границы; если нет – это нечто внешнее по отношению к системе. Таким образом, мы делим мир на два интересующих нас класса.
-
Наша система.
-
То, что взаимодействует с нашей системой.
Определим "то, что взаимодействует с нашей системой", общим понятием "актанты" (actors). Они выполняют некоторые действия, заставляя систему делать ее работу. Актант изображается простой пиктограммой в виде человечка. Его определение выглядит следующим образом.
Актант - это находящееся вне системы нечто (или некто), взаимодействующее с системой.
С помощью данного понятия мы можем проиллюстрировать границы системы.
Во многих случаях границы системы очевидны. Например, однопользовательский персональный планировщик контактов, работающий на автономной платформе Windows 2000, имеет достаточно хорошо определенные границы. Имеется всего один пользователь и одна платформа. Интерфейсы между пользователем и приложением состоят из диалогов, посредством которых пользователь получает доступ к информации системы, и неких выходных сообщений и коммуникационных путей, которые система использует для документирования или передачи этой информации.
Для системы ввода заказов из нашего примера, которая должна быть объединена с уже существующей информационной системой компании, границы не столь очевидны. Аналитик должен определить, будут ли данные использоваться совместно с другими приложениями, должно ли новое приложение распределяться по разным хостам и клиентам, а также кто будет пользователем. Например, должен ли персонал, занятый в производстве, иметь интерактивный доступ к заказам на покупку? Обеспечивается ли контроль качества или функции аудита? Будет ли система выполняться на компьютере-мэйнфрейме или на новом компьютере-клиенте? Должны ли предоставляться специальные отчеты?
Выявление актантов является ключевым аналитическим этапом в анализе проблемы. Ответы на следующие вопросы помогут их обнаружить.
-
Кто будет поставлять, использовать или удалять информацию из системы?
-
Кто будет управлять системой?
-
Кто будет осуществлять сопровождение системы?
-
Где будет использоваться система?
-
Откуда система получает информацию?
-
Какие внешние системы будут взаимодействовать с системой?
Имея ответы на эти вопросы, аналитик может создать блок-схему, описывающую границы системы, пользователей и другие интерфейсы.
2.3.6.Этап 5. Выявление ограничений, налагаемых на решение
Ограничение уменьшает степень свободы, которой мы располагаем при предложении решения.
Каждое ограничение может значительно сузить нашу возможность создать предполагаемое решение. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения. Многие из них могут даже заставить нас пересмотреть изначально предполагавшийся технологический подход.
Необходимо учитывать, что существуют различные источники ограничений (экономические, технические, политические и т.д.). Ограничения могут быть заданы еще до начала работы ("Никакой новой аппаратуры!"), но может получиться, что нам действительно придется их выявлять.
Чтобы их выявить, полезно знать, на что следует обратить внимание. В таблице 3.4 указаны возможные источники системных ограничений. Перечисленные в таблице вопросы помогут выявить большую часть ограничений. Часто полезно получить объяснение ограничения, как для того, чтобы убедиться, что вы поняли его назначение, так и для того, чтобы можно было обнаружить (если такое произойдет), что данное ограничение больше не применимо к вашему решению.
Таблица 2.6
Возможные источники ограничений системы
|
Источник |
Образцы вопросов |
|
Экономический |
|
|
Политический |
|
|
Технический |
|
|
Системный |
|
|
Эксплуатационный |
|
|
График и ресурсы |
|
После того как ограничения выявлены, некоторые из них станут требованиями к новой системе. Другие ограничения будут оказывать влияние на ресурсы и планы реализации. Именно при анализе проблемы необходимо выявить потенциальные источники ограничений и понять, какое влияние каждое ограничение окажет на область возможных решений.
Возвратимся к нашему примеру. Ограничения, которые могут налагаться на новую систему ввода заказов на покупку, представлены в таблице 3.5.
Таблица 2.7
Ограничения, налагаемые на систему ввода заказов на покупку
|
Источник |
Ограничение |
Объяснение |
|
Эксплуатационный |
Копия данных заказа на покупку должна оставаться в унаследованной базе данных в течении одного года |
Риск потери данных слишком велик |
|
Системы и операционные системы |
Приложение должно занимать на сервере не более 20 мегабайт |
Количество доступной памяти сервера ограничено |
|
Средства, выделенные на оборудование |
Система должна быть разработана на существующем сервере |
Сокращение издержек и поддержка существующих систем |
|
Средства, выделенные на оплату труда персонала |
Фиксированный штат; не привлекать работников со стороны |
Фиксированные расходы на зарплату по отношению к текущему бюджету |
|
Технические требования |
Должна использоваться новая объектно-ориентированная технология |
Мы надеемся, что эта технология повысит производительность и надёжность ПО |
2.4.Методология ARIS
В теории систем различают структуру системы и ее поведение. Структура описывает статику системы, а поведение описывает ее динамику. Четыре первых представления в ARIS (организационное, функциональное, представление выходов и представление данных) описывают структуру системы. В процессном представлении устанавливаются связи перечисленных представлений, и описывается динамическое поведение системы. На Рис. 2 .22 перечисленные представления сгруппированы в пять частей, образующих “здание” АРИС.
Функциональное представление содержит описание целей, выполняемых функций, перечень отдельных подфункций, а также общие взаимосвязи и связи подчиненности, которые существуют между функциями, целями и факторами успеха.
Организационное представление описывает взаимодействие пользователей и организационных единиц (ОЕ), а также их связи и имеющие к ним отношение структуры. Организационные модели служат для описания иерархической структуры организации, где группируются субъекты ответственности, ОЕ, должностей и средств, выполняющих работу над объектами, а также для многого другого.
В представлении данных описывают информационную среду предприятия (среду обработки данных), события, сообщения и т. д., где неявно фиксируются также объекты в виде информационных услуг.
Представление процессов (управления) используется для описания связей между тремя предшествующими представлениями. Интеграция этих связей в пределах отдельного представления делает возможным учесть все связи без избыточности. Модели представления процессов описывают отношения между отдельными моделями в рамках всего бизнес-процесса. Это позволяет отслеживать все двусторонние и многосторонние отношения между моделями различных видов, а также полностью описать бизнес-процесс.