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

Программирование Скачать презентацию
<< Линейное программирование		Разработка программ >>

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

Фото из презентации «Разработка ПО» к уроку информатики на тему «Программирование»

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

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

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

содержание презентации «Разработка ПО»

Сл	Текст	Эф	Сл	Текст	Эф
1	Цикл разработки ПО и роль тестера на каждом этапе.	0	29	разработчиков, ответственных за реализацию проекта	0
1	1.	0		скрам-мастер (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 основан на компонентном
8	ИТМО).	0		подходе, использует стандарт визуального моделирования.
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		Павловская Т.А. (СПбГУ ИТМО).
13	Т.А. (СПбГУ ИТМО).	0	41	UML. Язык для специфицирования, визуализации,	0
14	Макетирование (прототипирование). 1. 2	0		конструирования и документирования программных
	Проектирование продукта. Построение/уточнение макета.			продуктов. Также используется в бизнес-моделировании и
	Оценка макета заказчиком. 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 case	0
	разработки небольшими группами (3-7 человек), каждая из		42	diagrams). 42. Павловская Т.А. (СПбГУ ИТМО).	0
	которых проектирует и реализует отдельные подсистемы,		43	Диаграммы деятельности (Activity diagrams). 43.	0
	позволяет улучшить управляемость проекта; использование		43	Павловская Т.А. (СПбГУ ИТМО).	0
	готовых компонентов способствует уменьшению времени		44	Диаграммы последовательностей действий (Sequence	0
	получения работоспособного прототипа; наличие четко		44	diagrams). 44. Павловская Т.А. (СПбГУ ИТМО).	0
	проработанного графика цикла, рассчитанного не более		45	Диаграммы компонент (Component diagrams). 45.	0
	чем на три месяца, существенно увеличивает		45	Павловская Т.А. (СПбГУ ИТМО).	0
	эффективность работы. Технология RAD хорошо		46	Пример реального процесса разработки ПО. 46.	0
	зарекомендовала себя для относительно небольших		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. SWA	0
	моментов перехода на следующие стадии. Для ее решения			разрабатывает на утверждение 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 и HPdM	0
	удовлетворение требований заказчика путем скорой и			проверяют, что продукт готов к выходу на рынок (все
	непрерывной поставки ценного и работоспособного ПО. •			собрано, документация подготовлена, отделы поддержки и
	Приветствуются изменяющиеся требования: их используют			тренинга готовы, реклама дана, произведена
	для повышения конкурентоспособности продукта. •			Интернет-подготовка, завод готов отштамповать диски,
	Работоспособное ПО поставляется как можно чаще,			отдел доставки готов их доставить, определены цены,
	периодами от пары недель до пары месяцев. • Бизнесмены			согласовано с продавцами, и т.п.). Milestone R2: все
	и разработчики ежедневно работают сообща. • Проекты			подготовлено и согласовано, назначена точная дата
	строятся вокруг мотивированных личностей, которым			выхода. Выпуск (R2) Продукт заливается на болванки,
	оказывается доверие и создаются все условия для работы.			доставляется в магазины. Дается контрольная отмашка о
	• Наиболее эффективным способом передачи информации			выходе продукта в свет. 54. Павловская Т.А. (СПбГУ
	(как внутри команды разработчиков, так и вовне)			ИТМО).
	является личный разговор. • Основной мерой прогресса		55	Все! 55. Павловская Т.А. (СПбГУ ИТМО).	0
	является работоспособное ПО. • Устанавливается удобный		56	Case-технологии. Computer Aided Software/System	0
	режим ведения разработки. • Непрерывное внимание к			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	Тестирование в ХР. Тестирование модулей (unit	0		программирования для создания компонентов — элементов
	testing): позволяет разработчикам убедиться, что код			управления ActiveX. Полученные таким образом элементы
	работает корректно, и без опасений выполнять			управления можно устанавливать на компьютер
	рефакторинг (refactoring). помогает не авторам кода			дистанционно с удаленного сервера, причем
	понять, зачем нужен тот или иной фрагмент кода и как он			устанавливаемый код зависит от используемой
	функционирует Приемочное тестирование (acceptance			операционной системы. 59. Павловская Т.А. (СПбГУ ИТМО).
	testing): позволяет убедиться в том, что система		60	Технологии СОМ. MTS (Microsoft Transaction Server —	0
	действительно обладает заявленными возможностями и			сервер управления транзакциями) — технология,
	функционирует корректно. TDD (Test Driven Development):			обеспечивающая безопасность и стабильную работу
	пишется тест (не проходит) пишется код, чтобы тест			распределенных приложений при больших объемах
	прошел выполняется рефакторинг кода. 27. Павловская			передаваемых данных. MIDAS (Multilier Distributed
	Т.А. (СПбГУ ИТМО).			Application Server — сервер многозвенных распределенных
28	Scrum. Основой Scrum является итеративная	0		приложений) — технология, организующая доступ к данным
	разработка. Scrum определяет итеративные правила			разных компьютеров с учетом балансировки нагрузки сети.
	управления проектом, которые призваны обеспечивать			Все указанные технологии реализуют компонентный подход,
	достижение максимального эффекта от реализованной			заложенный в СОМ. 60. Павловская Т.А. (СПбГУ ИТМО).
	функциональности. В Scrum определяются основные правила		61	Технология СОRВА. Технология СОRВА, разработанная	0
	взаимодействия участников команды, которые призваны			группой компаний ОМG, реализует подход, аналогичный
	обеспечивать максимально быструю реакцию на			СОМ, на базе объектов и интерфейсов СОRВА. Программное
	существующую ситуацию. Каждая итерация в Scrum может			ядро СОRВА реализовано для всех основных аппаратных и
	быть описана так: планируем – фиксируем – реализуем –			программных платформ и потому эту технологию можно
	анализируем. За счет фиксирования требований на время			использовать для создания распределенного программного
	одной итерации и изменения длины итерации методология			обеспечения в разнородной вычислительной среде.
	Scrum позволяет управлять балансом между гибкостью и			Организация взаимодействия между объектами клиента и
	предсказуемостью разработки. 28. Павловская Т.А. (СПбГУ			сервера в СОRВА осуществляется с помощью специального
	ИТМО).			посредника, названного VisiBroker, и другого
29	Общие положения. 3 роли: владелец продукта (Product	0		специализированного программного обеспечения. 61.
	Owner) - отвечает за определение требований к продукту			Павловская Т.А. (СПбГУ ИТМО).
	команда (Team) - группа самостоятельных и инициативных
61	«Разработка ПО» \| Разработка ПО				5