Стратегии разработки программного обеспечения реферат

Обновлено: 04.07.2024

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

- Объектно-ориентированный – основан на анализе проектировании и программировании объектов.

Программный модуль, программный продукт, система, нотация

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

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

Нотация – система графических обозначений для записи результата разработки программных средств.

4. Жизненный цикл программных средств. Группы процессов жизненного цикла (определения) - –совокупность процессов работ и задач, охватывающих их жизнь от формирования концепции до прекращения использования. Каждый процесс ЖЦ разделен на набор работ. Каждая работа разделена на набор задач. Делятся на основные, вспомогательные, организационные.

Группы процессов жизненного цикла:

1. процессы соглашения — 2;

2. процессы организационного обеспечения проекта — 5;

3. процессы проекта — 7;

4. технические процессы — 11;

5. процессы реализации программных средств — 7;

6. процессы поддержки программных средств — 8;

7. процессы повторного применения программных средств — 3.

5. Основные процессы жизненного цикла (определения). Работы, из которых состоит процесс разработки

- Приобретение (действия и задачи заказчика, приобретающего ПО)

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

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

- Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

Работы, из которых состоит процесс разработки:

· Анализ требований → Спецификация программного обеспечения

· Проектирование программного обеспечения

· Тестирование программного обеспечения

· Системная интеграция (Systemintegration)

· Внедрение программного обеспечения (или Установка программного обеспечения)

· Сопровождение программного обеспечения

Базовые стратегии разработки ПО

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

Каскадная стратегия разработки программных средств и систем –однократный проход этапов разработки.

Достоинства:

· Стабильность требований в течении ЖЦ

· Необходимость только одного прохода этапов разработки, это обеспечивает простоту применения стратегии

· Простота планирования контроля и управления проектом

· Доступность для понимания заказчиков

Недостатки:

· Сложность полного формулирования требований

· Сложность структуры процесса разработки

· Непригодность промежуточных продуктов для использования

· Недостаточное участие пользователя в процессе разработки ПО

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

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

Достоинства:

· Получение функционального продукта на промежуточных этапах

· Короткая продолжительность создания инкремента

· Включение в процесс пользователей

Недостатки

· Сложность планирования и распределения работ

· Проявление человеческого фактора

V-образная модель

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

Недостатки

1) необходимость в постоянном участии пользователя в процессе разработки

2) необходимость в высококвалифицированных разработчиках

3) возможность применения только для систем или ПС, для которых отсутствует требование высокой производительности;

4) жесткость временных ограничений на разработку прототипа;

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

Область применения

· если пользователь может принимать постоянное участие в процессе разработки;

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

· при выполнении проектов в сокращенные сроки;

· при невысокой степени технических рисков;

· в составе других моделей жизненного цикла.

Эволюционная модель (выше)

Виды комментариев.

1) заголовки. Объясняют назначение основных компонентов

2) построчные. Описывают мелкие фрагменты программы;

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

Нормами комментариев.

• 4 - 5 строк комментария-заголовка на каждый компонент программы (подпрограмму, блок, модуль);

• по одному комментарию на каждые две строки исходного текста для построчных комментариев.

ESD-диаграмма

ESD-диаграмма представляет собой иерархию действий, выполняемых некоторой сущностью во времени. Сущности и действия на ESD-диаграмме представляются в виде прямоугольников. На каждой ESD-диаграмме имеется только одна сущность. Она помещается в корне дерева ESD-диаграммы.

Диаграммы Варнье–Орра

CASE-технологии

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

Основные понятия IDEF0-модели

Система -совокупность взаимодействующих компонентов и взаимосвязей между ними.

Моделирование - процесс создания точного описания системы.

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

Цель модели- назначение опсания.

Точка зрения – это позиция человека или объекта, в которую надо встать, чтобы увидеть систему в действии.

Субъектом моделирования является сама система.

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

Виды диаграмм языка UML

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

· диаграмма вариантов использования (UseCaseDiagram);

· диаграмма классов (ClassDiagram);

· диаграммы поведения (BehaviorDiagram), в том числе: диаграмма состояний (StatechartDiagram);

· диаграмма деятельности (ActivityDiagram);

· диаграммы взаимодействия (InteractionDiagram), в том числе: диаграмма последовательности (SequenceDiagram);

· диаграмма кооперации (CollaborationDiagram);

· диаграммы реализации (ImplementationDiagram), в том числе: диаграмма компонентов (ComponentDiagram);

· диаграмма развертывания (DeploymentDiagram)

Язык UML Модели языка UML

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

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

Уровни моделей языка UML

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

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

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

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

61. Диаграмма вариантов использования

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

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

62. Виды отношений между элементами на диаграммах вариантов использования

На диаграммах вариантов использования определены следующие виды отношений между отдельными элементами:

· отношение ассоциации(определено для всех видов диаграмм языка UML. На диаграммах вариантов использования данное 238 отношение связывает актеров с вариантами использования и определяет конкретную роль актера при взаимодействии с вариантом использования);

· отношение включения(может иметь место между двумя вариантами использования. Данное отношение определяет, что последовательность действий одного варианта использования (включаемого) включается в качестве составной части в последовательность действий другого варианта использования (базового));

· отношение расширения(может существовать между двумя вариантами использования. Данное отношение определяет, что некоторый вариант использования является расширением для другого варианта использования (базового). Это означает, что последовательность действий базового варианта использования может быть дополнена последовательностью действий варианта-расширения);

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

Отработка стратегий

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

Документы обзоров

Документы обзоров ЖЦПИ

Фаза	Обзор событий	Вопросы
1.исследования	Ресурсы распределения	1,2	1. Распределение бюджета 2. Извещение о сроках 3. Согласование о требованиях 4. Спецификации 5. Издание документации 6. План испытаний 7. План поддержки 8. Отчеты 9. План выпуска 10. Конфигуратор
2.анализ осуществимости	Требование утверждения	1, 2, 3, 9, 10
3.конструирование	Спецификации утверждения	1, 2, 4, 5, 6
4.программирование	Испытания начаты	1, 2, 8
5.оценка	Распределение начато	2, 8, 9, 10
6.исполнение	Изделие снято с производства

Базовые принципы разработки программ (их описание)

- Объектно-ориентированный – основан на анализе проектировании и программировании объектов.

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

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

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого.

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰).

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

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

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

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

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

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

При написании работы будут рассчитаны следующие показатели: затраты на создание программного обеспечения, трудоёмкость по видам.

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

Теоретическая часть

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

Расчет затрат на создание программного обеспечения, цены и прибыли от его реализации.

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

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

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

Структурированный дизайн

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

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

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

Сплоченность — группировка всех функционально связанных элементов.

Сцепление — связь между различными модулями.

Хорошая структурированная конструкция имеет высокую когезию и низкое сцепное устройство.

Функционально-ориентированный дизайн

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

Объектно-ориентированный дизайн

Объектно-ориентированный дизайн работает вокруг сущностей и их характеристик, а не функций, задействованных в программной системе. Эта стратегия проектирования ориентирована на сущности и ее характеристики. Вся концепция программного решения вращается вокруг заинтересованных лиц.

Давайте посмотрим на важные концепции объектно-ориентированного дизайна:

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

Классы . Класс — это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.

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

Процесс проектирования

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

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

Подходы к разработке программного обеспечения

Вот два общих подхода к разработке программного обеспечения:

Дизайн сверху вниз

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

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

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

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

Дизайн снизу вверх

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

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

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

Делать, пока не будет сделано

Очевидно, что недостатками такой модели являются:

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

· ориентация на индивидуальные знания и умения программиста;

· сложность управления и планирования проекта;

· большая длительность и стоимость разработки;

· низкое качество программных продуктов;

· высокий уровень рисков проекта.

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

Некоторые характеристики каскадной, инкрементной и эволюционной стратегий разработки ПС и предъявляемые к ним требования приведены в стандарте ГОСТ Р ИСО/МЭК ТО 15271-2002 – Информационная технология

– Руководство по применению ISO/IEC 12207 (Процессы жизненного цикла программных средств) [6].

Выбор той или иной стратегии определяется характеристиками:

· требований к продукту;

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

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

Три базовых стратегии могут быть реализованы различными моделями

2.1.2. Каскадная стратегия разработки программных средств и систем

Каскадная стратегия представляет собой однократный проход этапов разработки.

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

стратегию, являются каскадная и V-образная модели.

Основными достоинствами каскадной стратегии , проявляемыми при

разработке соответствующего ей проекта, являются:

прохода этапов разработки; 3) простота планирования, контроля и управления проектом;

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

5) доступность для понимания заказчиками.

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

1) сложность четкого формулирования требований в начале жизненного цикла ПС и невозможность их динамического изменения на протяжении ЖЦ ПС;

2) последовательность линейной структуры процесса разработки; на практике разрабатываемые ПС (или система) обычно слишком велики, чтобы все работы по их созданию выполнить однократно; в результате возврат к

увеличению затрат и нарушению графика работ;

3) проблемность финансирования проекта, связанная со сложностью единовременного распределения больших денежных средств;

4) непригодность промежуточного продукта для использования;

5) недостаточное участие пользователя в разработке системы или ПС– только в самом начале(при разработке требований) и в конце(во время приемочных испытаний), что приводит к невозможности предварительной оценки пользователем качества ПС или системы.

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

1) при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями, понятными реализацией и техническими методиками;

2) при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;

3) при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;

4) при разработке проекта, связанного с переносом уже существующего продукта на новую платформу;

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

2.1.3. Инкрементная стратегия разработки программных средств и систем

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

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

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

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

Когда использовать каскадную методологию?

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

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

Когда использовать V-модель?

Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
Для малых и средних проектов, где требования четко определены и фиксированы.
В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

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

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

Когда использовать инкрементную модель?

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

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

Модель быстрой разработки приложений включает следующие фазы:

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

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

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

Когда использовать Agile?

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

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

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

Когда оптимально использовать итеративную модель?

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

Спиральная модель предполагает 4 этапа для каждого витка:

планирование;
анализ рисков;
конструирование;
оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

Читайте также: