Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Ошибки, которые вы уже не сделаете, прочитав эту статью

Пол Шульц

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

Неумение учитывать опыт прошлого

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

Web-службы не панацея

Тенденции, наблюдающиеся в сферах разработки и маркетинга Web-служб, поневоле наводят на мысль о том, что, похоже, мы снова свернули на ту же дорогу, по которой когда-то уже ходили. Идея создания компьютерных систем на базе сервис-ориентированной архитектуры (Services-Oriented Architecture - SOA) поистине грандиозна. Однако при этом чрезвычайно важно суметь ограничить область применения таких систем теми средами, в которых существуют мощные бизнес-стимулы для принятия данной технологии.

Концепция SOA - это закономерный результат развития относительно недавно возникшей тенденции использования компьютеров в качестве коммуникационных устройств.

Полную версию данной статьи смотрите в 1-ом номере журнала за 2003 год.

Продукты и услуги

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

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

EJB и .Net

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

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

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

Недостаточное тестирование

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

Контролируйте свою работу

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

* способствуют детальному документированию классов;

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

* укрепляют уверенность разработчика в надежности программного кода;

* обеспечивают быструю правку кода.

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

Как это выглядит на практике

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

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

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

Правка кода

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

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

Для осуществления рефакторинга программной системы с помощью интегрированных модульных тестов следует выполнить следующие шаги:

* определите, к какому фрагменту кода следует применить рефакторинг;

* если для данного фрагмента кода существует модульный тест, выполните его - в противном случае создайте для этого фрагмента кода модульный тест;

* осуществите пошаговый рефакторинг кода;

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

* при необходимости адаптируйте код модульного теста к измененным интерфейсам;

* после окончания рефакторинга кода запустите соответствующие модульные тесты еще раз.

Если при этом не обнаружится никаких проблем, можно считать, что рефакторинг прошел успешно.

Базовая среда для тестирования

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

"Децентрализация" клиента

Чтобы поддерживать правильные взаимоотношения с клиентами, следует использовать три основных принципа:

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

Рассмотрите вопрос об изменении методологии проектирования ПО. Такие методологии разработки ПО, как Extreme Programming (XP), способствуют широкому вовлечению клиентов непосредственно в процесс разработки программных продуктов. Основной упор в XP делается на командный метод работы (teamwork). Все это служит одной-единственной цели - наискорейшей разработке надежного ПО, полностью удовлетворяющего требованию заказчика. Может показаться, что точно такую же цель преследует и любая другая методология. Да собственно, так оно и есть, но в XP используется несколько инновационных подходов, обеспечивающих успешное завершение разработки ПО в реалистичные сроки.

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

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

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

Переоценка интеллектуальной собственности

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

Секретность должна быть разумной

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

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

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

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

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

Нужен ли вам патент?

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

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

Пренебрежение политическим курсом

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

Новые регулирующие положения

К двум последним постановлениям, непосредственно влияющим на индустрию ПО и Интернет, относятся Uniform Computer Information Transaction Act (UCITA) и Digital Millennium Copyright Act (DMCA). Хотя маловероятно, чтобы их сторонники руководствовались чем-либо еще, помимо благих намерений, но оба постановления могут негативно повлиять на некоторые непреложные ценности, такие, как свобода слова и безопасность информационных систем.

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

* закон позволяет поставщикам ПО продавать свои продукты, освобождая их от ответственности за наличие в них дефектов;

* он также дает возможность поставщикам ПО изменять условия контракта после совершения покупки;

* допускает наличие в программных и информационных продуктах "лазеек", делающих пользовательские системы уязвимыми;

* содержит ограничения, запрещающие пользователям критиковать или публично комментировать купленное ими ПО.

Старый враг

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

Наглядным примером того, как DMCA может ограничить свободу слова и ослабить компьютерную безопасность, является случай с Эдвардом Фелтеном, исследователем в области компьютерной техники Принстонского университета. В октябре 2000 г. он и его команда успешно "взломали" цифровую схему формирования "водяных знаков", разработанную в рамках инициативы SDMI (Secure Digital Music Initiative) с целью выявления фактов нелегального копирования музыкальной продукции. Как правило, сообщество разработчиков средств компьютерной безопасности только приветствует такие акции. Если криптографическая система содержит дефекты и уязвима для взломщиков, разработчики должны знать об этом, чтобы устранить проблемы. В данном случае реакция была полностью противоположной: как только члены группы SDMI и RIAA (Recording Industry Association of America) узнали о взломе, они начали угрожать Фелтену возбуждением судебного процесса, если он станет публично обсуждать полученные им данные. Хотя RIAA в конце концов образумилась, сам факт случившегося говорит о том, что реальность такова, что безопасность Интернет зависит от возможности исследователей открыто полемизировать о том, что и как работает. Ограничьте возможность технологов обмениваться информацией таким - и безопасность Интернет в целом окажется под угрозой.

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

Что вы можете предпринять

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





  
1 '2003
СОДЕРЖАНИЕ

бизнес

• С чего начинается адаптивное управление?

• Ошибки, которые вы уже не сделаете, прочитав эту статью

• "Интерпроком ЛАН" - "неправильный" дистрибутор

инфраструктура

• Тестируем средства создания и распространения образов дисков

информационные системы

• Опыт внедрения ERP-системы в крупном медицинском учреждении. Часть I

• Опыт внедрения ERP-системы в крупном медицинском учреждении. Часть II

• ПО мониторинга работы операторов в call-центрах

• Web-сервисы и спецификация SOAP

кабельные системы

• Проектирование и построение защищенных беспроводных ЛВС

• Интероперабельность компонентов категории 6

• Скалыватели оптоволокна

сети связи

• Quo vadis, VoIP?

• Сеть MPLS на Урале

защита данных

• Решения HIP предотвратят вторжения на хосты

новые продукты

• Новая версия NIC Express; Alcatel 5020 Softswitch; SI2000 COCOS — контакт-центр Iskratel и «Искрауралтел»; OptiSwitch-F — фиксированная конфигурация, SFP-трансиверы


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх