Главная страница

Чеканин. Цели достоверность доступность достаточность Службы центры генерации(получение инфы) центр распределения( получение


Скачать 0.82 Mb.
НазваниеЦели достоверность доступность достаточность Службы центры генерации(получение инфы) центр распределения( получение
АнкорЧеканин.pdf
Дата14.07.2017
Размер0.82 Mb.
Формат файлаpdf
Имя файлаChekanin.pdf
оригинальный pdf просмотр
ТипДокументы
#25836
Каталогsimlas

С этим файлом связано 55 файл(ов). Среди них: Computer_in_my_life.pdf, IiP_3_laba_teoria.pdf, Computer in my life.docx, IiP_3_laba_teoria.docx, Elektrofizicheskie_i_elektrokhimicheskie_metody_obrabotki.pdf, Teoria_poznania_Lokka.pdf, Теория познания Локка.docx, Elektrofizichesk_i_elektroxim_metod_obrabotki_POLYKOV_2006.pdf, KibzunTeorVer.pdf и ещё 45 файл(а).
Показать все связанные файлы

1) деловая(биржа) , научная(ислед раб) , потребительская(СМИ)
Цели : достоверность; доступность; достаточность
Службы: центры генерации(получение инфы); центр распределения( получение
от1 источника и систематизация); инф агенство ( объединение первых 2)
Понятие информационной системы. Этапы развития информационных
систем. Классификация информационных систем.
2) ИС совокупность средств, методов , персонала для автоматизации процессов
об обработке инфы
Этапы развития
1950­1960 электротехнические машины
1960­1970 управляющие информационные системы
1970­1980 АСУ (автоматическое системное управление ­ выбор решения)
с 1980 СтратеГИЧЕСКИе ИС
Классификация :
По представлению инфы; по функциональному; по уровням управления; по
использованию инфы
3) ИС совокупность средств, методов , персонала для автоматизации процессов
об обработке инфы
Представление ИС в виде системы :( схема ввод­> обработка ­> вывод_> обр
связь)
причины юзания :
выработка рационального решения
поиск решения
повышение достоверности инфы
управление инф потоками
Информационные процедуры(блок обработки инф)
полностью формализуемые
не формализуемые
частично формализуемые
4)подсистемы: техническое обеспечение( 3 подхода:1­(пк­> БД+БЗ <­пк) ;
2­(пк­пк­пк) 3­(ПК­пк); математические(нейросеть; нечетная логика); программное
обеспеч; информационное обеспечение(задача­ повышение доступности(
структура : структура данных; справочн инф)); организационное
обеспечение(порядок) ;организационное(порядок взаимодействия( определение
областей целей и задач; разработка и создание и распределение; мероприятия
для улучшения ИС)

5) техническое обеспечение( 3 подхода:1­(пк­> БД+БЗ <­пк) ; 2­(пк­пк­пк) 3­(ПК­пк)
математические(нейросеть; нечетная логика);+ программное
6) информационное обеспечение(задача­ повышение доступности( структура :
структура данных; справочн инф) + организационное(порядок взаимодействия(
определение областей целей и задач; разработка и создание и распределение;
мероприятия для улучшения ИС)
Правовое(лицензионное соглашение)
7) ИТ менедж: стратегический уровень( постановка цели);
тактический(планировка времени ресов) ; операционный (решение пробл)
Объекты : инфраструктура; ит­ проекты; приложения; организационная
структура ит;
8)

ит ­ сервис???
Параметры ит­серва: функциональность; время обслуживание; доступность;
надежность; масштабность; конфиденциальность ; производительность;
стоимость;
9) функцион модель
10) процессная модель:
Процесс: определение задач; назначение ответственных; регламентация
действий; автоматизация действий

11) достоинства и недостатки функцион и процессной модели Управление служб
ИС(БОЛЬШАЯ СХЕМА С 2 видами управлений)
функцион: + решение люб задачи
обмен знаниями
простота модели
­ перегрузка руководителя
отсутствие мотивации на резалт
проблема назначения ответственного за качество серва
процессная: + решение люб задачи
обмен знаниями
простота модели
уменьшение работы руководителя(менеджер процесса)
появление обратной связи
12.Назначение и состав библиотеки инфраструктуры информационных
технологий ITIL.
­ библиотека инфраструктуры информационных технологий) — библиотека,
описывающая лучшие из применяемых на практике способов организации
работы подразделений или компаний, занимающихся предоставлением услуг в
области информационных технологий.
С остав: 1. стратегия услуг( внедрение IT­услуг в различные сферы)
2. проектиров. IT­услуг(различные этапы разработки IT­сервисов)
3. преобразование услуг(преобразование IT­сервиса для внедрения новых
технологий)
4. эксплуатация услуг(все вопросы с обеспечением функционирования
IT­сервиса)
5. постоянное улучшение услуг
13.Обзор процессов поддержки ИТ­сервисов.

1.Пр. управления инцидентами(для обеспечения быстрого
восстановления ITсервиса.)
Инцидент­ любое событие, котор. не явл. частью нормального
функционирования системы.
Характеристики: ­ число зарегистрированных инцидентов
­ временная продолжительность инцидента
2.ПР. управления проблемами(для минимизации негативного
влияния инцидентов, за счет предотвращения возможных причин их
возникновения)
Проблема­инцидент или группа инцидентов, имеющих общую
неизвестную причину
известная ошибка­знаем причину возникновения проблемы
3.ПР.управлен. конфигурациями(обеспечивает совместимость всех
используемых конфигурационных единиц, использованн. при разработке
и сопровождении ITсервиса
Виды конфигурационных единиц:
­материальная сущность
­файлы
­потоки данных
­ документы
­ персонал
­БД реализация(марки и модели, серийные номера, идентификаторы,
технич и операционные хар­ки)
4.Пр. управления изменениями( обеспеч. в уверенности в том, что все
изменения необходимы, запланиров, согласованны)
5.Пр. упр. релизами(обеспеч.согласов. вносимых изменений)
Релиз­1 или несколько позиций конфигурации, которые разраб. и тестир.
совместно
13.Обзор процессов поддержки ИТ­сервисов.
14.Процесс управления инцидентами ИТ­сервиса.
Пр. управления инцидентами(для обеспечения быстрого восстановления
ITсервиса.)
Инцидент­ любое событие, котор. не явл. частью нормального
функционирования системы.
Характеристики: ­ число зарегистрированных инцидентов
­ временная продолжительность инцидента

Основные задачи: 1. регистрация инцидента
2.категоризация(определение уровня важности и назначения
приоритета его выполнения)
3.обработка инцидента
4.пополнение БЗ по инцидентам
5. закрытие инцидента и уведомление пользлвателя
15.Процесс управления проблемами ИТ­сервиса.
ПР. управления проблемами(для минимизации негативного
влияния инцидентов, за счет предотвращения возможных причин их
возникновения)
Проблема­инцидент или группа инцидентов, имеющих общую
неизвестную причину
известная ошибка­знаем причину возникновения проблемы
Основные задачи:
1.определен. корневых причин инцидентов
2. управление проблемами и известными ошибками
3. отслеживание изменений
16.Процесс управления конфигурациями ИТ­сервиса.
ПР.управлен. конфигурациями(обеспечивает совместимость всех
используемых конфигурационных единиц, использованн. при разработке и
сопровождении ITсервиса
Виды конфигурационных единиц:
­материальная сущность
­файлы
­потоки данных
­ документы
­ персонал
­БД реализация(марки и модели, серийные номера,
идентификаторы, технич и операционные хар­ки)
17.Процесс управления изменениями ИТ­сервиса.
Пр. управления изменениями( обеспеч. в уверенности в том, что
все изменения необходимы, запланиров, согласованны)
Основные задачи :
Допущ. вынужд., провер. изменений, отслеживание изменений,
приводящих к плохим последствиям
­
Отслеживание изменений
­
оценка возможностей
­
Отмена изменений
­
Оценка продолжительности

18.Процесс управления релизами ИТ­сервиса. Виды релизов конфигураций
информационных систем.
Пр. упр. релизами(обеспеч.согласов. вносимых изменений)
Релиз­1 или несколько позиций конфигурации, которые разраб. и тестир.
совместно
Виды релиза:
Частичный/ Черезвычайный
Малый
большие (внедрение функциональности)
Этапы:
разработка релиза
эксплуатация
тестирование
Типы:
Полный
дельта­релиз
пакетный релиз
19.Обзор процессов предоставления ИТ­сервисов.
1.Процесс управления уровнем сервиса
соглашение об уровне IT сервисов:
РУКОВОДСТВО
МП управления
МП управления
уровнем сервиса мощностями
ЗАКАЗЧИК
установление соответствий между параметрами IT серв. и ресурсами IT
службами
2. Процесс управления мощностями ИТ­сервиса.
Предн. для оптимального распределения ресурсов службы инф. системы
для выполнения согл. об уровне сервиса
­
оценка требуемых ресурсов
­
анализ имеющихся ресурсов (инвентаризация)
­
решение проблем избыточности и нехватки ресурсов
­
перераспределение ресурсов
­
оценка возможности виртуализации ресурсов
­
автоматизация процессов управления ресурсами
3.Процесс управления доступностью ИТ­сервиса.

Предн. для контроля возм. обеспечения заданного уровня
доступности ИТ­сервиса.
­
анализ “узких” мест
­
выработка изменений
­
анализ текущей доступности
­
регистрация проблем доступности
4. Пр. управлен. непрерывности
Обеспечение работоспособности ITсервиса, при возникновении чрезвычайных
ситуаций (Стихийные бедствия, отключение света)
Выполнение действий :
1.Анализ возможных проблем( риска )
2.Оценка в случае ЧС
3.План восстановления ITсервиса
5.ПР. упр финансами
Предназначен для контроля фактических затрат на предоставление IT
стервиса задачи:
­оценка стоимости ITсервиса (себестоимость)
­оценка прибыли
­оценка затрат на сопровождение ITсервиса
6. ПР упр. безопасностью
Информ. без предоставляемых и itсервисов
Задачи:
определение политики безопасности
определение “узких” мест с точки зрения безопасности
повышение безопасности
сертификация системы безопасности
——/)/)—­­­–/),/)—­(\__/)—­(\.(\—–(\(\
—–(’:'=)—­(’:'=)—(=’;'=)—(=’:')—­(=’:')
–(”)(”),,)­(”)(”),,)—(”)_(”)—(..(”)(”)­(..(”)( “)
/О\ ЧЕКАНИНЛОЛКЕКЛОХ
.. |"""""""""""""""""| |\
... |Холодное пиво! ||""\__,_
... |_____________ |||_|__|_ )
... *(@)|(@)"""*******(@)"(“)

ЗОНА АНГЕЛИНЫ :С
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
ЗОНА МАРИНЫ :3

(это Ангелина смайлик
поставила)
20. Процесс управления уровнем ИТ­сервиса. Содержание соглашения об уровне
сервиса SLA.

М.П. упр. ур. сервиса
МП упр. мощностями
Руководство ←­­­­­­­­­­­­­→ Заказчик
Установление компромиса (соответсвий) между параметрами ИТ­сервиса и
ресурсными возм. ИТ­службы.

21. Процесс управления мощностями ИТ­сервиса.
Предн. для оптимального распределения ресурсов службы инф. системы
для выполнения согл. об уровне сервиса
­
оценка требуемых ресурсов
­
анализ имеющихся ресурсов (инвентаризация)
­
решение проблем избыточности и нехватки ресурсов
­
перераспределение ресурсов
­
оценка возможности виртуализации ресурсов
­
автоматизация процессов управления ресурсами
22. Процесс управления доступностью ИТ­сервиса.
Предн. для контроля возм. обеспечения заданного уровня доступности
ИТ­сервиса.
­
анализ “узких” мест
­
выработка изменений
­
анализ текущей доступности
­
регистрация проблем доступности

23.Процессы управления непрерывностью, финансами и безопасностью
ИТ­сервиса.
П. упр. непрерывностью

обесп. работоспособность ИТ­сервиса при
возникновении ЧС.
­
стихийные бедствия
­
откл. света
­
анализ возм. рисков
­
оценка времени восст.
­
составление плана восст.
П. упр. финансами

предн. для контроля фактических затрат на
предоставление IT сервиса задачи:
­оценка стоимости IT­сервиса (себестоимость)
­оценка прибыли
­оценка затрат на сопровождение IT­сервисов
П. упр. безопасности

предн. для обесп. инф безопасности
предоставленных ИТ­сервисов

­
опр. политика безопасности
­
опр “узких” мест по безопасности
­
выработка реком. по повыш. безоп.
­
сертификация систем безопасности
24.Понятие базы данных. Модели данных.
Базы данных(БД) ­ это независ. от прикладных программ совокупность данных,
организованных по опр. правилам, предусматривающих общие принципы их
создания, хранения и манипулирования.
Внешняя информационная модель

отражает предметную область привычных
для пользователей терминов (факты, предметы, св­ва, связи | сущность,
атриюут, экземпляр)
Внутр. ИМ

содержит описание предметной области, соотв. исп. ПО
Физическая БД

представл. собой БД в виде наборов файлов
Логическая модель БД
1) Типы данных + Структуры данных
2) Набор допустимых операций
3) Ограничения контроля целостности
3.1) Модель данных (статич. модель)
3.2) Модель визуализации
­ запреты
­ формы
­ отчёты
3.3)Модель управления данными (динамич. модель)
­ выборка
­ удаление
­ добавление
25.Функции системы управления базой данных (СУБД).
СУБД ­ комплекс программ и языковых средств, обеспечивающих создание
структур БД, наполнение её содержимым и визуализации информацией
1) Обеспечения языковыми средствами доступа
2) Поддержка логич.модели
3) Обесп. совместного доступа к данным
26.Иерархическая и сетевая модели баз данных.
Иеархическая БД (предок ­­ потомок)
+ очень высокая степень наглядности

+ простота
+ высокое быстродействие
­
проблем. создание больших БД
Сетевая БД (Интернет)
Разница между иерархической моделью данных и сетевой состоит в том, что
в иерархических структурах запись­потомок должна иметь в точности одного
предка, а в сетевой структуре данных у потомка может иметься любое число
предков.
Сетевая БД состоит из набора экземпляров определенного типа записи и
набора экземпляров определенного типа связей между этими записями.
27.Реляционная модель баз данных. (таблицы)
Реляционная модель данных — логическая модель данных, которая является
приложением к задачам обработки данных таких разделов математики как теории
множеств и логика первого порядка.
Реляционная модель данных включает следующие компоненты:
● Структурный аспект (составляющая) — данные в базе данных
представляют собой набор отношений.
● Аспект (составляющая) целостности — отношения (таблицы) отвечают
определенным условиям целостности. РМД поддерживает декларативные
ограничения целостности уровня домена (типа данных), уровня
отношения и уровня базы данных.
● Аспект (составляющая) обработки (манипулирования) — РМД
поддерживает операторы манипулирования отношениями (реляционная
алгебра,реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
28.Свойства отношений реляционных баз данных.
1. Отсутствие кортежей­дубликатов.
2. Отсутствие упорядоченности кортежей.
3. Отсутствие упорядоченности атрибутов.
4. Атомарность значений атрибутов.
*

Кортеж — конечное множество взаимосвязанных допустимых значений
атрибутов, которые вместе описывают некоторую сущность (строка
таблицы).
*Атрибут — свойство некоторой сущности. Часто называется полем
таблицы.

29.Нормализация отношений реляционной базы данных.
Первая нормальная форма
Отношение находится в 1НФ, если определен первичный ключ и знач.
всех атрибутов явл. атомарными (неделимыми)
Вторая нормальная форма
Отн. находятся во 2НФ, если они нах. в 1НФ и каждый неключевой
атрибут функционально полно зависит от ключа целиком
Третья нормальная форма
Отн. нах. в 3НФ, если в нем отсутствуют транзистивные зависимости, т.е. все
неключевые отрибуты взаимно независимы.
Нормальная форма Бойса-Козда
Отн. нах. в НФБК, если они нах. в 3НФ и каждый детерминант явл. первичным
ключом (если всего 1 возможный ключ)
Четвертая нормальная форма
Отн. нах в 4НФ, если они нах в НФБК и отсутствуют нетривиальные
многозначные зависимости.
КОНЕЦ ЗОНЫ МАРИНЫ
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
... |"""""""""""""""""| |\
... |Холодное пиво! ||""\__,_
... |_____________ |||_|__|_ )
... *(@)|(@)"""*******(@)"
30)Жизненный цикл инф. сис . Модели жизненного цикла ПО
Жизненный цикл­ряд событий , происходящих с системой в процессе ее
создания и использования.
Модель жизненного цикла ­ процесс , действия и задачи которого выполняются
в ходе функционирования инф. систем на всех этапах.
виды Моделей:
каскадная:
разработка требований
проектирование
реализация

тестирование
ввод в экспл.
плюсы:
полный набор документации на каждом шаге
минусы:
нельзя вернуться на предыдущие шаги
жесткость архитектуры
отсутствие отработки изменений , параллелизма
излишняя документированность
конечный продукт только на последнем этапе
Поэтапная модель с промежуточным контролем:
(то же самое только можно возвращаться на предыдущие шаги , напрмер: с
проектирования на разработку требований или с реализации на проектирование
и разработку требований итд)
минусы:
общие требования к ИС зафиксированы
согласование результата с заказчиком между этапами
V образная модель

­ крч как буковка v , перечеркнутая четырьмя палками ,
думаю сможете нарисовать
Спиральная модель
прототип ­>разработка требований ­>проектрирование
­>реализация­>тестирование­> эксплуатация и с начала и так по кругу , пока не
будет завершен проект.У этой модели "­" в том , что нельзя оценить стоимость.
Используется по привычке.Иногда ее используют , потому что считают более
надежной.
31)Основные фазы проекта в унифицированной технологии разработки ПО RUP.
Фазы: начала проекта , проектирования , построения , внедрения (более
подробно­ниже)
32)фаза начала проекта в унифицированной технологии разработки ПО RUP
основная задача ­ достичь компромиса между всеми заинтересованными
лицами относительно цели и задачи проекта (10% времени и 5% трудоемкости)

33)Фаза проектирования в унифицированной технологии разработки ПО RUP
Осн. задача­разработка архитектуры системы на базе наиболее существенных
требований (30% времени , 20% трудоемкости)
34)Фаза построения в унифицированной технологии разработки ПО RUP
50% времени и 65% труда
35)Фаза внедрения в унифицированной технологии разработки ПО RUP
36)Основные артефакты проекта в технологии RUP
модель вариантов использования (use­case model)
модель анализа (analysis model)

модель проектирования (design model)
модель реализации (implementation model)
модель развертывания (deployment model)
модель тестирования (test model/test suite)
37)Модели анализа и вариантов использования в унифицированной технологии
разработки программного обеспечения RUP
МОДЕЛЬ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ МОДЕЛЬ АНАЛИЗА
38)Модели проектирования и реализации в унифицированной технологии
разработки программного обеспечения RUP
.NET ; .COM ; .corba ; субд… (бля , сам хз , это все что у меня в лекции D: )
39)Модели развертывания и тестирования в унифицированной технологии
разработки программного обеспечения RUP
Модель развертывания: список всех узлов для разверт.
Модель тестирования: test case­тестовый вариант , test script­тестовая
процедура
КАКАЯТО ТАБЛИЦА , КОТОРАЯ ХЕР ЗНАЕТ КУДА ОТНОСИЦА
40)Дисциплины унифицированной технологии разработки ПО RUP
Моделирование предметной области (business modelling)

Определение требований
Анализ и проектирование
Реализация
Тестирование
Развертывание
Управление конфигурациями и изменениями
управление проектом
управление средой проекта
41) Основные положения унифицированной технологии разработки
программного обеспечения RUP.
1. Начальная стадия (Inception)
В фазе начальной стадии:
● Формируются видение и границы проекта.
● Создается экономическое обоснование (business case).
● Определяются основные требования, ограничения и ключевая
функциональность продукта.
● Создается базовая версия

модели прецедентов

.
● Оцениваются риски.
При завершении начальной фазы оценивается достижение

этапа


жизненного
цикла


цели

(

англ.


Lifecycle Objective Milestone

), которое предполагает соглашение
заинтересованных сторон о продолжении проекта.
2. Уточнение (Elaboration)
В фазе «Уточнение» производится анализ предметной области и построение
исполняемой архитектуры. Это включает в себя:
● Документирование требований (включая детальное описание для
большинства

прецедентов

).
● Спроектированную, реализованную и оттестированную исполняемую
архитектуру.
● Обновленное экономическое обоснование и более точные оценки
сроков и стоимости.
● Сниженные основные риски.
Успешное выполнение фазы разработки означает достижение

этапа
жизненного цикла


архитектуры

(

англ.


Lifecycle Architecture Milestone

).
3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности
продукта. Фаза Построение завершается первым внешним релизом системы и
вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение
В фазе «Внедрение» создается финальная версия продукта и передается от
разработчика к заказчику. Это включает в себя программу бета­тестирования,
обучение пользователей, а также определение качества продукта. В случае, если
качество не соответствует ожиданиям пользователей или критериям,
установленным в фазе Начало, фаза Внедрение повторяется снова.
Выполнение всех целей означает достижение вехи готового продукта (Product
Release) и завершение полного цикла разработки.
42) Основные принципы Agile­разработки программного обеспечения.
а) Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
б) Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile­процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
в) Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
г) На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
е) Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
ж) Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
з) Работающий продукт — основной показатель прогресса.
и) Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
к) Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
л) Простота — искусство минимизации лишней работы — крайне необходима.
м) Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
н) Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать

стиль своей работы.
43) Схема процесса разработки программного обеспечения в технологии
экстремального программирования XP.
1. Тестирование
2. Игра в планирование (

Основная цель игры в планирование — быстро
сформировать приблизительный план работы и постоянно обновлять его по
мере того, как условия задачи становятся всё более чёткими)
3. Заказчик всегда рядом (

«Заказчик» в XP — это не тот, кто оплачивает счета,
а конечный пользователь программного продукта. XP утверждает, что
заказчик должен быть всё время на связи и доступен для вопросов.

)
4. Парное программирование (

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

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

)
5. Непрерывная интеграция (

Если выполнять интеграцию разрабатываемой
системы достаточно часто, то можно избежать большей части связанных с
этим проблем. В традиционных методиках интеграция, как правило,
выполняется в самом конце работы над продуктом, когда считается, что все
составные части разрабатываемой системы полностью готовы. В XP
интеграция кода всей системы выполняется несколько раз в день, после
того, как разработчики убедились в том, что все тесты модулей корректно
срабатывают.

)
6. Рефакторинг (

Рефакторинг

(refactoring) — это методика улучшения кода без
изменения его функциональности. XP подразумевает, что однажды
написанный код в процессе работы над проектом почти наверняка будет
неоднократно переделан.

)
7. Частые небольшие релизы
8. Простота проектирования
9. Метафора системы (

Метафора системы (system metaphor) — это аналог того,
что в большинстве методик называется архитектурой.Метафора системы
даёт команде представление о том, каким образом система работает в
настоящее время, в каких местах добавляются новые компоненты, и какую

форму они должны принять.Архитектура — это представление о компонентах
системы и их взаимосвязях между собой.

)
10. Стандарты кодирования (

Все члены команды в ходе работы должны
соблюдать требования общих стандартов кодирования. Благодаря этому:
● члены команды не тратят время на глупые споры о вещах, которые
фактически никак не влияют на скорость работы над проектом;
● обеспечивается эффективное выполнение остальных практик.

)
11. Коллективное владение (

Коллективное владение

означает, что каждый член
команды несёт ответственность за весь

исходный код

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

)
44) Основные положения технологии экстремального программирования XP.
а)

Экстремальный цикл (в основе экстремального программирования — очень
короткий, постоянно повторяющийся цикл разработки, составляющий одну­три
недели. К концу каждого цикла вы должны иметь полностью рабочий,
функциональный и протестированный релиз приложения. Эти циклы должны
быть повторяющимися и бесперебойными на протяжении всего проекта)
б) Позднее принятие решений ("Поздний анализ" означает "принимайте
конкретные решения только тогда, когда это нужно". В большинстве случаев
принятые на начальной стадии решения относительно кода приходилось
отменять под влиянием новых требований или других обстоятельств)
в) Кодирование в глубину (кодирование в глубину обозначает, что в течение
цикла должна быть полностью разработана и протестирована отдельная
функциональность и проигнорированы соседние с ней области.)
г) Идеальный день разработчика и фактор загрузки (важным первичным
инструментом при расчетах является идеальный день разработчика — то есть
день, когда разработчик полностью концентрируется на решении проблем
проекта. Фактор загрузки — это отношение реальных календарных рабочих дней
к идеальным дням разработчика; он характеризует "температуру" разработки.)
д) Скорость проекта (скорость проекта — это скорость реализации частей
программы, определенных для заданного цикла. В качестве основных
ориентиров прогресса в разработке выступают реализации историй
пользователей.)
е) История пользователей (история пользователей — это аналог Use Case, но
имеющий несколько другой оттенок. История пользователя — это компактный
документ (предположительно около трех предложений) составленный
пользователем и описывающий одну отдельную операцию для данного
пользователя в духе "я захожу в программу и...". )
ж) План релиза (план релиза, утверждаемый на специальном совещании, дает
точный ответ на вопрос, какие именно истории пользователей будут
реализованы в данном релизе.)
з) План итераций (План итераций ограничивает количество заданий, которые
будут выполняться в данной итерации)
и)Тесты приемки (Тесты приемки создаются на основании историй
пользователей и желательно до, а не после создания программных модулей.

Без прохождения тестов история не может считаться реализованной ни в какой
мере)
к) Представители заказчиков (представители заказчиков являются важнейшим
звеном успешной разработки по технологии XP. Представители должны не
просто контактировать, но буквально физически присутствовать в
непосредственной близости и работать в команде разработчиков)
л)Структура группы разработчиков(для быстрой разработки применяется
особая методология организации работы, основанная на теории психологии
малых групп. Основной принцип: все разработчики должны быть доступны друг
для друга, как организационно, так и физически,— преимущественно желательно
располагать группу в одной большой комнате. Структура в группе —
одноранговая, то есть существует только профессиональный авторитет, но не
административное деление.)
м) Простота и эффективность используемого кода (Фактически, все члены
команды изначально должны выбрать технологии, которыми владеют все или
большинство членов команды)
н) Рефракторинг (Это наведение порядка в коде, переработка отдельных файлов
и их групп с целью наведения порядка, удаления максимального количества
ненужных
фрагментов,
объединения
классов
на
основе
схожей
функциональности, коррекция комментариев, осмысленное переименование
объектов и так далее. )
о) Тестирование модулей (тестирование модулей — это сугубо технологическая
проверка
корректности
классов
на основании готовой или созданной
специально для этих целей автоматизированной системы.)
п) Групповое авторство.
45) Сравнительный анализ унифицированной технологии разработки ПО RUP и
технологии экстремального прогания XP.
RUP является хорошо сбалансированным решением для средних по размерам
коллектив разработчиков, работающих с применением продуктов и технологий
компании Rational. Сопровождение разработки системы и самой системы
регламентируется самой методологией RUP, однако данная технология
достаточно сильно ориентирована на внутрифирменные инструментальные
средства.
Extreme Programming (XP) хорошо подходит для проектных групп малого
размера и для небольших систем с часто изменяемыми требованиями.
Основная проблема XP ­ сопровождаемость. В случае текучки кадров в
коллективе разработчиков значительная часть проектной информации может
быть утеряна из­за практически отсутствующей документации.
46) Технология Scrum разработки программного обеспечения.
Технология Scrum была разработана в начале 1990­х годов американскими
разрабами Кеном Швабером и Джеффом Садерлендом. Сама технология
является методологией управления проектами, активно применяется при
разработке информационных систем для гибкой разработки ПО. Scrum – это
набор принципов, на которых строится процесс разработки, позволяющий в
фиксированные сроки и небольшие по времени итерации (спринты)

предоставить пользователю конечный продукт. Один Спринт длится от 2 до 4
недель. Планирование спринта происходит начального спринта: команда
выбирает объем работ и обслуживает реализацию, при этом задачи оценивают
в человеко ­ часах (не более 12 часов или одного дня) и разбивают на задачи.
Для отслеживания процесса разработки используют диаграммы, например,
диаграмма сгорания задач (общедоступный график, показывающий, сколько
задач выполнено и сколько осталось).

перейти в каталог файлов
связь с админом