Файл: Основы проектирования программ. Этапы создания программного обеспечения (Разработка стандартов для процесса документирования).pdf

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

2.4.Проектирование оптимальных бизнес-процессов с учетом внедрения информационной системы

Автоматизацию рабочего места бухгалтера ТЦ «Семеновский» можно представить в виде моделирования информационных потоков. Для этого строится схема исследуемой системы при помощи функциональной методики IDEF0.

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

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

Управляющими данными являются законодательство РФ и инструкции.

В качестве механизмов выступают: персонал, программное обеспечение.

Выходными являются отчеты о проделанной работе, договора.

Контекстная диаграмма основной задачи автоматизации рабочего места бухгалтера ТЦ «Семеновский» изображена на рисунке 9

Рисунок 9 – Контекстная диаграмма

Диаграмма декомпозиции моделирования потоков данных изображена на рисунке 10

Рисунок 10 – Диаграмма декомпозиции

2.5. Разработка концептуальной модели данных

На основе информации, выявленной на этапах бизнес-моделирования, разрабатывается концептуальная модель данных, которая будет использоваться в программном обеспечении «АРМ бухгалтера»
(рисунок 11).

Рисунок 11 – Концептуальная модель

• 0..1 – ноль или один экземпляр;
• 1 – обязательно один экземпляр;
• 0..* – ноль или более экземпляров;

1..* – один или более экземпляров.

ГЛАВА 3. ПРОЦЕСС ДОКУМЕНТИРОВАНИЯ СТРАТЕГИЙ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ

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

3.1. Разработка стандартов для процесса документирования

1. Стандарты обеспечивают совместимость между проектами. Это означает, что код и документация, разработанные для одного случая могут быть переданы в другой. Стандарты улучшают понимание среди инженеров.
2. Следующие организации публикуют важные стандарты. [7]
3. 1. IEEE – год образования 1865. Его главная задача - стандартизированные телекоммуникационные протоколы и интерфейсы с целью поддержания и развития глобальной мировой телекоммуникационной сети. Наиболее известные стандарты:
4. • ISDN (цифровая телефонная служба, которая сочетает в себе услуги телефонной связи и передачи данных)
5. • ADSL (известная технология модемного подключения позволяет использовать телефонную линию для подключения к Интернету, без блокирования нормальной телефонной связи)
6. • OSI (Открытая модель сетевого протокола 7-уровневая, на основе которой существуют все современные стандартные сетевого интерфейса и протоколы)
7. • Языки визуального проектирования телекоммуникационных систем, SDL и MSC, которые слились позже в UML.
8. 2. ISO (Международная организация по стандартизации) – год образования 1964. Цель - содействие развитию стандартизации и смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услугами, а также содействовать развитию сотрудничества в интеллектуальной, научной, технической и экономической областях. На сегодняшний день создано около 17 000 стандартов ISO в различных областях.
9. Стандарты ISO семейства 9000, описывают технологические процессы, связанные с разработкой программного продукта (рисунок 12)
10. 

Рисунок 12 – Семейства стандартов ИСО

1. К основополагающим стандартам относятся ISO 9000-1, ISO 9001, ISO 9002, ISO 9003 и ISO 9004-1. Любая организация, внедряющая систему качества, должна выбрать одну из трех моделей обеспечения качества (стандарт ISO 9001, ISO 9002 или ISO 9003) и сделать ссылки на стандарты ISO 9000-1 и ISO 9004-1. [17]
2. Стандарт ISO 9000-1 (ДСТУ ISO 9000-1-95; EN 29000). Общее руководство качеством и стандарты по обеспечению качества. Ч. 1. Руководящие указания к выбору и применению. Стандарт уточняет главное — принципы, относящиеся к качеству, и обеспечивает методическую помощь при выборе и применении стандартов ISO серии 9000. Стандарт содержит основные понятия, анализ ситуаций, в которых применяются системы качества и методические указания. Организациям, которые планируют создание системы качества, следует начинать работу с изучения руководящих указаний стандарта ISO 9000-1.
3. 3. ETSI (Европейский институт стандартизации электросвязи) – год создания 1988. Это независимая, некоммерческая, организация по стандартизации в области телекоммуникаций (производители оборудования и операторы сети) в Европе. Наиболее известные стандарты - GSM, система TETRA профессиональной мобильной радиосвязи.
4. Существует определенная система стандартов (рисунок 8), определяющих различные элементы в структуре жизненных циклов разработки программных систем. Поскольку эти элементы являются основными для процесса разработки, - они четко отличают разные наборы деятельности, которые решают одну проблему или взаимосвязанную последовательность задач, такую как создание процесса, процесс отслеживания программного обеспечения, процесс формирования качества, процесс создания документации, тестирование процесс и так далее.
5. Процессы определяют различные этапы жизненного цикла и связывают их с различными видами деятельности, роли вовлеченных людей, цели, результаты. Они фиксирует все этапы жизненного цикла процесса управления изменениями разработки программного обеспечения.
6. 

Рисунок 8 – Классификация стандартов

3.2. Процесс документации программного средства

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

Ниже приводится описание каждого документа из набора IEEE [19, с.56]

SVVP (Software Verification and Validation Plan): План экспертизы программного обеспечения. Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам продукт на соответствие поставленным требованиям. Верификация — это процесс проверки правильности сборки приложения; валидация проверяет тот факт, что собран требуемый продукт. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (IV&V — Independent V&V).

Рисунок 9 – Документация проекта

SQAP (Software Quality Assurance Plan): План контроля качества программного обеспечения. Этот план определяет, каким образом проект должен достигнуть соответствия установленному уровню качества. [4, с.86]

SCMP (Software Configuration Management Plan): План управления конфигурациями программного обеспечения. SCMP определяет, как и где должны храниться документы, программный код и их версии, а также устанавливает их взаимное соответствие. Было бы крайне неразумным начинать работу без такого плана, так как самый первый созданный документ обречен на изменения, а мы должны знать, как управлять этими изменениями до того, как мы начнем составлять документ.

SPMP (Software Project Management Plan): План управления программным проектом. Этот план определяет, каким образом управлять проектом. Обычно он соответствует известному процессу разработки, например стандартному процессу компании.

SRS (Software Requirements Specification): Спецификация требований к программному обеспечению. Этот документ определяет требования к приложению и является подобием контракта и путеводной нити для заказчика и разработчиков.

SDD (Software Design Document): Проектная документация программного обеспечения. SDD представляет архитектуру и детали проектирования приложения, обычно с использованием диаграмм объектных моделей и потоков данных.

STD (Software Test Documentation): Документация по тестированию программного обеспечения. Этот документ описывает, каким образом должно проводиться тестирование приложения

3.3. Документация стратегии разработки программного средства

Каждая организация в процессе своей работы приходит к собственной схеме ведения документации и к выбору программных средств удобных для них. Рассмотрим на примере компании ООО «ИнформЗащита», какие выводы получили они из 20 летнего опыта разработки [11, с.56].

1. Документация не должна быть избыточной и объемной. Избыточное количество текста – раздражает и затрудняет восприятие.

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

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

4. Всегда необходимо формировать списки оповещения заинтересованных участников. [5, с.23]

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

1. Техническое задание.

2. Частное техническое задание (опционально).

3. Сценарий использования (Use Case).

4. Сценарий тестирования (Test Case).

5. Отчет об ошибке (Bug Report).

6. Руководство пользователя.

7. Руководство администратора (опционально).

На рисунке ниже — схема связи между этими документами.

Рисунок 10 – Схема связи между этими документами

1. Техническое задание

Большое Техническое задание включает в себя:

• словарь терминов предметной области;

• описание предметной области;

• описание ролевой системы;

• описание функциональных требований;

• описание нефункциональных требований.

1. Частное техническое задание

В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.

ЧТЗ должны содержать:

• ссылку на пункт ТЗ;

• максимально подробную информацию по каждой функции;

• список UseCases для функции.

1. Use Case

Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.

Каждый Use Case должен быть привязан к пункту ЧТЗ.

формат описания, включает:

• Макет экрана.

• Диаграмму действий экрана

• Таблицу с описанием полей.

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

1. Test Case

Test Case, должен содержать описание тестовых сценариев.

Каждый такой документ привязывается к соответствующему Use Case

1. Bug Report

Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.

Содержать документ должен:

• скриншот возникшей ошибки;

• описание предшествующих действий.

• текстовое описание самой ошибки.

1. Руководство пользователя/Руководство администратора

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

• ГОСТ Р ИСО 9127-94 «Документация пользователя и информация на упаковке для потребительских программных пакетов»
• ГОСТ Р ИСО/МЭК 15910-2002 «Процесс создания документации пользователя программного средства»
• ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
• ГОСТ 19.402-78 ЕСПД. Описание программы. Требования к содержанию и оформлению.
• ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
• ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению.
• ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — стандарт на ТЗ.

ЗАКЛЮЧЕНИЕ

Несмотря на появление новых тенденций, основные этапы разработки ПО остались неизменными. Описания. Данный этап включает в себя совместную работу заказчика (определяет пользу продукта, требования к внешнему виду и работоспособности) и разработчика (предлагает алгоритмические и технические решения поставленной задачи). Определения архитектуры. На данном этапе утверждают язык программирования, базу данных, фреймворки и серверы. Разработки технического задания (ТЗ). ТЗ составляет архитектор в соответствии с описанием и ответами на вопросы заказчика. Затем ТЗ согласовывают с менеджером проекта, далее передают клиенту и производят правки. Этапа разработки макетов, которые затем добавляются к ТЗ. На данном этапе разрабатывают макеты принципиальных схем устройства, интерфейсов, диаграмм структуры базы данных, схем взаимодействия компонентов. Контроля. В ходе этого этапа архитектором устраняются замечания менеджера проектов. Утверждения. На данном этапе заказчиком проверяется и меняется самостоятельно ТЗ, либо сообщается список правок проект-менеджеру. После устранения замечаний ТЗ утверждают и прилагают к контракту.