Основные этапы разработки программ

Разработка должна быть проведена в три стадии:

— разработка технического задания;

Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

— разработка программной документации;

На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

— определение и уточнение требований к техническим средствам;

— определение требований к конфигурации;

— определение стадий, этапов и сроков разработки конфигурации и документации на неё;

— согласование и утверждение технического задания.

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

Как делают игры | Все этапы создания игр — подробно

На этапе испытаний конфигурации должны быть выполнены перечисленные ниже виды работ:

— разработка, согласование и утверждение и методики испытаний;

— проведение приемо-сдаточных испытаний;

— корректировка конфигурации и программной документации по результатам испытаний.

На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче конфигурации и документации в эксплуатацию на объектах Заказчика.

Виды испытаний

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки.

Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний.

Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний.

Общие требования к приемке работы

На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

Характеристика разрабатываемого продукта

Назначение программы

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

Так же имеется возможность вывода ведомости, оформленной по стандарту (Форма Т-13) в Microsoft Excel и её последующей распечатки.

Техническое и программное описание программы

Для разработки приложения были выбран ПК со следующими техническими характеристиками:

— процессор Intel 2.3 GHz;

— оперативную память объемом, 1Гигабайт;

— HDD, 50 Гигабайт, свободного места на котором не менее 80 Мб;

Урок 2. Этапы разработки ПО

— видеоадаптер nVidia GeForce GTX 580;

— монитор Samsung S22C200NY;

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

— операционная систему версии от Windows XP;

— приложение MS Office 2007;

— программа работы с базами данных Access;

— программа работы с электронными таблицами Excel;

— программа разработки и создания приложений Visual Studio 2008;

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

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

Рисунок 5. Связи по данным базы.

Вся информация администратором вносится в базу данных, а затем посредствам разработанного в данной дипломной работе приложения, (по средствам Visual Studio 2008), с этой информацией работает сотрудник кадровой службы.

Пользовательское описание программы

Пользователь работает с разработанным прикладным решением с помощью Windows-интерфейса и базы данных.

При запуске перед пользователем открывается форма Главная (Рисунок 6) в которой можно выбрать необходимые действия работы с программой.

Рисунок 6. Форма Главная

В подсистеме «Добавление» доступны формы добавления даты рабочего дня, нового вида работ (Рисунок 7), или добавление нового сотрудника (Рисунок 8).

Рисунок 7. Добавление нового вида работ.

Рисунок 8 — Добавление нового сотрудника.

В подсистеме «Просмотр» можно увидеть весь персонал, либо объём выполненных работ за определённый срок определённым сотрудником, либо объём всех работ интересующего сотрудника (Рисунок 9).

Рисунок 9. Просмотр всех работ сотрудника.

В подсистеме «Создание ведомостей» можно создать стандартную форму табеля учёта рабочего времени сотрудника или группы сотрудников (Рисунок 10)

Рисунок 10. Табель учёта рабочего времени (форма Т-13)

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

Создание печатной формы ведомости происходит в автоматическом режимы по нажатию кнопки «Печать» из программы Excel.

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

Описание программного кода приведено в Приложении А.

Источник: studbooks.net

7.3. Основные стадии и этапы разработки программ и программной документации

Государственный стандарт ГОСТ 19.102—77 устанавливает следующие стадии разработки программной документации:

1) техническое задание;

2) эскизный проект;

3) технический проект;

4) рабочий проект;

Рассмотрим подробнее каждую из стадий.

Таблица 7.5. Работы, выполняемые на стадии «Техническое задание»

Обоснование необходимости разработки программы

Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ

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

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

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

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

Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания

Документ «Техническое задание» оформляется в соответствии с ГОСТ 19.106—78 на листах формата А4 и А3 номера листов (страниц) проставляются в верхней части листа над текстом.

Содержание технического задания должно соответствовать ГОCT 19.201—78 и включать следующие разделы:

основания для разработки;

требования к программе или программному изделию;

требования к программной документации;

стадии и этапы разработки;

порядок контроля и приемки;

в техническое задание допускается включать приложения.

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

В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

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

В разделе «Основания для разработки» должны быть указаны:

документ (документы), на основании которых ведется разработка;

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

требования к функциональным характеристикам;

требования к надежности;

требования к составу и параметрам технических средств;

требования информационной и программной совместимости;

требования к маркировке и упаковке;

требования к транспортированию и хранению;

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

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

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

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

Необходимый состав технических средств (конфигурация системы), с указанием их основных технических характеристик приводится в подразделе «Требования к составу и параметрам технических средств».

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

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

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

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

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

1) в форме программной документации;

2) в форме конструкторской документации на программное изделие;

3) в форме программного изделия.

В приложениях к техническому заданию при необходимости приводят:

перечень научно-исследовательских и других работ, обосновывающих разработку;

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

другие источники разработки.

Таблица 7.6. Работы, выполняемые íà стадии Эскиэный проект»

Разработка эскизного проекта Утверждение эскизного проекта

Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования. Разработка пояснительной записки

Согласование и утверждение эскизного проекта

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

Результаты эскизного проектирования отображаются в документе «Пояснительная записка к эскизному проекту:», оформляемом в соответствии с ГОСТ 19.105—78 и ГОСТ 19.404—79. Этот документ должен содержать следующие разделы:

2) назначение и область применения;

3) технические характеристики;

4) ожидаемые технико-экономические показатели;

5) источники, использованные при разработке;

В зависимости от особенностей документа отдельные разделы (подразделы) допускается объединять, а также вводить новые разделы (подразделы).

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

В разделе «Назначение и область применения» указывают назначение программы и характеризуют область ее применения. Характеристики области применения должны точно соответствовать характеристикам, указанным в техническом задании, но должны быть более подробно описаны с точки зрения функционирования программного комплекса.

Раздел «Технические характеристики» должен содержать следующие подразделы:

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

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

описание и обоснование выбора метода организации входных и выходных данных;

описание и обоснование выбора состава технических и программных средств на основании проведенных расчетов и (или) анализов, распределение носителей данных.

В разделе «Ожидаемые технико-экономические показатели» указывают технико-экономические показатели, обосновывающие преимущество выбранного варианта технического решения, а также при необходимости ожидаемые оперативные показатели,

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

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

После утверждения пояснительной записки она становится программным документом, правила дублирования учета и хранения которого определяются ГОСТ 19.601—78 и ГОСТ 19.602—78. Последующие стадии и этапы разработки программной системы могут выявить необходимость внесения изменений в ее эскизный проект. Эти изменения должны быть отражены в пояснительной записке эскизного проекта; правила внесения изменений определяются ГОСТ 19.603—78 и ГОСТ 19.604—78.

Таблица 7.7. Работы, выполненные на стадии «Технический проект»

Разработка технического проекта

Утверждение технического проекта

Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств

Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта

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

Требования к содержанию и оформлению этого документа определены ГОСТ 19.105—78, ГОСТ 19.404—79. Рассмотрим важнейшие этапы работы на этой стадии. Разработка структуры программной системы заключается в выделении всех программных компонентов по функциональным признакам, определении функциональных спецификаций программных модулей и уточнении внешних функциональных спецификаций системы и структуры входных и выходных данных, определении • операционной среды, языковых средств и конфигурации технических средств.

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

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

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

4. Стадия «Рабочий .проект». Содержанием работ на этой стадии является описание программы на выбранном проблемно-ориентированном языке (кодирование), отладка, разработка, согласование и утверждение порядка и методики испытаний, разработка программных документов в соответствии с требованиями ГОСТ 19.101—77, проведение предварительных испытаний (тестирование), корректировка программы и программной документации по результатам испытаний, проведение приемо-сдаточных межведомственных, государственных и других видов испытаний.

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

Отметим, что хотя ЕСПД предусматривает разработку порядка и методики испытаний на стадии «Рабочий проект», работа по подготовке и проведению испытаний фактически начинается уже на стадии «Техническое задание», когда намечается порядок контроля и приемки, и ее целесообразно вести в течение всего процесса проектирования программы.

5. Стадия «Внедрение». Содержанием работ на этой стадии является подготовка и передача программы и программной документации для сопровождения и (или) изготовления, оформления и утверждения акта о передаче программы на сопровождение или изготовление, передача программы в фонд алгоритмов и программ.

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

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

Значение сопровождения в жизненном цикле больших программ стало осознаваться специалистами лишь в последние годы, когда выяснилось, что затраты на их сопровождение могут составлять до 60% затрат на программное обеспечение, или 50% общих затрат на вычислительную технику. Жизненный цикл программного обеспечения длится около 5—7 лет, в течение которых требования к нему могут существенно меняться. Различие между большими и малыми программами проявляется не только и не столько в их разработке, сколько в сопровождении.

Большую программу по понятным причинам нельзя переделать заново, но при изменении и дополнении больших программ на стадии сопровождения приходится в какой-то степени повторять все предыдущие стадии разработки, что приводит к большим затратам и множеству ошибок. Типичным является следующее распределение ресурсов для больших систем: 100 чел. в течение 2 лет заняты разработкой программного обеспечения и 35 чел. в течение 8 лет — сопровождением. Один из путей упрощения стадии сопровождения состоит в учете особенностей этого этапа на остальных стадиях разработки программного изделия.

Источник: studfile.net

Модели и методологии разработки ПО

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

Этапы жизненного цикла ПО

У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

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

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

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

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

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

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

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

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

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

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

V-образная модель (разработка через тестирование)

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

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

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

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

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

• Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.
• Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

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

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

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

• Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения.
• Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

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

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

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

• Большое внимание уделяется проработке рисков.

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

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

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

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны.

Помимо Scrum, часто используют Kanban.

Kanban

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

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

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!

Источник: gb.ru