Главная > Расчеты

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

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

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

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

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

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

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

  1. Анализ требований,
  2. Проектирование,
  3. Кодирование (программирование),
  4. Тестирование и отладка,
  5. Эксплуатация и сопровождение.

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

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

Недостатки модели:

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

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

Область применения Каскадной модели

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

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

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

(поэтапная модель с промежуточным контролем)

Инкрементная модель (англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.


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

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

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

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

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

Достоинства:

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

Недостатки модели:

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

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

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

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


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

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

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

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

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

Недостатки модели:

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

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

Область применения спиральной модели

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

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

Жизненный цикл ПО. Стадии и этапы

Жизненный цикл ИС - ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

Традиционно выделяются следующие основные этапы ЖЦ ПО:

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

Проектирование,

Кодирование (программирование),

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

Эксплуатация и сопровождение.

Жизненный цикл ПО. Каскадная модель

каскадная модель (70-80г.г.) ≈ предполагает переход на следующий этап после полного окончания работ по предыдущему этапу,

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

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

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

поэтапная модель с промежуточным контролем (80-85г.г.) ≈ итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; однако, время жизни каждого из этапов растягивается на весь период разработки,

Основные этапы решения задач

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

Данные (data) - это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация (information) - это смысл, который придается данным при их представлении.

Обработка данных (data processing) - это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на носителях данных.

Совокупность носителей данных, используемых при какой-либо обработке данных называется информационной средой (data medium).

Набор данных, содержащихся в какой-либо момент в информационной среде - состояние информационной среды.

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

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

Критерии качества ПО

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

Качество – объективная характеристика товара (продукции, услуги), показывающая степень удовлетворенности потребителя

Характеристики качества:

› Работоспособность – система работает и реализует требуемые функции.

› Надежность – система работает без отказов и сбоев.

› Восстанавливаемость .

› Эффективность – система реализует свои функции наилучшим образом.

› Экономическая эффективность – минимальная стоимость конечного продукта при максимальной прибыли.

Характеристики качества:

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

› Переносимость (мобильность) – переносимость кода на другую платформу или систему.

› Функциональная полнота – возможно наиболее полная реализация внешних функций.

› Точность вычисления

Свойства алгоритма.

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

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

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

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

Способы описания алгоритмов

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

1. словесное описание;

2. описание алгоритма с помощью математических формул;

3. графическое описание алгоритма в виде блок-схемы;

4. описание алгоритма с помощью псевдокода;

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

6. с помощью сетей Петри.

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

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

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

Символы, из которых состоит блок-схема алгоритма, определяет ГОСТ 19.701-90. Этот ГОСТ соответствует международному стандарту оформления алгоритмов, поэтому блок-схемы алгоритмов, оформленные согласно ГОСТ 19.701-90, в разных странах понимаются однозначно.

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

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


Рисунок 1 - Пример описания алгоритма в виде блок-схемы

Описание этого же алгоритма на псевдокоде:

2. Ввод чисел: Z, X

3. Если Z > X то Вывод Z

4. Иначе вывод Х

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

Виды алгоритмов

линейные;

ветвящиеся;

циклические.

· Линейный алгоритм - набор команд (указаний), выполняемых последовательно друг за другом.

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

· Циклический алгоритм - алгоритм, предусматривающий многократное повторение одного и того же действия (одних и тех же операций) Над новыми исходными данными. К циклическим алгоритмам сводится большинство методов вычислений, перебора вариантов. Цикл программы - последовательность команд (серия, тело цикла), которая может выполняться многократно (для новых исходных данных) до удовлетворения некоторому условию.

Си.Типы данных.

Тип данных – это описание диапазона значений, которые может принимать переменная, указанного типа. Каждый тип данных характеризуется:
  1. количеством занимаемых байт(размером)
  2. диапазоном значений которые может принимать переменная данного типа.

Все типы данных можно разделить на следующие виды:
  1. простые (скалярные) и сложные (векторные) типы;
  2. базовые (системные) и пользовательские(которые определил пользователь).
 В языке СИ систему базовых типов образуют четыре типа данных:
  1. символьный,
  2. целочисленный,
  3. вещественный одинарной точности,
  4. вещественный двойной точности.

Структура программы на Си.

1. Операторы языка C++

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

try { <операторы> }
catch (<объявление исключения>) { <операторы> }
catch (<объявление исключения>) { <операторы> }
...
catch (<объявление исключения>) { <операторы> }

Условный оператор

if (<выражение>) <оператор 1>

Оператор-переключатель

switch (<выражение>)
{ case <константное выражение 1>: <операторы 1>
case <константное выражение 2>: <операторы 2>
...
case <константное выражение N>: <операторы N>
}
Оператор-переключатель предназначен для выбора одного из нескольких альтернативных путей выполнения программы. Вычисление оператора-переключателя начинается с вычисления выражения, после чего управление передается оператору, помеченному константным выражением, равным вычисленному значению выражения. Выход из оператора-переключателя осуществляется оператором break. Если значение выражения не равно ни одному константному выражению, то управление передается оператору, помеченному ключевым словом default, если он есть.
Оператор цикла с предусловием

while (<выражение>) <оператор>

Оператор цикла с постусловием

do <оператор> while <выражение>;
В языке C++ этот оператор отличается от классической реализации цикла с постусловием тем, что при истинности выражения происходит продолжение работы цикла, а не выход из цикла.
Оператор пошагового цикла

for ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Тело оператора for выполняется до тех пор, пока условное выражение не станет ложным (равным 0). Начальное выражение и выражение приращения обычно используются для инициализации и модификации параметров цикла и других значений. Начальное выражение вычисляется один раз до первой проверки условного выражения, а выражение приращения вычисляется после каждого выполнения оператора. Любое из трех выражений заголовка цикла, и даже все три могут быть опущены (не забывайте только оставлять точки с запятой). Если опущено условное выражение, то оно считается истинным, и цикл становится бесконечным.
Оператор пошагового цикла в языке С++ является гибкой и удобной конструкцией, поэтому оператор цикла с предусловием while используется в языке С++ крайне редко, т.к. в большинстве случаев удобнее пользоваться оператором for.
Оператор разрыва

break;
Оператор разрыва прерывает выполнение операторов while, do, for и switch. Он может содержаться только в теле этих операторов. Управление передается оператору программы, следующему за прерванным. Если оператор разрыва записан внутри вложенных операторов while, do, for, switch, то он завершает только непосредственно охватывающий его оператор.
Оператор продолжения

continue;
Оператор продолжения передает управление на следующую итерацию в операторах цикла while, do, for. Он может содержаться только в теле этих операторов. В операторах do и while следующая итерация начинается с вычисления условного выражения. В операторе for следующая итерация начинается с вычисления выражения приращения, а затем происходит вычисление условного выражения.
Оператор возврата

return [<выражение>];
Оператора возврата заканчивает выполнение функции, в которой он содержится, и возвращает управление в вызывающую функцию. Управление передается в точку вызывающей функции

If (логическое выражение)

оператор;

If (логическое выражение)

оператор_1;

оператор_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

Если значение логического выражения истинно, то вычисляется выражение_1, в противном случае вычисляется выражение_2.

switch (выражение целого типа)

case значение_1:

последовательность_операторов_1;

case значение_2:

последовательность_операторов_2;

case значение_n:

последовательность_операторов_n;

default:

последовательность_операторов_n+1;

Ветку default можно не описывать. Она выполняется, если ни одно из вышестоящих выражений не удовлетворено.

Оператор цикла.

В Турбо Си имеются следующие конструкции, позволяющие программировать циклы: while, do while и for . Их структуру можно описать следующим образом:

Цикл с проверкой условия наверху:

Оператор выбора

Если действия, которые необходимо выполнить в программе, зависят от значения некоторой переменной, можно использовать оператор выбора. При этом в C++ в качестве переменных в операторе выбора можно использовать только численные. В общем виде запись оператора выбора выглядит так:

switch(переменная)
{
case значение1:
действия1
break;

case значение2:
действия2
break;
...

default:
действия по умолчанию
}

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

switch(переменная)
{
case значение1:
case значение2:
действия1
break;

case значение3:
действия2
break;
...
}

Пример использования выбора:

int n, x;
...
switch(n)
{
case 0:
break; //если n равна 0, то не выполняем никаких действий

case 1:
case 2:
case 3:
x = 3 * n; //если n равна 1, 2 или 3, то выполняем некоторые действия
break;

case 4:
x = n; //если n равна 4, то выполняем другие действия
break;

default:
x = 0; //при всех других значениях n выполняем действия по умолчанию
}

Си.Цикл: цикл с параметром

Общая форма записи

for (инициализация параметра; проверка условия окончания; коррекция параметра) {

блок операций;

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

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

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

§ коррекция параметра - изменение значения параметра при каждом прохождении тела цикла.

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

Пример

#include
int main() {

for(num = 1; num < 5; num++)

printf("num = %d\n",num);

Си. Цикл с предусловием

Общая форма записи

while(выражение) {

блок операций;
}

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

Пример

int k=5;
int i=1;
int sum=0;
while(i <=k) {

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

блок операций;
}

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

Си. Цикл с постусловием

Цикл с постусловием do...while

Общая форма записи

блок операций;

} while(выражение);

Цикл с постусловием

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

Использовать цикл do...while лучше использовать в тех случаях, когда должна быть выполнена хотя бы одна итерация, либо когда инициализация объектов, участвующих в проверке условия, происходит внутри тела цикла.

Пример . Ввести число от 0 до 10

#include
#include
int main() {

system("chcp 1251");

printf("Введите число от 0 до 10: ");

scanf("%d", &num);

} while((num < 0) || (num > 10));

printf("Вы ввели число %d", num);

getchar(); getchar();

Определение функций

Рассмотрим определение функции на примере функции sum.

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

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

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

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

1) Вычислительные задачи, связанные с обработкой числовой информации. К ним относится, например, задача решения системы линейных уравнений большой размерности. Раньше была основной, доминирующей областью использования ЭВМ.

2) Задачи по обработке символьной информации, связанные с созданием, редактированием и преобразованием текстовых данных. С решением таких задач связан труд, например, секретаря-машинистки.

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

4) Задачи по обработке алфавитно-цивровой информации – ИС. В настоящее время стало одной из основных областей применеия ЭВМ и задачи все усложняются.

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

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

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

Рисунок

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

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

Разработка ПО подчиняется определенному жизненному циклу.

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


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

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

Технологические подходы – это механизмы реализации жизненного цикла.

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

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

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

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

Реализация

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

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

Простейшее представление ЖЦ программы (каскадный технологический подход к ведению жизненного цикла):

Процессы

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

Программирование

Тестирование

Сопровождение

Анализ Проектирование Реализация ТестированиеВнедрениеэксплуатация

и отладка и сопровождение

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

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

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

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

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

ЖЦ ПО регламентируется многими стандартами в том числе и международными.

Цель стандартизации ЖЦ сложных ПС:

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

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

Стандарты включают:

Правила описания исходной информации, способов и методов выполнения операций;

Устанавливают правила контроля технологических процессов;

Устанавливают требования к оформлению результатов;

Регламентируют содержание технологических и эксплуатационных документов;

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

Обеспечивают распределение и планирование заданий;

Обеспечивают контроль за ходом создания ПС.

В России действуют стандарты, регламентирующие ЖЦ:

Стадии разработки ПО– ГОСТ 19.102-77

Стадии создания АС - ГОСТ 34.601 –90;

ТЗ на создание АС - ГОСТ 34.602-89;

Виды испытания АС - ГОСТ 34.603-92;

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

В связи с этим следует отметить международный стандарт ISO/IEC 12207-1999 – «Информационные технологии – Процессы жизненного цикла программного обеспечения».

ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.

Он определяет структуру ЖЦ ПО и его процессы.

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

Структура ЖЦ ПО по международному стандарту ISO/IEC 12207-95 базируется на трех группах процессов:

1) основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение ). Мы основное внимание уделим последним.

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

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

2. Верификация -это процесс определения того, отвечает ли текущее состояние ПО, достигнутое на данном этапе, требованиям этого этапа.

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

4. Совместный анализ(оценка) – систематическое определение степени соответствия объекта установленным критериям.

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

3) организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

Мы будем рассматривать ЖЦ ПО с точки зрения разработчика.

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

По стандарту жизненный цикл ПО ИС включает в себя следующие действия:

1) возникновение и исследование идеи(замысла);

2) подготовительный этап - выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ.

3) анализ требований к информационной системе - определение ее

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

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

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

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

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

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

8) кодирование ПО - – разработка и документирование

каждого программного компонента;

9)тестирование ПО – разработка совокупности тестовых процедур и данных для их тестирования, тестирование компонентов, обновление пользовательской документации, обновление плана интеграции ПО;

10) интеграция ПО – сборка программных компонентов в соответсвие с

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

11) квалификационное тестирование ПО – тестирование ПО в

присутствии заказчика для демонстрации его соответствия

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

12) интеграция системы – сборка всех компонетов информационной системы, включая ПО и оборудование;

13) квалификационное тестирование ИС – тестирование системы на

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

14) установка ПО – установка ПО на обородование заказчика и проверка его работоспособюности; ;

15) приемка ПО – оценка результатов квалифицированного

тестирования ПО и информционной системы в целом и

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

16)Управление и разработка документации;

17)эксплуатация

18)сопровождение – процесс создания и внедрения новых версий

программного продукта. ;

19)завершение эксплуатации.

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

· постановка задачи(ТЗ) (по ГОСТ 19.102-77 стадия «Техническое задание»)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I . Системный анализ:

а) исследования;

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

Эксплуатационной;

Экономической;

Коммерческой.

II . Проектирование программного обеспечения:

а) конструирование:

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

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

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

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

б) программирование:

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

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

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

Кодирование;

Отладка программ;

Компоновка программ;

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

III . Оценка (испытания) программного обеспечения.

IV . Использование программного обеспечения:

а) эксплуатация;

б) сопровождение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы ЖЦ ПО:

Основные,

Вспомогательные,

Организационные.


Основные:

1. Приобретение – действия и задачи заказчика, приобретающего ПО;

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

3. Разработка – действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов;

4. Эксплуатация – действия и задачи оператора организации, эксплуатирующей систему;

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

Вспомогательные:

1. Документирование – формализованное описание информации, созданной в течение ЖЦ ПО;

2. Управление конфигурацией– применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями;

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

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

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

6. Совместная оценка– оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами;

7. Аудит – определение соответствия требованиям, планам и условиям договора;

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

Организационные:

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

2. Создание инфраструктуры– выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО;

3. Усовершенствование – оценка, измерение, контроль и усовершенствование процессов ЖЦ;

4. Обучение – первоначальное обучение и последующее постоянное повышение квалификации персонала.

В 2002 г. был опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение – поддержка создания компьютеризированных систем.



Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

Приобретение (внутренние решения или решения внешнего поставщика);

Поставка (внутренние решения или решения внешнего поставщика);

2. Процессы предприятия:

Управление окружающей средой предприятия;

Инвестиционное управление;

Управление ЖЦ ИС;

Управление ресурсами;

Управление качеством;

3. Проектные процессы:

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

Оценка проекта;

Контроль проекта;

Управление рисками;

Управление конфигурацией;

Управление информационными потоками;

Принятие решений.

4. Технические процессы:

Определение требований;

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

Разработка архитектуры;

Внедрение;

Интеграция;

Верификация;

Переход;

Аттестация;

Эксплуатация;

Сопровождение;

Утилизация.

5. Специальные процессы:

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


Создание основных процессов ЖЦ ПО по ИС (ISO/IEC 15288)

Процесс (исполнитель процесса) Действия Вход Результат
Приобретение (заказчик) - Инициирование - Подготовка заявочных предложений - Подготовка договора - Контроль деятельности поставщика - Приемка ИС - Решение о начале работ по внедрению ИС - Результаты обследования действий заказчика - Результаты анализа рынка ИС/ тендера - План поставки/ разработки - Комплексный тест ИС - Технико-экономическое обоснование внедрения ИС - Техническое задание на ИС - Договор на поставку/ разработку - Акты приемки этапов работы - Акт приемно-сдаточных испытаний
Поставка (разработчик ИС) - Инициирование - Ответ на заявочные предложения - Подготовка договора - Планирование исполнения - Поставка ИС - Техническое задание на ИС - Решение руководства об участии в разработке - Результаты тендера - Техническое задание на ИС - План управления проектом - Разработанная ИС и документация - Решение об участии в разработке - Коммерческие предложения/ конкурсная заявка - Договор на поставку/ разработку - План управления проектом - Реализация/ корректировка - Акт приемно-сдаточных испытаний
Разработка (разработчик ИС) - Подготовка - Анализ требований к ИС - Проектирование архитектуры ИС - Разработка требований к ПО - Проектирование архитектуры ПО - Детальное проектирование ПО - Кодирование и тестирование ПО - Интеграция ПО и квалифицированное тестирование ПО - Интеграция ИС и квалифицированное тестирование ИС - Техническое задание на ИС - Техническое задание на ИС, модель ЖЦ - Подсистемы ИС - Спецификации требования к компонентам ПО - Архитектура ПО - Материалы детального проектирования ПО - План интеграции ПО, тесты - Архитектура ИС, ПО, документация на ИС, тесты - Используемая модель ЖЦ, стандарты разработки - План работ - Состав подсистем, компоненты оборудования - Спецификации требования к компонентам ПО - Состав компонентов ПО, интерфейсы с БД, план интеграции ПО - Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам - Тексты модулей ПО, акты автономного тестирования - Оценка соответствия комплекса ПО требованиям ТЗ - Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Стадии создания систем (ISO/IEC 15288)


СРС: Создать техническое задание для проекта «Очередь» на сайте www.mastertz.ru

Модели ЖЦ ПО:

1. каскадная,

2. спиральная,

3. итерационная.

Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

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

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

Разработка требований
Формирование

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Уильямса Эдварда Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

Прототип – действующий компонент ПО, реализующий отдельные функции и внешние интерфейсы.

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

Рис. 21. Спиральная модель ЖЦ ПО

На каждой итерации оцениваются:

1. Риск превышения сроков и стоимости проекта;

2. Необходимость выполнения еще одной итерации;

3. Степень полноты и точности понимания требований к системе;

4. Целесообразность прекращения проекта.

Один из примеров реализации спиральной модели - RAD.

Основные принципы RAD:

1. Инструментарий должен быть нацелен на минимизацию времени разработки;

2. Создание прототипа для уточнения требований заказчика;

3. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;

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

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

6. Управление проектом должно минимизировать длительность цикла разработки.

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

Рис. 22. Итерационная модель ЖЦ ПО

Рекомендуем также

Loading...Loading...