Содержание:

Введение

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

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

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

Цель была достигнута при помощи выполнения следующих задач:

- изучить теоретические основы программного обеспечения;

- определить модели жизненных циклов программного проекта.

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

Глава 1. Теоретические основы
программного обеспечения

1.1. Понятие программного обеспечения

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

Рассмотрим понятие системного программного обеспечения.

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

Согласно ISO/IEC 2382-1:1993, программное обеспечение – все или часть программ, процедур, правил и соответствующей документации системы обработки информации ^[1].

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

IEEE Std 829-2008: программное обеспечение – компьютерные программы, процедуры и, возможно, соответствующая документация и данные, относящиеся к функционированию компьютерной системы^[2];

ISO/IEC 26514-2008: программное обеспечение – программа или множество программ, используемых для управления компьютером^[3];

ГОСТ 19781-90: программное обеспечение – совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ^[4].

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

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

Системное программное обеспечение – это своеобразная «прослойка» между аппаратными составляющими компьютера и программными приложениями^[5].

В современных компьютерных системах ни одно из запущенных программных приложений не может непосредственно вступать во взаимодействие с аппаратными компонентами, как было во времена MS-DOS, когда подобный подход преобладал. Теперь требуется, чтобы приложение отвечало определенным правилам, и было запрограммировано специально для используемой системы. Как раз по этой причине программы, созданные для ОС Windows, не могут функционировать в системе Linux или Mac и, соответственно, наоборот.

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

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

Системное программирование, которое заключается в создании системного программного обеспечения есть удел системных программистов, которые специализируются исключительно на создании, отладке и корректировке системного программного обеспечения. Кроме системных программистов, есть прикладные программисты, в задачи которых входит использование на практике, разработка, отладка и адаптация прикладного программного обеспечения. Кстати, я в свое время работала прикладным программистом. И хочу сказать, что писать программы для людей иногда сложнее (в первую очередь, по эмоциональному накалу), чем для «железа»^[6].

Исходя из разделения программного обеспечения на системное и прикладное, уже стало определенным стандартом, что обычный пользователь хранит на компьютере системное программное обеспечение (операционную систему и драйверы) на системном диске C:, а свои наработки, тексты, таблицы, рисунки, фото — на диске D:. Такое разделение позволяет при возникновении проблем с операционной системой на диске C: сохранить пользователю все, что им «нажито непосильным трудом» на диске D:. Хотя про архивацию в любом случае нужно помнить.

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

1.2. Классификация программного обеспечения

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

Современное программное обеспечение делят на следующие виды (рис. 1).

Рисунок 1 – Классификация программного обеспечения^[7]

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

Системы программирования предназначены для создания новых программ с использованием различных языков программирования, например Scratch 1.4, Free Pascal 2.6, DEV-C++ 5.11, Microsoft Visual Studio 2013 Professional, Android Studio 1.4.0, Lazarus 1.4.4, Python 2.6.1 и др.

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

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

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

На компьютерные программы распространяется действие главы 70 «Авторское право» Гражданского кодекса РФ^[8], и их использование возможно только при условии соблюдения требований этого закона, а также требований лицензии, с которой пользователь соглашается, устанавливая программу на свой компьютер.

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

Аналогичные программы есть и в других операционных системах. Так, в Linux Ubuntu такими программами, например, являются: Менеджер архивов, Журнал системы, Анализатор использования диска, Резервное копирование, Системный монитор, System Testing, Диски и др.

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

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

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

1.3. Основы программного проектирования

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

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

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

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

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

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

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

1. Анализ требований.

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

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

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

В рамках данного этапа стороны должны осуществить:

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

2) поиск критических участков проекта;

3) формирование окончательной архитектуры создаваемой системы;

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

5) проектирование основных элементов продукта – модели базы данных, процессов и кода;

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

7) определение основных требований к безопасности разрабатываемого программному обеспечению^[12].

3. Кодирование.

Следующим шагом становится непосредственная работа с кодом, опираясь на выбранный в процессе подготовки язык программирования. Описывать особенности и тонкости самого трудоемкого и сложного этапа вряд ли стоит, достаточно указать, что успех реализации любого проекта напрямую зависит от качества предварительного анализа и оценки конкурирующих решений, с которыми создаваемой программе предстоит «бороться» за право называться лучшей в своей нише. Если речь идет о написании кода для выполнения узкоспециализированных задач в рамках конкретного предприятия, то от грамотного подхода к этапу кодирования зависит эффективность работы компании, заказавшей разработку. Кодирование может происходить параллельно со следующим этапом разработки – тестированием программного обеспечения, что помогает вносить изменения непосредственно по ходу написания кода. Уровень и эффективность взаимодействия всех элементов, задействованных для выполнения сформулированных задач компанией-разработчиком, на текущем этапе является самым важным — от слаженности действий программистов, тестировщиков и проектировщиков зависит качество реализации проекта^[13].

4. Тестирование и отладка.

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

5. Внедрение.

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

1) первоначальная загрузка данных;

2) постепенное накопление информации;

3) вывод созданного программного обеспечения на проектную мощность.

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

6. Заключение.

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

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

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

Глава 2. Модели и типы жизненных циклов программного проекта

2.1. Характеристика жизненного цикла программы

Технология разработки программного обеспечения  – это комплекс мер по созданию программных продуктов. Данная деятельность включает в себя несколько этапов, с которыми так или иначе придётся столкнуться при разработке достаточно крупного программного обеспечения^[16].

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

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

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

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

3. Процесс разработки (рассмотрен подробно ниже).

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

5. Процесс сопровождения. Фирма-разработчик осуществляет поддержку пользователей программного продукта в случае возникновения у них каких-либо вопросов или проблем. Если в процессе эксплуатации будет обнаружена ошибка в ПП, разработчики должны её устранить. Процесс эксплуатации и процесс сопровождения идут параллельно^[17].

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

1. Процесс документирования. В процессе разработки и далее исполнитель пишет документацию и руководства пользователя к разрабатываемому программному продукту. Данные документы помогут разработчикам [вспомнить/разобраться] структуру и код программного обеспечения (ибо со временем всё забывается, особенно в больших проектах), а пользователям освоить работу с программой.

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

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

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

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

6. Процесс совместной оценки. Нужен для контроля и проверки состояния персонала и разрабатываемого программного продукта. Выполняется обеими сторонами (заказчиком и исполнителем) на протяжении времени всех работ по проекту.

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

8. Процесс разрешения проблем. Реализует устранение недочётов, выявленных во время всех процессов связанных к контролем и оценкой^[18].

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

2.2. Организационные процессы жизненного цикла программного продукта

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

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

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

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

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

4. Процесс обучения. Постоянное обучение сотрудников и повышение их квалификации – это залог производства качественных продуктов и программ. Процесс обучения направлен на организацию мероприятий для повышения уровня и получения новых навыков сотрудниками компании-разработчика^[19].

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

Этапы создания программных продуктов приведены на рис. 2.

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

Приведём все основные этапы создания программного продукта. Всего их пять. Они так или иначе характерны для любой методологии разработки программного обеспечения: будь то классическая водопадная, либо современные гибкие методологии (Agile software development) – во всех из них разработчики проходят через следующие этапы создания программного обеспечения:

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

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

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

3. Разработка. Когда требования сформулированы и архитектура готова – команда начинает разработку программного продукта. На этапе разработки также выполняется документирование системы.

4. Тестирование. После разработки необходимо произвести тестирование системы в целом, тем самым подтвердить её соответствие требованиям заказчика. Здесь стоит сказать, что модульные тесты (unit-тесты; т.е. тесты отдельных частей программы) обычно выполняются на этапе разработки программистом, разрабатывавшем конкретный модуль. Когда все тесты пройдены, программное обеспечение готово к выпуску.

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

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

2.3. Модели жизненного цикла программных продуктов

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

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

1. Каскадная (водопадная) модель.

Схематически данная модель изображена на рис. 3.

Рисунок 3 – Каскадная (водопадная) модель
жизненного цикла программного продукта^[21]

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

Характерные черты каскадной модели:

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

2) циклическое повторение пройденных этапов (как в классической модели).

2. V-образная модель разработки.

Схема данной модели изображена на рис. 4.

Рисунок 4 – V-образная модель разработки
жизненного цикла программного продукта^[22]

По рис. 4 можно проследить, что в V-образной модели имеется возможность вернуться на некоторые этапы разработки и уточнить нужные требования.

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

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

Схема данной модели изображена на рис. 5.

Рисунок 5 – Модель прототипирования
жизненного цикла программного продукта^[23]

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

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

Эффективность использования УП имеет высокий потенциал. Помимо успешного распределения ресурсов на реализацию ПО, тестирование и процессы синхронизации/верификации, интеграция в процесс программной разработки всех составляющих управляющего прототипа говорит о положительном опыте применения модели. Гарантировать более высокое качество конечного продукта, а также повышение уровня зрелости, как долгосрочных проектов, так и организации в целом использование модели УП-разработки способно лишь при совпадении запланированного объёма человеко-часов с точкой минимальных потерь, что было продемонстрировано в ходе апробации модели.

4. Модель быстрой разработки (RAD-модель).

Схема данной модели изображена на рис. 6.

Рисунок 6 – RAD-модель жизненного цикла программного продукта^[24]

RAD-модель (rapid application development — быстрая разработка приложений) ориентирована в первую очередь на быстроту и удобство программирования. Команда делает акцент именно на разработке, а большая часть работы по составлению требований и описанию пользователей возлагается на заказчика.

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

5. Итерационная модель.

Схема данной модели изображена на рис. 7.

Рисунок 7 – Итерационная модель жизненного цикла программного продукта^[25]

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

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

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

Схема данной модели изображена на рис. 8.

Рисунок 8 – Спиральная модель жизненного цикла программного продукта^[26]

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

7. Гибкие методологии

Гибкие методологии (Agile) олицетворяют современные подходы к разработке программного обеспечения. Они используются обычно в небольших командах разработчиков. Среди них такие модели жизненного цикла программного продукта, как Scrum, DSDM, XP, FDD и другие.

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

Глава 3. Выбор модели жизненного цикла программного проекта

Институтом качества программного обеспечения SQI (Software Quality Institute, США) специально для выбора модели жизненного цикла предложена схема классификации проектов по разработке программного обеспечения и систем^[27]. Основу данной классификации составляют четыре категории критериев. По каждому критерию проекты подразделяются на два альтернативных класса.

Критерии классификации проектов, предложенные Институтом SQI, объединены в следующие категории.

1. Характеристики требований к проекту.

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

2. Характеристики команды разработчиков.

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

3. Характеристики пользователей (заказчиков).

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

4. Характеристики типов проектов и рисков.

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

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

Для выбора подходящей к условиям конкретного проекта модели жизненного цикла программного обеспечения и систем SQI рекомендуется использовать специальную процедуру. Данная процедура базируется на применении четырех таблиц вопросов. Примеры вопросов приведены в Приложении 1-4.

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

Рассматриваемая процедура состоит из следующей последовательности шагов:

1-й шаг. Проанализировать отличительные черты проекта по критериям категорий, представленным в виде вопросов.

2-й шаг. Ответить на вопросы по анализируемому проекту, отметив слова «да» или «нет» в соответствующих строках табл. Приложений 1-4. Если слов «да» или «нет» в строке несколько, необходимо отметить все из них (все «да» или все «нет»). В качестве примера в табл. Приложения 1 выделены варианты ответов для проекта разработки сложного и критичного программного средства, требования к кото- рому заранее не известны и будут уточняться по ходу разработки.

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

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

Для рассмотренного примера на основе результатов заполнения табл. Приложения 1 наиболее подходящими являются модели быстрого прототипирования и эволюционные модели. Уточнение выбора модели следует производить по результатам анализа табл. Приложений 1-4.

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

Заключение

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

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

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

1. Планирование разработки.

2. Определение требований к системе:

- выработка требований;

- анализ требований.

3. Проектирование системы:

- проектирование архитектуры системы;

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

- общее проектирование программного обеспечения;

- проектирование отдельных программных компонент.

4. Реализация и тестирование системы:

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

- создание отдельных программных модулей;

- тестирование отдельных программных модулей;

- тестирование компонент системы, в т.ч. программного обеспечения как единого компонента системы;

- интегрирование отдельных компонент в систему.

5. Выпуск системы.

6. Эксплуатация системы.

7. Завершение разработки.

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

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

Институтом качества программного обеспечения SQI (США) специально для выбора модели жизненного цикла разработана схема классификации проектов по разработке программного обеспечения и систем. Основу данной классификации составляют четыре категории критериев: характеристики требований к проекту, характеристики команды разработчиков, характеристики пользователей (заказчиков), характеристики типов проектов и рисков. По каждому из критериев проекты подразделяются на два альтернативных класса. Данная классификация предназначена для достаточно крупных проектов.

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

1. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ (ред. от 13.12.2016) // СПС «КонсультантПлюс».
2. Александров А. Е., Шильманов В. П. Инструментальные средства разработки и сопровождения программного обеспечения на основе генерации кода // Бизнес-информатика. – 2015. - №4 (22). – С. 10-17.
3. Бабенко Л.К. Классификация программного обеспечения на основе поведенческих признаков // Известия ЮФУ. Технические науки. – 2016. - №4. – С. 50-59.
4. Барабанов А.В., Марков А.С., Цирлов В.Л. Методический аппарат анализа и синтеза комплекса мер разработки безопасного программного обеспечения // Программные продукты и системы. – 2015. - №4 (112). – С. 166-174.
5. Бракоренко А.С. Тестирование и обеспечение качества программно-технических комплексов // Приборы и методы измерений. – 2014. - №2 (9). – С. 75-80.
6. Гладких М.В., Кужева С. Н. Организационные аспекты разработки программного обеспечения // Вестник ОмГУ. Серия: Экономика. – 2015. - №2. – С. 109-113.
7. Данилин А.О. Методология разработки программного обеспечения с использованием управляющего прототипа // Вестник ВИ МВД России. – 2016. - №1. – С. 104-111.
8. Демидов Д.С. Разработка программных средств моделирования информационных систем // Известия ТулГУ. Технические науки. – 2014. - №9-2. – С. 28-35.
9. Домарацкий А.Н., Ласточкин Н.К. Жизненный цикл разработки программных изделий // Программные продукты и системы. – 2015. - №4. – С. 2-7.
10. Карпов В.В., Карпов А.В. Особенности применения современных методов разработки программного обеспечения защищенных автоматизированных систем // Программные продукты и системы. – 2016. - №1 (113). – С. 5-12.
11. Кочкаров Р.А. Жизненный цикл целевой программы // Известия ЮФУ. Технические науки. – 2016. - №1 (138). – С. 227-235.
12. Мансурова Н.А., Веселов П.С. Предпосылки и этапы внедрения программного обеспечения на предприятиях // Экономические исследования. – 2016. - №1. – С. 35-41.
13. Матвеев А.А. Программное обеспечение и этапы внедрения организационно-технических комплексов проектирования судов // Вестник государственного университета морского и речного флота им. адмирала С.О. Макарова. – 2014. - №2 (24). – С. 162-172.
14. Орлик С.В. Модели жизненного цикла программного обеспечения // Ученые записки РГСУ. – 2016. - №9. – С. 234-239.
15. Петриева О.В. Проектирование программного обеспечения информационной системы // 2016. - №3. – С. 55-56.
16. Романов В.Ю. Анализ и визуализация эволюции программного обеспечения // International Journal of Open Information Technologies. – 2016. - №9. – С. 64-73.
17. Силуянов А.В. Информационное и программное обеспечение автоматизированного проектирования интеллектуального здания // Электротехнические и информационные комплексы и системы. – 2015. - №1. – С. 14-21.
18. Хруставлев Е.Ю. Моделирование жизненного цикла программы создания наукоемкой продукции // Экономический анализ: теория и практика. – 2017. - №1. – С. 2-12.
19. Чумакова Т.Я., Цыганенко С.М. Международные стандарты и жизненные циклы программного обеспечения // ММС. – 2014. - №3. – С. 144-150.
20. Чупрынова К.С., Заходякин Г.В. Разработка проекта внедрения автоматизированной системы управления // Успехи в химии и химической технологии. – 2015. - №9 (149). – С. 80-84.
21. A Unified Reference Model for the Processes of Software and System Life Cycles [Электронный документ] // School of Information and Communication Technology. – Режим доступа: http://www.ict.griffith.edu.au/~bernus/taskforce/Meetings/brisbane98/technicalprogramme/pos-ppr/terryrout.html (дата обращения: 07.03.2017).
22. IEEE Std 829—2008 IEEE Standard for Software and System Test Documentation [Электронный документ] // IEEE.org. – Режим доступа: https://standards.ieee.org/findstds/standard/829-2008.html (дата обращения: 07.03.2017).
23. ISO/IEC 26514:2008(en) Systems and software engineering – Requirements for designers and developers of user documentation [Электронный документ] // ISO. – Режим доступа: https://www.iso.org/obp/ui/#iso:std:iso-iec:26514:ed-1:v1:en (дата обращения: 07.03.2017).
24. ГОСТ 19781-90. Обеспечение систем обработки информации программное. Термины и определения [Электронный документ] // ТехЭксперт. – Режим доступа: http://docs.cntd.ru/document/gost-19781-90: 07.03.2017).
25. Термины и определения стандарта ISO/IEC 2382-1 [Электронный документ] // morePC. – Режим доступа: http://www.morepc.ru/informatisation/iso2381-1.html (дата обращения: 07.03.2017).

Приложения

Приложение 1

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

Приложение 2

Выбор модели жизненного цикла на основе
характеристик команды разработчиков

Приложение 3

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

Приложение 4

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

1. Термины и определения стандарта ISO/IEC 2382-1 [Электронный документ] // morePC. – Режим доступа: http://www.morepc.ru/informatisation/iso2381-1.html (дата обращения: 07.03.2017). ↑

2. IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation [Электронный документ] // IEEE.org. – Режим доступа: https://standards.ieee.org/findstds/standard/829-2008.html (дата обращения: 07.03.2017). ↑

3. ISO/IEC 26514:2008(en) Systems and software engineering – Requirements for designers and developers of user documentation [Электронный документ] // ISO. – Режим доступа: https://www.iso.org/obp/ui/#iso:std:iso-iec:26514:ed-1:v1:en (дата обращения: 07.03.2017)/ ↑

4. ГОСТ 19781-90. Обеспечение систем обработки информации программное. Термины и определения [Электронный документ] // ТехЭксперт. – Режим доступа: http://docs.cntd.ru/document/gost-19781-90: 07.03.2017). ↑

5. Барабанов А.В., Марков А.С., Цирлов В.Л. Методический аппарат анализа и синтеза комплекса мер разработки безопасного программного обеспечения // Программные продукты и системы. – 2015. - №4 (112). – С. 166/ ↑

6. Александров А. Е., Шильманов В. П. Инструментальные средства разработки и сопровождения программного обеспечения на основе генерации кода // Бизнес-информатика. – 2015. - №4 (22). – С. 12. ↑

7. Бабенко Л.К. Классификация программного обеспечения на основе поведенческих признаков // Известия ЮФУ. Технические науки. – 2016. - №4. – С. 53. ↑

8. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ (ред. от 13.12.2016) // СПС «КонсультантПлюс». ↑

9. Романов В.Ю. Анализ и визуализация эволюции программного обеспечения // International Journal of Open Information Technologies. – 2016. - №9. – С. 67. ↑

10. Петриева О.В. Проектирование программного обеспечения информационной системы // 2016. - №3. – С. 55. ↑

11. Силуянов А.В. Информационное и программное обеспечение автоматизированного проектирования интеллектуального здания // Электротехнические и информационные комплексы и системы. – 2015. - №1. – С. 16. ↑

12. Матвеев А.А. Программное обеспечение и этапы внедрения организационно-технических комплексов проектирования судов // Вестник государственного университета морского и речного флота им. адмирала С.О. Макарова. – 2014. - №2 (24). – С. 166. ↑

13. Демидов Д.С. Разработка программных средств моделирования информационных систем // Известия ТулГУ. Технические науки. – 2014. - №9-2. – С. 30. ↑

14. Бракоренко А.С. Тестирование и обеспечение качества программно-технических комплексов // Приборы и методы измерений. – 2014. - №2 (9). – С. 74. ↑

15. Чупрынова К.С., Заходякин Г.В. Разработка проекта внедрения автоматизированной системы управления // Успехи в химии и химической технологии. – 2015. - №9 (149). – С. 82. ↑

16. Кочкаров Р.А. Жизненный цикл целевой программы // Известия ЮФУ. Технические науки. – 2016. - №1 (138). – С. 227. ↑

17. Хруставлев Е.Ю. Моделирование жизненного цикла программы создания наукоемкой продукции // Экономический анализ: теория и практика. – 2017. - №1. – С. 4. ↑

18. Мансурова Н.А., Веселов П.С. Предпосылки и этапы внедрения программного обеспечения на предприятиях // Экономические исследования. – 2016. - №1. – С. 38. ↑

19. Гладких М.В., Кужева С. Н. Организационные аспекты разработки программного обеспечения // Вестник ОмГУ. Серия: Экономика. – 2015. - №2. – С. 111. ↑

20. Карпов В.В., Карпов А.В. Особенности применения современных методов разработки программного обеспечения защищенных автоматизированных систем // Программные продукты и системы. – 2016. - №1 (113). – С. 8. ↑

21. Чумакова Т.Я., Цыганенко С.М. Международные стандарты и жизненные циклы программного обеспечения // ММС. – 2014. - №3. – С. 148. ↑

22. Орлик С.В. Модели жизненного цикла программного обеспечения // Ученые записки РГСУ. – 2016. - №9. – С. 236. ↑

23. Данилин А.О. Методология разработки программного обеспечения с использованием управляющего прототипа // Вестник ВИ МВД России. – 2016. - №1. – С. 107. ↑

24. Домарацкий А.Н., Ласточкин Н.К. Жизненный цикл разработки программных изделий // Программные продукты и системы. – 2015. - №4. – С. 4. ↑

25. Орлик С.В. Указ. соч. – С. 237. ↑

26. Чумакова Т.Я., Цыганенко С.М. Указ. соч. – С. 149. ↑

27. A Unified Reference Model for the Processes of Software and System Life Cycles [Электронный документ] // School of Information and Communication Technology. – Режим доступа: http://www.ict.griffith.edu.au/~bernus/taskforce/Meetings/brisbane98/technicalprogramme/pos-ppr/terryrout.html (дата обращения: 07.03.2017). ↑