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

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

Содержание:

Введение

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

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

Характер математического и программного обеспечения АСУ существенно меняется по мере развития возможностей технических средств. В нашей стране принята программа всеобщей компьютерной грамотности и массового выпуска персональных микроЭВМ, обладающих высокой производительностью, развитой памятью и возможностью объединения в локальные вычислительные сети.

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

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

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

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

1 Проектирование программного обеспечения

1.1 Основы разработки программ

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

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

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

Процесс программирования может сопровождаться как «ручным» проектированием, так автоматизированным. Это зависит от класса создаваемого продукта. В процессе проектирования программы для выражения его характеристик используются различные нотации — блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат:

Архитектура программного обеспечения;
Устройство компонентов программного обеспечения;
Пользовательские интерфейсы.

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

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

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

1.2 Жизненный цикл

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

Провести анализ предметной области и составить техническое задание (на этом этапе разработчики взаимодействуют с заказчиком)
Разработать структуру программы
Набрать программный код согласно проектной документации
Протестировать и произвести отладку
Внедрить программное обеспечение в эксплуатацию
Сопроводить программное обеспечение
Утилизировать.

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

сведения об элементах,
сведения о явлениях,
сведения об отношениях,
сведения о процессах.

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

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

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

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

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

Для проектирования модульных программ применяются два основных метода: нисходящего и восходящего проектирования.

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

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

Понятие жизненного цикла (software life cycle) рассматривают как, период с момента возникновения идеи до изъятия его из эксплуатации. Жизненный цикл включате в себя довольно сложный процесс создания и использования (software process). Организация этого процесса зависит от класса программного продукта и коллектива разработчиков.

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

Рисунок 1. Пример взаимосвязи между стандартными процессами и стадиями

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

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

Рисунок 2. Водопадный подход

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

Еще одним подход является прототипирование. В этом подходе сначала моделируется начальная фаза исследовательского программирования. Моделируются и рабочие версии программного продукта, которые используются экспериментов. Цель таких экспериментов - установление требований к программе. Дальнейшая разработка проводится по любым другим подходам, например каскадным. Модель прототипирования изображена на рисунке 3.

Рисунок 3 - Модель прототипирования

Следующий подход – подход формальных преобразований. Этот подход состоит из разработки формальных спецификаций программы и преобразование их в программы путем корректных преобразований. Этот подход лежит в основе компьютерных технологий (CASE-технологий) разработки программных средств. Схема процессов в CASE-технологиях приведена на рисунке 4.

Рисунок 4 - Схема процессов в CASE-технологиях

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

2 Этапы разработки программного обеспечения

2.1 Этапы разработки ПО согласно ГОСТ 2.103-68

Среди российских программистов распространена практика создания программ согласно стадиям ГОСТ 2.103-68:

Техническое предложение,
Эскизный проект,
Технический проект,
Рабочий проект.

На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).

На стадии Техническое предложение выполняются следующие виды работ:

Подбор материалов.
Разработка технического предложения с присвоением документам литеры «П».
Рассмотрение и утверждение технического предложения

Стадия Эскизный проект характеризуется следующими работами:

Разработка эскизного проекта с присвоением документам литеры «Э».
Изготовление и испытание макетов (при необходимости)
Рассмотрение и утверждение эскизного проекта.

Для стадии Технический проект характерны следующие действия:

Разработка технического проекта с присвоением документам литеры «Т».
Изготовление и испытание макетов (при необходимости).
Рассмотрение и утверждение технического проекта.

Стадия Рабочий проект самая объемная по количеству работ. На этой стадии выполняются такие действия, как:

Рассмотрение и утверждение технического проекта.
Разработка конструкторской документации, предназначенной для изготовления и испытания опытного образца (опытной партии), без присвоения литеры.
Изготовление и предварительные испытания опытного образца (опытной партии).
Корректировка конструкторской документации по результатам изготовления и предварительных испытаний опытного образца (опытной партии) с присвоением документам литеры «О».
Приемочные испытания опытного образца (опытной партии).

2.2 Этапы разработки ПО Software Architecture Document

В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document

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

Весь процесс разработки состоит из фаз.

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

Этот этап сопровождается следующей документацией:

Техническое задание (Software Requirement Specification)
Проектное предложение (Project Proposal)
План проекта (Project Plan)
Архитектура приложения (Software Architecture Document)

Техническое задание (Software Requirement Specification)определяет технические требования, в общем то, что клиент ожидает от будущей программы.

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

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

Документ Архитектура приложения заключает в себе всесторонний обзор архитектуры. Он описывает различные стороны решения. А также служит для фиксирования и передачи важных архитектурных решений при разработке.

Вторая фаза - проектирование системы

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

Этот этап сопровождается документом - Технический дизайн (Design Document).

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

разработка структуры данных,
архитектурное проектирование,
разработка интерфейсов ,
процедурное разработка.

Третья фаза представляет собой собственно процесс разработки.

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

На данном этапе создаются такие документы как, План тестирования (Test Plan) и Тестовые примеры (System Test Cases).

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

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

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

Следующая фаза - Системное тестирование.

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

Эта фаза характеризуется следующими действиями:

Прохождение тестовых примеров (Test cases running)
Исправление найденных ошибок (Bug Fixing)
Анализ запросов на изменения/исправления (Change request review)
Уточнение тестовых примеров (Update test cases)
Уточнение технического дизайна приложения (Update Design Document)

Этот этап сопровождается следующей документацией:

Уточненные Тестовые примеры (Test Cases)
Журнал испытаний (Test Log sheet)
Запрос на модификацию(Approved Change Requests)
Уточненный Технический дизайн (Updated Design Document)

Последняя фаза - Установка и интеграция.

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

В ходе данного этапа создается следующая документация:

Акт приемки системы (Sign Off on Acceptance)
Перечень ошибок (List of QA bugs)
Руководство пользователя (User Manual)
Инструкция по установке системы (Installation/Release Notes)

Участники процесса разработки ПО

Пользователь
Заказчик
Разработчик
Руководитель проекта
Аналитик
Тестировщик
Поставщик

2.3 Майлстоун

Майлстоун (milestone) — метафора, которой в software development обозначают промежуточный этап разработки проекта.

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

Майлстоун фиксирует все принятые решения, чтобы у разработчиков не возникало соблазна переделывать всё до бесконечности.

Исторически, майлстоуны — это каменные плиты с указанием расстояний до населённых пунктов, которые расставлялись вдоль дорог и служили ориентиром путешественникам.

Milestone - этапы разработки, каждая из которых имеет свой номер (1, 2, 3 и т.д.). Это может быть как пре-альфа, как и бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как pre-. Например pre-Milestone 1.

Рассмотрим каждый этап Milestone.

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

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

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

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

Бета-продукт не претендует на название финальной версией. Так как публичное тестирование производится усмотрение пользователя, то разработчик снимает с себя ответственность за ущерб, причинённый в результате использования бета-версии. Такой положение предоставляет многим производителям возможность уйти от ответственности, представляя только бета-версии продукта.

Следующая стадия используется крайне редко - Beta Escrow. Другое название стадия бета-тестирования, релиз-кандидат на Beta.

Релиз-кандидат – одна из основных стадий.

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия - кандидат на то, чтобы стать стабильной. В программах на этой стадии были найдены и исправлены все найденные ошибки, то есть они прошли комплексное тестирование. Тем не менее, не исключено появление некоторого числа ошибок, которые были не найдены на тестировании.

Стадия RC Escrow – это релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

Стадия релиз или RTM (англ. release to manufacturing промышленное издание) – это выпуск программного продукта, который готов к тиражированию. Обычно - это стабильная версия программного обеспечения, который прошел все предыдущие стадии. На предыдущих стадиях были исправлены основные ошибки. Также существует малая вероятность появления новых, ранее не замеченных, ошибок.

Стадия RTM Escrow – это конечный этап разработки программы, которая готова стать RTM-релизом.

Стадия Пост-релиз или Post-RTM (англ. post-release to manufacturing) - это издание продукта, у которого есть несколько отличий от RTM. Иногда из этой стадии получается первая стадия разработки следующего продукта. Такие релизы продаются, а раздаются бета-тестерам. Это может быть как и стабильная (если не замечено ошибок) либо с ошибками.

Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко. Beta-Escrow, RC-Escrow, RTM-Escrow - статус, указывающий, что на определенном этапе продукт не имеет серьезных ошибок в коде. Сборки с этим статусом передаются для тестирования ключевым и TAP-партнерам. Если тестирование не выявляет серьезных проблем - код подписывается для публичного тестирования

2.4 MSF

Microsoft предлагает MSF (Microsoft Solution Framework) Process Model. MSF – методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения.

Еще есть RUP – Rational Unified Process.

Рассмотрим суть MSF. Разработка продукта согласно MSF включает следующие фазы:

Формулирование идеи (концепции) проекта.
Планирование.
Разработка.
Стабилизация решения.
Развертывание.

Каждая фаза оканчивается контрольной точкой или вехой или milestone (рис.5).

Рисунок 5 – Схема процессов MSF

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

Роли могут быть следующие.

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

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

Рисунок 6 - Рекомендации по распределению ролей

2.4 Трудности при проектировании программного обеспечения

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

Одной из проблем является недостаток прозрачности. Она заключается в сложности отслеживания процесса проектирования.

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

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

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

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

Недостаточная надёжность также является типичным затруднением в процессе проектирования программного обеспечения. Выявление и исправление ошибок одни из самых сложных действий. Так количество ошибок невозможно предугадать, то и определить время, отводимое на их исправление также невозможно предсказать. Гарантировать отсутствие ошибок не представляется возможным. Решением может являться доказательный подход к процессу. Свой вклад в развитие данного подхода внесли такие ученые как Кнут, Дейкстра и Вирт. Доказательный подход позволяет обнаружить ошибки в программе до её выполнения.

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

Неудачный выбор методологии конструирования программ. От выбора необходимой методологии зависят многие показатели программного обеспечения, такие как гибкость, стоимость и функциональность. Так называемые гибкие методологии разработки помогают решить основные проблемы, однако, стоит отметить, что и каскадная модель (waterfall) так же имеет свои преимущества. В некоторых случаях наиболее целесообразным будет применение гибридных методологий в связке Agile + каскадная модель + MSF + RUP и т.д.

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

Однако данное затруднение не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества — это проблема выбора поставщика товара (не продукта).

Заключение

Разрабо́тка програ́ммного обеспе́чения (software development) — это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.

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

Этапы разработки ПО согласно ГОСТ 2.103-68
Этапы разработки ПО Software Architecture Document
Майлстоун
MSF .

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

Список литературы

ГОСТ 2.103-68. Единая система конструкторской документации. Стадии разработки. М.:Стандартинформ, 2007. 38 с.
Абросимова А.С., Белова С.В. Пошаговая детализация как метод проектирования алгоритмов // Современные наукоемкие технологии. 2013. № 8 (1). С. 109-110.
С. Девятов. Проектирование программного обеспечения с использованием стандартов UML 2.0 и SysML 1.0 . Litres, 2014 г.
Орлов С.А. Технологии разработки программного обеспечения: современный курс по программной инженерии : [по специальности "Программное обеспечение вычислительной техники и автоматизированных систем"] . Спб.: Издательский дом "Питер", 2012. 608 с.
Одинцов И. О. Профессиональное программирование. Системный подход, 2 изд. Спб.:БХВ-Петербург, 2004. 624 с.
Супрун А. Жизненный цикл и версии программного обеспечения. URL: http://popel-studio.com/blog/article/zhiznenniy-tsikl-i-versii-programmnogo-obespecheniya.html
Дэвид Белладжио, Том Миллиган. Стратегия управления конфигурацией программного обеспечения с использованием IBM Rational ClearCase. Litres, 17 янв. 2014 г.
Молчанов А.Ю. Системное программное обеспечение: [по специальностям "Вычисл. машины, комплексы, системы и сети" и "Автоматизир. системы обраб. информ. и упр." направления подгот. дипломир. специалистов "Информатика и вычисл. техника"]. Спб.:Издательский дом "Питер", 2010. 397 с.
Методология разработки ПО Microsoft Solutions Framework (MSF). URL: http://www.dpgrup.ru/methodology-msf.htm
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. М.: Финансы и статистика, 2000.
Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998.
Гайсарян С. С. Объектно-ориентированные технологии проектирования прикладных программных систем. Центр Информационных Технологий, http://citmgu.ru, 1998.