- •1) Деловая(биржа) , научная(ислед раб) , потребительская(сми)
- •2) Ис совокупность средств, методов , персонала для автоматизации процессов об обработке инфы
- •1950-1960 Электротехнические машины 1960-1970 управляющие информационные системы 1970-1980 асу (автоматическое системное управление - выбор решения)
- •3) Ис совокупность средств, методов , персонала для автоматизации процессов об обработке инфы
- •24.Понятие базы данных. Модели данных.
- •27.Реляционная модель баз данных. (таблицы)
- •30)Жизненный цикл инф. Сис . Модели жизненного цикла по
- •3. Построение (Construction)
- •4. Внедрение
- •42) Основные принципы Agile-разработки программного обеспечения.
- •1. Начальная стадия (Inception)
- •2. Уточнение (Elaboration) в фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
- •43) Схема процесса разработки программного обеспечения в технологии
- •44) Основные положения технологии экстремального программирования xp.
- •45) Сравнительный анализ унифицированной технологии разработки по rup и технологии экстремального прогания xp.
- •46) Технология Scrum разработки программного обеспечения.
43) Схема процесса разработки программного обеспечения в технологии
экстремального программирования XP.
Тестирование
Игра в планирование (Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими)
Заказчик всегда рядом («Заказчик» в XP — это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.)
Парное программирование (Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.)
Непрерывная интеграция (Если выполнять интеграцию разрабатываемой системы достаточно часто, то можно избежать большей части связанных с этим проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.)
Рефакторинг (Рефакторинг (refactoring) — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.)
Частые небольшие релизы
Простота проектирования
Метафора системы (Метафора системы (system metaphor) — это аналог того, что в большинстве методик называется архитектурой.Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.Архитектура — это представление о компонентах системы и их взаимосвязях между собой.)
Стандарты кодирования (Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;
обеспечивается эффективное выполнение остальных практик.)
Коллективное владение (Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.)
44) Основные положения технологии экстремального программирования xp.
а) Экстремальный цикл (в основе экстремального программирования — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта)
б) Позднее принятие решений ("Поздний анализ" означает "принимайте конкретные решения только тогда, когда это нужно". В большинстве случаев принятые на начальной стадии решения относительно кода приходилось отменять под влиянием новых требований или других обстоятельств)
в) Кодирование в глубину (кодирование в глубину обозначает, что в течение цикла должна быть полностью разработана и протестирована отдельная функциональность и проигнорированы соседние с ней области.)
г) Идеальный день разработчика и фактор загрузки (важным первичным инструментом при расчетах является идеальный день разработчика — то есть день, когда разработчик полностью концентрируется на решении проблем проекта. Фактор загрузки — это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки.)
д) Скорость проекта (скорость проекта — это скорость реализации частей программы, определенных для заданного цикла. В качестве основных ориентиров прогресса в разработке выступают реализации историй пользователей.)
е) История пользователей (история пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". )
ж) План релиза (план релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе.)
з) План итераций (План итераций ограничивает количество заданий, которые будут выполняться в данной итерации)
и)Тесты приемки (Тесты приемки создаются на основании историй пользователей и желательно до, а не после создания программных модулей. Без прохождения тестов история не может считаться реализованной ни в какой мере)
к) Представители заказчиков (представители заказчиков являются важнейшим звеном успешной разработки по технологии XP. Представители должны не просто контактировать, но буквально физически присутствовать в непосредственной близости и работать в команде разработчиков)
л)Структура группы разработчиков(для быстрой разработки применяется особая методология организации работы, основанная на теории психологии малых групп. Основной принцип: все разработчики должны быть доступны друг для друга, как организационно, так и физически,— преимущественно желательно располагать группу в одной большой комнате. Структура в группе — одноранговая, то есть существует только профессиональный авторитет, но не административное деление.)
м) Простота и эффективность используемого кода (Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды)
н) Рефракторинг (Это наведение порядка в коде, переработка отдельных файлов и их групп с целью наведения порядка, удаления максимального количества ненужных фрагментов, объединения классов на основе схожей функциональности, коррекция комментариев, осмысленное переименование объектов и так далее. )
о) Тестирование модулей (тестирование модулей — это сугубо технологическая проверка корректности классов на основании готовой или созданной специально для этих целей автоматизированной системы.)
п) Групповое авторство.
