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

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

Это заблуждение произошло потому, что центр "F1" не заложил в базу данных один очень важный параметр - качественную оценку по каждому свойству. Качество ранжируется по стандартной шкале, от 1 (очень плохое) до 10 (очень хорошее). При этом база данных должна была выглядеть примерно так:

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

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

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

• детальную документацию требований пользователей вашей организации;
• документацию по программе;
• результаты консультаций с продавцами и другими пользователями данной программы;
• советы опытного консультанта по программам данного класса.

Поэтому выполнение этой работы связано с определёнными затратами времени и финансов.

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

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

Из всего сказанного выше можно сделать неутешительный вывод: предложенная центром "F1" методика выбора программы не выдерживает никакой критики.

Офис

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

Обслуживание

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

Например, вы обращаетесь с просьбой разработать какой-либо отчёт по данным, находящимся в базе данных купленной вами ранее учётной программы. Инженер знает, что с этой работой он справится за один час, но вам он этого никогда не скажет. Да, конечно, работа будет сделана, но при этом вы заплатите минимум за 2-3 часа работы. Почему? Давайте попробуем разобраться.

Существуют пять чётко определённых уровней компетентности (рис. 1) в приёмах разработки программного обеспечения.

Рис 1. Модель уровней компетентности.

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

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

Дополнительно отмечу, что обязательные этапы - анализ, проектирование, реализация и тестирование - зачастую выпускаются или выполняются в неполном объёме. Известные методики создания программного обеспечения - модель водопада и спиральная модель (рис. 2) - игнорируются даже при разработке крупных проектов.

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

Говорить про использование передовых приёмов проектирования - объектно-ориентированном анализе, CASE-технологиях и выполнении анализа с помощью UML (унифицированного языка моделирования) - в данном случае уже просто не приходится.

Заключение

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