Затонский А.В. Пособие по полному жизненному циклу информационных систем
Подождите немного. Документ загружается.
341
Современные средства поддержки разработки (см. ниже) включают в
себя автоматизированные средства планирования и отчетности с различными:
• формой и структурой планов и отчетов;
• периодичностью и сроками подготовки отчетов;
• формой и структурой контроля текущего состояния разработки.
Программное обеспечение для управления проектами традиционно
разделяется на профессиональные системы и системы для массового
пользователя.
Профессиональные системы предоставляют гибкие средства реализации
функций планирования и контроля, но требуют больших затрат времени на
подготовку и анализ данных и соответственно высокой квалификации
пользователей. Системы для массового пользователя адресованы
пользователям-непрофессионалам, для которых управление проектами не
является основным видом деятельности. От пользователей, использующих
пакеты планирования лишь время от времени при необходимости спланировать
небольшой комплекс работ или ввести фактические данные по проекту, нельзя
ожидать серьезных затрат времени и усилий на то, чтобы освоить и держать в
памяти какие-либо специфические функции планирования или оптимизации
расписаний. Для них более важным является простота использования и
скорость получения результата.
В настоящее время даже относительно дешевые системы способны
поддерживать планирование проектов, состоящих из десятков тысяч задач и
использующих тысячи видов ресурсов. Основные различия между системами
проявляются в реализации функций ресурсного планирования и
многопроектного планирования и контроля. Возможности эффективного
внедрения системы управления проектами во многом зависят от возможностей
настройки системы на специфические показатели конкретных проектов,
гибкости средств обмена данными, возможностей стандартизации
управленческой среды и обеспечения групповой работы с данными проекта.
Microsoft Project (рис. 176, 177) и Time Line – недорогие системы
управления проектами, просты в использовании, доступны для новичков и
непрофессионалов. Они содержат базовые возможности, позволяющие
осуществлять достаточно гибкое планирование и управление людскими
ресурсами, поддерживают несложное многопроектное планирование и
контроль.
Microsoft Project 2003 – один из лидеров по возможностям объединения
участников проекта средствами электронной почты или Интранет. При
описании ресурса для каждого исполнителя может быть указан адрес его
электронной почты. Информация о работах проекта может сохраняться в
формате HTML и публиковаться на внутреннем Web-сервере. Кроме
стандартных форматов файлов Microsoft Project (MPP и МРХ) пользователь
может сохранять информацию о проекте в форматах ODBC, Excel и Access.
Формат MPD (Microsoft Project Database) позволяет хранить все данные о
проекте в структуре, доступной как из Microsoft Project, так и из Access.
342
Что касается Time Line, то система позволяет хранить все данные,
касающиеся проектов организации, в единой базе данных. Отдельный модуль
импорта/экспорта позволяет обмениваться данными с другими системами
(Microsoft Project, Time Line 1.0 for Windows), базами данных (dbf) и
электронными таблицами. Система Time Line 6.5 поддерживает стандарты
ODBC, OLE 2.0, DDE и макроязык Symantec Basic.
Однако возможности недорогих систем, к которым относятся Microsoft
Project и Time Line, не позволяют в полной мере реализовать режим
многопользовательской работы с информацией проекта, поскольку не
обеспечивают режим распределенного ввода данных и системы ограничения
доступа к данным.
Open Plan Professional (Welcom Software) – представитель класса
профессиональных систем. Одним из основных отличий системы являются
мощные средства ресурсного и стоимостного планирования, которые
позволяют значительно облегчить задачу нахождения наиболее эффективного
распределения ресурсов и составления их рабочего расписания. Кроме того,
пользователями интегрированной системы управления проектами организации
являются как профессиональные менеджеры, осуществляющие согласование и
оптимизацию планов проектов, анализ рисков, прогнозирование и т.д., так и
участники проектов, выполняющие сбор, уточнение и актуализацию данных,
готовящие отчеты. Если для профессионалов важны мощность и гибкость
предоставляемых системой функций планирования и анализа состояния
проектов, то для остальных пользователей важнее простота и прозрачность
системы. Open Plan обеспечивает как полную интеграцию между
профессиональной и настольной версиями системы, так и открытость для
обмена данными с внешними приложениями.
Open Plan поставляется в двух вариантах (Professional и Desktop), каждый
из которых отвечает различным потребностям исполнителей, менеджеров и
других участников проекта. Обе версии работают с одной базой данных.
Совместное использование профессиональной и «облегченной» версий системы
управления проектами дает возможность не только учесть потребности всех
групп пользователей, но и значительно снизить стоимость решения.
Open Plan обладает прямым доступом к базам данных. Пользователь
может выбрать, в каком формате хранить данные по проектам (в собственном
формате Open Plan, в форматах Oracle, SQL Server, Sybase, xBase).
Open Plan обеспечивает ограничение доступа к данным проекта,
предоставляя различные права на доступ к определенным данным, делая их
доступными ограниченному кругу лиц и регулируя их совместное
использование. Средство "Директор управления проектами", встроенное в Open
Plan, позволяет упорядочить применение стандартных элементов проектов и
процедур. В Open Plan предлагается 65 моделей, построенных на базе
руководств PMI (Project Management Institute - Институт проектного
менеджмента, США), которые можно настроить для создания документов,
отвечающих требованиям стандартов ISO.
343
Рис. 127. Пример оформления состояния проекта в MS Project
344
Рис. 128. Пример оформления состояния разработки релиза в MS Project
345
Рис. 129. Пример оформления базы данных состояния разработки в MS Access.
346
Однако существует обоснованное мнение, что высокая квалификация
проектантов и разработчиков вполне позволяет ограничиться средствами
электронных таблиц, особенно при поддержке одиночных или небольших
проектов. Могут использоваться также более продвинутые средства, например,
все функции проекта с указанием сроков, ответственных и т.п. могут быть
сведены в таблицы базы данных в MS Access (рис. 178), MS Source Safe и
другие.
Совместное использование ресурсов
Совместному использованию подлежит дисковое пространство в одном
из вариантов:
• хранение файлов проекта на разделе файлового сервера с организацией
доступа к ним разработчиков с их рабочих мест;
• репликация файлов с локальных дисков разработчиков на сервер;
Рис. 130. Пример названий папок при совместной разработке
В любом случае встает вопрос синхронизации работы разработчиков.
Необходимо чтобы:
1. разработчики получали информацию о деятельности других разработчиков:
1.1. уведомлениями по электронной почте;
1.2. уведомлением в тексте специального документа на файловом сервере;
347
1.3. на собраниях (происходит обмен информацией);
1.4. на семинарах (происходит обмен информацией и рецензирование кодов
и документов);
1.5. с использованием автоматизированной системы, обеспечивающей
блокирование одновременного редактирования и слияние документов
(их частей).
2. не допускалась одновременная работа нескольких разработчиков над одним
документом, чего можно достичь:
2.1. применением графика использования рабочих мест;
2.2. фиксированием правил совместной работы над файлами и, особенно,
документацией;
2.3. применением автоматизированных систем коллективной разработки.
Простым и эффективным средством поддержки совместного
использования ресурсов является продуманная структура каталога проекта с
«говорящими» названиями папок (рис. 179), что, отчасти, позволяет
структурировать все файлы проекта и отслеживать их изменения безо всяких
автоматизированных систем.
Аттестация программного средства
Завершающим этапом разработки ИС является аттестация ИС,
подводящая итог всей разработке. Аттестация (certification) ИС − это
авторитетное подтверждение качества ИС. Обычно для аттестации ИС
создается аттестационная комиссия из экспертов, представителей заказчика и
представителей разработчика. Эта комиссия проводит приемо-сдаточные
испытания ИС с целью получения необходимой информации для оценки его
качества. Под испытанием ИС здесь понимают процесс проведения комплекса
мероприятий, исследующих пригодность ИС для успешной его эксплуатации
(применения и сопровождения) в соответствии с требованиями заказчика. В
этом процессе проверяется полнота и исследуется качество представленной
программной документации, производится необходимое тестирование
программ, входящих в состав ИС, а также исследуются и другие свойства ИС,
декларированные в его спецификации качества. На основе полученной
информации комиссия должна установить, в какой степени ИС выполняет
декларированные функции и в какой степени ИС обладает декларированными
примитивами и критериями качества. Решение аттестационной комиссии о
произведенной оценке качества ИС фиксируется в соответствующем документе
(сертификате), который подписывается членами комиссии.
Таким образом, оценка качества ИС является основным содержанием
процесса аттестации. Прежде всего, следует отметить, что оценка качества ИС
производится по предъявленной спецификации его качества, т.е. оценивается
только декларированное разработчиками качество ИС. При этом оценка
качества ИС по каждому из критериев сводится к оценке каждого из
примитивов качества, связанному с этим критерием качества ИС, в
348
соответствии с их конкретизацией в спецификации качества. Различают
следующие группы методов оценки примитивов качества ИС:
• непосредственное измерение показателей примитива качества;
• тестирование программ ИС;
• экспертная оценка на основании изучения программ и документации
ИС.
Непосредственное измерение показателей примитива качества
производится путем проверки соответствия предъявленной документации
(включая тексты программ на языке программирования) стандартам или явным
требованиям, указанным в спецификации качества ИС, а также путем
измерения времени работы различных устройств и используемых ресурсов при
выполнении контрольных (тестовых) задач. Например, некоторым показателем
эффективности по памяти может быть число строк программы на языке
программирования, а некоторым показателем временнóй эффективности может
быть время ответа на запрос пользователя.
Для оценки некоторых примитивов качества ИС используется
тестирование. К таким примитивам относятся, прежде всего, завершенность
ИС, а также его точность, устойчивость, защищенность и другие примитивы
качества. Однако во время приемо-сдаточных испытаний нет необходимости
проведения тестирование ИС в полном объеме (это может слишком дорого
стоить). Аттестационная комиссия должна, прежде всего, изучить
предъявленную документацию по проведенному разработчиками тестированию
ИС и лишь выборочно пропустить предъявленные тесты. Дополнительные
тесты составляются, если у комиссии возникают определенные сомнения в
полноте тестирования, проведенного разработчиками. Кроме того, обычно
работоспособность и некоторые показатели качества ИС демонстрируются на
решении контрольных задач, предъявляемых заказчиком.
В некоторых случаях для оценки качества ИС проводятся
дополнительные полевые или промышленные испытания. Полевые испытания
ИС – это демонстрация ИС вместе с технической системой, которой управляет
эта ИС, с обеспечением тщательного наблюдения за поведением ИС.
Заказчикам должна быть предоставлена возможность задания собственных
контрольных примеров, в частности, с выходом в критические режимы работы
технической системы, а также с вызовом в ней аварийных ситуаций.
Промышленные испытания ИС – это процесс передачи ИС в постоянную
эксплуатацию пользователям, представляющий собой опытную эксплуатацию
ИС пользователями со сбором информации об особенностях поведения ИС и ее
эксплуатационных характеристиках.
Многие примитивы качества ИС трудно уловимы с точки зрения их
(объективной) оценки. В этих случаях иногда применяют метод экспертных
оценок. Этот метод заключается в следующем. Назначается группа экспертов и
каждый из этих экспертов в результате изучения представленной документации
составляет свое мнение об обладании ИС требуемым примитивом качества.
Затем голосованием членов этой группы устанавливается оценка требуемого
примитива качества ИС, т.е. получаемая оценка является некоторым
349
усреднением совокупности субъективных оценок. Эта оценка может
производиться как по двухбалльной системе («обладает» − «не обладает»), так
и учитывать степень обладания ИС этим примитивом качества (например,
производиться по пятибальной системе) в соответствии с требованиями
относительно этого примитива, сформулированными в спецификации качества
аттестуемого ИС.
Аттестация ИС похожа на смотр различных компонент ИС в процессе
управления качеством ИС, однако, имеются и существенные различия. Во-
первых, смотр проводится менее представительной группой специалистов. Во-
вторых, в процессе смотра не производится полной оценки качества ИС, а
выявляются лишь отдельные просчеты и нарушения требований относительно
качества ИС, связанные с обозреваемой компонентой (документом), при этом
не требуется немедленного устранения выявленных недостатков, если они не
мешают проведения последующих работ. Целью же аттестации является
проверка и фиксация реальных показателей качества предъявленного ИС. Если
аттестационная комиссия подтверждает, что предъявленное ИС соответствует
всем требованиям относительно его качества, сформулированным во внешнем
описании этого ИС, то считается, что его разработка завершена успешно и
заказчик обязан принять это ИС. Если же будут обнаружены отступления от
этих требований, то должны приниматься определенные решения о
продолжении или прекращении разработки предъявленного ИС, но это уже
вопрос взаимоотношений между заказчиком и разработчиками. Таким образом,
аттестационная комиссия, подписывая документ о произведенной оценке
качества ИС, принимает на себя определенную ответственность за гарантию
качества этого ИС. Но здесь имеются определенные правовые проблемы,
обсуждение которых выходит за рамки обсуждаемого вопроса.
Инсталляция и внедрение ИС
Последовательность стадий внедрения
Существует несколько подходов к автоматизации предприятий. Наиболее
правильным, грамотным подходом считается так называемый «западный» [13].
Изначально, он развился и оформился в более развитых (в области управления)
странах, и теперь осуществляются попытки его применения на российских
предприятиях.
За основу подхода можно взять следующее утверждение: Автоматизация
процессов предприятия должна вытекать из стратегии развития
предприятия и быть эффективной. Другими словами, автоматизировать нужно
только те задачи, которые способствуют достижению цели предприятия. При
этом каждая задача автоматизации должна быть оценена с позиции
Цена/Эффективность.
Этот подход действительно можно назвать правильным, даже идеальным.
Суть его заключается в следующем:
• Исходя из целей и стратегии предприятия выделяются бизнес-
процессы, требующие качественного улучшения.
350
• Для каждого выделенного бизнес-процесса ставится задача
автоматизации, позволяющая повысить эффективность работы
процесса.
• Предполагаемый эффект от задачи автоматизации оценивается заранее
и сравнивается с величиной затрат на ее реализацию.
• Реорганизация и автоматизация бизнес-процессов предприятия.
При таком подходе основными задачами, требующими автоматизации на
предприятиях, будут те, эффект от реализации которых можно оценить
наиболее явным образом:
• Задачи планирования ресурсов предприятия (материальных, трудовых,
финансовых) – уменьшение затрат, связанных с использованием
ресурсов.
• Управление отношениями с клиентами – привлечение новых и удержание
существующих клиентов.
• Конструкторско-технологические процессы – уменьшение стоимости и
повышение качества конструкторско-технологических разработок.
Понятно, что при этом подходе задачи учета и контроля будут являться
вторичными, поскольку связать их с целями компании и оценить их эффект
очень сложно. Задачи учета и контроля в этом случае скорее являются
неотъемлемой частью задач планирования и анализа, чем-то, что
подразумевается по умолчанию.
Именно на этих предпосылках основаны комплексные информационные
системы, поддерживающие стандарты ERP (планирование ресурсов
предприятия), CRM (управление взаимоотношениями с клиентами), CAD/CAM
системы.
Все плюсы такого подхода вытекают из его описания. Теперь рассмотрим
минусы этого подхода при применении его на российских предприятиях:
• На очень немногих российских предприятиях сформулированы цели и
стратегия. Поэтому о согласованности задач автоматизации и целей
предприятия говорить сложно. Значит, для применения означенного
выше подхода к автоматизации на предприятии необходима разработка
стратегии, возможно, с привлечением сторонних консультантов, и
перестройки всей системы стратегического планирования. Как это ни
печально, но менеджмент и собственники многих российских
предприятий к таким преобразованиям пока не готовы.
• Реализация задач автоматизации планирования ресурсов, управления
отношениями с клиентами на российских предприятиях зачастую требует
серьезной перестройки бизнес-процессов предприятия (реинжиниринг),
что, опять же, требует серьезных материальных, временных затрат и,
конечно же, готовности к преобразованиям персонала и менеджмента
предприятия.
• Стоимость применения комплексных средств автоматизация,
направленных на автоматизацию задач планирования и управления пока
что является «неподъемной» для Российских предприятий, особенно если