Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

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

Федеральное государственное автономное образовательное

Учреждение высшего профессионального образования

«УрФУ имени первого Президента России Б.Н.Ельцина»

Высшая школа экономики и менеджмента

Кафедра систем управления энергетикой и промышленными предприятиями

Курсовой проект

По дисциплине:

«Информационные технологии в менеджменте»

На тему:

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

Научный руководитель Гаврилова Т.Б.

Курс, группа ЭМ-210703

Студент Жаурова Т.Б

Екатеринбург

2012

Содержание

Введение
Стандарты жизненного цикл

2.1 Стандарт ГОСТ 34.601-90

2.2 Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

Процессы жизненного цикла ПО
Стадии жизненного цикла ПО
Модели жизненного цикла ПО

Каскадная (Водопадная) модель
Итерационная модель
Спиральная модель

Список использованной литературы

1.Введение

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

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

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

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

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

2.Стандарты жизненного цикла

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

2.1 Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

Формирование требований к АС

Обследование объекта и обоснование необходимости создания АС

Формирование требований пользователя к АС
Оформление отчета о выполнении работ и заявки на разработку АС

Разработка концепции АС

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

Техническое задание

Разработка и утверждение технического задания на создание АС

Эскизный проект

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

Технический проект

Разработка проектных решений по системе и ее частям
Разработка документации на АС и ее части
Разработка и оформление документации на поставку комплектующих изделий
Разработка заданий на проектирование в смежных частях проекта

Рабочая документация

Разработка рабочей документации на АС и ее части
Разработка и адаптация программ

Ввод в действие

Подготовка объекта автоматизации
Подготовка персонала
Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
Строительно-монтажные работы
Пусконаладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний

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

Выполнение работ в соответствии с гарантийными обязательствами
Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

2.2 Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».

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

3.Процессы жизненного цикла ПО

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

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

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

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

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

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

4.Стадии жизненного цикла ПО

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Модель ЖЦ ПО включает в себя:

Стадии;
Результаты выполнения работ на каждой стадии;
Ключевые события — точки завершения работ и принятия решений.

5.Модели жизненного цикла ПО

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

В настоящее время используются следующие модели жизненного цикла:

каскадная (водопадная, waterfall) или последовательная;
итеративная и инкрементальная — эволюционная (гибридная,

смешанная);

спиральная (spiral) или модель Боэма

5.1Каскадная (Водопадная) модель

Принципы каскадной модели

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

Основными принципами каскадной модели являются:

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

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

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

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

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

Рис. 1. Каскадная модель жизненного цикла

Преимущества каскадной модели

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

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

Будучи активно используема (де факто и, например, в свое время, как часть соответствующего отраслевого стандарта в США), эта модель продемонстрировала свою «проблемность» в подавляющем большинстве ИТ- проектов, за исключением, может быть, отдельных проектов обновления программных систем для критически-важных программно-аппаратных комплексов (например, авионики или медицинского оборудования). Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких систем — требования характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения требований до начала работ по реализации (особенно, для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.

Недостатки каскадной модели

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

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

Задержка в получении результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что из-за последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Может оказаться, что разрабатываемая ИС не соответствует требованиям пользователей, причем такие несоответствия могут возникать на любом этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они необязательно хорошо разбираются в тех предметных областях, для которых производится разработка ИС. Кроме того, используемые при разработке ИС модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валяют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации. Возврат на более ранние стадии. Данный недостаток каскадной модели в общем-то является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может

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

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

Рис. 2. Реальный процесс разработки по каскадной модели

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

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

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

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

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

возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени. Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, сокращая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабо связанных подсистем. Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки — этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования — требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии

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

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group в США более 31% проектов корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти 53% ИТ-проектов завершается с перерасходом бюджета (в среднем на 189%, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

Применимость каскадной модели

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

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

5.2 Итерационная модель

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

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

Жизненный цикл программного обеспечения 📙 Курсовая → 🆔 78808