
- •Введение
- •Жизненный цикл it-проекта
- •Концепция проекта
- •Определение проекта
- •Выполнение проекта
- •Завершение проекта
- •Стандарты жизненного цикла
- •Выбор методологии
- •Жесткие и гибкие методологии Модель водопада
- •Итеративная разработка
- •Спиральная модель
- •Архитектура Вычислительные системы
- •Операционные системы
- •Выбор языка и среды программирования
- •Краткий обзор распространенныхпромышленных языков программирования и программных платформ
- •Разработка программного обеспечения Парадигмы программирования
- •Структурное программирование
- •Процедурное программирование
- •Функциональное программирование
- •Событийно-ориентированное программирование
- •Объектно-ориентированное программирование
- •Аспектно-ориентированное программирование
- •Визуально-ориентированное программирование
- •Метапрограммирование
- •Качество кода. Критерии качества кода
- •Форматирование и оформление
- •Комментарии
- •Читаемость
- •Обработка исключений
- •Документирование
- •Рефакторинг
- •Архитектура программного обеспечения
- •Отличие архитектуры по от детального проектирования по
- •Примеры архитектурных стилей и моделей
- •Паттерны проектирования
- •Адаптер (adapter, wrapper)
- •Абстрактная фабрика (abstractfactory, kit)
- •Стратегия (strategy, policy)
- •Менеджмент Проекта
- •Проектный менеджмент
- •Команда менеджмента проекта Команды в проекте
- •Соотношение между различными командами в проекте
- •Цели кмп в проекте
- •Создание и развитие кмп Сущность и характеристики кмп
- •Управление трудовыми ресурсами проекта и менеджмент человеческих ресурсов проекта
- •Интегрированная культура кмп
- •Оценка деятельности кмп Что такое эффективная кмп?
- •Команда Менеджмента Проекта – критический фактор успеха проекта
- •Структура проекта Определение проекта
- •Основные признаки проекта
- •Направленность на достижение целей
- •Координированное выполнение взаимосвязанных действий
- •Ограниченная протяженность во времени
- •Уникальность
- •Структура проекта
- •Разработка программного обеспечения Виртуальная реальность
- •Виртуальная реальность в играх.
- •Виртуальная реальность и 3d.
- •История виртуальной реальности.
- •Что такое виртуальная реальность?
- •Миры с различными потенциально-возможными сценариями хода событий
- •Студии виртуальной реальности на телевидении
- •Имитационное моделирование
- •Искусственный интеллект
- •Предпосылки развития науки искусственного интеллекта
- •Подходы и направления
- •Тест Тьюринга
- •Символьный подход
- •Логический подход
- •Накопление и использование знаний
- •Суть процесса искусственного мышления
- •Применение
- •Перспективы
- •Искусственный интеллект в играх
- •Распределённые и облачные вычисления Распределённые вычисления
- •История
- •Участие в проектах распределенных вычислений Общая схема участия
- •Привлечение и мотивация участников
- •Критика проектов распределенных вычислений
- •Организации, участвующие в проектах распределенных вычислений
- •Список проектов распределённых вычислений
- •Биология и медицина
- •Математика и криптография
- •Естественные науки
- •По для организации распределённых вычислений
- •Облачные вычисления
- •Терминология
- •Критика
- •Примеры
- •Потребность
- •Внешние и внутренние облака
- •Стоимость
- •Надёжность
- •Проблемы облачных технологий
- •Нейронные сети
- •Возможные способы применения и реализации
- •Категории аппаратного обеспечения инс
- •Цифровое исполнение
- •Аналоговое исполнение
- •Гибридное исполнение
- •Области применения нейронных сетей
- •Аутсорсинг
- •Мировой рынок экспортного программирования
- •Прогноз развития мирового и российского рынка
- •Белорусскиекомпании
- •Типы аутсорсинга
- •Развитие cad технологий
- •Исправление ошибок
- •Системы старшего класса
- •Большие сборки
- •Зачем нужны сборки
- •Стратегии упрощения
- •Моделирование
- •Параметризация
- •Гибридное моделирование
- •Практические результаты
- •Проектная база: технология моделирования
- •Переход к гибридному моделированию
- •Электронная сборка
- •Модель акторов
- •История
- •Фундаментальные концепции
- •Формальные системы
- •Применения
- •Семантика передачи сообщений
- •Локальность
- •Безопасность
- •Актуальность в настоящий момент
- •Социальный компьютинг
- •Сферы применения
- •С чего начать
- •Тестирование программного обеспечения Уровни тестирования
- •Модульное тестирование
- •Интеграционное тестирование
- •Системы непрерывной интеграции
- •Системное тестирование программного обеспечения
- •Функциональное тестирование
- •Регрессионное тестирование
- •Виды тестов регрессии
- •Нагрузочное тестирование
- •Тестирование «белого ящика» и «чёрного ящика»
- •Серый ящик. Комбинация предыдущих.
- •Права автора Личные неимущественные права:
- •Личные имущественные права:
- •Способы защиты авторского права
- •Защита при помощи компьютерных компакт-дисков
- •Методы взлома/обхода технических мер защиты
- •Нарушение авторских прав
- •Типы лицензий
- •Проприетарные лицензии
- •Свободные и открытые лицензии
- •Пиратское по
- •Взгляд в будущее
- •Взлом информации и защита от взлома Классы атак Аутентификация (Authentication)
- •Авторизация (Authorization)
- •Атакинаклиентов (Client-side Attacks)
- •Выполнение кода (Command Execution)
- •Разглашение информации (Information Disclosure)
- •Логические атаки (Logical Attacks)
- •Компьютерные вирусы
- •Классификация вирусов
- •Антивирусные программы
- •Методы обнаружения вирусов
- •Метод соответствия определению вирусов в словаре
- •Метод обнаружения странного поведения программ
- •Метод обнаружения при помощи эмуляции
- •Метод «Белого списка»
- •Эвристический анализ
- •Классические hips
- •Экспертные hips
- •Жизненный цикл вируса.
- •Стратегии развития крупнейших it-компаний
- •Перспективы развития Microsoft
- •Секреты успеха
- •Крупнейшие производители современных операционных систем и их продукты
- •Основные заблуждения по поводу Macintosh
- •Технические подробности операционной системы
- •Причины успеха и будущее компании
- •История создания Linux
- •Свободное программное обеспечение
- •Графические интерфейсы Linux
- •Дистрибутивы Linux
- •Безопасность Linux
- •Краткая история FreeBsd и unix
- •Рождение системы bsd
- •Bsd на платформах Intel х86
- •Рождение FreeBsd
- •Преимущества FreeBsd
- •Различия между FreeBsd и Windows
- •Мобильные ос
Адаптер (adapter, wrapper)
Назначение: Преобразует интерфейс одного класса в интерфейс другого, который
ожидают клиенты. Адаптер обеспечивает совместную работу классов с несовместимыми
интерфейсами, которая без него была бы невозможна.
Применять адаптер следует, когда Вы:
Хотите использовать существующий класс, но его интерфейс не соответствует вашимпотребностям;
Собираетесь создать повторно используемый класс, который должен взаимодействоватьс заранее неизвестными или не связанными с ним классами, имеющими несовместимыеинтерфейсы;
Видите необходимость использовать несколько существующих подклассов, нонепрактично адаптировать их интерфейсы путем порождения новых подклассов откаждого. В этом случае адаптер объектов может приспосабливать интерфейс их общегородительского класса.
Адаптер класса использует множественное наследование для адаптации одного интерфейса кдругому. Адаптер объекта применяет композицию объектов.
Абстрактная фабрика (abstractfactory, kit)
Назначение: предоставляет интерфейс для создания семейств взаимосвязанных или
взаимозависимых объектов, не специфицируя их конкретных классов.
Используйте абстрактную фабрику, когда:
Система не должна зависеть от того, как создаются, компонуются и представляютсявходящие в нее объекты;
Входящие в семейство взаимосвязанные объекты должны использоваться вместе, и вамнеобходимо обеспечить выполнение этого ограничения;
Вы хотите предоставить библиотеку объектов, раскрывая только их интерфейсы, но нереализацию.
Плюсы и минусы абстрактной фабрики:
Изолирует конкретные классы. Поскольку фабрика инкапсулирует ответственностьза создание классов и сам процесс их создания, то она изолирует клиента от деталейреализации классов. Клиенты манипулируют экземплярами через их абстрактныеинтерфейсы.
Упрощает замену семейств продуктов. Класс конкретной фабрики появляется в
приложении только один раз: при инстанцировании. Это облегчает замену используемойприложением конкретной фабрики. Приложение может изменить конфигурациюпродуктов, просто подставив новую конкретную фабрику.
Гарантирует сочетаемость продуктов. Если продукты некоторого семейства
спроектированы для совместного использования, то важно, чтобы приложение в каждыймомент времени работало только с продуктами единственного семейства.
Абстрактнаяфабрика позволяет легко соблюсти это ограничение;
Поддержать новый вид продуктов трудно. Расширение абстрактной фабрики дляизготовления новых продуктов – непростая задача. Интерфейс фиксирует наборпродуктов, которые можно создать. Для поддержки новых продуктов необходиморасширить интерфейс фабрики и изменить все подклассы.
Стратегия (strategy, policy)
Назначение: определяет семейство алгоритмов, инкапсулирует каждый из них и делает извзаимозаменяемыми. Стратегия позволяет изменять алгоритмы независимо от клиентов, которыеими пользуются.
Используйте паттерн стратегия, когда:
Имеется много родственных классов, отличающихся только поведением. Стратегия
позволит сконфигурировать класс, задав одно из возможных поведений;
Вам нужно иметь несколько разных вариантов алгоритма. Например, можно определитьдва варианта алгоритма, один из которых требует больше времени, а другой – большепамяти;
В алгоритме содержатся данные, о которых клиент не должен «знать».
Используйте паттерн стратегия, чтобы не раскрывать сложные, специфичные для алгоритма структурыданных;
В классе определено много поведений, что предоставлено разветвленными условнымиоператорами. В этом случае проще перенести код из ветвей в отдельные классы стратегий.
Достоинства и недостатки паттерна стратегия:
Семейства родственных алгоритмов. Иерархия классов Strategy определяет семействоалгоритмов или поведений, которые можно повторно использовать в разных контекстах.
Наследование позволяет вычленить общую для всех алгоритмов функциональность.
Альтернатива порождению подклассов. Наследование поддерживает многообразие
алгоритмов или поведений. Можно напрямую породить от Context подклассы с
различными поведениями. Но при этом поведение жестко «замешивается» в класс
Context. Реализация алгоритма и контекста смешиваются, что затрудняет понимание,сопровождение и расширение контекста. Кроме того, заменить алгоритм динамическиуже не удастся. В результате вы получите множество родственных классов, отличающихсятолько алгоритмом или поведением. Инкапсуляция алгоритма в отдельный класспозволяет изменять его независимо от контекста;
С помощью стратегии можно избавиться от условных операторов при выборе нужногоповедения. Если код содержит много условных операторов, то часто это признак того, чтонужно применить паттерн стратегия;