Программирование Скачать
презентацию
<<  Линейное программирование Разработка программ  >>
Разработчики получают задачу, берут соответствующий фрагмент
Разработчики получают задачу, берут соответствующий фрагмент
Диаграммы вариантов использования (Use case diagrams)
Диаграммы вариантов использования (Use case diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы деятельности (Activity diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы последовательностей действий (Sequence diagrams)
Диаграммы компонент (Component diagrams)
Диаграммы компонент (Component diagrams)
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Пример реального процесса разработки ПО
Фото из презентации «Разработка ПО» к уроку информатики на тему «Программирование»

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

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

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

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

Информатика

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