Файл: Программное обеспечение и его историческое развитие.pdf

Массовое тиражирование позволило снизить к середине 90 годов 20 века стоимость программного обеспечения для персональных компьютеров до ста — пятисот долларов, при этом бизнес производителей программного обеспечения приобрел определенное сходство с бизнесом звукозаписывающих компаний^[21] [2, 9, 16].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• каскадная модель;
• поэтапная модель с промежуточным контролем;
• инкрементная модель;
• спиральная модель^[34] [2, 9, 10, 11, 13, 15].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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