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

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

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

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

Добавлен: 04.12.2020

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

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

Заключение

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

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.Установление стратегии документирования

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

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

Стратегия должна поддерживать основные элементы эффективного документирования:

1) требования документации охватывают весь жизненный цикл программного обеспечения;

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

2) документирование должно быть управляемым.

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

3) документация должна соответствовать ее читательской аудитории.

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

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

Процесс разработки должен быть определен;

5) должны быть определены и использованы стандарты по документированию.

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

6) должны быть определены средства поддержки.

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

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

Внутри организаций должны быть приняты стандарты и руководства для:


  • модели жизненного цикла программного обеспечения;

  • типов и взаимосвязей документов;

  • содержания документа;

  • качества документа;

  • форматов документа;

  • обозначения документа.

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

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

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

  • какие типы документов требуются?

  • каков объем представляемой документации?

  • что документы содержат?

  • какой уровень качества будет достигнут?

  • где документы будут созданы?

  • как документы будут хранить, сопровождать и обращать?

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

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

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

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

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

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

Программные документы можно представить разделенными на три категории:

  1. документация разработки;

  2. документация продукции;

  3. документация управления проектом;


Документация разработки

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

Разработка документов преследует пять целей:

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

2) они описывают обязанности группы разработки. Они определяют, кто, что и когда делает, учитывая роль программного обеспечения, предмета работ, документации, персонала, обеспечивающего качество, и каждого вовлеченного в процесс разработки;

3) они выступают как контрольные пункты, которые позволяют руководителям оценивать ход разработки. Если документы разработки отсутствуют, неполны или устарели, руководители теряют важное средство для отслеживания и контроля проекта программного обеспечения;

4) они образуют основу документации сопровождения программного обеспечения, требуемой сопровождающими программистами как часть документации продукции;

5) они описывают историю разработки программного обеспечения.

Типовыми документами разработки являются:

  1. анализы осуществимости и исходные заявки;

  2. спецификации требований;

  3. спецификации функций;

  4. проектные спецификации, включая спецификации программ и данных;

  5. планы разработки;

  6. планы сборки и тестирования программного обеспечения;

  7. планы обеспечения качества, стандарты и графики;

  8. защитная и тестовая информация.

Документация продукции

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

Документация продукции преследует три цели:

  • она обеспечивает учебную и справочную информацию для любого использующего или эксплуатирующего программную продукцию;

  • она облегчает программистам, не разрабатывавшим программное обеспечение, его сопровождение и модернизацию;

  • она помогает продаже или приемке программной продукции.

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

  • пользователей, которые вводят данные, восстанавливают информацию и решают задачи с помощью программного обеспечения;

  • операторов, которые «прогоняют» программное обеспечение на вычислительной системе;

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


Документация продукции может также включать в себя:

  • руководства и материалы для руководителей, которые следят за использованием программного обеспечения;

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

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

Типовые документы продукции включают в себя:

  • учебные руководства;

  • справочные руководства и руководства пользователя;

  • руководства по сопровождению программного обеспечения;

  • брошюры и информационные листовки, посвященные продукции.

Документация управления проектом

Документы создают на основе информации управления проектом, такой как:

  • графики для каждой стадии процесса разработки и отчеты об изменениях графиков;

  • отчеты о согласованных изменениях программного обеспечения;

  • отчеты о решениях, связанных с разработкой;

  • распределение обязанностей.

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

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

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

Понятия качества, применимые к содержанию, структуре и представлению документации:

  • качество содержания можно измерять в элементах точности, полноты и ясности;

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

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

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

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

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

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

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

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