Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

Объект исследования –этапы разработки программного продукта.

Предмет исследования – документальное сопровождение этапов жизненного цикла программных средств

Цель исследования данной курсовой работы – этапов разработки программных средств.

Для достижения этой цели в данной работе будут решаться следующие задачи

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

Тема данной работы довольно-таки хорошо рассмотрена различными авторами, среди которых можно отметить следующих: Иванова Г.С., Липаев В.В., Орлов С.А., Голосовский М.С., Гусятников В.Н., Макарова Н.В.

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

ГЛАВА 1. СТРАТЕГИИ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ

В 80-е и 90-е годы в области разработки ПО доминировали две тенденции [1, с.56]:

Одна тенденция - это быстро растущее количество приложений, в том числе созданных для Web.
Другая тенденция - это рост количества инструментов и парадигм (проектные подходы, такие как объектно-ориентированный).

Тем не менее, несмотря на появление новых тенденций, основные этапы разработки ПО остались неизменными:

• Определение процесса разработки ПО

• Управление проектом развития

• Описание целевого ПО

• Проектирование продукта

• Разработка продукта, то есть, его программирование

• Тестирование частей продукта

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

• Поддержка продукта

Система разработки ПО включает в себя процесс, персонал, и проект, и продукт, так называемое четыре «П» (рис. 1).

«Персонал» - люди, которые работают в команде. [12, с.45]

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

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

Рисунок 1 – Система разработки ПО

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

Программирование - это одно из мероприятий, включенных в цикл разработки ПО. [6, c. 55]

Программная инженерия должна охватывать различные типы программ[2, с.89]:

Независимое программное обеспечение:

установлено на одном компьютере; не связано с другим ПО и аппаратными средствами;
пример - текстовый редактор.

Интегрированное программное обеспечение:

часть уникального приложения внутри технических средств;
пример - контроллер автомобиля.

Программное обеспечение реального времени:

должны обеспечивать работоспособность в течение небольшого промежутка времени, обычно несколько микросекунд;
пример - ПО «Радары».

Сетевое программное обеспечение

состоит из частей, которые взаимодействуют через сеть;
пример – видеоигры на основе веб-технологии.

Выделяют следующие последовательности разработки: [13, с.156]

классическая;
итеративная:

спиральные
инкрементальные процессы

1.1. Каскадная стратегия разработки программных средств

Классической моделью процесса разработки ПО является каскадная (водопадная) модель, в котором процесс представляет чередования фаз (рисунок 2.): [3, с.22]

анализ требований,
проектирование,
внедрение,
интеграцию
тестирование

Рисунок 2 – Каскадная стратегия разработки программных средств

Анализ требований - является фазой сбора требований к продукту. В результате анализа, как правило, получается какой-нибудь текст.

Проектирование описывает внутреннюю структуру продукта. Как правило, такое описание дается в виде графиков и текстов.

Реализация - это программирование. Результатом является реализация кода на всех уровнях. [8, c.34]

Интеграция - это процесс сборки всех отдельных частей изделия.

Иногда процесс водопадной модели расширяют (рис. 3) в него включаются следующие дополнительные фазы.

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

Системное тестирования, которые проходят соответственно части приложения и все приложения в целом.

Поддержка, состоящая в модификации и поправки к приложению, и осуществляется в самом конце процесса.

За долгие годы функционирования каскадной стратегии разделение деятельности на этапы и их наименования постоянно изменялись. Помимо всего прочего, самые адекватные методики и стандарты не прикрепляли какие-либо установленные работы к конкретным стадиям. Но так или иначе, все же вполне возможно идентифицировать наиболее стабильные стадии:

- анализ требований заказчика;

- проектирование;

- разработка;

- тестирование и опытная эксплуатация;

- сдача готового продукта.

На первом этапе осуществляется анализ проблемы, которую необходимо решить, однозначно определяются потребности заказчика. Итогом этой стадии является согласованное техническое задание. [9, c.44]

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

Третий этап — реализация проекта. На данной стадии разрабатывается ПО в соответствии тезисами, выработанными на предшествующей стадии. Методы, применяемые для реализации, не принципиальны, а склонны к изменениям, исходя из конкретной ситуации. На данном этапе производится готовый программный продукт. [10, c.86]

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

Последний этап - сдача нового проекта. Ключевая задача данной стадии — доказать клиенту, что все его требования целиком и полностью выполнены. Стадии деятельности в разрезе классической стратегии нередко именуют компонентами «проектного цикла» системы ввиду того, что они включают множество системных итераций и алгоритмов проектных решений. Жизненный цикл самой системы намного сложнее по структуре. Он способен хранить в себе случайное количество циклов уточнения, изменения и дополнения уже принятых и осуществленных проектных решений. В данных циклах осуществляется развитие ИС и модернизация ее составляющих.

Рисунок 3 – Расширенная каскадная стратегия разработки программных средств

В чистом виде, процесс водопадной модели редко используется, кроме как в случае небольших проектов или когда команда осуществляет проект, аналогичный прежним. Ключевой причиной неприменимости процесса водопадной модели в чистом виде является сложность многих приложений. [14, с.123]

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

Существуют два типа итеративных процессов:

спиральная модель
итеративная модель.

1.2. Спиральная стратегия разработки программных средств

Здесь фазы «анализ требований - проектирование - реализация – тестирование» выполняются более одного раза.

Это может происходить ввиду нескольких причин. Ключевая из них связана с необходимостью предотвращения рисков. Другой причиной может быть запрос заказчиком прототипа проекта, чтобы получить обратную связь и предложения. Если разработанное ПО довольно громоздко, необходимо выполнить промежуточную интеграцию, не откладывая эту фазу в самом конце, как это предписано водопадной моделью. [15, с.201]

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

Рисунок 4 – Спиральная стратегия разработки программных средств

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

Одна из сложностей состоит в поддержании целостности документации, которую необходимо целиком обновлять и расширять в конце всякой итерации. Так, каждая версия кода должна осуществлять документированный проект и документально соответствовать тем же требованиям. [16, c.55]

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

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

Ключевая проблема данной стратегии – нахождение момента перехода на дальнейшую стадию. [18, c.41] Поэтому целесообразно создать временные рамки на каждую стадию жизненного цикла. Переход проводится по плану, даже если не вся запланированная работа завершена. План формируется на базе статистической информации, приобретенной в предыдущих проектах, и личного опыта разработчиков.

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

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

Недостатки спиральной модели: новизна (нет полной статистики эффективности модели); повышенные требования к клиенту; сложность регулирования и управления временем разработки.

1.3. Инкрементная стратегия разработки программных средств

Иногда можно постепенно продвигать проект вперед, по существу, не прерывая процесс разработки. Эта модель процесса является особенно полезной в более поздних стадиях проекта, когда продукт сдан, или при сопровождении разработанного продукта очень похожего на ранее существовавший. [21, с.22]

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

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

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

Рисунок 5 – Инкрементальная модель процесса разработки программных средств

Сравним модели процесса разработки.

Характеристики особенностей для рассматриваемых стратегий изображены на рисунке 6.

Рисунок 6 - Сравнение процессов разработки

Далее следуют пояснения к рисунку 6.

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

2. Шаги спиральной разработки немногочисленны, что позволяет проектировать на высоком уровне, но вместе с тем их сравнительно много, чтобы гарантировать проектировщикам понимание проблем проекта. Это преимущество аргументирует повсеместное применение спиральной стратегии.

Преимущества данной стратегии:

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

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

- заказчик может вмешиваться в разработку продукта на каждом этапе осуществления стратегии;

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

- есть опция поддержки непрерывного прогресса в процессе реализации продукта;

- уменьшаются затраты на первоначальную поставку программного продукта. [20, c.91]

Менеджер проекта может быть уверен в правильности использования модели, если есть следующие условия:

- преимущественное число требований возможно установить заранее, но их появление планируется через некоторый промежуток времени;

- рыночное окно очень мало и есть необходимость оперативно ввести на рынок продукт, обладающий функциональными основными качествами;

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

- при равномерном распределении признаков разной степени важности.

ГЛАВА 2. ЭТАПЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1.Описание моделей бизнес-процессов объекта автоматизации

Модель «как есть» («as-is») представляет собой «снимок» положения дел в работе бухгалтера на момент обследования и позволяет понять, что делает и как функционирует данное подразделение с позиций системного анализа, а также выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации. В процессе анализа моделей бизнес-процессов «как есть» следует выяснить, соответствуют ли привлекаемые для выполнения процесса ресурсы поставленным задачам. Может оказаться, что для обеспечения выполнения процесса привлечены лишние ресурсы: материальные, финансовые, человеческие и т.д. Устранение лишних ресурсов должно привести к снижению стоимости бизнес-процесса в целом.

Для построения модели бизнес-процесса («как есть») можно будет использовано CASE-средство BPWin 4.1. с использованием методологии IDEF3.

На рисунке 7 представлена контекстная диаграмма бизнес-процесса

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

На рисунке 8 представлена декомпозиция контекстной диаграммы
А-1.

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

2.2.Определение недостатков существующей системы обработки информации

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

Объект аренды должен быть определен предельно четко: наименование, качественные и количественные характеристики и иные данные, позволяющие однозначно идентифицировать имущество, передаваемое в аренду; для недвижимого имущества – адрес, площадь, номера и наименование помещений в соответствии с данными БТИ (экспликация и поэтажный план, которые являются приложением к договору аренды). При отсутствии этих данных согласно ч.3.ст.607 ГК договор считается незаключенным.

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

Перечисленные выше сведения целесообразно включить в раздел «Предмет договора».

Арендатор обязан своевременно вносить плату за пользование имуществом (арендную плату).

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

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

1) определенных в твердой сумме платежей, вносимых периодически или единовременно;

2) установленной доли полученных в результате использования арендованного имущества продукции, плодов или доходов;

3) предоставления арендатором определенных услуг;

4) передачи арендатором арендодателю обусловленной договором вещи в собственность или в аренду;

5) возложения на арендатора обусловленных договором затрат на улучшение арендованного имущества.

Стороны могут предусматривать в договоре аренды сочетание указанных форм арендной платы или иные формы оплаты аренды.

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

Традиционной на сегодняшний день является практика начисления арендной платы, при которой арендная ставка является фиксированной на весь срок договора (обычно 3-5 лет). При этом для разных арендаторов размер арендной ставки устанавливается дифференцированно и зависит от профиля арендатора (например, якорные арендаторы – супермаркет, кинотеатр и т.д. - платят меньше), арендуемой площади (чем больше площадь, тем меньше арендная ставка), этажности и т.д.

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

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

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

Размер арендной платы и размер доли от оборота определяется в процессе переговоров в каждом конкретном случае индивидуально. В настоящее время ставки, взимаемые с процента от оборота предприятия, варьируются следующим образом: 4-5% для крупных супермаркетов, 15-20% для предприятий, специализирующихся на продаже одежды и обуви, более 20% для предприятий, торгующих ювелирными изделиями и т.д.

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

2.3.Определение цели и задач проектирования ИС. Формирование требований к информационной системе

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

Задачи и назначение программного обеспечения:

1) заключение договоров с арендаторами, возможное продление уже существующих договоров, редактирование введенных данных;

2) ведение поступлений платежей от арендаторов;

3) ведение базы платежей с определением неплательщиков;

4) обеспечение поиска и выборки данных по различным критериям и их сочетаниям;

5) подготовка отчетов по приему платежей, договоров, арендаторов, торговых площадей;

6) формирование отчетов и других выходных данных.

К разрабатываемой системе предъявляются следующие требования:

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

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

Система должна обладать следующими возможностями:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К основополагающим стандартам относятся 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]
Стандарт ISO 9000-1 (ДСТУ ISO 9000-1-95; EN 29000). Общее руководство качеством и стандарты по обеспечению качества. Ч. 1. Руководящие указания к выбору и применению. Стандарт уточняет главное — принципы, относящиеся к качеству, и обеспечивает методическую помощь при выборе и применении стандартов ISO серии 9000. Стандарт содержит основные понятия, анализ ситуаций, в которых применяются системы качества и методические указания. Организациям, которые планируют создание системы качества, следует начинать работу с изучения руководящих указаний стандарта ISO 9000-1.
3. ETSI (Европейский институт стандартизации электросвязи) – год создания 1988. Это независимая, некоммерческая, организация по стандартизации в области телекоммуникаций (производители оборудования и операторы сети) в Европе. Наиболее известные стандарты - GSM, система TETRA профессиональной мобильной радиосвязи.
Существует определенная система стандартов (рисунок 8), определяющих различные элементы в структуре жизненных циклов разработки программных систем. Поскольку эти элементы являются основными для процесса разработки, - они четко отличают разные наборы деятельности, которые решают одну проблему или взаимосвязанную последовательность задач, такую как создание процесса, процесс отслеживания программного обеспечения, процесс формирования качества, процесс создания документации, тестирование процесс и так далее.
Процессы определяют различные этапы жизненного цикла и связывают их с различными видами деятельности, роли вовлеченных людей, цели, результаты. Они фиксирует все этапы жизненного цикла процесса управления изменениями разработки программного обеспечения.

Рисунок 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 – Схема связи между этими документами

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

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

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

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

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

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

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

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

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

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

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

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

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

Use Case

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

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

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

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

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

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

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

Test Case

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

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

Bug Report

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

Международными организациями (такими как IEEE, ISO, EIA, IEC), а также некоторыми национальными и региональными институтами и организациями (такими как ANSI, SEI, ECMA) разработана система стандартов, регламентирующих разные аспекты жизненного цикла и включённых в него процессов.

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

Также в работе подробно рассмотрен процесс документации программного средства.

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

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

На основании некоторых ГОСТов в данной курсовой работе разработан пример оформления документации для задачи. Также рассмотрено создание документации к программе:

Технического задания
Описание программы
Руководство оператора.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Д. Кнут Искусство программирования. Том 4. - М.: Мир, 2011, - 900 с.
Душин В.К. Теоретические основы информационных процессов и систем: Учебник. – М.: Дашков и К, 2012. – 348 с.
Идеальная разработка ПО. Рецепты лучших программистов - СПб.: Питер, 2012 - 592 с.: ил
Куприянов Д.В., Белоусова С.Н., Меликян А.В. Введение в программные системы и их разработку. – М.: Интуит, 2012. – 755 с.
Культин Н. Б. Delphi в задачах и примерах. - БХВ-Петербург, 2012. – 288 с.
Кознов Д. Введение в программную инженерию: Учебный курс. – М.: Интуит, 2010. – 390 с.
Информатика [Электронный ресурс] URL http://library.kuzstu.ru/ (Дата обращения 17.07.2017).
Липаев В.В. Проектирование и производство сложных заказных программных продуктов. – М.: Синтег, 2011. – 408 с.
Липаев В.В. Процессы и стандарты жизненного цикла сложных программных средств. Справочник. – М.: Синтег, 2010. – 315 с.
Макарова Н.В. Информатика. – СПб: Питер, 2013. – 573 с.
Макконнелл С. Совершенный код. Мастер класс / Пер. с англ. — М.: Издательство «Русская редакция», 2012. — 896 стр. : ил.
Мацяшек, Лешек А., Лионг, Брюс Ли Практическая программная инженерия на основе учебного примера : учебное пособие: М.: БИНОМ. Лаборатория знаний, 2012 - 956 с.: ил.
Мезенцев К.Н. Автоматизированные информационные системы: Учебник. – М.: Академия, 2013. – 357 с.
Минитаева А.М. Разработка и стандартизация программных средств и информационных технологий. – Омск: ОмГТУ, 2011. – 92 с.
Орлов С.А. Технологии разработки программного обеспечения. Современный курс по программной инженерии. – СПб: Питер, 2012. – 608 с.
Стандарты в области разработки программного обеспечения. [Электронный ресурс] URL: http://iteam.ru/publications/project/section_35/ article_795 (дата обращения: 17.07.2017).
Рудаков А.В. Технология разработки программных продуктов: Учебник. – М: Академия, 2011. – 207 с.
Рассел Д. Жизненный цикл программного обеспечения. – М.: VSD, 2012. – 89 с.
Разработка и стандартизация программных средств. Электронный ресурс] URL: http://www.xsieit.ru/download/the_development_and_ standardization_of_software-tools/lectures (дата обращения: 17.07.2017).
Орлов, Сергей Александрович, Цилькер, Борис Яковлевич. Технологии разработки программного обеспечения : современный курс по программной инженерии: учебник . -4-е изд. : СПб.: Питер, 2012 - 608 с.: ил.
Чумакова Т.Я., Цыганенко С.М. Международные стандарты и жизненные циклы программного обеспечения. // Математические машины и системы. – 2010. – №3. – С. 45-51.