Проектирование КИС План Проектирование КИС Основные понятия

Проектирование КИС.

План Проектирование КИС. Основные понятия. Каноническое проектирование Этапы проектирования КИС и проектная документация. Техническое задание и его содержание Понятие о типовом проектировании КИС Организационное обеспечение разработок КИС Консалтинг и аутсорсинг при разработках КИС Оценки качества КИС Стандартизация и сертификация корпоративных информационных систем. Инструментарии управления проектом. Microsoft Project

Проектирование КИС. Основные понятия.

Общая методология Проектирование –это процесс составления описания, необходимого для создания еще не существующего объекта (алгоритма его функционирования или алгоритма процесса), который осуществляется преобразованием первичного описания (технического задания), оптимизацией заданных характеристик объекта и алгоритма его функционирования , устранением некорректностей первичного описания и последовательным представлением описаний детализируемого объекта на различных языках для различных этапов проектирования. ГОСТ 34. 601 -90 Комплекс стандартов на автоматизированный системы. Автоматизированные системы. Стадии создания

Проектирование как процесс Проектирование –информационный процесс , в котором осуществляется преобразование входной информации об проектируемом объекте , состояния знаний о предметной области, опыта проектирования в выходную информацию в виде проектных документов выполненных в заданной форме.

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

Виды проектирования Внутреннее проектируемый объект составлен из компонент и каждая должна быть спроектирована Внешнее- объект сам является частью системы более высокого уровня и его параметры должны быть согласованы с параметрами среды. Восходящее- проектирование производится от компонент объекта с последующей увязкой в общую систему. Нисходящее- процесс реализуется от общего описания объекта к детализации и последующим проектированием отдельных компонент. Типовое- проектируемая ИС собирается из готовых программных модулей. Оригинальное- все проектные решения разрабатываются «с нуля» в соответствии со спецификационными требованиями.

Временные затраты этапов жизненного цикла (1 итерация)

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

Области охвата проектирования Проектирование информационных систем охватывает три основные области: проектирование объектов данных, которые будут реализованы в базе данных; проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.

Каноническое проектирование ИС

Каноническое проектирование ИС Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34. 60190. В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей. Стадии и этапы создания ИС, выполняемые организациями -участниками, прописываются в договорах и технических заданиях на выполнение работ

Стадии проектирования(жизненный цикл проектирования) . Предпроектные исследования (анализ) Исследуются необходимость в системе. уровень знаний, ресурсы. Техническое задание и техническое обоснование Эскизное проектирование Проверяется корректность ТЗ и выполнимость проекта, принципы и положения функционирования системы. Разработка и автономная отладка компонент системы Эскизный проект Техническое проектирование Полная проработка всех частей проекта. Разработка макета системы. Комплексная отладка всех компонент в составе макета системы Технический проект Рабочее проектирование Создается и проверяется опытный (рабочий) образец системы на стенде исполнителя Разрабатывается программная и техническая документация. Рабочий Проект + образец системы Сопровождение Проверка функционирования в составе других Информацио систем на стенде заказчика. Эксплуатация системы. нная Система Исправление замеченных недостатков.

Схема разработки ИС при каноническом проектировании. Обследование В целом ТЗ Диагностический Анализ организации Стадии проектирования Детализированное обследование Сопровождение

Этапы проектирования КИС и проектная документация.

Стадия 1. Предпроектный анализ Включает следующие этапы работ: обследование объекта и обоснование необходимости создания ИС; формирование требований пользователей к ИС; оформление отчета о выполненной работе и тактико-технического задания на разработку.

Стадия 1 Этап 1 Обследования изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются: обоснования разработки и поэтапного внедрения систем; составления технического задания на разработку систем; разработки технического и рабочего проектов систем.

Задачи обследования оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня Построение моделей «Как есть» и «Как будет» для объекта и процесса автоматизации Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес -экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями

Этап 2 Формирование требований определения стратегии является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).

содержание ТЭО: совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы; описание выполняемых системой функций; возможности развития системы; информационные объекты системы; интерфейсы и распределение функций между человеком и системой; требования к программным и информационным компонентам ПО, требования к СУБД; ограничения, риски, критические факторы, которые могут повлиять на успешность проекта; сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации.

Стадия 1. Этап 3 Разработка технического задания. Если заказчик удовлетворен результатом пред проектного анализа , согласен с выводами ТЭО , согласен на финансирование работ , то следующим этапом разрабатывается техническое задание на разработку КИС, документ, определяющий цели, требования и основные исходные данные, необходимые для разработки ЭИС.

Стадия 2. Проектирование Этап 1. Эскизный проект. Эскизный проект разрабатывают, если это предусмотрено техническим заданием или протоколом рассмотрения технического предложения. Эскизный проект разрабатывают с целью установления принципиальных (конструктивных, схемных и др. ) решений изделия, дающих общее представление о принципе работы и (или) устройстве изделия, когда это целесообразно сделать до разработки технического проекта или рабочей документации. Регламентируется ЕСКД ГОСТ 2. 119 -73 Разработка проектных решений по системе и её частям. Разработка проектной документации на автоматизированную систему и её части. Разработка и оформление документации на поставку изделий для комплектования автоматизированной системы и (или) технических требований (технических заданий) на их разработку. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации. разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части.

Стадия 2 Этап 2 Технический проект Технический и рабочий проекты регламентируется ГОСТ 34. 601 -90 разработка проектных решений по системе и ее частям; разработка документации на ИС и ее части; разработка и оформление документации на поставку комплектующих изделий; разработка заданий на проектирование в смежных частях проекта.

Перечень документов, создаваемых на стадии «Технический проект» , определяется документом ГОСТ 34. 20189. и включает: Перечень входных данных Перечень выходных данных Ведомость оборудования и материалов Ведомость покупных изделий Схема организационной структуры Описание алгоритма Схема деления системы (структурная) Пояснительная записка к техническому проекту Описание автоматизируемых функций Описание постановки задач (комплекса задач) Описание информационного обеспечения системы

Перечень документов, создаваемых на стадии «Технический проект» Описание организации информационной базы Описание систем классификации и кодирования Описание массива информации Описание программного обеспечения Схема структурная комплекса технических средств Схема автоматизации Схема функциональной структуры Ведомость технического проекта

Стадия 2 Этап 3 Рабочий проект Рабочая документация. разработка рабочей документации на ИС и ее части; разработка и адаптация программ.

Рабочий проект содержит следующие документы 1. Ведомость документов рабочего проекта. 2. Обоснование дополнительных проектных решений, принятых после утверждения технического проекта и утвержденных в установленном порядке. 3. Уточненный расчет экономической эффективности системы по официальной методике. 4. Технология ввода и регистрации информации. 5. Формы первичных и промежуточных документов, заполняемы^' вручную и используемых для решения задач, с указанием маршрутов движения документов отдельно для каждой задачи. 6. Должностные инструкции, составляемые персонально для каждого должностного лица, участвующего в функционировании системы, с указанием действий в случае отказа технических средств АСУ. 7. Формы нормативно-справочной информации, инструкции по их заполнению и внесению изменений. 8. Альбом шифров, содержащий систему шифровки и альбом шифров

Рабочий проект 9. Программы организации и ведения массивов нормативно-справочной информации, включая тип ЭВМ и необходимый комплект внешних устройств, особенности организации и ведения массивов информации, описание программ, инструкции по перфорации входных документов и по эксплуатации программ. Кроме того, приводятся программы на машинных носителях. " 10. Рабочие программы и инструкции. По каждой задаче производится описание алгоритмов и рабочих программ, инструкции по перфорации оперативных входных документов и по эксплуатации программ, а также программы и контрольный пример с записью исходной информации на машинных носителях.

Рабочий проект 11. Характеристика комплекса технических средств, содержащая • спецификацию оборудования, описание и техническую характеристику всех устройств, перечень стандартных процедур работы с ними, схему функциональных связей устройств, схему и чертежи их размещения, принципиальные электрические схемы связи и питания. Характеристика охватывает как оборудование вычислительного центра, диспетчерских пунктов, так и периферийные технические средства, располагаемые в производственных помещениях. 12. В случае необходимости в рабочий проект включается также эксплуатационная документация на новые, нестандартные устройства, разработка которых выполнялась для данной системы, а также чертежи строительной части проекта и монтажа технических средств.

Стадия 3. Испытания и Ввод в действие. подготовка объекта автоматизации; подготовка персонала; комплектация ИС поставляемыми изделиями (программными и техническими средствами, программнотехническими комплексами, информационными изделиями); строительно-монтажные работы; пусконаладочные работы; проведение предварительных испытаний; проведение опытной эксплуатации; проведение приемочных испытаний.

Стадия 4. Сопровождение ИС. выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание.

Техническое задание на разработку

Техническое задание. Техническое задание регламентируется ГОСТ 19. 201 - 89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ. ГОСТ 34. 602 -89 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Содержание стадии- разработка и утверждение технического задания на создание ИС на основе предварительного обследования.

Содержание ТЗ Общие сведения Назначение : Цели и задачи системы. Характеристики объекта и процесса автоматизации. Архитектура системы Состав и содержание работ при разработке системы. Порядок контроля и приемки системы Требования составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Требования к документации Источники разработки

Общие сведения 1) полное наименование системы и ее условное обозначение; 2) шифр темы или шифр (номер) договора; 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы; 5) плановые сроки начала и окончания работы по созданию системы; 6) сведения об источниках и порядке финансирования работ; 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

Назначение и цели создания (развития) системы 1) назначение системы; 2) цели создания системы. В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п. ) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

Характеристики объекта автоматизации 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Требования к архитектуре 1) требования к системе в целом; 2) требования к функциям (задачам), выполняемым системой; 3) требования к видам обеспечения

требования к системе в целом требования к структуре и функционированию системы; требования к численности и квалификации персонала системы и режиму его работы; показатели назначения; требования к надежности; требования безопасности; требования к эргономике и технической эстетике; требования к транспортабельности для подвижных АС; требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; требования к защите информации от несанкционированного доступа; требования по сохранности информации при авариях; требования к защите от влияния внешних воздействий; требования к патентной чистоте; требования по стандартизации и унификации;

требования к структуре и функционированию системы

Требование к функциям (задачам)» , выполняемым системой 1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации; 2) временной регламент реализации каждой функции, задачи (или комплекса задач); 3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов; 4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

Требования к видам обеспечения приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы

Для информационного обеспечения системы 1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы; 3) к информационной совместимости со смежными системами; 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии; 5) по применению систем управления базами данных; 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 7) к защите данных от разрушений при авариях и сбоях в электропитании системы; 8) к контролю, хранению, обновлению и восстановлению данных;

технического обеспечения системы 1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе; 2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы

Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24. 601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

Порядок контроля и приемки системы 1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); 2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации; З) статус приемочной комиссии (государственная, межведомственная, ведомственная

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие. В перечень основных мероприятий включают: 1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; 2) изменения, которые необходимо осуществить в объекте автоматизации; 3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; 4) создание необходимых для функционирования системы подразделений и служб;

Требования к документированию 1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34. 201 -89 ; 2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД; 3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

Источники разработки должны быть перечислены документы и информационные материалы (техникоэкономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др. ), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Типовое проектирование ИС

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

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

Плюсы и минусы элементные ТПР: Библиотеки методо - ориентированных программ Плюс обеспечивается применение модульного подхода к проектированию и документированию ИС Минусы: большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости большие затраты времени на доработку ТПР отдельных элементов

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

Объектные ТПР Отраслевые проекты ИС Плюсы: комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости открытость архитектуры — позволяет устанавливать ТПР на разных программно-технических платформах масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест конфигурируемость — позволяет выбирать необходимое подмножество компонентов Минусы: проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации

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

Оценки ППП включают: назначение и возможности пакета; отличительные признаки и свойства пакета; требования к техническим и программным средствам; документация пакета; факторы финансового порядка; особенности установки пакета; особенности эксплуатации пакета; помощь поставщика по внедрению и поддержанию пакета; оценка качества пакета и опыт его использования; перспективы развития пакета.

Модельно-ориентированное проектирование Включает адаптацию состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия. Типовая ИС в специальной базе метаинформации - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

Организационное обеспечение разработок КИС

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

Характеристика процесса 1. Прежде всего, процесс проектирования КИС по своему характеру является творческим. Поэтому при отсутствии достаточно полного формализованного перечня операций проектирования и состояний проекта в процессе его разработки управление проектированием носит ситуационный характер. 2. Пользователь на этапе разработки системы может изменять требования к качеству системы, срокам и затратам проектирования. В связи с отсутствием общепринятых, надежных способов оценки качества проектных решений затруднен его контроль. 3. Стремление разработчиков к индивидуальному характеру труда приводит к невысокой степени организации контроля и координации деятельности отдельных разработчиков проекта.

Характеристика проекта Проект, как вид деятельности проектирующей организации, отличается следующими особенностями: - направлен на достижение конкретных целей; - включает в себя координированное выполнение взаимосвязанных действий; - имеет ограниченную протяженность во времени, с определенным началом и концом; - все проекты в определенной степени неповторимы и уникальны.

Характеристика организации - масштабы разработки КИС; - взаимосвязь различных по своей природе элементов проекта ЭИС (информационные, программные и технические средства обработки информации; экономико-математические модели; методы и средства проектирования; специалистыразработчики; элементы проекта системы и др. ); - различные факторы старения указанных элементов; - разный временной цикл существования и темпов обновления элементов; - длительность процесса проектирования системы; - индивидуальность проекта, обусловленная спецификой объекта проектирования; - коллективный характер труда многих специалистов различной квалификации

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

Проектирование как целенаправленный процесс Глобальной целью управления проектированием КИС является получение проекта с заданными пользователем параметрами. Ограничениями могут выступать сроки проектирования, требуемые ресурсы. Объектом управления является процесс проектирования КИС, как деятельность коллектива разработчиков системы, а также состояние используемых ресурсов.

Управление проектированием Управление проектированием, как правило, рассматривают в двух аспектах: организационном и функциональном. В организационном аспекте управление проектированием рассматривается по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования. В функциональном аспекте управление проектированием рассматривается как применение соответствующих методов и средств организации и ведения проектных работ.

Субъект управления проектированием КИС Выделение субъекта управления связано с разделением труда в группе специалистов в процессе проектирования КИС. Управление проектными работами в этом случае может осуществляться на нескольких уровнях: - руководства проектной организации; - руководства обеспечивающих подразделений (например, планово-производственного отдела и т. п. ); - руководства функциональными подразделениями; - руководителей проектов (главных конструкторов); - руководителей проектных групп (ответственных исполнителей). Организация работ по проектированию КИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком

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

Заказчик ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции: - формирует требования к системе и ее частям, - выдает техническое задание, финансирует разработку КИС, - обеспечивает проведение комплекса мероприятий по ее созданию, - проводит внедрение и прием проекта КИС. заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования КИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования.

Администратор ответственное лицо, которое выполняет эксплуатацию программно-технических средств и информационного и методологического обеспечения КИС (технологические и инструкционные карты), Администратор несет ответственность перед пользователем за правильность результатов работы КИС и их своевременность, а перед заказчиком и разработчиком за соблюдением условий эксплуатации, требований к технической документации

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

Схемы организаций разработчиков Существует несколько типов схем организации работ с участием четырех сторон, выбор которых зависит от объема проектируемой системы.

Схема организации при малом заказе заказ имеет небольшие размеры по стоимости и по продолжительности работ, например разработка локального АРМ или настройка типовой «коробчатой» системы, то в одном лице выступают заказчик, разработчик и администратор К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки. Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков: - отсутствует действенный контроль научно-технического уровня разработки, сроков выполнения работ; - не достигается высокого профессионального уровня разработчиков

Схема при малом заказе

Средний и большой заказ Для средних и больших заказов применяют схему, согласно которой функции разработчика отделяются от функций заказчика и администратора и выполняются другой организацией преимущества схемы - рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС; - возникает возможность привлечения к разработке ЭИС специализированных организаций (НИИ, СКБ). недостатки: - отсутствие прямой связи между разработчиком и пользователем, что создает трудности в своевременном получении и детализации исходных данных для проектирования; - возникают определенные трудности приеме проекта в эксплуатацию из-за желания администраторов получить методологическое обеспечение задач, соответствующее идеальным условиям эксплуатации, что в свою очередь требует больших сроков и объемов по доработке проекта

Схема

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

схема

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

Схема

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

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

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

Задачи консалтинговой фирмы консалтинговая фирма должна выдать качественную оценку сложившейся ситуации и/или ряд рекомендаций, после чего заказчику остается только использовать ее выводы. Обычно перед консалтинговой фирмой стоят две параллельные задачи: выработать заключения и рекомендации по всем рассматриваемым проблемам максимально объективно и квалифицированно произвести хорошее впечатление на руководство заказчика, чтобы поддержать репутацию и в конечном счете обеспечить дальнейшие заказы в своей области;

Примеры недобросовестных консультаций Пусть цель консалтингового исследования является сравнительный обзор рынка программных средств определенного назначения, с тем чтобы заказчик смог выбрать наилучший в его условиях программный пакет для внедрения. При этом, допустим, среди рассматриваемого десятка производителей ПО есть один, давно находящийся с консалтинговой фирмой в особо дружественных отношениях, тогда с высокой степенью вероятности можно ожидать, что будут выгодно подчеркнуты те аспекты, по которым “нужный” программный пакет выигрывает, и окажутся в тени аспекты, по которым он проигрывает остальным.

Проблемы аутсорсинга целесообразно и выгодно применять аутсорсинг тогда, когда речь идет о работах разовых или эпизодических. Там же, где работа имеет постоянный, жизненно важный для предприятия с технологической точки зрения характер (стратегическое планирование в области развития ИТ в компании; администрирование корпоративной сети и АИС; информационная безопасность и т. д. ), гораздо выгоднее и эффективнее держать от одного до нескольких высококвалифицированных специалистов. Очевидно, что далеко не каждая компания в состоянии (или считает целесообразным) хорошо оплачивать весь технический персонал. Но отказ от найма высокооплачиваемых ключевых специалистов и ориентация на тотальный аутсорсинг по сложным видам работ означает реализацию известной поговорки “скупой платит дважды, кроме того при любом аутсорсинге используются во всех смыслах чужие сотрудники, которые прямо не подчиняются руководству компании-заказчика и никак не заинтересованы в ее конечных успехах. А такая позиция не может не влиять на эффективность их работы. Мотивация собственного специалиста, отдающего себе отчет, что его работа достойно оплачивается именно за высокую квалификацию, и связывающего свое будущее с компанией, неизмеримо выше

Технологии управления качеством КИС

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

Стандарты качества. История стандартов качества ИСО 9000 восходит к Британским стандартам BSI 5750, которые были одобрены Британским институтом стандартов (British Standard Institute - BSI) в 1979 году. В свою очередь эти стандарты часто считаются восходящими к американским военным стандартам MIL-Q 9858, принятым в конце 50 -х годов в США. Стандарты серии ИСО 9000 - это пакет документов по созданию систем качества и обеспечению качества, подготовленный членами международной организации, известной как "ИСО/Технический Комитет 176" (ISO/TC 176). Ныне стандарт BSI 5750 известен как стандарт ИСО 9000 версии 1987 года.

Стандарты качества. все международные стандарты с номерами ИСО 9000 9004, в том числе все разделы (которые могут модифицироваться отдельно) стандарта ИСО 9000 и стандарта ИСО 9004; все международные стандарты с номерами ИСО 10001 10020, в том числе все их разделы; ИСО 8402 и в отдельных случаях - некоторые другие стандарты, определяющие специфическую деятельность поставщика. Три стандарта из серии ИСО 9000 (ИСО 9001, ИСО 9002 и ИСО 9003) являются фундаментальными документами Системы Качества, определяют методологию обеспечения качества и представляют собой три различные модели функциональных или организационных взаимоотношений между участниками системы качества (как правило "поставщик", "потребитель", "субконтрактор" или "субпоставщик").

Руководства можно разделить по направлениям: Подготовка руководства по качеству (Quality manual) и другой документации - ISO 10013 ("Руководящие указания по разработке руководств по качеству") и ISO 10016. Подготовка персонала и управления, проектирование - ISO 1005, ISO 1006, ISO 1007, ISO 10014, ISO 10015. Руководящие и специфические требования: ISO 40001, ISO 40002, ISO 13485 и другие и соответственно ГОСТ Р 40. 001 -96, ГОСТ Р 40. 002 -96, ГОСТ Р 40. 003 -96, ГОСТ Р 40. 00496, ГОСТ Р 40. 005 -96 и другие. Получившая система стандартов (точнее ее подмножество 9001 -9003) обладает определенной вложенностью, то есть каждый последующий стандарт определяет систему качества для более узкой области нежели предыдущей. Стандарты 9000 и 9004 определяю общие требования к системе качества и модели управления качеством.

Структура стандартов

Качество по Стандарту ИСО-9126 Функциональность Надежность Пригодность к использованию Эффективность Переносимость Сопровождаемость

Качество по Стандарту ИСО-9126 Функциональность Соответствие назначению Точность Способность взаимодействовать со средой Соответствие нормам Безопасность (защита от взлома данных и других преступных посягательств) Надежность Зрелость ("обкатанность") Отказоустойчивость Способность восстанавливаться после сбоев Пригодность к использованию Понимаемость Изучаемость Удобство и простота в работе

Качество по Стандарту ИСО-9126 Эффективность Быстродействие и время отклика Потребление ресурсов Сопровождаемость Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом) Пригодность к изменениям Стабильность Тестируемость Переносимость Адаптируемость Легкость инсталляции Соответствие нормам по переносимости и инсталляции Заменяемость (способность заменить аналоги? )

Процесс сертификации. Для того, чтобы получить свидетельство о соответствии системы качества стандартам ИСО 9000, необходимо пройти процесс сертификации. Так как сертификацию проходит система качества, то она должна быть предварительно создана на предприятии. В принципе предприятие может создать систему качества совершенно самостоятельно, не прибегая к помощи консультантов. Однако если предприятие не имеет опыта в такой деятельности, то полезно бывает пригласить специалиста уже на этом этапе, что позволит в будущем сократить количество сертификационных аудитов. Далее с помощью внешнего аудита качества предприятие должно удостовериться, что созданная система качества соответствует требованиям ИСО 9000 и, если это произошло, то она получает соответствующий сертификат. Обычно с первого раза пройти аудит не удается, так как в его ходе выявляются недостатки системы качества. На их устранение выделяется некоторое время, после которого аудит повторяется. Такой процесс считается нормальным и закладывается в проект сертификации. Проект сертификации является плодом совместной деятельности регистратора (специализированной компании, имеющей право проводить сертификацию) и компании-претендента. Обычно с 34 попытки сертификация проходит

Стоимость сертификации включает стоимость создания системы качества стоимость услуг по аудиту и фиксированная плата за сертификацию стоимость поддержания системы качества в актуальном состоянии и стоимость периодического аудита

Программное обеспечение и система качества. В системах качества о программных продуктах говорят в случаях: собственно поддержание системы качества (системы документооборота) поддержание качества процессов управления поддержание качества технологических процессов.

Требование ИСО 9000 Так как основное требование ИСО 9000 - это документированность процессов, то для поддержания документации и доведения ее до заинтересованных лиц, необходим как минимум текстовый редактор и система электронной почты. Лучше если конечно есть хоть какая-нибудь система документооборота, например MS Outlook и IBM Lotus Notes и Novel Group. Wize Если применено какое-нибудь средство автоматизации процессов управления (например ERP система соответствующего класса), то острота данной проблемы может быть несколько или совсем снята, так как такие системы по меньшей мере поддерживают так называемое "управление техническими изменениями" (engineering change order), что часто бывает достаточно для реализации внутреннего документооборота, связанного с изменениями продукции и технологии. Если имеется необходимость в системе качества описания бизнеспроцессов с помощью программных средств, то целесообразно использовать MS Visio

Total Quality Management. В настоящее время достигнуто понимание того, что стандарты серии ИСО 9000 обеспечив построение Системы качества на предприятии, не могут однако обеспечить во-первых ее совершенствование, вовторых удовлетворенность конечного потребителя, что является основным для рыночно ориентированной экономики. Для того, чтобы разрешить возникающие противоречия и создать всеобъемлющую концепцию качества как системы удовлетворения потребителя и разрабатываются концепции системы всеобщего управления качеством -TQM (Total Quality Management). Предполагается, что все новые стандарты управления качеством будут строиться на основании именно этой концепции

Базовые элементы. TQM. Вовлеченность высшего руководства Вовлеченность покупателя Разработка продуктов для качества Разработка производственных процессов исходя из требований качества. Контроль производственных процессов для достижения качества Развитие партнерских отношений с поставщиками Послепродажное обслуживание и после-производственный сервис. Вовлеченность работников в процесс управления качеством. Тестирование и стремление к постоянному улучшению, на основе достигнутых результатов.

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

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

Разработка производственных процессов исходя из требований качества. Производственные процессы рассматриваются в стандарте ИС-9000. Одна из основных задач этих стандартов, как раз установление, разработка производственных процессов для производства качественной продукции. Как основное требование стандартов можно сформулировать то, что должны быть четко разделены неконтролируемые факторы и такие, как возможное неправильное функционирование машин, некачественные материалы, неправильное выполнение рабочими своих обязанностей. Такие контролируемые факторы могут быть устранены в процессе внедрения системы ИС-9000.

Тестирование и стремление к постоянному улучшению Тестирование в данном случае имеется в виду, как тестирование по абсолютным показателям: проверка качества продукции и тестирование сравнимых образцов или рыночные тесты. Рыночные тесты это тестирование нескольких образцов разных производителей одинаковой продукции с целью выявления наиболее оптимальных решений и неформальный обмен опытом между конкурентами. Это широко практикуется в настоящее время и у нас, во всех разумно организованных производствах.

Стандарты АС и ПС Стандарт ISO 12207: 1995. Автоматизированная система по ISO и ГОСТ "По определению ISO 12207 - это базовый стандарт процессов жизненного цикла (ЖЦ) ПС, ориентированный на различные (любые!) виды ПС и типы проектов АС, куда ПС входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПС, он охватывает ЖЦ ПС от концептуализации идей до завершения ЖЦ. Стандарты фиксируют, что в понятие АС включены такие свойства/характеристики системы, как "потребности", "цели" и "люди", а также предполагают связь стандартов на АС и ПС.

Общие показатели качества и надежности ПС "По ISO 9126: 1991: рекомендуется использовать 6 основных групп характеристик качества ПС, детализируемых через 21 характеристику: функциональная пригодность (пригодность для применения, точность, защищенность, способность к взаимодействию, соответствие стандартам и правилам проектирования); надежность (уровень завершенности (отсутствия ошибок), устойчивость к ошибкам, перезапускаемость (повторновыполняемость)); применимость (понятность, изучаемость, простота использования); эффективность (ресурсная экономичность, временная экономичность); сопровождаемость (удобство для анализа, возможность модификации, стабильность, тестируемость); переносимость (адаптируемость, структурированность, замещаемость, внедряемость

Процессы и требования для обеспечения качества "В ISO 12207 описаны 8 вспомогательных процессов, которые поддерживают реализацию какого-либо основного процесса (например, "создание ПС"), будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПС. Это процессы: "решение проблем", "документирование", "управление конфигурацией", "гарантирование качества". Последний использует результаты остальных процессов группы обеспечения качества, в которую входят процессы: "верификация", "аттестация", "совместная оценка", "аудит".

требований к АС предусматривается, что: рассматривается область применения для определения требований системы (к системе); спецификация требований системы должна описывать: функции и возможности системы, бизнес -требования, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования; квалификация требований системы должна быть документирована.

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

Инструментарии управления проектами КИС

Инструментарии управления проектами представляют собой организационно-технологический комплекс методических, технических, программных и информационных средств, направленный на поддержку и повышение эффективности процессов планирования и управления проектом. Инструментарии управления проектами содержит набор функциональных средств, которые помогают менеджеру планировать работы, временные, ресурсные и стоимостные оценки выполнения комплекса работ, а затем, в процессе выполнения, отслеживать ход работ и корректировать план. Функциональных средства, реализующие взаимосвязанные методы, являются основой для информационных систем, которые моделируют комплекс работ и потребности в ресурсах. Эти методы используют оценки требуемых объемов работ, и позволяют менеджеру регулировать выполнение работ по времени, стоимости, составу работ, качеству и организационной структуре исполнения

ИС управления проектом Основные преимущества использования информационной системы для управления проектами включают: - централизованное хранение информации по графику работ, ресурсам и стоимости - возможности быстрого анализа влияния изменений в графике, ресурсном обеспечении финансировании на план проекта; - возможность распределенной поддержки и обновления данных в сетевом режиме; - возможности автоматизированной генерации отчетов и графических диаграмм, разработки документации по проекту.

Типовой состав задач Структуризация и описание состава и характеристик работ, ресурсов, затрат и доходов проекта. Расчет расписания исполнения работ проекта с учетом всех имеющихся ограничений. Определение критических операций и резервов времени для исполнения других операций проекта. Расчет бюджета проекта и распределение запланированных затрат во времени. Расчет распределения во времени потребности проекта в основных материалах и оборудовании. Определение оптимального состава ресурсов проекта и распределения во времени их плановой загрузки. Анализ рисков и определение необходимых резервов для надежной реализации проекта. Определение вероятности успешного исполнения директивных показателей. Ведение учета и анализ исполнения проекта. Моделирование последствий управленческих воздействий с целью принятия оптимальных решений. Ведение архивов проекта. Получение необходимой отчетности.

Состав инструментариев Системы управления корпоративными проектами старшего класса Системы управления проектами среднего уровня Специализированные продукты и продукты, ориентированные на определенный рынок

Системы управления проектами старшего класса КИС Artemis International Solutions (www. artemispm. com) Состав: View. Point: управление проектами и организация взаимодействия на базе технологий Web; Portfolio. Director: анализ и управление портфелями проектов. Niku(www. niku. com) Состав: Portfolio Manager: планирование, оценка, составление календарного расписания, управление ресурсами, создание шаблонов для организации взаимодействия и формирования методологии; Director: высокоуровневое обобщение проектов и организация контроля со стороны высшего руководства; Revenue Manager: расчет времени реализации проекта и необходимых затрат, управление документооборотом, планирование доходов

Системы управления проектами старшего класса Plan. View (www. planview. com): Plan. Viewуправление проектами, затратами и временными параметрами. Primavera Systems (www. primavera. com). Состав: Team. Play- управление ИТ-проектами; Enterprise- управление корпоративными проектами и анализ портфеля; Expedition- управление договорами и документами.

управления проектами среднего уровня Advanced Management Solutions (www. amsrealtime. com) Real. Time Projects- составление расписаний и управление затратами ; Real. Time Resources- управление ресурсами Pacific Edge Software (www. pacificedge. com) Project Office: управление портфелем проектов. Business Engine Software (www. businessengine. com) Business Engine Network: оперативное управление портфелем проектов на основе технологий Web, управление финансами и бюджетирование, управление взаимоотношениями и договорами с партнерами, учет временных параметров и затрат. Интегрируется с программным обеспечением Microsoft Project 2002 с целью организации детального управления проектами и управления корпоративными ресурсами Microsoft (www. microsoft. com): Project 2007: планирование проектов, составление расписаний, контроль за ходом выполнения поставленных задач Project Standard: обновленная версия Project 2007 Project Professional и Project Server: поддержка новых функций корпоративного анализа и управления ресурсами

Специализированные продукты Rational Software (www. rational. com) Продукты для поддержки управления проектами, анализа требований, программирования, моделирования, тестирования и оформления документации QSM (www. qsm. com) Продукты для составления расписаний и оценки затрат, контроля за ходом реализации проекта, эталонного тестирования и определения параметров улучшения процесса, а также для адаптивного прогнозирования Software Productivity Research (www. spr. com) Инструментальные средства для качественной оценки, эталонного тестирования и функционального анализа

Microsoft Project

Microsoft Office Project 2007 – это комплексное решение корпорации Microsoft по управлению корпоративными проектами, которое позволяет управлять проектами любой сложности и включает в себя семейство следующих программных продуктов: MS Office Project Standart – пакет начального уровня для управления простыми проектами; MS Office Project Professional – пакет для профессионального управления проектами любой сложности на любом уровне управления; MS Office Project Server – серверный продукт, который используется для взаимодействия менеджеров проекта при управлении распределенными проектами; MS Office Project Web Access – веб-интерфейс MS Project, позволяющий участникам проектов получить доступ к проектной информации через Internet Explorer.

Задачи решаемые Ms Office Project 2007 Структуризация и описание состава и характеристик работ, ресурсов, затрат и доходов проекта. Расчет расписания исполнения работ проекта с учетом всех имеющихся ограничений. Определение критических операций и резервов времени для исполнения других операций проекта. Расчет бюджета проекта и распределение запланированных затрат во времени. Расчет распределения во времени потребности проекта в основных материалах и оборудовании. Определение оптимального состава ресурсов проекта и распределения во времени их плановой загрузки. Анализ рисков и определение необходимых резервов для надежной реализации проекта. Ведение учета и анализ исполнения проекта. Получение необходимой отчетности.

Окно Microsoft Office Project 2007 состоит из следующих элементов: строка меню; панели инструментов; строка ввода; панель представлений; рабочая область; строка состояния.

Комментарии Строка ввода предназначена для ввода и редактирования данных в ячейки таблиц Панель представлений используется для переключения между представлениями рабочей области окна. Все данные о проекте хранятся в единой базе данных, состоящей из большого количества полей. Представление – это способ отображения части связанных между собой данных из общей базы данных проекта. В системе реализовано достаточно большое количество представлений – диаграмма Ганта, сетевой график, календарь, график ресурсов и т. д. При желании можно изменять стандартные представления, добавляя или удаляя отображаемые в их таблицах поля данных. Рабочая область предназначена для отображения выбранного представления. Она может содержать таблицы, диаграммы, графики, формы и используется как для просмотра, так и для редактирования данных проекта.

создания нового проекта следует выбрать пункт меню Файл/Создать. Будет создан пустой проект с пустой базой данных. Прежде всего необходимо задать ключевые параметры проекта в окне сведений о проекте (пункт меню Проект/Сведения о проекте). Установки этого пункта имеют определяющее значение для всего последующего процесса планирования.

Календарь(настройки проекта) Поле Календарь устанавливает календарь (график) рабочего времени, используемый по умолчанию при планировании работ. В качестве такового следует использовать календарь, по которому работает большинство сотрудников, занятых в проекте. В системе предопределены три базовых календаря: стандартный – соответствует 40 -часовой рабочей неделе с часовым перерывом и выходными в субботу и воскресенье. Рабочим считается время с 9 до 18 часов; 24 часа – непрерывный календарь рабочего времени без перерывов и выходных. Используется для планирования непрерывных технологических процессов (например, выплавка стали); ночная смена – календарь, в котором используется 40 -часовая рабочая неделя, но рабочим считается время с 23 до 8 часов с часовым перерывом. Предопределенные календари могут не соответствовать графику работы организации, поэтому менеджер проекта имеет возможность изменить предопределенный календарь или создать свой собственный.

Настройка рабочего времени

планирование работ в системе Microsoft Project Работы проекта могут быть нескольких видов: обычная работа (задача); веха; фаза; суммарная задача проекта.

Определения Работа обозначает какие-то действия, направленные на выполнение некоторой части проекта. Веха – это работа нулевой длины. Вехи предназначены для фиксации в плане проекта контрольных точек, в которых происходят важные с точки зрения управления проектом события. Например, завершение одного этапа работ и начало другого. Обычно вехи используются для обозначения начала и окончания проекта, а также для обозначения конца каждой фазы. Фаза – это составная работа, состоящая из нескольких работ и завершаемая вехой. Фаза описывает определенный логически законченный этап проекта и может состоять как из работ, так и из других фаз. Для разграничения работ и фаз в системе принято следующее правило. Все работы разделены на уровни, задающие их иерархию. Любая работа, имеющая подчиненные работы низшего уровня, является фазой. Все остальные работы фазами не являются. Суммарная задача проекта – это искусственно создаваемая системой работа, длительность которой равна длительности всего проекта. Эта работа используется для вычисления, отображения и анализа обобщенных данных о проекте, используемых им ресурсах и его стоимостных характеристиках.

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

Составление перечня задач начинается с выделения этапов проекта. Каждому этапу будет соответствовать фаза. При необходимости, особенно для крупных проектов, этапы могут разделяться на более мелкие этапы. В этом случае фаза будет состоять из более мелких фаз. Когда перечень этапов готов, составляется список задач, выполняемых на каждом этапе. В качестве последней работы этапа используется задача нулевой длины, которой соответствует веха.

Ввод перечня задач проекта выполняется в любом из представлений, имеющем таблицу для ввода данных. Лучше всего для этого подходит Диаграмма Ганта, в которой помимо таблицы отображается календарный график проекта. Для ввода задачи достаточно в пустой строке таблицы ввести ее название в столбец Название задачи. По умолчанию длительность новой задачи принимается равной одному дню, а дата начала задачи – дате начала проекта. Рядом с величиной длительности изображается вопросительный знак, что говорит о том, что это значение длительности является предварительным и задано системой. После назначения длительности пользователем вопросительный знак исчезает.

Для преобразования задачи в веху достаточно установить нулевую длительность работы. Для преобразования задачи в фазу нужно выполнить следующие действия: проверить правильность расположения названия фазы и названий входящих в нее задач (они должны быть расположены непосредственно после фазы); выделить все входящие в фазу задачи, используя в качестве области выделения номера задач (кроме самой фазы); нажатием кнопки (увеличить отступ) выделенные задачи помещаются на один уровень иерархии ниже и подчиняются первой предшествующей им не выделенной задаче, которая становится фазой.

Создание связей между задачами выполняется как непосредственно в календарном графике, так и в таблице ввода данных. На календарном графике следует навести указатель мыши на значок задачи, нажать левую кнопку мыши и, не отпуская ее, переместить указатель на значок другой задачи, после чего отпустить мышь. Между ними будет установлена связь. Связывание задач в таблице ввода данных выполняется при помощи столбца Предшественник, в который вводятся номера непосредственно предшествующих задач, разделенные точкой с запятой Создание линейной последовательности связей : выделить в таблице все последовательно связываемые задачи: выбрать пункт меню Правка/Связать задачи и – связи устанавливаются в соответствии с последовательностью выделения задач.

Назначение длительности задач можно выполнить двумя способами: изменить значение в столбце Длительность таблицы ввода данных; двойным щелчком мыши по строке задачи открыть окно Сведения о задаче и на вкладке Общие установить значение длительности. По умолчанию длительность задается в днях. Однако единицу измерения можно изменить, указав ее рядом с числовым значением. Например, 10 д означает 10 дней, 10 ч – 10 часов, 10 м – 10 минут, 10 мес – 10 месяцев.

Уточнение типа связей и ввод значений задержек или опережений Первый способ – двойной щелчок мыши по линии со стрелкой, обозначающей связь между задачами на календарном графике. В открывшемся окне Зависимость задач имеется всего два поля: тип и запаздывание. Тип принимает одно из четырех значений: ОН (окончание–начало), НН (начало–начало), ОО (окончание–окончание), НО (начало–окончание). Запаздывание задается числом и единицей измерения, аналогично длительности задачи. Положительное значение запаздывания означает задержку работы-последователя, отрицательное значение – опережение. Помимо двух полей окно имеет кнопку Удалить для удаления связи. Этот способ не очень удобен тем, что при большом количестве работ и связей между ними найти нужную связь на календарном графике может оказаться непросто. Второй способ – окно Сведения о задаче (двойной щелчок мыши по строке задачи), на вкладке Предшественники которого находится таблица с перечнем всех задач-предшественников. Столбцы Тип и Запаздывание этой таблицы устанавливают свойства соответствующей связи. Для удаления связи нужно в качестве типа связи выбрать значение Нет. Третий способ – редактирование связей при помощи формы. Этот способ применяется, когда требуется редактировать большое количество связей.

Дата начала/окончания проекта устанавливается в окне сведений о проекте, После ее изменения система автоматически перепланирует проект с учетом нового значения. Ограничения, крайние сроки и календари задач устанавливаются в окне Сведения о задаче на вкладке Дополнительно

Ограничения на выполнение задач Ограничение задается полями Тип ограничения и Дата ограничения. В эти поля вводятся соответственно тип ограничения и дата, в том случае, когда тип ограничения требует указать конкретную дату. Крайний срок вводится в поле Крайний срок. Задача, для которой установлено ограничение помечается значком в столбце идентификаторов таблиц представлений. Установленный крайний срок обозначается значком на диаграмме Ганта Календарь задачи выбирается из числа базовых календарей в поле Календарь. По умолчанию это поле содержит Нет. В этом случае задача планируется по стандартному календарю и календарю назначенных на нее ресурсов. Если указать календарь задачи, она будет планироваться на периоды времени, которые являются рабочими как в календаре задачи, так и в календаре ее ресурсов. В этом же окне имеется поле Код СДР, которое содержит уникальный код задачи в структуре проекта. По умолчанию этот код автоматически формируется системой. Пользователь сам может определить порядок формирования кода СДР при помощи пункта меню Проект/СДР/Определить код.

Повторяющиеся задачи Добавление в проект повторяющейся задачи выполняется при помощи пункта меню Вставка/Повторяющаяся задача, который открывает окно ее свойств задающее сроки и периодичность повторения. В качестве примера используется задача Профилактика, которая имеет длительность один день, проводится раз в две недели с 30 июня по 30 сентября.