66253

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

Реферат

Информатика, кибернетика и программирование

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

Русский

2014-08-15

53.5 KB

90 чел.

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

Жизненный цикл программного продукта – от англ. Software life cycle) – это

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

Он состоит из следующих этапов:

a) маркетинг рынка программных средств, спецификация требований к программному продукту;

b) проектирование структуры программного продукта;

c) программирование (создание программного кода), тестирование, автономная и комплексная отладка программ;

d) документирование программного продукта;

e) выход на рынок программных средств, распространение программного продукта;

f) эксплуатация программного продукта пользователями;

g) сопровождение программного продукта; 

h) снятие с продажи, отказ от сопровождения.

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

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

Процесс создания программного продукта – это

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

Выделяют стадии этого процесса:

анализ

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

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

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

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

или

спецификация1

разработка

аттестация2

модернизация3

или4 ...

Очень важный вывод: собственно программирование – далеко не единственное занятие коллектива. Более того, оно не является даже главным, наиболее трудоемким делом. Многие исследования отдают на фазу программирования не более 15-20% времени, затраченного на разработку (сопровождение вообще бесконечно). Эти цифры, между прочим, свидетельствуют о важности различных аспектов образования – от умения найти и обосновать эффективный алгоритм до искусства владения родным языком.

Модели процесса создания ПП

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

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

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

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

Одну из первых моделей ЖЦП назвали каскадной или "водопадной" – от англ. Pure Waterfall, подчеркивая тот факт, что к предыдущей фазе проектирования вернуться невозможно.

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

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

Каскадно-возвратный технологический подход допускает возможность возврата на предыдущие стадии и пересмотр решений.

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

2. Эволюционная модель

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

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

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

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

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

4. Экстремальное программирование

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки – протеста против чрезмерной бюрократизации.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки, появившемся в 2000 году.

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

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

Доп. вопросы

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

1 Формулирование спецификаций определяет основные требования к ПО (что должна делать система).

2 проверка ПО на соответствие потребностям заказчика.

3 развитие ПО в соответствии с изменяющимися потребностями заказчика.

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

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


 

А также другие работы, которые могут Вас заинтересовать

62256. Самостоятельная работа на уроках русского языка как средство активизации познавательного интереса 34.33 KB
  В этом смысле особое значение приобретает проблема внедрения эффективных приемов самостоятельной работы в учебно-воспитательный процесс. Значит учителям необходимо учить детей самостоятельной работе.
62257. Самым лучшим уроком жизни бывает армия 20.01 KB
  Армия Что на самом деле дает этот важный урок в нашей жизни Вопрос на самом деле очень интересен и важен но в то же время кажущимся бесполезным для всех тех героев которые отслужили и вернулись домой. Армия Отнимает она на первый взгляд кажется больше чем дает. При всем моем огромном желании возможностях и начальных способностях я не умею воевать Задавим количеством А если Китай Что же на самом деле дает Армия Ты вглядываешься на жизнь совсем с другой стороны учишься жить в большом непростом коллективе когда каждый сам за...
62259. Счет победителей. Невыученные уроки войн, проигранных Россией 442.6 KB
  Прекратилась ли после этого информационная психологическая война Запада против России Сошла ли на нет русофобия Не прекратилась и не сошла. Вовторых восприятие России Западом как Чужого повидимому сохранится до тех пор пока Россия и Запад будут существовать в их нынешнем виде. Втретьих Запад в долгосрочной перспективе будет стремиться к максимальному ослаблению вплоть до раздробления России об этом откровенно говорили и говорят многие на Западе включая друга Билла Клинтона в октябре 1995 г. до такой степени при которой...