
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •Bcnf - нормальная форма Бойса-Кодда вводит дополнительное ограничение в сравнении с 3нф.
- •Анализ информационной связности действий и систем.
- •Анализ функциональной связности данных и систем.
- •Анализ производительности ис
- •Психологические аспекты принятия решений в процессе проектирования.
- •Организационные формы управления проектами
- •Архитектура корпоративных информационных систем (кис)
- •Mrp/erp системы. Современная структура модели mrp/erp
- •Тестирование. Методы тестирования. Категории тестов и оценок системы. Планирование тестирования и оценки системы.
- •Тестирование программного обеспечения
- •Уровни тестирования
- •Верификация и валидация – цели и задачи. V – модель как основа организации процесса верификации.
- •Основные принципы
- •Достоинства
- •Ограничения
- •Аутсорсинг и определение поставщиков.
- •Язык uml (Unificed Moeling Language). Основные модели uml (схема). Виды диаграмм.
- •Диаграмма вариантов использования. Виды отношений между актерами и вариантами использования. Отношения ассоциации, расширения, включения, обобщения
- •Диаграмма классов
- •Диаграмма состояний
- •Диаграмма деятельности. Диаграммы взаимодействия
- •Диаграмма последовательности. Диаграмма кооперации
- •Диаграмма компонентов. Диаграмма развертывания
- •23) Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.
- •24) Структурный (функциональный) и процессный подходы к разработке информационных систем
- •25) Управление требованиями к информационной системе. ГосТы и методология rup.
- •Принципы
- •Жизненный цикл разработки
- •1. Начало (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •Автоматизированное создание документов серии гост 34 и 19 с помощью инструментальных средств фирмы ibm Rational
- •26) Моделирование потоков данных. Основные компоненты диаграмм
- •1. Внешние сущности
- •2. Системы и подсистемы
- •3. Процессы
- •4. Накопители данных
- •5. Потоки данных
- •6. Построение иерархии диаграмм потоков данных
- •27) Диаграмма «сущность–связь» (erd). Сущность (Entity). Связь (Relationship). Атрибут. Виды идентификации. Подтипы и супертипы
- •28) Стадии разработки информационных систем. Модели представления для описания проектных решений. Уровни детализации, регламентирующие методики проектирования. Этапы создания информационных систем
- •29) Модели жизненного цикла программного продукта. Виды и особенности. Процессы жизненного цикла систем по iso 15288:2002
- •V модель (разработка через тестирование)
- •Iso / iec 15288 - Инженерные системы стандартных охватывающих процессы и этапы жизненного цикла.
- •30) Понятие требования. Классификация требований. Свойства требований
Организационные формы управления проектами
В рамках предприятия разворачивается внедрение и разработка множества проектов. Для их успешной реализации необходимо правильно выбрать организационную форму управления. Можно выделить 4 формы: а) Работа над проектом как дополнительная задача: вплетение в обычный ритм работы. Руководство определяет ответственного руководителя проекта, который одновременно в рамках организационной схемы выполняет и свои обычные обязанности, однако дополнительно руководит проектной командой и имеет профессиональный доступ к значимым сотрудникам, вне зависимости от границ отделов, планирует ресурсы и координирует всю инновационную деятельность. Эта модель выбирается в случае с ограниченными по времени и ресурсам проектами.
Проблемы могут заключаться в том, что менеджер проекта лишь в незначительной степени может влиять на сотрудников из других отделов из-за жесткой иерархии предприятия. Работа над проектом из-за каждодневной работы оттесняется на второй план и "засыпает". Двойная нагрузка может привести к небрежностям.
б) Классическая организация проекта ("предприятие в предприятии"): в этой модели, которая выбирается при комплексных и объемных задачах, особенно сильно подчеркнуто значение работы над проектом в организационной схеме предприятия. Работа в команде проекта имеет однозначный приоритет перед дисциплинарными отношениями подчинения классической структуры отделов. Проект опекается непосредственно руководством, и руководитель проекта, а отчасти даже и отдельные сотрудники проекта, полностью или частично освобождаются от своей обычной деятельности.
в) Смешанные формы преобладают на средних предприятиях. Освобождается опытный руководитель проекта и, в зависимости от проекта, привлекаются специализированные сотрудники, которые, однако, одновременно занимаются своей обычной деятельностью. При этом вся ответственность лежит на "проектном профессионале", который полностью может сконцентрироваться на реализации проекта и благодаря прикрытию силами руководства имеет больше свободы при назначении сотрудников проекта.
Вторая возможность - назначение внутреннего координатора проекта, занимающего высокую иерархическую позицию на предприятии и ведущего проект дополнительно к своей обычной работе, которому выделен более молодой инженер проекта, который посвящает себя исключительно проекту.
в) Концентрическое управление проектами: для управления компанией в изменившихся условиях нужна новая модель управления проектами, предусматривающая одновременную координацию и консолидацию данных, подчинение всех проектов общим целям компании при сохранении независимого управления отдельными проектами. Концентрическое управление проектами (CPM) является логическим развитием методологии управления проектами на современном этапе. СРМ - структурированный, интегрированный и масштабируемый подход к координации людей, команд и проектов.
Оргструктура - важный момент в управлении проектами - приобретает особенное значение, когда возрастает размер и сложность проектов или увеличивается их количество. СРМ предполагает, что все проекты имеют одинаковую структуру и подобно системе учета подчиняются общим правилам, используют одинаковые способы коммуникации. Именно общая структура позволяет сопоставлять деятельность разных подразделений организации и собирать детали многочисленных различных проектов в общую картину. Проекты не могут рассматриваться изолированно от остальной деятельности компании: результат и состояние работ по проектам влияют на будущее всей компании. Проекты могут быть очень большими и сложными, тогда они требуют профессиональных менеджеров для управления. С другой стороны, проекты могут быть небольшими и управляться одним человеком от имени команды. Такой менеджер должен знать, как составлять расписание, использовать простые программные средства, и при необходимости обращаться за советом к более опытному менеджеру по проекту. Отметим, что компании, которые используют единое программное обеспечение для управления проектами разного масштаба, обеспечивают своих менеджеров либо излишне усложненным, либо маломощным инструментом. В рамках СРМ все менеджеры получают подходящие им инструменты.
Методология СРМ сквозного управления проектами компании реализуется с помощью современного поколения специальных программных средств и использования единой БД по проекту, к которой имеют доступ менеджеры всех уровней. Система СРМ позволяет менеджерам работать на своих рабочих местах и встраивать свои планы в общую картину без задержек во времени.