Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Жизненные циклы разработки ПО

No description
by

Alexander Timochko

on 23 March 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Жизненные циклы разработки ПО

Лекция 3
Жизненные циклы разработки ПО
Что такое проект
Проект
– это временное предприятие, предназначенное для создания
уникальных продуктов, услуг или результатов (PMBoK).

Что такое проект?
Временность - каждый проект имеет четкие временные рамки
т.е. выполняется в условиях ограничений - стоимость, сроки и масштаб


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

Сроки
Сроки (график): Как говорится, 'время - деньги', ценный ресурс, уходящий слишком легко. Большинство проектов имеют предельный срок сдачи. Когда
сроки проекта уменьшаются, приходится увеличивать его стоимость или сокращать масштаб.
Fast? Cheap? Good?
Масштаб: Многие проекты не соблюдают данное ограничение, потому что полный масштаб проекта не был полностью определен или понят в начале. Когда масштаб проекта увеличивается, приходится увеличивать его стоимость или сроки.
Масштаб
Типичный состав участников проекта
Заказчик

Проектная команда

Менеджмент

Проектный менеджер
Заказчик
человек или группа лиц, кому принадлежит идея проекта и кто оплачивает работы по разработке ПО
Проектная команда - занимается выяснением требований к системе,
разработкой и тестированием
Проектная команда
Проектная команда
Как мы думаем мы выглядим?
Проектная команда
Как мы на самом деле выглядим?
Менеджмент - группа людей, который занимаются контрактами с заказчиком,
организацией рабочих мест, бухгалтерией, управляют компанией, которая сотрудничает с заказчиком.
Менеджмент
Проектный Менеджер (project manager) - связующее звено между командой и заказчиком. Область ответственности: сроки, бюджет, масштаб, риски проекта, управление проектной командой
Проектный менеджер
Проектная команда
Бизнес аналитик
- ответственен за выяснение требований к продукту у заказчика и донесение данной информации до понимания команды
Разработчик
- выполняет написание программного кода
Тестировщик
- тестирует требования, программу.
Проектный менеджер
- рассмотрен выше.
Stakeholders
- люди, заинтересованные в успешном выполнении проектаматериально или не материально)
Разработка продукта (сам проект) совершается процессно. Это значит, что
что-то подается на вход каждого этапа и что-то ожидается на выходе.
Еще раз: каждая инженерная и управленческая практика – это ПРОЦЕСС с входами, действиями и выходами
Вход: доменные знания (знания того бизнеса, для чего разрабатывается продукт), общение с заказчиком

Выход: Software requirements specification (SRS) - они же "требования", "спецификации"
Анализ требований:
Вход: SRS, дизайн архитектуры ПО (схема того, как ПО будет организовано
изнутри), стандарты кодирования
Выход: запускаемое ПО
Разработка:
Вход: SRS, запускаемое ПО

Выход: отчеты об ошибках, отчет о результатах тестирования
Тестирование:
Оценка работ
Effort Estimate - это количество работы, которую нужно выполнить.
Измеряется в человеко-часах, человеко-днях, человеко-неделях, человеко-месяцах.

Schedule Estimate (Duration) - как долго данная работа будет выполняться в календарных днях. Измеряется в в часах, неделях, месяцах.
Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Для построения календарного плана работ по проекту используют Gantt chart (Диаграмма Ганта).
Как быть?
Пример диаграммы Ганта
Циклы разработки ПО
Инициация
Планирование
Анализ требований
Дизайн
Разработка
Интеграция и тестирование
Внедрение
Поддержка
Инициация
Появляется идея либо бизнес предложение

Разработка концепта - определение объема работ и анализ осуществимости проектных решений
Планирование
разработка плана проекта и другой проектной документации
Анализ требований
анализ и разработка функциональных и нефункциональных требований
Дизайн
разработка дизайна системы для реализации поставленных требований
Разработка
создание системного окружения, кодирование, подготовка к тестированию: создание тестов, тестовых данных
Интеграция и тестирование
подтверждение того, что система разработана
в соответствии с заявленными требованиями и удовлетворяет ожиданиям пользователей.
Внедрение
подготовка и ввод системы в эксплуатацию, решение проблем, выявленных на фазе интеграции и тестирования
Поддержка
поддержка системы после ввода ее в эксплуатацию
Домашнее задание
Почитать и ознакомиться:
Водопадная модель
Инкрементальная
Agile (Scrum)
Agile (Kanban)
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.
SDLC что такое?
Systems development life cycle
Модели жизненного цикла ПО
Водопадная модель
Инкрементальная модель
V модель
Agile модель


Водопадная модель
Другие названия: watefall, каскадная, последовательная модель
модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Алгоритм водопадной модели
Преимущества
Последовательное выполнение этапов проекта в строгом фиксированном порядке
Позволяет оценивать качество продукта на каждом этапе
Полная и согласованная документация на каждом этапе;
Легко определить сроки и затраты на проект
Недостатки
Переход от одной фазы проекта к другой предполагает полную корректность результата предыдущей фазы.
Неточность какого-либо требования или его интерпретации приводит к тому, что приходится «откатываться» к ранней фазе и увеличивает время разработки, качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался.
Отсутствие обратных связей между этапами
Не соответствует реальным условиям разработки программного продукта

Инкрементальная модель
Инкрементальная, итеративная Iterative and Incremental model - процесс разработки ПО, состоящий из серии повторяющихся итераций (их число зависит от конкретного проекта), каждая из которых фактически является полноценным мини-проектом с фазами определения требований, анализа, дизайна и т.д.

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

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

Agile Model
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum
DSDM
Метод разработки динамических систем (Dynamic Systems Development Method) это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя
Принципы DSDM
Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
Главный критерий - как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
Разработка - итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
Любые изменения во время разработки - обратимы.
Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
Тестирование интегрировано в жизненный цикл разработки.
Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.
Экстремальное программирование XP
Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development — разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошел. TDD, в некотором смысле, позволяет писать код, более удобный в использовании — потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.
Короткий цикл обратной связи (Fine-scale feedback)
Разработка через тестирование (Test-driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous integration)
Рефакторинг (Design improvement, Refactoring)
Частые небольшие релизы (Small releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

Двенадцать основных приёмов экстремального программирования
Scrum
Scrum (от англ. scrum «толкучка»)
Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Спринт
Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель
Бэклог проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников скрам процесса
Project Backlog
Sprint backlog
Бэклог спринта — содержит функциональность, выбранную владельцем проекта из Бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта
Список всех юзер стори, которые нужно реализовать в рамках проекта, записаны в документе product backlog.
Список всех юзер стори, которые нужно реализовать в рамках одного спринта записаны в документе с названием sprint backlog.
Размер работы внутри каждой юзер стори оценивается в виртуальных единицах story point. Размер данной единицы свой для каждого проекта.
Количество работы, которое может выполнить команда в течение спринта называется velocity (velocity это фактически скорость работы). Velocity равна сумме стори поинтов для всех юзер стори внутри спринта. 
Как это работает???
Все требования оформляются так называемыми user story, выглядят в следующем формате:
"Я, как потенциальный покупатель,
Хочу иметь возможность добавить выбранный товар в корзину".
Velocity - скорость работы
Kanban
Преимущества
Нет опыта в доменной области
Нет четких требований
Заказчик доступен
Недостатки
Без заказчика "рядом" практически не возможно планировать
Гибкий подход к управлению требованиями не подразумевает далеко идущих планов
Работа по agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом
Подход — «работает, и ладно»
Канбан отличается от скрама тем, что в нем нет итераций. Канбан можно сравнить с конвейером. На конвейер "падают" задачи, каждый разработчик может взять на исполнение только одну задачу. Как только задача реализована и протестирована - она сразу попадает в эксплуатацию. Данная методология эффективна на стадии поддержки продукта после ввода его в эксплуатацию.
Kanban
Agile Manifesto

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

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

Full transcript