ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОЕКТА (Понятие и стадии жизненного цикла)

Содержание:

Введение

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

Создание программного обеспечения – это сложный и длительный процесс, поэтому для его упрощения были продуманы процедуры, унифицирующие этот процесс. Такие процедуры были оформлены в виде стандартов. Первоначально, в России создание ПО регламентировалось стандартами ГОСТ ЕСПД, которые применялись для относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели, сроки их действия закончились и использование нецелесообразно. Процессы создания автоматизированных систем (АС), в состав которых входит и программное обеспечение, регламентированы стандартами ГОСТ 34.601-90, ГОСТ 34.602-89 и ГОСТ 34.603-92. Однако процессы создания ПО для современных распределенных ЭИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдельные их положения явно устарели. В результате для каждого серьезного проекта ЭИС приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

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

На основе цели поставлены следующие задачи:

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

1. Понятие и стадии жизненного цикла

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

Стадии жизненного цикла (далее ЖЦ) описаны в Государственном стандарте РФ ГОСТ Р ИСО/МЭК "Информационная технология. Процессы жизненного цикла программных средств" под номером 12207-99, принятый и введенный в действие постановлением Госстандарта России от 23 декабря 1999 г. № 675-ст. Настоящий стандарт содержит полный аутентичный текст международного стандарта ISO/IEC 12007:95 «Информационная технология. Процессы жизненного цикла программных средств», который действует с незначительными поправками в настоящее время и регламентирует процессы жизненного цикла программных средств и информационных технологий. Все процессы ЖЦ в соответствии с этим стандартом делятся на три группы: основные процессы, вспомогательные и организационные (рисунок 1.1). Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами [2]. Стандарт не определяет конкретной модели жизненного цикла или метода разработки программного средства. Пользователи, применяющие настоящий стандарт, должны сами выбирать модель ЖЦ применительно к своему программному проекту и распределять процессы, работы и задачи, выбранные из настоящего стандарта, на данной модели [6].

Рисунок 1.1. Структура стандарта

ГОСТ 34.60190 определяет следующие стадии и этапы создания АИС [7]:

1. Формирование требований к АИС:

• обследование организации и обоснование необходимости разработки ИС;
• требования конечных пользователей к системе;
• оформление отчёта о проделанной работе (тактико-техническое задание).

2. Разработка концепции АИС:

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

3. Разработка технического задания (далее ТЗ). ТЗ – это документ, в котором сформулированы основные цели разработки, требование к программному продукту, определены сроки и этапы разработки, и регламентирован процесс приёмно-сдаточных испытаний.

4. Эскизный проект (макет):

• планирование предварительных проектных решений по будущей системе, по отдельным её частям;
• разработка документаций как на АИС.

5. Технический проект:

• принятие решений по создаваемой системе;
• разработка документаций на систему;
• разработка и оформление документации на поставку изделий на комплектование АИС;
• оформление технических требований на разработку изделий для комплектования АИС;
• задания на проектирование в смежных модулях ИС.

6. Рабочая документация:

• создание рабочей документации;
• разработка программ и её адаптация.

7. Ввод в действие:

• подготовка предприятия-заказчика к началу установки ИС;
• обучение персонала;
• комплектование АИС техническими и программными средствами;
• строительно-монтажные работы;
• пуско-наладочные действия;
• предварительные испытания ИС;
• опытная эксплуатация установленной и проверенной системы;
• приёмочные испытания.

8. Сопровождение АИС:

• выполнение обязательств по гарантийному обслуживанию;
• послегарантийное обслуживание.

Модель жизненного цикла отражает различные состояния системы в процессе всего жизненного цикла ИС. Модель ЖЦ – это такая структура, которая содержит все процессы, действия и задачи по разработке программного продукта, по его сопровождению и функционированию в течении всей жизни созданной системы, вплоть до её исчезновения [2].

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

1. Планирование и анализ требований.
2. Проектирование (техническое и логическое.).
3. Реализация (рабочее проектирование, физическое проектирование, программирование. Разработка и настройка программ, наполнение баз данных, создание инструкций).
4. Внедрение (Тестирование, опытная эксплуатация. Обучение персонала).
5. Эксплуатация (Сопровождение и модернизация. Исправление ошибок и недоработок. Повторение стадий 2-5 при необходимости). [3]

2. Модели жизненного цикла

2.1. Каскадная модель

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

Рисунок 2.1. Каскадная модель ЖЦ ИС

Эта модель предусматривает линейный процесс функционирования ИС, т.е. пока не будет завершён один этап, на другой будет перейти невозможно. Каждый этап заканчивается получением некоторых результатов, которые служат исходными данными для следующего этапа. Каждый этап завершается выпуском полного комплекта документации. Этот вид модели используется для сложных систем с большим числом задач вычислительного характера. Недостатками данной модели можно назвать высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователя. Существует возможность запаздывания с получением результатов. [1]

2.2. V-образная модель

V-образная модель (рисунок 2.2) основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага:

• анализ (планирование и требования);
• проектирование;
• разработка (кодирование);
• обзор (тестирование).

Рисунок 2.2. V-образная модель ЖЦ ИС

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

• детальное проектирование – определяется алгоритм работы каждого компонента;
• кодирование – преобразование алгоритма в готовое программное обеспечение (далее ПО);
• модульное тестирование – проверка каждого компонента или модуля;
• интеграционное тестирование – интеграция программного продукта (далее ПП) и его тестирование;
• системное тестирование – проверка функционирования ПП после помещения его в аппаратную среду [5].

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

2.3. Модель прототипирования

Модель прототипирования позволяет создать прототип ПП до или в течении этапа составления требований к ПП. (рис. 4) Потенциальные пользователи работают с этим прототипом, определяя его сильнее и слабые стороны, о результатах сообщают разработчикам ПП. Жизненный цикл разработки ПП так же как и у других моделей ЖЦ, начинается с разработки плана проекта. В результате получается документ, содержащий частичную спецификацию требований к ПП. В результате прототипирования разработчик демонстрирует пользователям готовый прототип, а пользователи оценивают его функционирование. Определяются проблемы, которые устраняются пользователями и разработчиками. Процесс продолжается до тех пор, пока пользователи не будут удовлетворены степенью соответствия ПП требованиям, затем прототип демонстрирует пользователям с целью получения предложений по его усовершенствованию, пока рабочая модель не окажется удовлетворительной. После этого получают от пользователя официальное одобрение прототипа, после чего происходит преобразование прототипа в готовый ПП [8].

У модели прототипирования достаточно большое количество достоинств по сравнению с недостатками. Преимуществами модели являются:

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

Недостатки в модели прототипирования:

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

Данную модель при разработке АИС следует выбрать, если на рынке нет аналогов системы или если требования к ПП заранее не известны

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

2.4. RAD-модель

RAD-модель – это модель быстрой разработки приложений. (рис. 5) Решающую роль в такой модели играет конечный пользователь. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах в RAD модели большую часть отводят планированию и проектированию. [8]

Рисунок 2.4. RAD-модель

Модель проходит четыре фазы:

1. Составление требований и планирование (метод совместного планирования требований: структурный анализ и осуждение задач).
2. Описание пользователя: проектирование ПП, выполняемого при участии заказчика.
3. Создание – детальное проектирование, кодирование, тестирование ПП, поставка его заказчику.
4. Сопровождение – приёмочные испытания, установка ПП, обучение пользователя.

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

Несмотря на эти недостатки у RAD-модели имеются и преимущества:

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

2.5. Многопроходная модель

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

Рисунок 2.5. Многопроходная модель ЖЦ ПП

На разных этапах ЖЦ разработки (планирование, анализ требований, разработка проекта) выполняется конструирование ПП в целом. Определяется число необходимых инкрементов (шагов) и относящихся к ним функций. Каждый инкремент затем проходит через оставшиеся фазы ЖЦ (кодирование, тестирование). Сначала выполняются конструирование, тестирование и реализация базовых функций, составляющих основу ПП. Последующие итерации направлены на улучшение функциональных возможностей ПП [8].

Преимущества многопроходной модели ЖЦ:

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

Недостатками данной модели являются:

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

Многопроходную модель следует выбрать для разработки ИС с заранее определёнными требованиями и большим периодом времени на выполнение.

2.6. Спиральная модель

Особенностью спиральной модели является то, что ПП создаётся по частям с использованием метода прототипирования. (рис. 7). Прототип – это действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПП. Создание прототипа осуществляется за несколько итераций. Каждая итерация соответствует созданию версии ПП. На ней уточняются цели и характеристики проекта. Оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта с целью определения необходимости выполнения ещё одной итерации, степени полноты точности понимания требований к системе, целесообразности прекращения проекта. Но главной проблемой в такой модели является определение момента перехода на следующую итерацию. Поэтому вводятся временные ограничения [4].

Рисунок 2.6. Спиральная модель ЖЦ ПП

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

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

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

3. Моделирование процесса управления жизненным циклом информационной системы

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

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

На рисунке 3.1. представлена контекстная диаграмма функциональной модели п6оцесса «Управление проектом внедрения информационной системы».

Рисунок 3.1. Контекстная диаграмма модели

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

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

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

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

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

• процедуры управления проектом (процедуры организации, планирования и выполнения проектами);
• стандарты управления проектами (известные компании стандарты и методики управления проектами).

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

Рисунок 3.2. Диаграмма декомпозиции основного процесса

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

1. Организация проекта.

2. Планирование проекта.

3. Исполнение проекта.

4. Мониторинг и управление.

5. Завершение проекта.

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

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

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

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

В качестве управления используются такие механизмы:

• процедуры управления проектом (процедуры организации, планирования и выполнения проектами);
• стандарты управления проектами (известные компании стандарты и методики управления проектами).

Механизмом реализации данной функции является руководитель проекта и команда проекта.

Проанализируем состав функций процесса «Инициация проекта» (рисунок 3.3).

Рисунок 3.3. Диаграмма декомпозиции процесса «Инициация проекта»

На основе анализа процесса было выявлено, что он включает такие основные этапы:

• предпроектное обследование компании и моделирование бизнес-процессов “as-is”. Обследование компании ставит своей целью анализ предметной области и бизнес-процессов, которые требуют автоматизации, выявление будущих пользователей, их задач.
• выбор модели КИС. На основе известных стандартов и методик, а также с учетом особенностей компании и проекта, формируется стандарт управления конкретным проектом.
• заключение контракта. В контракте оговариваются цель проекта, сроки выполнения и стоимость разработки.
• согласование процедур. После заключения контракта с заказчиком согласуются процедуры проекта и корректируется стандарт управления проектом.
• сбор и обучение команды. После определения цели, заключения контракта и определения стандарта управления, отбирается команда, проводится ее обучение.

Проанализируем, каким образом выполняется функция «Выбор модели КИС» (рисунок 3.4).

Рисунок 3.4. Диаграмма декомпозиции процесса «Выбор модели КИС»

Для выполнения функции «Планирование проекта» необходимо получение таких первоначальных данных или документов:

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

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

• техническое задание (ТЗ);
• документация проекта (характеристика моделей, описание физической модели и модели интерфейса);
• технический проект (физические модели, описание интерфейса).

В качестве управления используются такие механизмы:

• процедуры управления проектом (процедуры организации, планирования и выполнения проектами).

Механизмом реализации данной функции является руководитель проекта и команда проекта.

Рисунок 3.5. Диаграмма декомпозиции процесса «Планирование проекта»

На основе анализа процесса было выявлено, что он включает такие основные этапы:

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

Для выполнения функции «Исполнение проекта» необходимо получение таких первоначальных данных или документов:

• техническое задание (ТЗ);
• контракт;
• технический проект (по которому выполняется создание и внедрение информационной системы);
• коррекция (замечания по результатам тестирования и опытной эксплуатации).

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

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

В качестве управления используются такие механизмы:

• процедуры управления проектом (процедуры организации, планирования и выполнения проектами);
• принятый стандарт управления проектом.

Механизмом реализации данной функции является команда проекта.

Рисунок 3.6. Диаграмма декомпозиции процесса «Исполнение проекта»

На основе анализа процесса было выявлено, что он включает такие основные этапы:

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

Для выполнения функции «Мониторинг и управление» необходимо получение таких первоначальных данных или документов:

• техническое задание (ТЗ);
• контракт;
• документация проекта (описание готового продукта, руководство пользователя и программиста);
• готовая система (готовая и введенная в эксплуатацию информационная система).

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

• коррекция проекта (замечания по результатам тестирования и опытной эксплуатации);
• результаты приемки системы.

Рисунок 3.7. Диаграмма декомпозиции процесса «Мониторинг и управление»

На основе анализа процесса было выявлено, что он включает такие основные этапы:

• проведение испытаний (тестирование проекта);
• опытная эксплуатация;
• приемочные испытания.

Структура проекта внедрения системы представлена на рисунке 3.8.

Рисунок 3.8. Структура проекта

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

Заключение

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

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

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

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

1. Архипенков С. Лекции по управлению программными проектами [текст] / С. Архипенков. – М.: 2014. – 128 с.
2. Братищенко В. В. Проектирование информационных систем. [Текст] / Иркутск: БГУЭП, 2015 – 84 стр.
3. Вендров А. М. CASE-технологии: Современные методы и средства проектирования информационных систем. [Текст] / М.: Финансы и статистика, 2014 – 176 стр.
4. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебное пособие. – М: Финансы и статистика, 2014.
5. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. Учеб. пособие. – М.: Финансы и статистика, 2014.
6. Гагарина Л.Г. Технология разработки программного обеспечения: учебное пособие [текст] / Л.Г.Гагарина, Е.В. Кокорева, Б.Д. Виснадул. – М.: ИД «ФОРУМ»: ИНФРА-М, 2015. – 400 с.
7. Гвоздева В.А. Основы построения автоматизированных информационных систем: учебник [текст] / В.А. Гвоздева, И.Ю. Лаврентьева. – М.: ИД «ФОРУМ»: ИНФРА-М, 2015. – 320 с.
8. ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения. — М. : Госстандарт РФ, 1990. — 23 с.
9. ГОСТ 4.071.030. Отраслевой стандарт. Автоматизированная система управления предприятием. Создание системы. Нормативы трудоемкости. www.shtz.shadrinsk.net/source/GOST/OST4.071.030.
10. ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств [Электронный ресурс]. – Режим доступа: http://www.rfcmd.ru/sphider/docs/InfoSec/GOST_R_ICO-IEC_12207-99.htm
11. ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом. — М. : Госстандарт РФ, 2003. — 114 с.
12. Грекул В.И. Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информ. технологий [текст] / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: Интернет-Ун-т Информ технологий, 2015. – 304 с.
13. Гусятников В. Н., Безруков А. И. Стандартизация и разработка программных систем, учебное пособие [Текст] / М.: ФиС, 2014 – 288 стр.
14. Емельянова Н.З. Основы построения автоматизированных информационных систем: Учебное пособие [текст] / Н.З.Емельянова, Т.Л.Партыка, И.И.Попов. – М.: ФОРУМ: ИНФРА-М, 2016. – 416 с.
15. Зыков С. В. Модели жизненного цикла и методологии разработки корпоративных систем [Видеокурс] / Интернет-университет информационных технологий – ИНТУИТ.ру, 2013 – DVD-box: 2 диска.
16. Избачков Ю.С. Информационные системы: Учебник для вузов. 2-е изд [текст] / Ю.С.Избачков, В.Н.Петров. – СПб.: Питер, 2016. – 656 с.
17. Котляров В.П. Основы тестирования программного обеспечения: Учебное пособие / В.П.Котляров, Т.В. Коликова. – М.: Интернет-Университет Информационных технологий; БИНОМ. Лаборатория знаний, 2016. – 285 с.
18. Крупский А.Ю. Разработка и стандартизация программных средств: Учебное пособие [текст] / А.Ю.Крупский, Л.А.Феоктистова. – М.: Издательско-торговая корпорация «Дашков и К^о», 2014. – 100 с.
19. Лойко В.И. Информационные системы и технологии в экономике: Учебник. – 2-е изд., доп. и перераб [текст] / В.И. Лойко, Т.П. Барановская, М.И. Семенов, А.И. Трубилин. – М.: Финансы и статистика, 2015. – 416 с.
20. Макконел Стив. Профессиональная разработка программного обеспечения [текст] / С. Макконел; пер. с англ. под ред. В.Агаповой. – СПб.: Символ-Плюс, 2016. – 240 с.
21. Маслов А.В. Проектирование информационных систем в экономике: учебное пособие / А.В. Маслов. – Томск: Изд-во Томского политехнического университета, 2016. – 216 с.
22. Принципы и этапы разработки ПО [Электронный ресурс]. – Режим доступа: http://www.tspu.tula.ru/ivt/old_site/umr/trpo/node14.html
23. Проектирование и разработка автоматизированных, информационных и аналитических систем [Электронный ресурс]. – Режим доступа: www.info-system.ru
24. Смирнов Н.В. Проектирование информационных систем [текст] / Н.В.Смирнов. – СПб.: БГТУ «ВОЕНМЕХ», 2016. – 146 с.
25. Технология освоения и внедрения CASE-средств [Электронный ресурс]. – Режим доступа: http://www.interface.ru/home.asp?artId=22623
26. Фельдман Я.А. Создаем информационные системы [текст] / Я.А.Фельдман. - М.: СОЛОН-ПРЕСС, 2016. – 120 с.