Программирование Скачать
презентацию
<<  Линейное программирование Разработка программ  >>
Цикл разработки ПО и роль тестера на каждом этапе
Цикл разработки ПО и роль тестера на каждом этапе
Проект
Проект
Четыре «П» разработки ПО
Четыре «П» разработки ПО
Продукт
Продукт
Проект
Проект
Процесс
Процесс
Семейства процессов разработки ПО
Семейства процессов разработки ПО
Стратегии создания ПО
Стратегии создания ПО
Технологии программирования
Технологии программирования
Источники сложности проекта
Источники сложности проекта
Проблемы управления проектами
Проблемы управления проектами
Водопадная модель жизненного цикла ПО:
Водопадная модель жизненного цикла ПО:
Модель с промежуточным контролем:
Модель с промежуточным контролем:
Макетирование (прототипирование)
Макетирование (прототипирование)
Инкрементная модель
Инкрементная модель
Технология RAD
Технология RAD
Этапы RAD
Этапы RAD
Спиральная модель разработки ПО
Спиральная модель разработки ПО
Особенности спиральной модели
Особенности спиральной модели
Гибкие технологии разработки ПО
Гибкие технологии разработки ПО
Основные идеи agile
Основные идеи agile
Основы манифеста гибких технологий
Основы манифеста гибких технологий
Проектирование в гибких технологиях
Проектирование в гибких технологиях
Разработчики получают задачу, берут соответствующий фрагмент
Разработчики получают задачу, берут соответствующий фрагмент
Разработчики получают задачу, берут соответствующий фрагмент
Разработчики получают задачу, берут соответствующий фрагмент
Экстремальное программирование
Экстремальное программирование
Основные принципы ХР
Основные принципы ХР
Тестирование в ХР
Тестирование в ХР
Scrum
Scrum
Общие положения
Общие положения
Реализация проекта в Scrum
Реализация проекта в Scrum
Документация в Scrum
Документация в Scrum
Унифицированный процесс (RUP)
Унифицированный процесс (RUP)
Характеристики УП
Характеристики УП
Преимущества управляемого УП
Преимущества управляемого УП
Жизненный цикл УП
Жизненный цикл УП
Назначение вех
Назначение вех
Цикл разработки
Цикл разработки
Содержание фаз
Содержание фаз
Построение уточнение базового уровня архитектуры реализация всех
Построение уточнение базового уровня архитектуры реализация всех
Модели УП
Модели УП
UML
UML
Диаграммы вариантов использования (Use case diagrams)
Диаграммы вариантов использования (Use case diagrams)
Диаграммы вариантов использования (Use case diagrams)
Диаграммы вариантов использования (Use case diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы компонент (Component diagrams)
Диаграммы компонент (Component diagrams)
Диаграммы компонент (Component diagrams)
Диаграммы компонент (Component diagrams)
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Обзор идеи
Обзор идеи
Обзор проекта
Обзор проекта
Подготовка проекта
Подготовка проекта
Разработка продукта (Development) - 1
Разработка продукта (Development) - 1
Разработка продукта (Development) - 2
Разработка продукта (Development) - 2
Альфа-тестирование
Альфа-тестирование
Бета-тестирование
Бета-тестирование
Подготовка к выпуску и выпуск
Подготовка к выпуску и выпуск
Все!
Все!
Case-технологии
Case-технологии
Компонентный подход и САSЕ-технологии
Компонентный подход и САSЕ-технологии
Технологии СОМ
Технологии СОМ
Технологии СОМ
Технологии СОМ
Технологии СОМ
Технологии СОМ
Технология СОRВА
Технология СОRВА
Картинки из презентации «Разработка ПО» к уроку информатики на тему «Программирование»

Автор: Mux. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока информатики, скачайте бесплатно презентацию «Разработка ПО.ppt» со всеми картинками в zip-архиве размером 206 КБ.

Скачать презентацию

Разработка ПО

содержание презентации «Разработка ПО.ppt»
Сл Текст Сл Текст
1Цикл разработки ПО и роль тестера на каждом этапе. 1. 29высокоуровневая архитектура продукта. Реализация (Game):
2Проект. Одним из ключевых понятий технологии разработки итеративное развитие продукта. Завершение (Postgame): действия,
программного обеспечения, как и многих других областей необходимые для подготовки продукта к выходу на рынок. 29.
деятельности, является понятие проекта. Проект есть уникальное Павловская Т.А. (СПбГУ ИТМО).
временное предприятие, направленное на создание определенного, 30Реализация проекта в Scrum. Фаза реализации разбита на
уникального продукта и услуги. Технология управления проектом последовательность итераций - спринтов (Sprint). В результате
есть совокупность знаний, навыков, инструментов и методов для каждого спринта в продукте реализуется новый, заметный для
планирования и реализации действий, направленных на достижение владельца продукта, объем функциональности. В конце каждого
поставленной в рамках проекта цели. Процесс разработки спринта продукт остается в работоспособном состоянии. Спринт
программного обеспечения является плохо определенным и начинается с сессии планирования (Sprint Planning Meeting) -
динамичным. 2. Павловская Т.А. (СПбГУ ИТМО). определяется объем функциональности, которая будет реализована в
3Четыре «П» разработки ПО. Персонал (кто это делает) Процесс течение спринта. Ежедневно проводится собрание участников
(способ, которым это делается) Проект (выполнение необходимых проекта - скрам-сессия (Daily Scrum Meeting). По завершению
действий) Продукт (артефакты). 3. Павловская Т.А. (СПбГУ ИТМО). спринта проводится демонстрационная сессия (Sprint Review
4Продукт. Артефакт – любой вид информации, создаваемый, Meeting). 30. Павловская Т.А. (СПбГУ ИТМО).
изменяемый и используемый сотрудниками при создании системы 31Документация в Scrum. Всего 3 документа: журнал продукта
Артефакты: Само приложение Спецификация требований Проектная (Product Backlog) высокоуровневый список функциональных и
модель Исходный и объектный код Тестовые процедуры … 4. технических требований, необходимых для реализации продукта
Павловская Т.А. (СПбГУ ИТМО). журнал спринта (Sprint Backlog) детализированный список
5Проект. Совокупность действий, необходимых для создания функциональных и технических требований, необходимых для
артефакта: контакт с заказчиком написание документации успешного завершения итерации график спринта (Burndown Chart).
проектирование программирование тестирование … 5. Павловская показывает ежедневное изменение общего объема работ, оставшегося
Т.А. (СПбГУ ИТМО). до завершения итерации. 31. Павловская Т.А. (СПбГУ ИТМО).
6Процесс. Процесс создания ПО – определение полного набора 32Унифицированный процесс (RUP). Разработчики: Г. Буч, А.
видов деятельности, необходимых для преобразования требований Якобсон, Д. Рамбо (Rational, 1998) Обобщенный каркас процесса
пользователя в продукт. Процесс служит шаблоном для создания разработки ПО Компонентно-ориентирован УП управляет действиями
проекта. Процесс определяет: кто делает что делает когда делает всех его участников: разработчиков руководства пользователей
как достичь цели Процессы делятся на тяжеловесные и легковесные заказчиков Процесс должен постоянно адаптироваться к реальному
(гибкие). 6. Павловская Т.А. (СПбГУ ИТМО). положению дел, которое определяется: доступными технологиями
7Семейства процессов разработки ПО. тяжеловесные утилитами персоналом организационными шаблонами. 32. Павловская
(heavyweight) применяются при фиксированных требованиях и Т.А. (СПбГУ ИТМО).
многочисленной группе разработчиков разной квалификации 33Характеристики УП. Управляемый вариантами использования
облегченные (lightweight, agile) применяются при малочисленной архитектурно-ориентированный итеративный и инкрементный
группе квалифицированных разработчиков и грамотном заказчике, использует UML основан на компонентном подходе, использует
который имеет возможность участвовать в процессе Начнем с гибких стандарт визуального моделирования. Архитектура - представление
технологий - наиболее актуальных. 7. Павловская Т.А. (СПбГУ всего проекта с выделением важных характеристик. Архитектура
ИТМО). описывается различными представлениями и охватывает наиболее
8Стратегии создания ПО. 8. Павловская Т.А. (СПбГУ ИТМО). важные статические и динамические аспекты системы. Разработка
9Технологии программирования. — Почему вы пилите тупой пилой, делится на мини-проекты (итерации), в ходе которых реализуется
ведь это очень долго и трудно? — Некогда точить, пилить надо!!! группа вариантов использования. Итерации не обязательно
Технология программирования (технология разработки ПО) — способ аддитивны. 33. Павловская Т.А. (СПбГУ ИТМО).
организации процесса создания программы, совокупность приемов и 34Преимущества управляемого УП. Ограничивает финансовые риски
способов выполнения определенных видов деятельности. На разных затратами на одну итерацию Снижает риск непоставки продукта
уровнях и по разным критериям выделяют пересекающиеся модели: Ускоряет темпы процесса разработки в целом Облегчает адаптацию к
Водопадная (каскадная) модель, нисходящее (структурное) неизбежным изменениям требований. 34. Павловская Т.А. (СПбГУ
программирование Макетирование Спиральная (итерационная) модель ИТМО).
разработки ПО Объектно-ориентированное программирование Гибкие 35Жизненный цикл УП. Каждый цикл состоит из 4х фаз, каждая
(agile) технологии: экстремальное программирование (XP), Scrum, фаза разделяется на итерации Результатом каждого цикла является
TDD, FDD… RUP Компонентный подход (COM, CORBA) САSЕ-технологии новый выпуск системы Каждая фаза заканчивается вехой Веха
RAD … 9. Павловская Т.А. (СПбГУ ИТМО). определяется по наличию определенного набора артефактов Артефакт
10Источники сложности проекта. Наличие высококвалифицированных – любой вид информации, создаваемый, изменяемый и используемый
специалистов на рынке труда. Стабильность используемой сотрудниками при создании системы. 35. Павловская Т.А. (СПбГУ
технологической платформы, стабильность и функциональность ИТМО).
инструментов разработки. Эффективность используемых методов 36Назначение вех. По ним руководитель принимает решения перед
разработки, включая методы моделирования, проектирования, тем, как перейти на следующую фазу Возможность отслеживать
тестирования и управления версиями. Доступность специалистов, процесс Возможность прогнозирования оценок в других процессах.
обладающих экспертизой в прикладной области. Используемая 36. Павловская Т.А. (СПбГУ ИТМО).
методология и ее соответствие данному проекту. Сроки и 37Цикл разработки. 37. Павловская Т.А. (СПбГУ ИТМО).
финансирование проекта. Множество других организационных и 38Содержание фаз. Проектирование: детальное описание вариантов
технических переменных. 10. Павловская Т.А. (СПбГУ ИТМО). использования архитектура в виде представлений всех моделей план
11Проблемы управления проектами. Многие процессы разработки действий и оценка ресурсов. Анализ и планирование требований:
неуправляемы. Их исходные данные и желаемый результат неизвестны идея превращается в концепцию готового продукта создается
или определены очень нечетко. Процесс достижения желаемого бизнес-план разработки упрощенная модель вариантов использования
результата не поддается формализации (например, разработка пробный вариант архитектуры выявление рисков и расстановка
архитектуры и исчерпывающее тестирование продукта). приоритетов грубая оценка проекта. 38. Павловская Т.А. (СПбГУ
Идентифицированные процессы разработки сопровождаются ИТМО).
неизвестным количеством неидентифицированных. Требования к 39Построение уточнение базового уровня архитектуры реализация
продукту часто меняются в течение жизненного цикла проекта, что всех вариантов использования Внедрение бета-версия тренинги
требует сложной процедуры изменения и согласования требований. сотрудников заказчиков исправление дефектов. 39. Павловская Т.А.
Попытки предложить формальную, детализованную методологию (СПбГУ ИТМО).
разработки ПО оказываются безуспешны, потому что сам процесс 40Модели УП. Модели – наиболее важный тип артефактов. Каждая
разработки не поддается детализации и формализации. Слепое модель описывает систему с определенной точки зрения на
следование методологиям, предполагающим управляемость и определенном уровне абстракции. Вариантов использования Анализа
предсказуемость процессов разработки, приводит к непредсказуемым Проектирования Развертывания Реализации Тестирования Все модели
результатам проекта. 11. Павловская Т.А. (СПбГУ ИТМО). связаны, они полностью описывают систему. Набор моделей дает
12Водопадная модель жизненного цикла ПО: Синонимы: варианты обозрения системы для всех сотрудников. 40. Павловская
классический ЖЦ, каскадная модель. 12. Павловская Т.А. (СПбГУ Т.А. (СПбГУ ИТМО).
ИТМО). 41UML. Язык для специфицирования, визуализации,
13Модель с промежуточным контролем: 13. Павловская Т.А. (СПбГУ конструирования и документирования программных продуктов. Также
ИТМО). используется в бизнес-моделировании и моделировании любых иных
14Макетирование (прототипирование). 1. 2 Проектирование (не программных) систем. UML позволяет задавать следующие
продукта. Построение/уточнение макета. Оценка макета заказчиком. аспекты: Диаграммы вариантов использования (use case diagrams)
14. Павловская Т.А. (СПбГУ ИТМО). Диаграммы классов (class diagrams) Диаграммы поведения Диаграммы
15Инкрементная модель. Поставка 1-го инкремента. 1-й состояний (statechart diagrams) Диаграммы действий (activity
инкремент. Проектирование. Кодиро-вание. Тестиро-вание. Анализ. diagrams) Диаграммы взаимодействия (interaction diagrams)
Поставка 2-го инкремента. 2-й инкремент. Проектирование. Диаграммы последовательностей(sequence diagrams) Диаграммы
Кодиро-вание. Тестиро-вание. Анализ. Поставка 3-го инкремента. взаимодействий(collaboration diagrams) Диаграммы реализации
3-й инкремент. Проектирование. Кодиро-вание. Тестиро-вание. (implementation diagrams) Диаграммы компонент (component
Анализ. 15. Павловская Т.А. (СПбГУ ИТМО). diagram) Диаграммы развертывания (deployment diagram). 41.
16Технология RAD. Rapid Application Development — Быстрая Павловская Т.А. (СПбГУ ИТМО).
разработка приложений. Ориентирована на максимально быстрое 42Диаграммы вариантов использования (Use case diagrams). 42.
получение первых версий разрабатываемого ПО. Она Павловская Т.А. (СПбГУ ИТМО).
предусматривает: ведение разработки небольшими группами (3-7 43Диаграммы деятельности (Activity diagrams). 43. Павловская
человек), каждая из которых проектирует и реализует отдельные Т.А. (СПбГУ ИТМО).
подсистемы, позволяет улучшить управляемость проекта; 44Диаграммы последовательностей действий (Sequence diagrams).
использование готовых компонентов способствует уменьшению 44. Павловская Т.А. (СПбГУ ИТМО).
времени получения работоспособного прототипа; наличие четко 45Диаграммы компонент (Component diagrams). 45. Павловская
проработанного графика цикла, рассчитанного не более чем на три Т.А. (СПбГУ ИТМО).
месяца, существенно увеличивает эффективность работы. Технология 46Пример реального процесса разработки ПО. 46. Павловская Т.А.
RAD хорошо зарекомендовала себя для относительно небольших (СПбГУ ИТМО).
стандартных проектов, разрабатываемых для конкретного заказчика. 47Обзор идеи. Выдвигается идея нового продукта Назначается
16. Павловская Т.А. (СПбГУ ИТМО). менеджер по продукту (PdM). Он оценивает идею и составляет ее
17Этапы RAD. Бизнес-моделирование (моделируются информационные краткий обзор, который направляет на утверждение HBU и HPdM.
потоки между бизнес-функциями) Моделирование данных (набор Назначается PjM Milestone S3: HBU или HPdM принимают решение о
объектов, которые требуются для поддержки бизнес-процессов) дальнейшем анализе бизнес-идеи. 47. Павловская Т.А. (СПбГУ
Моделирование обработки (определяются преобразования объектов, ИТМО).
обеспечивающие реализацию бизнес-функций. Описание обработки для 48Обзор проекта. Pjm назначает системного архитектора (SWA) и
добавления, изменения, удаления и поиска данных) Создание старшего тестера (CQA). Pdm, pjm, представитель спонсора, SWA,
приложения (используются готовые компоненты и утилиты CQA формируют руководящую группу (steering group), принимающую
автоматизации) Объединение и тестирование (компоненты решения по проекту. SWA анализирует техническую возможность
тестировать не надо). 17. Павловская Т.А. (СПбГУ ИТМО). реализации. Pjm составляет обзор по своему проекту. Pjm
18Спиральная модель разработки ПО. На 1-й итерации может составляет черновик плана проекта (project plan) pdm
использоваться макет, который оценивается заказчиком. подготавливает отчет об анализе бизнес-идеи продукта. Milestone
Программное обеспечение создается итерационно с использованием S2: HBU или hpdm дают добро на начало разработки проекта. 48.
метода прототипирования. Прототипом обычно называют действующий Павловская Т.А. (СПбГУ ИТМО).
программный продукт, реализующий отдельные функции и внешние 49Подготовка проекта. PjM уточняет план проекта, назначает
интерфейсы разрабатываемого программного обеспечения. 18. команду разработчиков, организует взаимодействие с другими
Павловская Т.А. (СПбГУ ИТМО). отделами (документация, локализация, поддержка пользователей,
19Особенности спиральной модели. Основным достоинством технические тренинги и т.д.) PdM и SWA составляют список
спиральной схемы является то, что, начиная с некоторой итерации, требований к программному продукту (Stakeholder Requirements):
продукт можно предоставлять пользователю, что позволяет: Функциональность (Functionality), Удобство использования
сократить время до появления первых версий программного (Usability), Надежность (Reliability), Быстродействие
продукта; заинтересовать большое количество пользователей, (Performance), Безопасность (security), Обеспеченность
обеспечивая быстрое продвижение следующих версий продукта на поддержкой (Supportability) требования могут градуироваться по
рынке; ускорить формирование и уточнение спецификаций за счет приоритетам: обязательно (must), желательно (should), возможно
появления практики использования продукта; уменьшить вероятность (may). SWA с SWE возможно создают прототип продукта StakeHolder
морального устаревания системы за время разработки. Основной Requirements – основной продукт по завершению фазы. Milestone
проблемой использования спиральной схемы является определение S1: Product Council разрешает начать разработку продукта. 49.
моментов перехода на следующие стадии. Для ее решения обычно Павловская Т.А. (СПбГУ ИТМО).
ограничивают сроки прохождения каждой стадии, основываясь на 50Разработка продукта (Development) - 1. SWA разрабатывает на
экспертных оценках. Спиральную модель применяют для программ, утверждение SG дизайн продукта (Design Description) и
основанных как на процедурной, так и на объектно-ориентированной спецификацию по Интерфейсу пользователя (UI description),
парадигме. 19. Павловская Т.А. (СПбГУ ИТМО). проводит декомпозицию на модули, описывает все в удобном для
20Гибкие технологии разработки ПО. Минимизируют риски разработки виде (напр. UML), PjM планирует сроки и расстановку
благодаря разделению процесса разработки на маленькие промежутки сил по разработке каждого модуля CQA начинает подготовку Test
времени (итерации), обычно 1-4 недели. Каждая итерация может Plan и Test Specification Тестовая спецификация строится с
рассматриваться как полноценный проект (может включать в себя учетом требований. Она описывает методы тестирования, Test
планирование, анализ требований, проектирование, реализацию, Cases, их важность и критерии проверки. Milestone DA: дизайн
тестирование и документирование). Обычно результатом итерации не утверждается SG (Руководящей группой). 50. Павловская Т.А.
является продукт, готовый к выходу на рынок. Но целью каждой (СПбГУ ИТМО).
итерации является получение стабильной версии продукта. В конце 51Разработка продукта (Development) - 2. Выполняется
каждой итерации происходит переоценка приоритетов проекта, что итеративно: анализ, дизайн, программирование, тестирование.
значительно сокращает риски. Все гибкие методологии имеют общие Milestones Dn – D1: завершение билда N, …, 1. Milestone D1:
характеристики: • итеративная разработка; • фокус на Фиксация - Code & feature freeze (alpha version) Нет
взаимодействии и коммуникации; •полный или частичный отказ от серьезных дефектов - No any urgent bugs CQA подготовил тестовую
создания дорогостоящих промежуточных артефактов проекта. 20. спецификацию Первая версия. TWriter подготовил черновик
Павловская Т.А. (СПбГУ ИТМО). руководства пользователя Продукт готов к системному
21Основные идеи agile. • Личности и их взаимодействие важнее, тестированию. 51. Павловская Т.А. (СПбГУ ИТМО).
чем процессы и инструменты. • Работающее программное обеспечение 52Альфа-тестирование. Итеративное тестирование продукта
важнее, чем полная документация. • Сотрудничество с заказчиком тестерами под руководством CQA. Как только серьезных проблем
важнее, чем переговоры по контракту. • Реакция на изменения больше не обнаруживается, продукт переходит в статус beta
важнее, чем следование плану. Краеугольным камнем гибких version. Milestone V3: product beta-version & draft of User
технологий программирования является разработка через Guide, нет серьезных проблем и отклонений от требований. 52.
тестирование: автоматические тесты пишутся для любой части Павловская Т.А. (СПбГУ ИТМО).
реализации, которая гипотетически «может сломаться»; тесты 53Бета-тестирование. Продукт отсылается на ознакомление и
пишутся непосредственно перед написанием соответствующего кода; тестирование ограниченному набору пользователей (User Support
существующий код никогда не меняется без написания team, beta testers, sales engineers, external partners).
соответствующих тестов; выполняется регулярный запуск всех Milestone V2: готов Release Candidate, no any unresolved
автоматических тестов. 21. Павловская Т.А. (СПбГУ ИТМО). problems found. Тестирование окончательной версии: Release
22Основы манифеста гибких технологий. • Главное – candidate version отсылается избранным заказчикам. Milestone V1:
удовлетворение требований заказчика путем скорой и непрерывной Руководящая группа принимает решение о том, что продукт готов к
поставки ценного и работоспособного ПО. • Приветствуются выходу. 53. Павловская Т.А. (СПбГУ ИТМО).
изменяющиеся требования: их используют для повышения 54Подготовка к выпуску и выпуск. PdM и HPdM проверяют, что
конкурентоспособности продукта. • Работоспособное ПО продукт готов к выходу на рынок (все собрано, документация
поставляется как можно чаще, периодами от пары недель до пары подготовлена, отделы поддержки и тренинга готовы, реклама дана,
месяцев. • Бизнесмены и разработчики ежедневно работают сообща. произведена Интернет-подготовка, завод готов отштамповать диски,
• Проекты строятся вокруг мотивированных личностей, которым отдел доставки готов их доставить, определены цены, согласовано
оказывается доверие и создаются все условия для работы. • с продавцами, и т.п.). Milestone R2: все подготовлено и
Наиболее эффективным способом передачи информации (как внутри согласовано, назначена точная дата выхода. Выпуск (R2) Продукт
команды разработчиков, так и вовне) является личный разговор. • заливается на болванки, доставляется в магазины. Дается
Основной мерой прогресса является работоспособное ПО. • контрольная отмашка о выходе продукта в свет. 54. Павловская
Устанавливается удобный режим ведения разработки. • Непрерывное Т.А. (СПбГУ ИТМО).
внимание к техническому совершенству и хорошему дизайну повышает 55Все! 55. Павловская Т.А. (СПбГУ ИТМО).
гибкость. • Простота — искусство НЕ делать лишней работы. • 56Case-технологии. Computer Aided Software/System Engineering
Лучшие архитектурные решения, наборы требований и дизайны – автоматизированная разработка ПО/систем Существуют
создаются самоорганизующимися командами. • Команда регулярно САSЕ-технологии, поддерживающие как структурный, так и объектный
рассматривает и внедряет любые методы повышения своей (в т. ч. компонентный) подход САSЕ-средства повышают
эффективности. 22. Павловская Т.А. (СПбГУ ИТМО). производительность труда программистов и улучшают качество
23Проектирование в гибких технологиях. Отказ от длительного программного обеспечения. Они: обеспечивают автоматизированный
проектирования перед началом работы и выполнение проектирования контроль совместимости спецификаций проекта; уменьшают время
на протяжении всего выполнения проекта. В начале проекта создания прототипа системы; ускоряют процесс проектирования и
выполняется лишь формирование общего представления. Для этого разработки; автоматизируют формирование проектной документации
используются системные метафоры, на основе которых формируется для всех этапов жизненного цикла; частично генерируют коды
высокоуровневая схема проекта. Процесс разработки состоит из программ для различных платформ разработки; поддерживают
большого количества очень коротких циклов. Конечный результат технологии повторного использования компонентов системы;
этапа планирования – список задач, подлежащих реализации на обеспечивают возможность восстановления проектной документации
следующей итерации. 23. Павловская Т.А. (СПбГУ ИТМО). по имеющимся исходным кодам. 56. Павловская Т.А. (СПбГУ ИТМО).
24Разработчики получают задачу, берут соответствующий фрагмент 57Компонентный подход и САSЕ-технологии. Компонентный подход
разрабатываемого кода, выполняют рефакторинг, необходимый для предполагает построение программного обеспечения из отдельных
упрощения написанного кода, составляют тесты, а только затем компонентов — физически отдельно существующих частей
создают сам код, который должен пройти тесты. Поскольку циклы программного обеспечения, которые взаимодействуют между собой
«дизайн–тест–код» непродолжительны, а заказчик часто получает через стандартизованные двоичные интерфейсы. В отличие от
работающие версии программного продукта, обратная связь обычных объектов, объекты-компоненты можно собрать в динамически
осуществляется непрерывно и служит для контроля, что вызываемые библиотеки или исполняемые файлы, распространять в
проектирование и кодирование продвигаются в нужном направлении. двоичном виде (без исходных текстов) и использовать в любом
Так как изменения на каждом цикле малы, решения, от которых языке программирования, поддерживающем соответствующую
приходится отказываться, невелики, в результате чего можно технологию. Компонентный подход лежит в основе технологий,
быстро реагировать на изменения с наименьшими затратами. 24. разработанных на базе СОМ и СОRВА. 57. Павловская Т.А. (СПбГУ
Павловская Т.А. (СПбГУ ИТМО). ИТМО).
25Экстремальное программирование. Основная идея экстремального 58Технологии СОМ. Технология СОМ определяет общий принцип
программирования (ХР) — устранить высокую стоимость изменений, взаимодействия программ любых типов: библиотек, приложений,
вносимых в ПО в процессе как разработки, так и эксплуатации. операционной системы, т. е. позволяет одной части программного
Цикл разработки в ХР состоит из очень коротких итераций. обеспечения использовать функции (службы), предоставляемые
Четырьмя базовыми действиями в цикле являются: выслушивание другой, независимо от того, функционируют ли эти части в
заказчика проектирование кодирование тестирование. Заказчик пределах одного процесса, в разных процессах на одном компьютере
постоянно присутствует в группе разработчиков. При принятии или на разных компьютерах. Модификация СОМ, обеспечивающая
решений всегда стремятся выбрать самое простое, тесты пишутся передачу вызовов между компьютерами, называется DCOM По
еще до написания кода. Сборка системы выполняется ежедневно. технологии СОМ приложение предоставляет свои службы, используя
Идеолог ХР - Кент Бек. 25. Павловская Т.А. (СПбГУ ИТМО). объекты СОM, которые являются экземплярами классов СОМ. Объект
26Основные принципы ХР. Коллективное владение Заказчик с СОМ может реализовывать несколько интерфейсов. 58. Павловская
постоянным участием 40-часовая неделя Открытое рабочее Т.А. (СПбГУ ИТМО).
пространство Стандарты кодирования Не более чем правила. 59Технологии СОМ. На базе технологии COM были разработаны
Планирование Частая смена версий Метафора Простой проект Тесты компонентные технологии, решающие различные задачи разработки
Переработка системы Программирование в паре Непрерывная программного обеспечения. OLE-automation — технология создания
интеграция. Область применимости ХР: небольшие и средние приложений, обеспечивающая доступ к их внутренним службам.
проекты. 26. Павловская Т.А. (СПбГУ ИТМО). Например, ее поддерживает Microsoft Ехсеl, предоставляя другим
27Тестирование в ХР. Тестирование модулей (unit testing): приложениям свои службы. ActiveX — технология, построенная на
позволяет разработчикам убедиться, что код работает корректно, и базе OLE-automation, предназначена для создания как
без опасений выполнять рефакторинг (refactoring). помогает не распределенного в сети, так и сосредоточенного на одном
авторам кода понять, зачем нужен тот или иной фрагмент кода и компьютере программного обеспечения. Предполагает использование
как он функционирует Приемочное тестирование (acceptance визуального программирования для создания компонентов —
testing): позволяет убедиться в том, что система действительно элементов управления ActiveX. Полученные таким образом элементы
обладает заявленными возможностями и функционирует корректно. управления можно устанавливать на компьютер дистанционно с
TDD (Test Driven Development): пишется тест (не проходит) удаленного сервера, причем устанавливаемый код зависит от
пишется код, чтобы тест прошел выполняется рефакторинг кода. 27. используемой операционной системы. 59. Павловская Т.А. (СПбГУ
Павловская Т.А. (СПбГУ ИТМО). ИТМО).
28Scrum. Основой Scrum является итеративная разработка. Scrum 60Технологии СОМ. MTS (Microsoft Transaction Server — сервер
определяет итеративные правила управления проектом, которые управления транзакциями) — технология, обеспечивающая
призваны обеспечивать достижение максимального эффекта от безопасность и стабильную работу распределенных приложений при
реализованной функциональности. В Scrum определяются основные больших объемах передаваемых данных. MIDAS (Multilier
правила взаимодействия участников команды, которые призваны Distributed Application Server — сервер многозвенных
обеспечивать максимально быструю реакцию на существующую распределенных приложений) — технология, организующая доступ к
ситуацию. Каждая итерация в Scrum может быть описана так: данным разных компьютеров с учетом балансировки нагрузки сети.
планируем – фиксируем – реализуем – анализируем. За счет Все указанные технологии реализуют компонентный подход,
фиксирования требований на время одной итерации и изменения заложенный в СОМ. 60. Павловская Т.А. (СПбГУ ИТМО).
длины итерации методология Scrum позволяет управлять балансом 61Технология СОRВА. Технология СОRВА, разработанная группой
между гибкостью и предсказуемостью разработки. 28. Павловская компаний ОМG, реализует подход, аналогичный СОМ, на базе
Т.А. (СПбГУ ИТМО). объектов и интерфейсов СОRВА. Программное ядро СОRВА реализовано
29Общие положения. 3 роли: владелец продукта (Product Owner) - для всех основных аппаратных и программных платформ и потому эту
отвечает за определение требований к продукту команда (Team) - технологию можно использовать для создания распределенного
группа самостоятельных и инициативных разработчиков, программного обеспечения в разнородной вычислительной среде.
ответственных за реализацию проекта скрам-мастер (ScrumMaster) Организация взаимодействия между объектами клиента и сервера в
отвечает за решение всех организационных проблем и соблюдение СОRВА осуществляется с помощью специального посредника,
методологии Scrum. 3 фазы проекта: Подготовка (Pregame): общий названного VisiBroker, и другого специализированного
план проекта, список основных требований к продукту, программного обеспечения. 61. Павловская Т.А. (СПбГУ ИТМО).
«Разработка ПО» | Разработка ПО.ppt
http://900igr.net/kartinki/informatika/Razrabotka-PO/Razrabotka-PO.html
cсылка на страницу

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

другие презентации о программировании

«Классификация программного обеспечения» - 2. Классификация программного обеспечения. 2.1. Операционные системы. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЭВМ 1. Определение понятия программного обеспечения. 6. Классификация программного обеспечения. 2.3. Прикладные программы. 05.06.2012. Классификация программного обеспечения. 2.4. Уникальные программы. Вопросы по теме лекции.

«Программное обеспечение ПК» - Программное обеспечение ПК. Приложения функционируют под управлением определенной ОС. Системное программное обеспечение. Предыстория возникновения ПО. Прикладное программное обеспечение. Программная конфигурация ПК многоуровневая (от низкого уровня к высокому). Иерархия программного обеспечения. Устройства компьютера.

«Программное обеспечение урок» - Системное программное обеспечение. Инструментарий программирования. Используются для упаковки файлов с целью уменьшения занимаемого места на диске. Обучающие программы. Автор: Учитель МОУ СОШ № 23 Гродинская Валентина Алексеевна e-mail: grodinskay@yandex.ru. Аннотация к уроку. Языки программирования (Basic,Pascal,C++).

«Разработка ПО» - Модель с промежуточным контролем: 14. 29. 19. Проектирование в гибких технологиях. 18. Унифицированный процесс (RUP). 16. Спиральная модель разработки ПО. 11. По завершению спринта проводится демонстрационная сессия (Sprint Review Meeting).

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

«ПО в школе» - Подготовительные курсы. Табличный процессор (MS Excel). Взгляд из школы. Что будет завтра? Свободное программное обеспечение. Указание Комитета образования. Программа создания презентаций (MS Power Point). По для учителей. «…Похоже на Word, но кнопки искать трудно…». Редакторы растровой графики (Photoshop).

Урок

Информатика

126 тем
Картинки
Презентация: Разработка ПО | Тема: Программирование | Урок: Информатика | Вид: Картинки