2.3. Модель разработки по по принципу «водопад»

Модель водопада (англ. waterfall model) — модель процесса разработки программного

обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия «водопад» часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки и даже не использовал термин «водопад».

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «модель водопада», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:

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

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

3. Конструирование (также «реализация» либо «кодирование»)

4. Интеграция

5. Тестирование и отладка (также «верификация»)

6. Инсталляция

7. Поддержка

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

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

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

2.4 Технология разработки программного обеспечения компанией

В ходе прохождения производственной практики были изучены все этапы разработки

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

Сегодня разработка программного обеспечения достаточно длительный этап, требущий

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

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

Начало производства любого программного обеспечения – это сотрудничество непосредственно с заказчиком данного продукта. Компания является аутсорсинговой ориентированной на выполнение заказов поступающих из Канады(г.Торонто). В столице Канады располагается офис компании CIO(Chief Information Officer), которая непосредственно является главным заказчиком. В компании «ХостингМакс» отдел верховных менеджеров постоянно поддерживает связь с менеджерами CIO.

После того, как заказ пришел в отдел верховных менеджеров «ХостингМакс» он попадает в отдел маркетинга. Данный отдел занимается прогнозированием сроков выполнения определенного заказа, количеством затраченных ресурсов, распоряжается бюджетом компании.

Функция оценивания сроков выполнения осуществляется посредством взаимодействия с IT-отделом компании.

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

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

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

Целостное ПО включает в себя спецификацию функций, которые оно должно выполнять. Для ведения интенсивного способа производства ПО, каждый из project-менеджеров получает определенную часть спецификации будущего ПО и берется за контроль ее выполнения. В этом ему помогают team-leaderы, люди которые непосредственно общаются с определенными группами программистов, обычно от 1 до 5 человек. Team-leader – это обычно опытный програмиист, который ведет программистов с меньшим количеством опыта, является как бы наставником.

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

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

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