программы с большим и малым временем жизни

Жизненный цикл программы

Понятие языка программирования и их классификация.

Язык – в теории программирования – совокупность символов (алфавит) и правила (определенные способы объединения этих символов в языковые конструкции для записи осмысленных текстов).

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

К языкам программирования предъявляют следующие требования:

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

2) универсальность – определяется возможностями языка в написании различных алгоритмов.

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

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

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

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

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

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

Любой язык программирования состоит из трех частей:

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

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

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

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

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

Основные (не содержат других операторов)

и производные (составные)

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

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

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

1) в любой момент времени хранит не более одного значения

2) имеет постоянный тип данных на протяжении всего времени работы программы

3) хранит текущее значение до записи нового

4) в начале работы программы значения неинициализированных переменных считаются неопределенными, то есть воспользоваться ими нельзя.

Жизненный цикл программы.

Первое поколения ЭВМ отличалось конструктивной простотой и небольшими возможностями.

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

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

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

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

По длительности жизненного цикла все программы делятся на два класса:

С малым и большим временем жизни.

Этим классам соответствуют 2 подхода в их создании:

— гибкий (как объект научного творчества)

— жестко стандартизированный (промышленный)

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

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

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

Жизненный цикл таких программ состоит из следующих этапов:

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

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

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

4) Сопровождение состоит в эксплуатации и обслуживании, улучшении характеристик и расширении возможности программного продукта, а также тиражировании и переносе программы на другие типы ВТ.

Источник

Программы с большим и малым временем жизни

Узбекское Агентство
Связи и Информатизации

Ташкентский Университет Информационных Технологий

Кафедра
«Программное обеспечение информационных технологий»

Направления:

Выдержки из лекций

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

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

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

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

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

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

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

Программные изделия с малой длительностью эксплуатации

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

чего жизненный цикл программного изделия редко превышает 3 года.

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

Программные изделия с большой длительностью эксплуатации

Их проектированием и эксплуатацией занимаются большие коллективы специалистов, для чего необходима формализация программной системы, а также формализованные испытания и определение достигнутых показателей качества конечного про­дукта. Их жизненный цикл составляет 10. 20 лет. До 70. 90 % этого времени приходится на эксплуатацию и сопровождение. Вследствие массового тиражирования и длительного сопровождения совокупные затраты в процессе эксплуатации и сопровождения таких программных изделий значительно превышают затраты на системный анализ и проектирование.

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

Обобщенная модель жизненного циклапрограммного изделия может выглядеть так:

б) анализ осуществимости:

— функциональная декомпозиция системы, ее архитектура;

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

— проектирование базы данных;

— архитектура программного обеспечения;

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

— внешнее проектирование программных модулей;

— внутреннее проектирование программных модулей;

в) отладка программного обеспечения.

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

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

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

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

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

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

Работа заключается в исследовании предполагаемого прог­раммного изделия с целью получения практической оценки возможности реализации проекта, в частности определяются:

— осуществимость эксплуатационная, будет ли изделие доста­точно удобно для практического использования?

— осуществимость экономическая, приемлема ли стоимость разрабатываемого изделия? Какова эта стоимость? Будет ли изделие экономически эффективным инструментом в руках пользователя?

— осуществимость коммерческая,будет ли изделие привлека­тельным, пользоваться спросом, легко устанавливаемым, прис­пособленным к обслуживанию, простым в освоении?

Эти и другие вопросы необходимо решать главным образом при рассмотрении указанных выше требований.

Анализ осуществимости заканчивается, когда все требования собраны и одобрены.

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

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

Часто в период системного анализа принимается решение о прекращении дальнейшей разработки программного обеспе­чения.

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

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

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

К моменту утверждения требований работа в фазе конст­руирования будет в самом разгаре.

На этом отрезке жизни программного обеспечения осу­ществляют:

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

— внешнее проектирование программного обеспечения, вы­ражающееся в форме внешнего взаимодействия его с поль­зователем;

— проектирование базы данных, если это необходимо;

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

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

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

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

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

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

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

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

Она продолжается так же долго, как и программирование.

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

Фаза использования программного изделия начинается тогда, когда изделие передается в систему распределения.

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

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

Использование программного продукта определяется его эксплуатацией и сопровождением.

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

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

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

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

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

Перекрытие между фазами жизненного цикла программного изделия

Возможны и обычно желательны перекрытия между разными фазами жизненного цикла программного изделия. Однако не должно быть никакого перекрытия между несмежными про­цессами.

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

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

Например, когда проектируется единственная программа, то часто обходятся без проектирования архитектуры системы и

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

Источник

ПО с большим и малым временем жизни

а) морального старения;

б) потери крайне важности решения соответствующих задач.

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

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

ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов.

Простейшее представление жизненного цикла, включаетстадии:

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

-Внедрение, эксплуатация и сопровождение.

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

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

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

Этап реализации включает написание программы.

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

Распределение затрат по стадиям ЖЦ

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

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

-факторы, определяющие организацию процесса разработки комплексов программ и его обеспечение квалифицированными специалистами;

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

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

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

ПО Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (.Модель ЖЦ зависит от специфики ИС и условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

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

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

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

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

Концептуальный проект не зависит от архитектуры!

— выбор комплекса технических средств (выбор «железа»)

— выбор общесистемных пакетов

-выбор способа тиражирования данных

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

Логический проект зависит от архитектуры (можно считать временные характеристики)

Результаты проектирования БД и приложений объединяются. В итоге разрабатывается пилотный проект системы

Выявление ошибок и их устранение, модернизация.

Достоинства каскадной модели:

— проста, естественна, имеет некоторую привязку к ГОСТу

— достаточно продолжительный цикл разработки по времени (система морально устаревает)

— доработка системы связана с большим объемом перепрограммирования (из-за слабого использования CASE-средств)

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

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

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

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

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

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

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

Каждый этап реализуется CASE-средствами. Содержание этапов совпадает с аналогичными в каскадной модели, но в отличие от нее, этапы реализуются с помощью CASE-средств (Computer Aided Software System Design) – (автоматизированная технология создания программных информационных систем) – использование этих средств позволяет существенно снизить время реализации витка спирали проектирования

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

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

Описанная схема разработки называют визуальным проектированием.

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

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

— небольших групп разработчиков (3-7 чел.), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

— короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

— определение функций, которые должна выполнять система;

— выделение наиболее приоритетных функций, требующих проработки в первую очередь;

— описание информационных потребностей. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков.

Кроме того, на данной стадии реализуются следующие задачи:

— ограничивается масштаб времени;

— устанавливаются временные рамки для каждой из последующих стадий.

Определяется сама возможность реализации проекта в заданных рамках финансирования, на имеющихся аппаратных средствах.

Результатом стадии должны быть список расставленных по приоритету функций будущего ПО ЭИС и предварительные модели ПО.

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

— более детально рассматриваются процессы системы;

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

— устанавливаются требования разграничения доступа к данным;

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

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

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

— входной элемент приложения (входной документ или экранная форма);

— выходной элемент приложения (отчет, документ, экранная форма)

— запрос (пара «вопрос/ответ»);

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

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

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

Результатом данной стадии должно быть:

— общая информационная модель системы;

— функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

— точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

— построенные прототипы экранных форм, отчетов, диалогов.

На этой стадии выполняется непосредственно сама быстрая разработка приложения.

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

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

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

Реализация системы завершается выполнением следующих работ:

— осуществляется анализ использования данных и определяется необходимость их распределения;

— Производится физическое проектирование базы данных;

— формируются требования к аппаратным ресурсам;

— устанавливаются способы увеличения производительности;

— завершается разработка документации проекта.

Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

— разрабатывается совершенно новая система;

— уже было проведено обследование организации и существует модель ее деятельности;

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

Следует отметить, что подход RAD, как и любой другой подход, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникаций, то на первый план выступают такие показатели проекта как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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

а) морального старения;

б) потери крайне важности решения соответствующих задач.

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

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

ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов.

Простейшее представление жизненного цикла, включаетстадии:

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

-Внедрение, эксплуатация и сопровождение.

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

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

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

Этап реализации включает написание программы.

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

ПО с большим и малым временем жизни

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

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

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

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

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

Источник