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

Содержание:

Введение

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

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

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

Объектом исследования являются основные стадии жизненного цикла программного обеспечения и их основные характеристики. Предметом исследования являются основные модели жизненного цикла в порядке их эволюционного развития.

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

Задачами данной работы являются:

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

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

1. Жизненный цикл программного обеспечения

1.1. Понятие информационной системы

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

Понятие информационной системы интерпретируется зависимо от контекста.

В широком понимании информационной системы подразумевается, что неотъемлемыми компонентами системы являются данные, программное и техническое обеспечение, а также организационные мероприятия и персонал. Понятие информационной системы широко трактуется федеральным законом РФ «Об информации, информационных технологиях и о защите информации». В данной законе под информационной системой подразумевается совокупность информации, содержащейся в базах данных, и информационных технологий и технических средств, обеспечивающих обработку этой информации^[2].

В области информатики среди российских ученых наиболее широкое определение информационной системы дается М. Р. Когаловским. По его мнению, понятие информационной системы помимо программ, данных, людских ресурсов и аппаратного обеспечения также включает информационные ресурсы, лингвистические средства и коммуникационное оборудование, образующие в совокупности систему, которая обеспечивает «поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей»^[3].

В узком понимании информационной системы ее состав ограничивается аппаратным обеспечением, программами и данными. Интеграция этих компонентов позволяет автоматизировать процессы целенаправленной деятельности конечных пользователей и управления информацией, которая направлена на хранение, модификацию и получение информации. Например, в российском стандарте ГОСТ РВ 51987 под информационной системой подразумевается «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». В ГОСТе Р 53622-2009 используется термин информационно-вычислительной системы в качестве обозначения совокупности отдельных данных или баз данных, прикладных программ и систем управления базами данных, которые функционируют на вычислительных средствах единым целым с целью решения определенных задач^[4].

В деятельности организаций информационная система рассматривается программным обеспечением, которое реализует деловую стратегию отдельной организации. При этом успешной практикой является развертывание и создание единой корпоративной информационной системы, которая удовлетворяет информационным потребностям всех подразделений, служб и отдельных сотрудников организации. Практическое создание подобной всеобъемлющей информационной системы очень затруднено или даже невозможно, поэтому на предприятиях чаще всего функционируют несколько различных систем, каждая из которых решает отдельные группы задач. Такими задачами может быть электронный документооборот, финансово-хозяйственная деятельность, управление производством и другие подобные. Иногда часть задач выполняется одновременно несколькими информационными системами, а часть задач может быть вовсе не автоматизированной. Подобные ситуации называют лоскутной автоматизацией, и данный метод довольно типичен для многих предприятий^[5] [1, 2].

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

Жизненный цикл программного обеспечения является периодом создания и использования программного обеспечения. Он начинается в момент возникновения потребности в программном обеспечении и заканчивается в момент полного выхода программы из эксплуатации^[6].

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

Жизненный цикл программного обеспечения можно представить рядом событий, которые происходят с программой в процессе ее использования и создания^[7].

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

Каждая стадия жизненного цикла программного обеспечения характеризуется конкретными задачами и методами их решения, полученными на предыдущем этапе исходными данными и результатами. Результатами анализа, в частности, являются информационные модели, функциональные модели и диаграммы, соответствующие им. Жизненный цикл программного обеспечения имеет итерационный характер: результаты очередного этапа часто вызывают изменения в выработанных на более ранних этапах проектных решениях^[8] [2, 3].

1.3. Стадии и этапы проектирования программного обеспечения

По стандарту ГОСТ 34.601-90 предусматривается восемь стадий и этапов создания программного обеспечения.

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

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

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

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

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

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

Седьмой этап является вводом в действие, который состоит из подготовки программного продукта, подготовки персонала, комплектации программного обеспечения поставляемыми изделиями, в которые входят программные и технические средства, программно-технические комплексы и информационные изделия, строительно-монтажных работ, пусконаладочных работ, проведения предварительных испытаний, проведения опытной эксплуатации и проведения приёмочных испытаний^[11].

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

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

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

В настоящее время данный стандарт является не совсем актуальным, так как некоторые положения уже устарели и многие процессы отражены недостаточно полно^[13] [2, 4, 5].

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

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

Стандартом ISO/IEC 12207 не предлагаются методы разработки информационной системы и конкретная модель жизненного цикла. Регламенты данного стандарта являются общими для любых моделей жизненного цикла, технологий и методологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как выполнить или реализовать задачи и действия, которые включены в эти процессы^[14].

На сегодняшний день выделяют четыре основных модели жизненного цикла:

• каскадная модель;
• поэтапная модель с промежуточным контролем;
• инкрементная модель;
• спиральная модель^[15] [6, 7].

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

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

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

Каскадная схема разработки программного обеспечения представлена на рисунке 1.

Рис. 1. Каскадная схема разработки программного обеспечения

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

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

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

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

2.2. Поэтапная модель с промежуточным контролем

Для преодоления проблем каскадной модели была предложена поэтапная модель с промежуточным контролем.

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

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

Поэтапная схема разработки программного обеспечения с промежуточным контролем представлена на рисунке 2^[21].

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

Основным недостатком каскадного и поэтапного подходов является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, которые планируются после завершения каждого этапа работы, требования к информационной системе фиксированы в виде технического задания на все время создания системы. Таким образом, пользователи могут внести свои замечания только после полного завершения работы над программой. В случае изменения требований или их неточного изложения в течение длительного периода создания программного обеспечения, пользователи получают программу, которая не удовлетворяет их потребностям. Модели объекта могут устаревать одновременно с их утверждением^[22] [8, 10, 11].

2.3. Инкрементная модель

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

Инкрементная схема разработки программного обеспечения представлена на рисунке 3^[23].

Рис. 3. Инкрементная схема разработки программного обеспечения

В начале работы над проектом определяются все основные требования к информационной системе, затем выполняется разработка данной системы в виде последовательности версий. При этом каждая версия представляет собой работоспособный и законченный продукт. Первая версия реализует отдельную часть запланированных возможностей, последующие версии реализуют дополнительные возможности. Данный процесс продолжается до получения полной системы^[24].

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

Недостатки и достоинства данной стратегии совпадают с каскадной моделью. За исключением более ранней видимости результатов заказчиком. Уже после результатов разработки и внедрения первой версии он имеет возможность незначительно изменять требования к разработке, предлагать разработку более совершенного продукта при заключении нового договора или совсем отказаться от нее^[25] [7, 11, 12].

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

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

В спиральной модели делается упор на начальные этапы жизненного цикла: проектирование и анализ. На данных этапах возможность реализации технических решений проверяется через создание прототипов. Каждый отдельный виток спирали соответствует созданию версии или фрагмента автоматизированной информационной системы, на котором уточняются характеристики и цели проекта, определяется его качество и планируются работы на следующем витке спирали. Таким образом, последовательно конкретизируются и углубляются детали проекта, а в результате выбирается доводимый до реализации обоснованный вариант^[26].

Итерационная разработка отражает объективно существующий спиральный цикл создания информационной системы. Неполное завершение работ на каждом отдельном этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. В итеративном способе разработки недостающая работа имеет возможность быть выполненной в процессе следующей итерации. Главная задача модели заключается в наибыстрейшем выводе к пользователям системы работоспособного продукта, тем самым активизируя процесс дополнения и уточнения требований^[27].

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

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

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

Рис. 4. Спиральная схема разработки программного обеспечения

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

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

Недостатками данной модели является увеличение неопределенности у разработчика в перспективах развития проекта и затруднение операции ресурсного и временного планирования всего проекта в целом. Для решения данной проблемы вводятся временные ограничения на каждый этап жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе полученных в предыдущих проектах статистических данных и личного опыта разработчиков^[31] [8, 12, 13, 14].

2.5. Сравнительный анализ моделей

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

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

Таблица 1 – Сравнение моделей жизненного цикла

Характеристика проекта	Модель жизненного цикла
	Каскадная и поэтапная	Инкрементная	Спиральная
Обеспеченность ресурсами и новизна разработки	Типовой. Хорошо проработаны методы и технология решения задачи		Новаторский (нетиповой). Нетрадиционный для разработчика
	Ресурсов разработчика и заказчика хватает для реализации проекта в сжатые сроки	Ресурсов разработчика или заказчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Средние и малые проекты	Крупные и средние проекты	Любые проекты
Сроки выполнения проекта	Меньше года	Порядка нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия является итоговым результатом проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями	Нет	Да	Да
Распространение промежуточного программного обеспечения	Нет	Может быть	Да

Не стоит рассматривать значения «Да» и «Нет» в таблице как жесткие требования. Такая ситуация, как добавление отдельных непредусмотренных сервисных функций с незначительным изменением требований по мере развития проекта при использовании каскадной модели может встречаться при создании систем и в случае изменений помогает улучшению взаимоотношений между разработчиком и заказчиком. Также распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах опытной эксплуатации и внедрения системы^[34].

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

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

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

Версия представляет собой любые изменения информационного и программного обеспечения, а также базы данных, которые обязательны для передачи на объекты внедрения и позволяют выполнять заявленные или дополнительные функции, а также обеспечивают переход на новую информационную среду и операционные системы^[36].

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

В соответствии с данной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче очередь системы или версия. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения рассматриваются модификации и ревизии. Как и было отмечено выше, частая передача модификаций и ревизий конечным пользователям нежелательна. Смену версий информационных систем на железнодорожном транспорте необходимо выполнять не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц^[37] [1, 6, 8, 9, 12, 14].

Заключение

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

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

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

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

Список используемой литературы

1. Бутенко Д. В. Алгоритм проведения предпроектных исследований и моделирования информационных систем/ Д. В. Бутенко // Программные продукты и системы – М., 2013. – №4. – С. 53-56.
2. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с.
3. Исаев Г. Проектирование информационных систем / Г. Исаев. — М.: Омега-Л, 2012. — 432 с.
4. Бодров О. А. Предметно-ориентированные экономические информационные системы / О. А. Бодров, Р. Е. Медведев. — М.: Горячая линия - Телеком, 2013. — 244 с.
5. Келим Ю. Вычислительная техника / Ю. Келим. — М.: Academia, 2013. — 368 с.
6. Майерс Г. Искусство тестирования программ / Г. Майерс, Т. Баджетт, К. Сандлер. — М.: «Диалектика», 2012. — 272 с.
7. Ефимов И. Н. Качественные и количественные характеристики открытых информационных систем / И. Н. Ефимов // Программные продукты и системы – М., 2012. – №4. – С. 80-83.
8. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с.
9. Левин В. Информационные технологии в машиностроении / В. Левин. — М.: Academia, 2013. — 272 с.
10. Бутенко Д. В. Методика концептуального проектирования программных информационных систем / Д. В. Бутенко // Программные продукты и системы – М., 2012. – №2. – С. 101.
11. Марков А. С. Методы оценки несоответствия средств защиты информации / А. С. Марков, В. Л. Цирлов, А. В. Барабанов. - М.: Радио и связь, 2012. – 192 с.
12. Мелехин В. Вычислительные системы и сети / В. Мелехин, Е. Павловский. — М.: Academia, 2013. — 208 с.
13. Бородакий Ю. В. Эволюция информационных систем (современное состояние и перспективы) / Ю. В Бородакий, Ю. Г. Лободинский. — М.: Горячая линия - Телеком, 2011. — 368 с.
14. Емельянова Н. З. Проектирование информационных систем: Учебное пособие / Н. З. Емельянова, Т. Л. Партыка, И. И. Попов. - М.: Форум: НИЦ ИНФРА-М, 2014. – 432 с.

1. Бутенко Д. В. Алгоритм проведения предпроектных исследований и моделирования информационных систем/ Д. В. Бутенко // Программные продукты и системы – М., 2013. – №4. – С. 53-56. ↑

2. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

3. Бутенко Д. В. Алгоритм проведения предпроектных исследований и моделирования информационных систем/ Д. В. Бутенко // Программные продукты и системы – М., 2013. – №4. – С. 53-56. ↑

4. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

5. Бутенко Д. В. Алгоритм проведения предпроектных исследований и моделирования информационных систем/ Д. В. Бутенко // Программные продукты и системы – М., 2013. – №4. – С. 53-56. ↑

6. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

7. Исаев Г. Проектирование информационных систем / Г. Исаев. — М.: Омега-Л, 2012. — 432 с. ↑

8. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

9. Бодров О. А. Предметно-ориентированные экономические информационные системы / О. А. Бодров, Р. Е. Медведев. — М.: Горячая линия - Телеком, 2013. — 244 с. ↑

10. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

11. Келим Ю. Вычислительная техника / Ю. Келим. — М.: Academia, 2013. — 368 с. ↑

12. Затонский А. В. Информационные технологии: разработка информационных моделей и систем: Учебное пособие / А. В. Затонский – ИНФРА-М, 2014. – 344 с. ↑

13. Бодров О. А. Предметно-ориентированные экономические информационные системы / О. А. Бодров, Р. Е. Медведев. — М.: Горячая линия - Телеком, 2013. — 244 с. ↑

14. Майерс Г. Искусство тестирования программ / Г. Майерс, Т. Баджетт, К. Сандлер. — М.:«Диалектика», 2012. — 272 с. ↑

15. Ефимов И. Н. Качественные и количественные характеристики открытых информационных систем / И. Н. Ефимов // Программные продукты и системы – М., 2012. – №4. – С. 80-83. ↑

16. Ефимов И. Н. Качественные и количественные характеристики открытых информационных систем / И. Н. Ефимов // Программные продукты и системы – М., 2012. – №4. – С. 80-83. ↑

17. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

18. Левин В. Информационные технологии в машиностроении / В. Левин. — М.: Academia, 2013. — 272 с. ↑

19. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

20. Марков А. С. Методы оценки несоответствия средств защиты информации / А. С. Марков, В. Л. Цирлов, А. В. Барабанов. - М.: Радио и связь, 2012. – 192 с. ↑

21. Бутенко Д. В. Методика концептуального проектирования программных информационных систем / Д. В. Бутенко // Программные продукты и системы – М., 2012. – №2. – С. 101. ↑

22. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

23. Ефимов И. Н. Качественные и количественные характеристики открытых информационных систем / И. Н. Ефимов // Программные продукты и системы – М., 2012. – №4. – С. 80-83. ↑

24. Марков А. С. Методы оценки несоответствия средств защиты информации / А. С. Марков, В. Л. Цирлов, А. В. Барабанов. - М.: Радио и связь, 2012. – 192 с. ↑

25. Мелехин В. Вычислительные системы и сети / В. Мелехин, Е. Павловский. — М.: Academia, 2013. — 208 с. ↑

26. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

27. Мелехин В. Вычислительные системы и сети / В. Мелехин, Е. Павловский. — М.: Academia, 2013. — 208 с. ↑

28. Емельянова Н. З. Проектирование информационных систем: Учебное пособие / Н. З. Емельянова, Т. Л. Партыка, И. И. Попов. - М.: Форум: НИЦ ИНФРА-М, 2014. – 432 с. ↑

29. Бородакий Ю. В. Эволюция информационных систем (современное состояние и перспективы) / Ю. В Бородакий, Ю. Г. Лободинский. — М.: Горячая линия - Телеком, 2011. — 368 с. ↑

30. Мелехин В. Вычислительные системы и сети / В. Мелехин, Е. Павловский. — М.: Academia, 2013. — 208 с. ↑

31. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

32. Бутенко Д. В. Алгоритм проведения предпроектных исследований и моделирования информационных систем/ Д. В. Бутенко // Программные продукты и системы – М., 2013. – №4. – С. 53-56. ↑

33. Майерс Г. Искусство тестирования программ / Г. Майерс, Т. Баджетт, К. Сандлер. — М.:«Диалектика», 2012. — 272 с. ↑

34. Мелехин В. Вычислительные машины / В. Мелехин, Е. Павловский. — М.: ДРОФА, 2013. — 384 с. ↑

35. Левин В. Информационные технологии в машиностроении / В. Левин. — М.: Academia, 2013. — 272 с. ↑

36. Емельянова Н. З. Проектирование информационных систем: Учебное пособие / Н. З. Емельянова, Т. Л. Партыка, И. И. Попов. - М.: Форум: НИЦ ИНФРА-М, 2014. – 432 с. ↑

37. Мелехин В. Вычислительные системы и сети / В. Мелехин, Е. Павловский. — М.: Academia, 2013. — 208 с. ↑