Методология разработки ПО waterfall. Особенности, достоинства, условия применения.
1. Последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей.
2. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.
3. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.
4. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта.
Когда использовать каскадную методологию?
- требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
-нет проблем с доступностью программистов нужной квалификации.
в относительно небольших проектах.
Достоинства:
● Прозрачная и интуитивно понятная структура работы, которая подходит для опытных команд;
● Высокое качество и детализации всей документации;
● Каскадная модель позволяет легко отслеживать ресурсы, риски и время, потраченное на реализацию проекта;
● Поставленные задачи максимально стабильны на всем протяжении разработки.
Недостатки:
● Определение в начальном этапе всех требований приводит к тому, что проект перестает быть гибким;
● Проект требует большего объема ресурсов и сроков;
● Заказчик увидит результаты работы проектной команды в самом конце этапа разработки;
● Полное отсутствие коммуникативного взаимодействия между этапами реализации.
Методология разработки ПО iterative. Особенности, достоинства, условия применения.
1. Модель не требует для начала полной спецификации требований.
2. Создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется.
Когда оптимально использовать итеративную модель?
- требования к конечной системе заранее четко определены и понятны;
- проект большой или очень большой;
- основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
Плюсы и минусы итеративной модели:
+ раннее создание работающего ПО;
+ гибкость – готовность к изменению требований на любом этапе разработки;
+ каждая итерация – маленький этап, для которого тестирование и анализ рисков обеспечить проще, чем для всего жизненного цикла продукта.
— каждая фаза – самостоятельна, отдельные итерации не накладываются;
— могут возникнуть проблемы с реализацией общей архитектуры системы, поскольку не все требования известны к началу проектирования.
Измерения времени PERT
Оптимистическое время (optimistic time) (O): минимальное возможное время для выполнения задачи, в предположении что все происходит лучше чем ожидается.
Пессимистическое время (pessimistic time) (P): максимально возможное время требующееся для выполнения задачи, в предположении что все происходит неправильно (исключая крупные катастрофы).
Наиболее вероятное время (most likely time) (M): оценка времени, требующегося для выполнения задачи, в предположении, что все происходит как обычно.
Ожидаемое время (expected time) (TE): лучшая оценка времени, требуемого для выполнения задачи, учитывая, что вещи не всегда происходят как обычно. (Ожидаемое среднее время выполнения задачи, если она будет повторяться многократно).
11 Методика планирования Agile-доска (варианты scrum и kanban). Особенности, сфера применения.
Гибкая методология создания проекта программного средства (например, ИС).
Привязана к основным положениям Agile методов разработки.
Agile — простая и симпатичная философия
Если вы думаете, что авторы Agile Manifesto написали сборник советов о работе над проектом, вы немного ошибаетесь. Манифест включает в себя 4 ценности, 12 принципов и 0 практик.
Начнем с ценностей, потому что именно они соль Agile:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
В этом виде Agile похож на религию прекраснодушных ИТ-эльфов. Авторы как будто не знают, что разработка ПО — это бессонные ночи авралов, скандалы между проектировщиками и кодерами, переносы релизов, нервы и прочие прелести реальной жизни.
К счастью, Agile — больше, чем набор из четырех заповедей. Авторы прописали в манифесте также 12 принципов методологии. Принципы тоже непохожи на руководство стартапера, но в них уже есть настоящее мясо.
Основополагающие принципы Agile-манифеста
1. Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Команды в Kanban и Scrum
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, работают небольшие автономные команды из 5—9 человек.В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
1. вести собрания;
2. устранять препятствия в работе (если команде мешает перфоратор в соседнем офисе, мастер ищет выход);
3. замечать и вытаскивать на поверхность скрытые проблемы;
4. отвечать за соблюдение методологии;
5. следить за статусом задач.
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
12 Методика планирования RACI. Особенности, сфера применения.
RACI matrix (RAM Responsibility Assignment Matrix) – график линейной ответственности. Показывает степень участия разных ролей в разных активностях процесса или проекта.
Выделяют множество альтернативных вариаций, из которых наиболее применимы RACI-VS и RASCI.
Матрица RACI
Матрица представляет собой таблицу, столбцами которой являются роли, а строками – деятельности процесса или проекта.
На пересечении столбца и строки устанавливается одна из следующих вариативных опций:
Responsible (на матрице отмечается буквой R) – ответственный непосредственно за выполнение работы
Accountable (A) – подотчетный, такую роль может занимать только один человек на одной задаче
Consulted (C) – один сотрудник или группа, с которыми проводятся консультации касательно задачи и мнения которых должно учитываться
Informed (I) – сотрудники, уведомляемые о выполнении конкретной задачи.
Вариации RACI
- В вариации RACI-VS добавляются еще две функции: Verifies (V) – один сотрудник или группа, проверяющие соответствие результата выполнения задачи согласованным заранее допустимым критериям, Signs off (S) – утверждает сдачу продукта заказчику (выполнения задачи). Данную роль можно совместить с подотчетной ролью.
- В вариации RASCI добавляется роль Supportive (S) – предоставляет дополнительные ресурсы для выполнения работы, такой как поддержка внедрения продукта, к примеру.
Пример RACI диаграммы
Анализ результатов по осям
По функциональным ролям:
Много «А» — правильно ли распределены обязанности? Есть ли в наличии «узкие места»?
Много «R» — не много ли мы ответственности повесили на одну роль?
Отсутствие пустых ячеек в таблице – действительно ли эта роль должна быть вовлечена в такое количество задач?
По выполняемым активностям:
Более одного «А» — только одна роль должна быть подотчетной
Отсутствие «А» — необходимо найти подотчетного
Более одного «R» или отсутствие такового – кто-то должен быть ответственный, однако нам не нужно, чтобы ответственность была широко распределена – есть риск того, что задача не будет выполнена
Много «С» — стоит ли нам консультироваться с многими ролями и будет ли это эффективно?
Отсутствие «С» и «I» — правильно ли у нас установлены коммуникации?
Группировка элементов
Группировка элементов UI — вообще очень важная часть планирования интерфейса. От удачности комбинации элементов взаимодействия зачастую зависит, уйдёт ли пользователь с сайта или же станет его активным пользователем.
а) Группировка по функциям
б) По результату действия
в) Смешанный тип группировки
2. Расположение элементов
Давайте поразмышляем, какие раздражители сильнее всего действуют на человека?
1. Звук
2. Прикосновение
3. Цвет
4. Запах
Т.к. чисто технически прикосновение и запахи на сайты не внедрены, мы рассмотрим цвет и звук.
Лично я категорически не приемлю звуки на сайтах, они меня вводят в заблуждение и оттягивают внимание на себя. Поэтому давайте воспользуемся оставшимся естественным раздражителем для человека — цветом.
Сам по себе цвет не может повлиять на удобство страницы, но его можно использовать в вспомогательных целях.
Деление на блоки
Прежде чем заняться полноценным дизайном страницы, займитесь разработкой блочной разметки. Просто расчертите белый лист на блоки, цвет которых варьируется в зависимости от важности блока на данной странице. Часто такое действие помогает четко разделить важный контент от неважного и опустить неважный пониже, подняв повыше собственно важный.
Вот несколько правил, о которых неплохо бы помнить при составлении макета дизайна:
1. Не экономьте место.
2. Используйте небольшие иконки.
3. Используйте как можно меньше линий на сайте.
4. Старайтесь не использовать вложенные таблицы.
5. Используйте вкладки.
Способы применения UML
Существует три основных режима использования UML диаграмм:
- режим эскиза
- режим проектирования
- режим языка программирования
У режимов есть две опции: прямой (диаграммы до кода) и обратный (диаграммы на основании кода) инжиниринг.
Исполняемый UML и MDA
MDA (Model Driven Architecture) – архитектура, управляемая моделью.
Основой является UML диаграммы.
В MDA существует два состояния:
PIM (Platform Independent Model) – модель, не зависящая от платформы.
PSM (Platform Specific Model) – модель, зависящая от платформы.
В “исполняемом UML” PSM заменена на компилятор модели.
Понятие метамодели
Большей строгостью моделирования (зачастую жертвуя практической полезностью) достигают определением метамодели.
Метамодель (metamodel) ‒ модель языка описания моделей
В описании UML используются три уровня: модели, метамодели и мета-метамодели. Добавим для полноты картины нулевой уровень ‒ сами моделируемые объекты, и дадим этим уровням имена в соответствии со стандартом UML 1: M0 ‒ уровень объектов, M1 ‒ уровень моделей, M2 ‒ уровень метамодели, M3 ‒ уровень мета-метамодели. Поскольку мета-метамодели и метамодели описываются с применением тех же средств ‒ то есть диаграмм классов, дальнейшее прибавление приставки "мета" не имеет смысла, так как не даст ничего нового.
В UML в качестве мета-метамодели применяется стандарт MOF (Meta Object Facility), специально разработанный OMG для спецификации метамоделей различных языков моделирования, таких как UML и CWM (Common Warehouse Metamodel).
Классификация UML диаграмм.
UML версии 2.0 описывает 13 официальных типов диаграмм с нотациями
Диаграммы классов
Наиболее распространенный тип диаграмм.
Описывает типы объектов системы и различного рода статические отношения, которые существуют между ними.
Помимо классов на диаграмме отображаются свойства классов, операции классов и ограничения классов.
Ассоциации классов
Ассоциации обозначаются сплошными линиями, стрелками,
направленными в одном или двух направлениях.
Каждая ассоциация описывается кратностью.
Кратность – это количество объектов, которые могут заполнять
данное свойство. Как правило, кратности обозначаются
cледующими символами:
1
0..1
*
Интерпретация класса в языке программирования (Java)
С public полями
С private полями
Централизованное управление
Распределённое управление
Фреймы взаимодействий
Так в диаграмме последовательности показаны разного рода циклы.
Сценарий для диаграммы
Последовательность шагов, описывающих взаимодействия пользователя и системы.
Текст прецедента
В тексте описывается главный успешный сценарий прецедента.
После этого приводятся расширения (ответвления или вариации) прецедента.
Диаграмма прецедентов
Диаграмма развертывания
Хороша не только при описании программного средства на этапе
его разработки, но и подходит при описании архитектуры ПО или
IT предприятия.
ДР представляют физическое расположение системы, показывая
на каком физическом оборудовании запускается та или иная
составляющая ПО.
Ключевые элементы:
Узел: то, что содержит ПО. Узлы бывают двух типов: устройство –
физическое оборудование, связанное с системой или среда
выполнения – ПО, включающее другое ПО (например - ОС)
Артефакт: физическое олицетворение ПО (исполняемые файлы,
библиотеки, сборки, JAR-файлы, HTML-документы).
Перечень артефактов внутри узла указывает на то, что на данном
узле этот артефект разворачивается в запускаемую систему.
Диаграмма пакетов
Если классы - это структурный костяк ООП системы, то пакет – это
более высокий уровень ее группировки.
Пакет – это инструмент группирования, который позволяет взять
любую конструкцию UML и объединить ее элементарные единицы
в единицы более высокого уровня.
Как правило, пакет включает в себя сгруппированные классы, но,
Если необходимо, пакеты также имеют свойство инкапсуляции
(пакет более высокого уровня может поглотить пакет более низкого
уровня).
Пакеты обозначаются прямоугольниками с вынесенным названием.
классы помещаются внутрь этого прямоугольника в произвольной
форме.
Параллельные состояния
Довольно распространенный случай, когда один объект не только меняет свои состояния, но и реализует некоторые из них параллельно.
Классическая диаграмма состояний с задачей визуализации этого не справится. Тогда изображают параллельные состояния.
Покажем их на примере MP3 будильника с радио.
Диаграмма деятельности
Технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ.
Являются блок-схемами, не поддерживающими параллельные процессы.
Читаются сверху-вниз, хотя в некоторых источниках можно встретить и исполнение слева-направо.
Методология разработки ПО waterfall. Особенности, достоинства, условия применения.
1. Последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей.
2. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.
3. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.
4. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта.
Когда использовать каскадную методологию?
- требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
-нет проблем с доступностью программистов нужной квалификации.
в относительно небольших проектах.
Достоинства:
● Прозрачная и интуитивно понятная структура работы, которая подходит для опытных команд;
● Высокое качество и детализации всей документации;
● Каскадная модель позволяет легко отслеживать ресурсы, риски и время, потраченное на реализацию проекта;
● Поставленные задачи максимально стабильны на всем протяжении разработки.
Недостатки:
● Определение в начальном этапе всех требований приводит к тому, что проект перестает быть гибким;
● Проект требует большего объема ресурсов и сроков;
● Заказчик увидит результаты работы проектной команды в самом конце этапа разработки;
● Полное отсутствие коммуникативного взаимодействия между этапами реализации.
Дата: 2018-12-28, просмотров: 879.
