Анализ систем документооборота в проектах по разработке программного обеспечения Текст научной статьи по специальности «Компьютерные и информационные науки»

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

АНАЛИЗ СИСТЕМ ДОКУМЕНТООБОРОТА В ПРОЕКТАХ ПО РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Б.А. Климов,

директор по развитию ООО «Зарница СЛ»,

преподаватель кафедры «Управление разработкой программного обеспечения» отделения программной инженерии факультета бизнес-информатики Государственного университета — Высшей школы экономики, e-mail: bak@slru.ru

Д.Ю. Романов,

магистрант кафедры «Управление разработкой программного обеспечения » отделения программной инженерии факультета бизнес-информатики Государственного университета — Высшей школы экономики, стажер отдела Управления проектами ООО «Зарница СЛ», e-mail: dyr@slru.ru

Адрес: 105187, г. Москва, ул. Кирпичная, д.33/5.

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

К__________________________________________________________________________J

Ключевые слова: программные инструменты, рабочий процесс, документооборот, спецификации программных продуктов, управление клиентами, субверсии.

1. Введение

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

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

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г.

15

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

1.1. Как «мы» работаем...

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

♦ разработка требований;

♦ анализ требований и проектирование дизайна;

♦ реализация требований в коде программы;

♦ тестирование;

♦ внедрение и сопровождение.

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

Практически на каждом этапе необходимы средства для автоматизации работы, начиная от CRM систем и заканчивая системами трассировки. Несомненно, самым автоматизированным процессом в компании производителе программно -го обеспечения является сам процесс разработки программного обеспечения, так как от эффективности разработки напрямую зависит прибыль компании.

Трудно себе представить, как инженеры технической поддержки будут отвечать на e-mail пользователей без использования систем трассировки, таких как Jira или RT. Как разработчики будут регистрировать и отслеживать ошибки программного кода без баг-трекинг систем, таких как Bugzilla, Trac или Rational ClearQuest, менеджеры проектов — состав-

лять план работ без систем управления проектами, а программисты — вносить изменения в исходный код программного продукта без использования систем версионного контроля. Без использования вышеперечисленных систем автоматизации процесс разработки какого-нибудь небольшого приложения затягивался бы в разы, а сложные проекты становились бы невыполнимыми.

1.2. Вопрос автоматизации документооборота в проектах по разработке ПО

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

Если задаться вопросом, почему документооборот так тяжело автоматизировать, становится понятно, что вся сложность заключается в индивидуальной настройке документооборота под нужды компаний. В зависимости от вида деятельности компании, то есть от специфики ее работы, требования к функционалу документооборота будут предъявляться разные, перечислить все возможные требования практически невозможно.

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

16'

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Основными документами проекта по разработке ПО обычно являются следующие документы:

• устав проекта

• содержание проекта

• концепция проекта (может быть включена в устав)

• SRS (software requirement specification) — все документации и спецификации по проекту

• план проекта

• необходимые для выполнения проекта регламенты.

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

Ф Что он должен сделать?

Ф Для чего все это делается?

Ф Когда он должен это сделать?

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

1.3. Основополагающие требования к автоматизации работы

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

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

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

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

1.4. Основные проблемы работы с документами, возникающие на практике

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

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

17

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

1.4.1. Пример 1

Классическим примером является использование пересылки документов по e-mail без создания единого хранилища документов. Основные проблемы, которые могут возникнуть в такой ситуации:

♦ кто-то из заинтересованных лиц просто не прочтет или не увидит письмо;

♦ если документ часто обновляется, то это может привести к проблемам актуальности документа, то есть заинтересованное лицо может проделать двойную работу и потратить рабочее время, комментируя документ, который уже потерял актуальность;

♦ в процессе обсуждения/утверждения документа в переписке может быть потерян ценный комментарий, который стоило бы внести в основной документ, из-за чего на дальнейших этапах разработки могут появиться противоречия в требованиях и т. п.;

♦ актуальный вариант есть в наличие только у ав-тора/авторов документа.

В результате, исправление последствий может крайне негативно сказаться на всем проекте в целом.

1.4.2. Пример 2

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

Ф нет отслеживания вносимых изменений в документ, что может испортить документ при одновременном редактировании несколькими сотрудниками;

Ф возникает проблема локального копирования документа, которая в совокупности с человеческим фактором может привести к проблеме актуальности документа, то есть человек, который читает документ, должен каждый раз качать документ заново;

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

1.4.3. Пример 3

Существует еще один популярный именно в небольших компаниях-производителях программно-

го обеспечения способ обмена документами. Разработчики любят использовать столь полюбившуюся им систему управления версиями Subversion (SVN) [1]. Система идеально подходит для работы с программным кодом, но для работы с документами крайне неудобна, поскольку SVN работает только с текстовыми файлами, то есть отслеживание истории редактирования файлов с расширениями .doc, .xls, .odt и т. д. невозможно, так как такие документы сохраняются в бинарном виде. Именно поэтому приходиться хранить все документы в текстовом формате, который, к сожалению, не будет пригоден для большинства, особенно, если учесть, что негласным стандартом являются документы формата Microsoft Office. Несмотря на то, что SVN имеет систему оповещений об вносимых изменениях, а так же возможности создавать многоуровневую структуру и настраивать права доступа, SVN остается, прежде всего, инструментом для программистов, и, к сожалению, не каждый имеет опыт работы с ней. Этот недостаток данного решения никак не позволяют назвать его идеальным.

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

2. «Что делать?»

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

2.1. Системы для online работы с документами

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

18

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

• MediaWiki — известнейший в мире способ создания HTML страниц

• Microsoft Sharepoint — многофункциональная платформа для построения корпоративных порталов

• Google Docs — бесплатный online сервис для работы с документами

Однако ни одна из этих систем не может удовлетворить в полном объеме потребности современных компаний-разработчиков ПО.

2.1.1. MediaWiki

MediaWiki — программный механизм для вебсайтов, работающих по технологии «вики» [2]. Это один из самых мощных вики-движков, написанный специально для Википедии и использующийся во многих других проектах фонда «Викимедиа», в частных и государственных организациях. MediaWiki — свободная программа, распространяющаяся на условиях Общественной лицензии GNU. Движок MediaWiki написан на PHP и для хранения данных использует реляционную базу данных (можно использовать MySQL, PostgreSQL, SQLite) [3].

MediaWiki предоставляет интерфейс работы с базой страниц, разграничение прав доступа к администрированию системы, возможность обработки текста, как в собственном формате, так и в форматах HTML и TeX (для формул), возможность загрузки изображений и других файлов, настройку оповещений обновления страниц и также другие возможности. Гибкая система плагинов позволяет пользователям добавлять собственные новые возможности и программные интерфейсы. Одним из самых удобных и важных таких плагинов является Rich Editor. Rich Editor — это текстовый редактор, который используется для набора текста новостей, статей и контентных зон [4]. По функциональности данный редактор схож с MS Word, поэтому освоить работу в Rich Editor для пользователей MS Office не составляет труда. Одна из ключевых его особенностей, помимо панели инструментов, схожую с MS Word, - это возможность вставки текста из Word, то есть пользователь просто может соз-

дать документ в Word и с помощью простого копирования текста вставить текст на Wiki, сохранив при этом его форматирование.

Если взвешивать все за и против использования MediaWiki в качестве системы для работы с документами, можно выделить следующие преимущества:

♦ открытость программного кода;

♦ кроссплатформенность;

♦ наличие большого количества общедоступных плагинов для улучшения функционала;

♦ возможность online редактирования документов, при условии, что компания переносит все написанные документы на Wiki-страницы;

♦ возможность хранения документов, как файлов, то есть функция хранилища документов;

♦настраиваемые права доступа для Wiki-страниц;

•♦•возможность e-mail оповещения пользователей системы о внесенных на страницу изменениях;

-♦•отслеживание истории изменений Wiki-страниц (кто, когда и что изменил на странице);

♦ отслеживание одновременного редактирования одной Wiki-страницы несколькими пользователями с отображением предупреждений об одновременной изменении и возможностью соединять изменения в случае, если оба редактирования не влияют на желаемый результат;

♦ простота в установке и настройке;

♦ удобный и понятный интерфейс (этим MediaWiki обязан огромной популярности Wikipedia — свободной энциклопедии).

Против использования MediaWiki в качестве системы для online работы с документами говорят следующие факты:

■ф данная система не имеет функционала по «импорту» и «экспорту», то есть не имеет полноценной поддержки форматов Word, Excel, Open Document;

•ф данная система не имеет настроек для создания процесса движения документов, так как она изначально не проектировалась под такие нужды;

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

2.1.2. Microsoft Sharepoint

Microsoft SharePoint Products and Technologies — это коллекция программных продуктов и компонентов, которая, не считая постоянно увеличивающееся число доступных решений, включает в себя

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

19

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

следующие элементы [5]:

■ набор веб-приложений для организации совместной работы;

■ функционал для создания порталов;

■ модуль поиска информации в документах и информационных системах;

■ функционал управления рабочими процессами и система управления содержимым масштаба предприятия;

■ модуль создания форм для ввода информации;

■ функционал для Бизнес-анализа.

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

SharePoint представлен в виде двух основных продуктов — Windows SharePoint Services (WSS) и Microsoft Office SharePoint Server (MOSS). Помимо этих продуктов, предлагается инструментальное средство Microsoft Office SharePoint Designer (SPD).

Windows SharePoint Services (WSS) — бесплатное приложение к Windows Server. WSS предоставляет базовую инфраструктуру для совместной работы: редактирование, хранение докумен-

тов, контроль версий и т. д. Также он включает в себя такую функциональность, как «маршруты» движения документов (платформа для документооборота), списки заданий, напоминания, онлайн-дискуссии. Ранее WSS был известен как SharePoint Team Services.

Microsoft Office SharePoint Server (MOSS) — платный компонент для интеграции функциональности SharePoint в работу приложений MS Office. Он является надстройкой WSS и расширяет его возможности. MOSS включает в себя инструменты для бизнес-аналитики — Excel Services, Business Data Catalog. Он позволяет получить доступ к Microsoft Project Server и к формам Microsoft Office InfoPath через браузер, централизовано, в соответствии с концепцией многомодульного портала. Поддерживает специальные библиотеки, такие как PowerPoint Template Libraries. MOSS ранее был известен как SharePoint Server и SharePoint Portal Server.

Microsoft Office SharePoint Designer (SPD) — HTML-редактор в стиле WYSIWYG (What You See Is What You Get), разработанный специально для создания SharePoint-страниц и управления документами для WSS сайтов. SPD дает возможность доступа к функциональности своего рендер-движка через Microsoft Expression Web и через среду разработки.

Microsoft Visual Studio. Весной 2009 года стал бесплатным продуктом. SPD ранее был известен как FrontPage.

Функционал системы впечатляет: данную платформу можно использовать как основной портал компании и на нем базировать все системы, в том числе размещать документы, при этом:

♦ документы можно не только редактировать online, но и хранить как файлы на сервере;

•♦■портал на платформе Sharepoint может служить инструментом общения между сотрудниками;

♦ при желании Sharepoint можно использовать как систему управления проектами.

Все эти возможности делают Sharepoint замечательной во всех отношениях системой. Компания Microsoft создала очень хорошую платформу с огромным функционалом, однозначно лучшую систему для создания корпоративного портала. При этом, если выбор крупных, численностью более 1000 человек, компаний, будет однозначно Sharepoint, то для средних и мелких компаний минусы использования Sharepoint скорее заставят отказаться от какой-то части функционала и выбрать другое решение. Минусы использования Sharepoint вытекают только из политики Microsoft, это — отсутствие кросплатформенности и стоимость использования. Для использования Sharepoint, прежде всего, должен быть лицензирован Windows Server. Windows Server 2008 например, лицензируется по схеме: лицензия на Сервер (или на процессор) + лицензия клиентского доступа [6]. Помимо этого необходимо по такой же схеме лицензировать Microsoft Office SharePoint Server, причем цена за лицензирование растет в зависимости от необходимого количества клиентских лицензий. Еще одним неприятным фактором помимо цены является полноценная поддержка online работы с документами только из-под браузера Internet Explorer — продукта компании Microsoft. Если для Interet Explorer был написан специальный плагин, который позволяет редактировать документы прямо на сервере через браузер без потери функционала пакета Microsoft Office, то для пользователей других браузеров сама

20

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

идея online редактирования будет бессмысленна, так как им придется редактировать документ только с помощью создания локальной копии файла. Есть еще один минус, который не менее важен — это сложность настройки системы под бизнес-процессы компании. Это означает, что компания будет вынуждена содержать отдельного обученного сотрудника, задачей которого будет настройка Sharepoint и поддержка ее функциональности, что подразумевает под собой дополнительные финансовые затраты.

2.1.3. Google Docs

Google Docs — это бесплатный онлайн офис, включающий в себя табличный текстовый, процессор и сервис для создания презентаций, разрабатываемый Google [7]. Сервис образован в итоге слияния Writely и Google Spreadsheets.

Google Docs — веб-ориентированное программное обеспечение, то есть программа, работающая в рамках веб-браузера без инсталляции на компьютер пользователя. Документы и таблицы, создаваемые пользователем, сохраняются на специальном сервере Google и могут быть экспортированы в файл. Это — одно из ключевых преимуществ программы, так как доступ к введённым данным может осуществляться с любого компьютера, подключенного к интернету (доступ при этом защищён только паролем). Все, что нужно пользователю - это получить учетную запись Google (аккаунт Google), которая дает доступ ко всем сервисам, предоставляемым компанией Google. Если у вас есть почта Google, то учетная запись у вас уже есть. Google Docs фактически может работать с текстами, таблицами и презентациями. Writely — текстовый редактор, позволяющий редактировать текстовые документы OpenDocument, Microsoft Word, а также электронные таблицы. Реализован при помощи AJAX. Доступно большое количество средств форматирования: смена размера и стиля шрифта, выбор цвета и декораций, создание списков и таблиц, вставка картинок, ссылок и специальных символов.

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

RTF, OpenDocument, PDF и несколько графических форматов. Можно получить подборку текстов в виде файлов HTML в архиве ZIP. Заявлена (но пока не реализована) поддержка Word Perfect.

Google Spreadsheets позволяет заносить данные в ряды и столбцы электронной таблицы, а также производить несложные вычисления, и даже имеет возможность построения стандартных диаграмм. Программа допускает импорт и экспорт данных и в специфический формат Microsoft Excel, и в общедоступные OpenDocument и CSV. Это новое программное обеспечение несравнимо по функциональности с полноценными электронными таблицами, такими, как Microsoft Excel или OpenOffice.org Calc, но вполне достаточно для простейших манипуляций с данными.

Google Presentations дает возможность создавать электронные презентации. Реализована возможность импорта/экспорта файлов Microsoft PowerPoint (*.ppt). В основу Google Presentations легли разработки компании Tonic System, приобретенной компанией Google в 2007 году.

Для всех видов документов предусмотрена возможность доступа других пользователей, как с правом редактирования, так и без. Максимум - до 10 пользователей одновременно для редактирования документов и презентаций и до 50 пользователей для таблиц, при этом совместный доступ к документу можно открыть для 200 пользователей (общее количество соавторов и читателей не может превышать 200 человек) [8].

Трудозатраты на реализацию проекта Google Docs поистине поражают. На сегодняшний день это определённо лучший универсальный (доступный для любых браузеров) способ редактирования документа online. Здесь стоит отметить, что Google Docs — это не офисное приложение. Оно могло бы быть офисным, если бы компания выпустила специальные плагины для браузеров, которые по функционалу не отличались об привычных офисных пакетов, таких как MS Office или Open Office. В таком случае online работа с документами была бы аналогична обработке документа, который лежит в свободном доступе на одном из ваших серверов офисным пакетом. Технологически Google Docs отличаются от офисного пакета тем, что это не очередная реализация офисного пакета, а система, которая умеет разбирать документы разных форматов и представлять их в своем внутреннем формате, который, в свою очередь, позволяет представлять данные из документов через

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

21

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

HTML. Заслуга Google Docs состоит в том, что их механизм разбора документов на сегодняшний день лучший в мире и в том, что он дуплексный, то есть может как разбирать документ в свой собственный формат, так и делать из внутреннего формата привычный документ, который пользователь может сохранить себе локально.

Конечно же, тяжело представить, что Google Docs будут использовать компании в своей работе, так как, прежде всего, для компаний важна безопасность, и никто не согласиться хранить внутренние документы на чужих серверах. Но данная система была исследована нами именно из-за своей технологии. Если бы Google Docs стали реализовывать еще и как серверное решение для online работы с документами, и компании получили бы возможность устанавливать на свои сервера и использовать

личный Google Docs, то система однозначно стала бы широко популярной.

К сожалению, у Google Docs есть еще ряд минусов, которые нельзя не отметить. Прежде всего, это огромная загрузка клиентского рабочего места. Объёмы Java скрипта, благодаря которому представление документа в браузере стало возможным, очень сильно загружает процессор, что непосредственно сказывается на скорости работы с системой.

3. Сводная информация по системам

Сводная информация о рассмотренных системах документооборота в компаниях — производителях ПО, представлена ниже в виде следующей сводной таблицы:

Таблица 1

Сводная информация по системам on-line работы с документами в разработке ПО

MediaWiki Sharepoint Google Docs

Клиент-сервер архитектура Да Да Да

Возможность интеграции с системой управления проектами Да Да Нет

Гибкость функционала системы Да (множество плагинов) Да Нет

Возможность самостоятельно дописать необходимый функционал Да (Open Source) Нет Нет

Гибкость настройки процесса (гибкий workflow) Нельзя настроить Да Нет

Хранение файлов Да Да Да

WEB-интерфейс Да Да Да

Клиентское приложение Браузер Браузер Браузер

Кроссплатформенность Да Только для Windows Server только как сервис (не продается в виде серверного решения)

Создание документов Нет Да Да

Online редактирование документов Нет Да (только под Internet Explorer) Да

Разграничение прав доступа Да Да Да

Управление версиями и история вносимых изменений Да Да Нет

Экспорт в doc Нет Да Да

Экспорт в xls Нет Да Да

Экспорт в rtf Нет Да Да

22

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

MediaWiki Sharepoint Google Docs

Экспорт в OpenDocument Нет Нет Да

Импорт из doc Да (с помощью copy/paste с использованием Rich Editor) Да Да

Импорт из xls Да (с помощью copy/paste с использованием Rich Editor) Да Да

Импорт из rtf Да (с помощью copy/paste с использованием Rich Editor) Да Да

Импорт из OpenDocument Да (с помощью copy/paste с использованием Rich Editor) Нет Да

E-mail оповещения о изменениях Да Да Нет

Комментирование документов Нет Да (в виде блога) Нет

Одновременное редактирование Да Нет (схема check in/check out доумента) Да (до 10 человек)

Оповещения о конфликте изменений Да Нет Да

4. Заключение

Исходя из результатов анализа, нельзя однозначно определить лучшую систему. Каждая система имеет свою определенную нишу. При наличие достаточного бюджета Sharepoint будет наилучшим выбором, в противном случае придется выбирать из «двух зол».

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

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

Литература

1. [1] URL: http://subversion.apache.org/docs/ (дата обращения: 09.09.2009).

2. [2] URL: http://en.wikipedia.org/wiki/Wiki (дата обращения: 17.09.2009).

3. [3] URL: http://ru.wikipedia.org/wiki/Mediawiki (дата обращения: 20.09.2009).

4. [4] URL: http://www.richarea.com/ (дата обращения: 20.09.2009)

5. [5] URL: http://ru.wikipedia.org/wiki/SharePoint (дата обращения: 22.09.2009).

6. [6] URL: http://sharepoint.microsoft.com/Pages/Default.aspx (дата обращения: 27.09.2009).

7. [7] URL: http://ru.wikipedia.org/wiki/Google_Docs (дата обращения: 30.09.2009).

8. [8] URL: http://docs.google.com/support/?hl=ru (дата обращения: 05.10.2009).

БИЗНЕС-ИНФОРМАТИКА №2(12)-2010 г

23