Практические аспекты разработки ПО #2

Жизненный цикл программного обеспечения

Тема № 2

Почему «цикл»?

Почему «цикл»?

Почему «цикл»?

Жизненный цикл ПО (AL)

Эдвард Деминг

Американский ученый-статистик, консультант по теории управления качеством. Основоположник концепции «бережливого производства» (lean manufacturing)

Цикл Деминга (PDCA)

Определение AL

• Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации

Стандарт IEEE 610.12

Разные модели AL

• Модель AL – это способ организации процессов разработки, внедрения и сопровождения программного обеспечения

• Модель AL – это способ, которым решили потратить время жизненного цикла ALб

Примитивная модель AI:Code & Fix

Стадии и активности AL

Модели AL

• «Водопадная»– Стадии проходятся последовательно с

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

• «Спиральная»– Стадии укорачиваются и проходятся

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

Уинстон Ройс

Американский менеджер в сфере разработки ПО, руководитель Центра программных технологий компании «Локхид». В 1970 г. опубликовал работу с описанием «водопадной» модели

Водопадная модель AL

Три амиго

Rational Unfied Process (RUP)

Читаем

А. ЯкобсонГ. БучДж. РамбоУнифицированный

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

Барри Боэм

Директор отдела исследований программного обеспечения и технологий аэрокосмической корпорации TRW. Автор метода оценки затрат на разработку ПО COCOMO и спиральной модели AI.

Спиральная модель AL

Спиральная модель AL

Спиральная модель AL

Время в водопадной модели AL

Время в спиральной модели AL

Гибкая разработка (Agile)

Гибкая разработка (Agile)

• Жизненный цикл состоит из повторяющихся итераций

• Каждая итерация содержит все стадии

• Результатом итераций является выпуск законченной версии продукта

Основные идеи Agile

• Личности и их взаимодействия важнее, чем процессы и инструменты;

• Работающее программное обеспечение важнее, чем полная документация;

• Сотрудничество с заказчиком важнее, чем контрактные обязательства;

• Реакция на изменения важнее, чем следование плану.

Agile Manifesto, 2001

Принципы Agile

• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;

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

• частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);

• тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

Agile Manifesto, 2001

Принципы Agile

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

• рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

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

возможность поддерживать постоянный темп на неопределенный срок;

Agile Manifesto, 2001

Принципы Agile

• постоянное внимание на улучшение технического мастерства и удобную архитектуру;

• простота — искусство НЕ делать лишней работы;• лучшие технические требования и архитектура

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

обстоятельствам.

Agile Manifesto, 2001

Варианты методологий Agile

• SCRUM• Экстремальное программирование

(eXtreme Programming, XP)• Бережливая разработка (Lean

Development); Kanban

SCRUM

Джефф Сазерленд, Кен Швабер

SCRUM

SCRUM: Burndown diagram

SCRUM: Burndown diagram

SCRUM: Task board

Максим ДорофеевРуководитель отдела

разработки Лаборатории Касперского.

Возможно, один из лучших IT-менеджеров России.

http://cartmendum.livejournal.com/

Дорофеев: История одной доски

Дорофеев: История одной доски

Дорофеев: История одной доски

Дорофеев: История одной доски

Читаем

Хенрик КнибергSCRUM и XP: Заметки

с передовой. Как мы делаем SCRUM

eXtreme programming

Кент Бек, Уорд Каннингем

eXtreme programming (XP)

Более технологичная методология, чем SCRUM

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

12 основных практик XP• Короткий цикл обратной связи (Fine scale feedback)

– Заказчик всегда рядом (Whole team, Onsite customer)– Игра в планирование (Planning game)– Разработка через тестирование (Test driven development)– Парное программирование (Pair programming)

• Непрерывный, а не пакетный процесс– Непрерывная интеграция (Continuous Integration)– Рефакторинг (Design Improvement, Refactor)– Частые небольшие релизы (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)

Читаем

Кент БекЭкстремальное

программирование

Читаем

Кент Бек, Мартин ФаулерЭкстремальное

программирование: Планирование

Читаем

Кент Бек, Экстремальное

программирование: Разработка через тестирование

Kanban

Kanban

• Kanban – это метод «гладкого и непрерывного» выполнения производственного процесса

• Это часть методологии «бережливого производства» (Lean Manufacturng)

• Разработано в Производственной системе компании Toyota (Toyota Production System, TPS) и подсмотрено американцами.

Толстая книжка

Джеффри ЛайкерДао «Тойота»: 14

принципов менеджмента ведущей компании мира

Смотрим презентацию

Максим ДорофеевLean: Принципы

бережливого производства

http://www.slideshare.net/Cartmendum/intro-2-lean

Таичи Оно

7 принципов Lean

1. Убираем потери2. Встраиваем качество3. Постоянное обучение4. Откладывать обещания на более позднее

время5. Доставлять заказчику как можно быстрее6. Уважать людей и доверять им7. Оптимизировать целое, а не частности

7 видов потерь

1. Не полностью сделанная работа2. Лишние возможности3. Изучение заново4. Слишком длинная цепочка5. Переключение с задачи на задачу6. Задержки7. Дефекты

Kanban

Читаем

Хенрик КнибергМаттиас СкаринScrum и Kanban:

выжимаем максимум

Выпуск продукта в «водопаде» и итеративной модели

Выбор модели AL

• В зависимости от размера проекта• Его типичности или новизны• Выделенного на него времени• Состава и опыта команды• Требований заказчика

Вопросы для реферата

• Какая модель жизненного цикла Вам лично ближе?

• Почему?• Как можно было бы применить полученные

знания в учебном процессе или на (будущей) работе?