Водопадная (каскадная) модель.
РЕФЕРАТ
на тему«Процесс разработки ПО. Шаги процесса»
Выполнила:
Студентка Аверьянова Ю. А.
Группа И958
Проверил:
Васюков В. М.
Санкт-Петербург
Содержание
Введение…………………………………….…..…..….…….…………………3
1 Модели процесса………………..…...…………..……….………………..…5
1.1Водопадная (каскадная модель)…....….………….………......…………5
1.2Итерационная модель……………..…...……….……….…......…………8
1.3 Спиральная модель…………………….…..……..…….………..…..…..10
2 Шаги процесса………………………...….….………..……………….…….14
2.1 Определение и анализ требований…………...………….………….…..14
2.2 Проектирование………………………………….………………….……16
2.3 Кодирование……………………………...……………...………….……18
2.4 Интегрирование………………………….…………..……………….….19
2.5 Тестирование и отладка…………………………………..……….…….19
2.7Внедрение……………………………..……………....………...………...20
2.7 Сопровождение и эксплуатация…………..………………..…………...22
2.8 Документирование……………………....……………..………………...23
Заключение……………………...……………….……….……………….……24
Список использованной литературы….……...….…………………………..25
Введение
Прежде чем перейти непосредственно к описанию процесса разработки программного обеспечения, его шагам, что является темой данного реферата, необходимо дать некоторые важные определения. Для начала следует указать, что же такое само программное обеспечение.
Под программным обеспечением понимается совокупность программ, выполняемых вычислительной системой. Если говорить немного более развёрнуто, то программное обеспечение – это совокупность специальных программ, облегчающих процесс подготовки задач к выполнению на ЭВМ и организующих прохождение их через машину, а также процедур, описаний, инструкций и правил вместе со всей связанной с этими компонентами документацией, используемых при эксплуатации вычислительной системы.[1]
К программному обеспечению относится также вся область деятельности по проектированию и разработке ПО, а именно:
1) технология проектирования программ;
2) методы тестирования программ;
3) методы доказательства правильности программ;
4) анализ качества работы программ;
5) документирование программ;
6) разработка и использование программных средств, облегчающих процесс проектирования программного обеспечения, и многое другое.[2]
Назначений у программного обеспечения несколько. Среди них:
1) обеспечение работоспособности компьютера;
2) облегчение взаимодействия пользователя с компьютером;
3) сокращение цикла от постановки задачи до получения результата;
4) повышение эффективности использования ресурсов компьютера.
Программное обеспечение позволяет:
1) усовершенствовать организацию работы вычислительной системы с целью максимального использования ее возможностей;
2) повысить производительность и качество труда пользователя;
3) адаптировать программы пользователя к ресурсам конкретной вычислительной системы;
4) расширить ПО вычислительной системы.
После того, как понятие «программное обеспечение» более чем разъяснено, можно переходить к процессу его разработки.
Процесс разработки программного обеспечения - структура, согласно которой построена разработка программного обеспечения.
Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.[3] Все они будут рассмотрены в рамках данной работы.
На сегодняшний момент не существует универсального или, можно сказать, общепринятого процесса разработки ПО - набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, в рамках определенного проекта, имеет существенное количество особенностей и индивидуальностей. Важно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты, порядок участия в их разработке членов команды и т.д.[4]
Модели процесса.
Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса.
Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель - самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И стали развиваться интегральные методологии разработки. Тем не менее, существует несколько классических моделей процесса, которые полезны на практике.[5]
Водопадная (каскадная) модель.
Модель водопада (каскадная модель) была предложена в 1970 году Уинстоном Ройсом и предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке.
В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:
1. Определение требований.
2. Проектирование.
3. Конструирование (также «реализация» либо «кодирование»).
4. Интеграция.
5. Тестирование и отладка (также «верификация»).
6. Инсталляция.
7. Поддержка.
Рисунок 1. – Этапы каскадной модели.
Следуя модели водопада, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка - внесение новой функциональности и устранение ошибок.
Тем самым, модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз - не происходит. [6]
Достоинством этой модели явилось ограничение возможности возвратов на произвольный шаг назад, например, от тестирования – к анализу, от разработки – к работе над требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг, например, от тестирования к кодированию, от кодирования к проектированию и т.д. [7]
Недостатками водопадной модели являются:
1) отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;
2) требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно полностью завершить разработку требований, дизайн системы и т.д. – все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии;
3) интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
4) пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;
5) модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".
Тем не менее, существуют модифицированные модели водопада (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.
Итерационная модель.
Общепринятая модель жизненного цикла не является идеальной уже потому, что только очень простые задачи проходят все этапы без каких-либо итераций - возвратов на предыдущие шаги производственного процесса. При программировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительностью. В этом случае необходимо перепроектирование, а может быть, и переделка спецификаций. При разработке больших нетрадиционных систем итеративность возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы.
Таковы мотивы классической итерационной модели жизненного цикла:
Рисунок 2. – Этапы итерационной модели.
Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа "Эксплуатация и сопровождение" к этапу "Тестирование и отладка". Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию. [8]
Основываясь на специфике проекта и требованиях заказчика, разработчики могут выбирать, что они хотят получить в результате очередной итерации:
1. Полноценную систему с ограниченной функциональностью, готовую для промышленной эксплуатации.
2. Функциональные и архитектурные прототипы, непригодные для промышленной эксплуатации, но позволяющие оценить функциональный дизайн, пользовательский интерфейс, производительность и т.д.[9]
Классическая итерационная модель абсолютизирует возможность возвратов на предыдущие этапы. Однако это обстоятельство отражает существенный недостаток программных разработок, проводимых в традиционном стиле: стремление заранее предвидеть все ситуации использования системы и невозможность в подавляющем большинстве случаев достичь этого. Все подобные методологии программирования направлены лишь на то, чтобы минимизировать возвраты. Но суть от этого не меняется: при возврате всегда приходится повторять построение того, что уже считалось готовым. [10]
Итеративная модель обладает рядом преимуществ по сравнению с водопадной:
1. Реализация наиболее важных функций может быть завершена в ходе нескольких первых итераций. После их завершения (то есть намного раньше окончания всего проекта) заказчик сможет начать использование системы.
2. Уже в начале проекта пользователи получают возможность оценить функциональность системы и ее соответствие своим потребностям. Необходимые изменения и дополнения могут быть сделаны в течение следующих итераций.
3. Основные проектные риски могут (и должны) быть разрешены на первых итерациях. Например, архитектурное решение, приводящее к неприемлемой производительности может быть обнаружено и исправлено уже в первой итерации.
Важно понимать, что все эти преимущества проявляются только при тщательном планировании итераций, в противном случае легко получить ухудшенный вариант модели водопада.[11]
Спиральная модель.
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной.
Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО, на следующем определяются системные требования, потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
1) определение целей, ограничений и альтернатив проекта;
2) оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
3) разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;
4) планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно. [12]
Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение.
Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели. [13]
Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей. [14]
Рисунок 3. – Этапы спиральной модели.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.[15]
Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО.[16]
Шаги процесса.
Разработка любой программы, будь то небольшая процедура по обработке поступающей на консоль информации или комплексный программный продукт, состоит из нескольких этапов, грамотная реализация которых является обязательным условием для получения хорошего результата. Четкое следование выверенным временем этапам разработки программного обеспечения становится основополагающим критерием для занимающихся созданием ПО компаний и их заказчиков, заинтересованных в получении превосходно выполняющей свои функции программы. [17]
Рассмотрим основные шаги процесса:
1. Определение и анализ требований.
2. Проектирование.
3. Конструирование (также «реализация» либо «кодирование»).
4. Интеграция.
5. Тестирование и отладка (также «верификация»).
6. Внедрение.
7. Сопровождение и эксплуатация.
8. Документирование.