66253

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

Реферат

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

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

Русский

2014-08-15

53.5 KB

91 чел.

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

Жизненный цикл программного продукта – от англ. 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 Эти две особенности часто приводят к синдрому "аналитического паралича", напряженным отношениям между разработчиками, заказчиками и пользователями.


 

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

43836. Проект станции технического обслуживания с разработкой участка по ремонту и окраске кузовов легковых автомобилей 2.82 MB
  Эксплуатационные повреждения кузова Аварийные повреждения кузова Нарушение геометрии кузова.Общие требования при устранении перекосов кузова Планировочное решение зон ТО и ТР и производственных участков
43837. Расчет водоснабжения спортивно-оздоровительной базы «Бережок» 1.54 MB
  Таким образом целью дипломного проекта является создание системы водоснабжения базы отдыха Бережок включая проектирование водозаборных сооружений нужной производительности и степени надежности сооружений очистки воды до питьевых нормативов внутренних и наружных водопроводных сетей и сооружений а также мероприятий по пожаротушению. Грунтовые воды Высота стояния грунтовых вод низкая. Воды не напорные не агрессивны по отношению к бетону. Показатели качества воды в озере представлены санитарноэпидемиологической службой Вологодской...
43838. Разработка стандарта организации «Управление несоответствующей продукцией» системы менеджмента качества (СМК) «Орловский завод» ОАО «Северсталь-метиз» 2.26 MB
  Аудит процесса Управление несоответствующей продукцией Описание исходного состояния процесса на предприятии Разработка модели процесса Результаты аудита процесса
43839. Программный комплекс классифицирования выпускников вуза (учебный аспект) 3.2 MB
  Разработка структуры данных Разработка инфологической модели данных Разработка даталогической модели данных Проектирование схемы базы данных
43840. Гражданско-правовое положение акционерного общества 649 KB
  Российское законодательство со всей очевидностью отдает предпочтение форме акционерного общества предоставляя ему право осуществлять практически любые виды предпринимательской деятельности. Одновременно существует убеждение что коммерческая организация в процессе своего функционирования не только вправе осуществлять любые виды деятельности и совершать любые сделки но и что это допустимо независимо от ее финансового состояния. ГК РФ устанавливает что...
43841. Сущность права на иск в гражданском и арбитражном процессе 384.5 KB
  Понятие иска. Элементы иска. Предпосылки права на предъявление иска. Порядок предъявления иска и последствия его не соблюдения в гражданском процессе.
43842. Разработка системы спутникового приема, с учетом обеспечения требуемого количества телевизионных сигналов, информационных потоков и сигналов IP- телефонии 1.18 MB
  Первые искусственные спутники земли ИСЗ выводились носителями мощности которых не хватало для вывода груза на геостационарную орбиту. Прием телевизионных и других информационных сигналов мы будем осуществлять с...
43843. Моделирование на ARIS бизнес-процессов с учётом требований безопасности 1.08 MB
  Темой дипломной работы является: “Моделирование на RIS бизнеспроцессов с учётом требований безопасности. Объектом исследования являются∙ инструментальная среда RIS регламент Центра сертификации ключей ЗАО Инфраструктура открытых ключей. Цели и задачи исследования ознакомление с принципами работы инструментальной среды RIS способами моделирования бизнеспроцессов. моделирование регламента Центра сертификации ключей ЗАО Инфраструктура открытых ключей с учётом требований безопасности...
43844. Правове регулювання укладання та виконання господарських договорів 649.5 KB
  Загальна характеристика зобовязальних правовідносин Поняття та склад зобовязання Норми які регулюють зобовязання становлять один із найважливіших інститутів цивільного права зобовязальне право. Норми зобовязального права є найбільш значною частиною цивільного законодавства. Система зобовязального права складається із інститутів Загальної частини та інститутів Особливої частини. Загальна частина включає: поняття зобовязання сторони в зобовязанні; виконання зобовязання; забезпечення виконання зобовязання; припинення...