Организация труда при разработке АИС
Важной стороной реализации проекта АИС является правильная организация исследовательских и проектных работ – проведение мероприятий, обеспечивающих рациональную работу каждого работника на своём участке с целью обеспечения создания запланированной АИС, способной эффективно удовлетворять запросы её пользователей. Для успешной реализации проекта необходимо устанавливать реальные этапы с чётко обозначенными началом и окончанием их. Разработка детального плана работ связана с описанием того, как и что будет выполняться на каждом этапе, какие потребуются для этого средства и ресурсы. В этом случае можно максимально избежать упущений и ошибок.
Действия и необходимые ресурсы для проведения проектирования АИС укрупнёно определяются в виде основных компонентов проекта и групп ресурсов. Их детализация проводится при дальнейшей разработке проекта.
Учитывая особенности мыслительной деятельности человека, процесс последовательного выполнения операций разработчиками программ получил называние пошаговой детализации. Она заключается в первоначальном выражении логики программы в терминах гипотетического языка «очень высокого уровня» с последующей детализацией каждого предложения в терминах языка более низкого уровня. Итак до тех пор, пока не будет достигнут уровень используемого языка программирования (важное свойство структурного программирования).
После анализа целей проект должен быть готов для проведения детального планирования, в результате чего может потребоваться уточнение принятых ранее формулировок целей, действий ресурсов.
При разработке АИС на основе указанных выше принципов программный комплекс строится как совокупность ряда модулей. Каждый модуль сис-темы относительно самостоятелен в решении своей прикладной задачи. Разбиение АИС на модули является одним из элементов обеспечения безопасного использования информации и представляет собой дополнительный способ санкционирования доступа, поскольку каждый модуль работает только с разрешёнными для него данными из корпоративной базы данных.
С точки зрения разработчика, модульная структура информационной системы отвечает современным тенденциям в разработке сложных про-граммных систем – объектно-ориентированному проектированию, компонентному подходу, независимости от среды разработки и платформы использования программного продукта.
Модульная структура системы обеспечивает возможность конструировать и настраивать автоматизированные рабочие места пользователей в соответствии с изменением их функциональных обязанностей. Гибкие средства настройки позволяют описывать специфику функционирования предприятия, требования конкретного пользователя, оперативно учитывать изменения в законодательстве без привлечения специалистов разработчиков. Система обеспечивает уровень надёжности, необходимый для работы в реальном масштабе времени. Общесистемный пользовательский интерфейс позволяет персоналу с минимальным уровнем подготовки освоить работу с системой в кратчайшие сроки, а с ростом квалификации использовать расширенный набор функций системы. Модульность построения информационных систем и принцип одноразового ввода дают возможность гибко варьировать компонентным составом этих систем.
Модульная структура АИС в совокупности с соответствием принципам открытых систем, подразумевающих построение системы на основе и с использованием общепринятых средств разработки, интерфейсов обмена данными, стандартных сетевых протоколов, механизмов взаимодействия программного обеспечения, означает также возможность максимально полно использовать имеющиеся в организации программы автоматизации участков деятельности путём их интеграции в единую систему, или путём использования соответствующих данных.
Модульность означает также возможность поэтапного внедрения. На начальном этапе компоненты системы устанавливаются, например, на рабочие места, в первую очередь нуждающиеся в компьютеризации. На втором этапе происходит расширение системы за счёт подсоединения новых модулей и охвата новых участков деятельности. При таком подходе меньше нагрузка на организацию в связи с освоением системы, легче решаются многие проблемы психологического плана (например, эффекты неприятия нововведений), на основе накапливаемого персоналом опыта отрабатываются рациональные схемы внедрения и т.д.
Для успешной реализации проекта и оценки его результатов важно четко сформулировать основные предположения и факторы риск, не поддающихся контролю со стороны менеджмента проекта и могущих оказать серьезное отрицательное влияние на выполнение проекта.
Для эффективного управления ходом реализации проекта и оценки степени достижения его целей необходимо определить соответствующие показатели, способы и источники информации для их измерения. К показателям предъявляют требование отражения в них таких характеристик как качество, количество и время. Отбор показателей проводится в несколько этапов.
Необходимо чтобы те, кто занимается планированием, и те, кто осуществляет проект, имели одинаковое представление о целях, обеспечении их реальности, конкретности и измеримости.
Дальнейшая разработка проекта связана с детализацией ранее принятых решений. При этом решаются традиционные вопросы планирования проектов: составление графиков работ, определение необходимых ресурсов, разработка бюджетов, определение характеристик эффективности проекта (экономической, коммерческой и др.), определение источников и способов финансирования, проектирование организационных схем управления, разрабатываются планы закупок, выбираются способы управления рисками и др. При решении этих вопросов используют хорошо известные методы и подходы составления различных структур необходимых работ, календарное планирование, методы разработки бюджетов, определения эффективности проектов, методы управления рисками и др.
Объём и детальность разработки определяются характером и масштабом проекта, а также регламентирующими документами по разработке проектов, принятыми в организации. Например, в организациях, финансирующих сравнительно небольшие проекты, объём документов планирования, как правило, невелик. Это могут быть концепция проекта, бизнесплан, ТЭО. В случае, когда финансируются масштабные и сложные по характеру проекты, планирование охватывает широкий круг аспектов и требует больших усилий.
Система управления проектом формируется на ранних фазах жизненного цикла проекта и во многом определяется его предметной областью, масштабом, составом участников, окружением. Для крупных и средних проектов характерна многоуровневость системы управления с разделением на стратегическое и оперативное управление. При этом стратегическое управление обычно осуществляется высшими уровнями управления или специально созданными Координационными советами, особенно, в случае сложных проектов с большим количеством участников. Оперативное управление осуществляется группой управления проектом (ГУП).
Среди используемых организационных решений для ГУП можно отметить следующие:
Использование консультантов (консультационных компаний).
Передача функций ГУП одному из действующих подразделений, исполняющему проект организации или вышестоящего органа в дополнение к существующим их обязанностям. При этом могут использоваться различные варианты организации управления проектом.
Создание новой структуры с административным подчинением одному из ведущих участников проекта.
Передача функций ГУП другой ГУП, уже ведущей близкие по характеру проекты и имеющей необходимый опыт.
Разделение функций ГУП между исполняющим ведомством (подразделением) с поручением ему функций связанных с содержательной частью проекта и одной из действующих и опытных ГУП с поручением ей специфи-ческих управленческих функций.
Мониторингу проекта уделяется особое внимание. Он осуществляется на всех уровнях управления проектом. Для его проведения могут привле-каться независимые эксперты. Особо жесткому контролю подвергаются про-цессы закупок и расходования средств; соответствие запланированных целей проекта текущей ситуации.
При построении системы мониторинга исходят из целей проекта, структуры работ, показателей достижения целей, показателей выполнения конкретных мероприятий по устранению ранее выявленных проблем и др.
Периодичность контроля и отчётности зависит от уровня управления, состояния проекта, его характера и для рассматриваемых проектов может варьироваться от одного раза в неделю до одного раза в год. Используются различные формы отчётности, содержащие основные финансовые и физиче-ские показатели, определённые в логико-структурной схеме, графиках работ и расходования средств. Кроме этого регулярно проводятся обзоры хода вы-полнения проекта путём совместного обсуждения основными заинтересован-ными сторонами положения дел, оценки состояния реализации проекта и вы-работки планов дальнейших действий.
Меры по регулированию хода проекта могут включать от совместных мероприятий по решению возникших проблем до изменения целей проекта (реструктуризации проекта), его преждевременного закрытия и аннулирова-ния неизрасходованных средств, в случае нецелесообразности дальнейшего продолжения проекта.
Одним из средств контроля за подготовкой и реализацией проекта яв-ляется регулярное проведение оценок проекта. Обычно, оно осуществляется после конца подготовки, в середине и после завершения проекта. Основной целью при этом является определение соответствия состояния проекта его целям. При окончании подготовки проекта независимая оценка помогает оп-ределить обоснованность целей проекта и соответствие уровня разработки выбранным целям. Промежуточные оценки дают возможность определить сохраняется ли актуальность целей проекта и соответствует ли состояние проекта этим целям. После окончания проекта в ходе оценки определяется степень достижения целей, основные проблемы реализации, анализируются основные причины этих проблем, формулируются рекомендации для будущих проектов близкого характера. Оценки осуществляются специальными подразделениями ведущих участников проекта на основе документов мони-торинга, дополнительных исследований или специальных миссий.
В ходе оценки используются различные критерии, например, адекват-ности, экономичности, продуктивности, эффективности, воздействия, экономической и финансовой жизнеспособности, самофункционирования. Могут применяться и более обобщенные критерии. Например, во Всемирном банке при обзоре портфеля проектов используют показатели: рейтинг реализации, рейтинг целей, общая эффективность. На основе оценки этих показателей каждому проекту присваивается одно из значений рейтинга: удовлетвори-тельно, неудовлетворительно, крайне неудовлетворительно.
После внедрения АИС, деятельность организации существенно зависит от нормальной работы системы. Поэтому большое значение приобретает качество сопровождения и поддержки поставщиком внедренного ПО. Косвенными показателями уровня качества поддержки могут выступать:
наличие у поставщика документарно-описанной политики по поддержке клиентов;
тщательность проработки контракта на сопровождение и техническую поддержку;
наличие отдельного подразделения, занимающегося техническим сопровождением;
наличие специальных каналов связи (выделенные телефонные номера, адрес электронной почты, сайт, страницы в Интернет, посвященные поддержке);
наличие специализированного ПО для автоматизации процесса приема и обработки проблем, возникающих у клиентов.
Таким образом, в частности, можно минимизировать или оптимизировать как финансовые затраты заказчика, так и трудовые (интеллектуальные, временные и др.) затраты разработчиков, поскольку объём программного кода практически отражает трудозатраты на разработку программы (число строк кода, человеко-дни и др.).
Приступая к разработке АИС, важно чётко разграничить цели, результаты и действия и соответственно определить области ответственности, в частности.
Организация труда разработчиков АИС
Очевидно, что основным вопросом организации труда при разработке АИС является организация труда разработчиков АИС. Важным элементом методологии программирования является принцип бригадной организации работ. Практическая реализация больших и средних программных проектов требует умения и опыта многих, входящих в бригаду, программистов. Выде-ляют три основные роли разработчиков:
1. архитектор проекта;
2. ответственные за подсистемы;
3. прикладные программисты.
Архитектор проекта отвечает за эволюцию и сопровождение архитектуры системы. Он не обязательно должен быть главным разработчиком, но обязан квалифицированно принимать стратегические решения, как правило, базируясь на имеющемся опыте построения подобных систем.
Руководитель (администратор, менеджер) проекта несёт ответственность за эффективное использование ресурсов и достижение результатов и не может нести прямую ответственность, например, за использование предоставляемых проектом услуг. Но он может осуществлять в течение определённого периода мониторинг связанных с этим рисков и допущений.
Архитекторы, хотя и должны уметь программировать, в первую очередь обязаны разбираться в принципах организации разработки АИС, а также весьма желательно чтобы они владели принципами менеджмента.
Ответственные за подсистемы отвечают за проектирование конкретных модулей и подсистем. В сотрудничестве с архитектором проекта каждый из ответственных разрабатывает, обосновывает и согласовывает с другими разработчиками интерфейс своей подсистемы, а затем возглавляет её реализацию, тестирование и выпуск обновлений в течение развития системы. Они должны знать принятую систему обозначений и организацию процесса разработки АИС. Обычно они программируют лучше, чем архитекторы проекта, но не располагают столь обширным опытом. Ответственные за подсистемы составляют от трети до половины численности команды разработчиков.
Прикладные программисты – это младшие по рангу участники проекта. В основном они занимаются реализацией и последующим тестированием выполненных ими элементов подсистем и модулей. Они могут участвовать и в проектировании некоторых подсистем. Прикладные программисты должны быть хорошими программистами. Количественно они составляют не менее половины команды.
В больших проектах дополнительно в состав бригады могут входить и другие специалисты: менеджер проекта и интеграции, аналитик, инженер по повторному использованию, контролёр качества, ответственный за документацию, инструментальщик и др.
Менеджер проекта отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ.
Аналитик отвечает за развитие и интерпретацию требований конечных пользователей. Он должен быть экспертом в предметной области, и его не следует изолировать от команды разработчиков.
Инженер по повторному использованию управляет хранилищем материалов проекта; активно ищет общее и добивается его использования; находит, разрабатывает или приспосабливает компоненты для общего использования.
Контролёр качества анализирует результаты процесса разработки; задаёт общее направление тестирования.
Менеджер интеграции отвечает за сборку подсистем в единое приложение и следит за конфигурированием подсистем.
Ответственный за документацию готовит для конечного пользователя документацию по выпускаемому продукту и его архитектуре.
Инструментальщик отвечает за создание и адаптацию инструментов программирования, которые облегчают создание программ.
Системный администратор управляет физическими компьютерными ресурсами в проекте.
Не каждый проект требует использования всех названных ролей. В не-больших проектах обязанности могут совмещаться. При этом в очень больших проектах каждой из ролей может заниматься отдельная организация.
Вопрос, который может возникнуть, как в самом начале проекта, так и на любой его фазе – осуществлять все работы своими силами или привлекать внешних консультантов? Привлечение консультантов (речь идёт о специалистах с соответствующей квалификацией и опытом работы) может увеличить первоначальные финансовые затраты на проект по выбору, но при этом значительно сокращается время на проведение работ и повышается качество их выполнения, а значит снижается риск их повторного выполнения, риск ошибок при принятии решений.
Качество разработки АИС напрямую зависит как от производительности, так и от квалификации разработчиков. Проблемы повышения качества программирования активно обсуждаются с конца 1960-х г. Оно включает ряд компонент, среди которых, например, одной из важных является снижение затрат на сопровождение АИС.
Существенный экономический эффект, высокое качество, сокращение сроков разработки АИС достигается применением интегрированного программно-математического обеспечения. Оно значительно упрощает процессы связывания и встраивания электронных документов, их передачи как внутри предприятия, так и другим информационным системам. Интегрированные программные системы максимально упрощают и эксплуатацию АИС, так как все задачи решаются с применением единообразного пользовательского интерфейса.
Значительно ускорить составление программ и облегчить их отладку можно, используя ранее составленные библиотеки стандартных, типовых модулей, а также средства автоматического проектирования программных продуктов. В этом случае CASE-средства служат также мощным инструмен-том решения исследовательских и проектных задач, связанных с начальными этапами разработки. К таким задачам относят: анализ предметной области, разработку проектных спецификаций, выпуск проектной документации, пла-нирование и контроль разработок, моделирование деловых приложений, опе-ративного и стратегического планирования, управления ресурсами и т. п.