Архивы: по дате | по разделам | по авторам

От хвоста до головы Практика разработки средних и крупных программных проектов

Архив
автор : Олег Борисов   21.02.2003

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

Все нижесказанное является личным мнением автора, которое он никому не навязывает и никоим образом не объявляет истиной в последней инстанции. Автор выражает благодарность своим коллегам Игорю Никольскому, Марку Сухорученкову и Руслану Минаеву за помощь в подготовке статьи.

Петрович добрался до пятого этажа. Горд собой. Обратили его внимание на тот факт, что его стена наклонена под углом 40 градусов. Он ругался, кричал, что мы ламеры и ничего не понимаем. Потом обещал подумать.
© Если бы программисты
строили дома…

Просматривая тот же job.ru, хочется воскликнуть вслед за Остапом: «Лед тронулся, господа присяжные заседатели, лед тронулся!» Наконец-то среди потока продавцов коробочных продуктов и администраторов — «мальчиков на всё» — все чаще появляются вакансии аналитиков и проектировщиков программного обеспечения. Это не может не радовать. Значит, несмотря на ограниченность и узкую специализацию рынка разработки в России, у нас все же есть надобность в людях, способных принимать решения, от которых зависит успех или неуспех того или иного программного продукта.
Несмотря на медленный рост потребности в собственном ПО, все же потребность эта есть, а попытки наших разработчиков выйти на международный уровень и закрепиться на рынке аутсорсинга1 ставят перед фирмами-разработчиками требование перейти на методы корпоративной разработки, перестроить все системы на одну задачу — эффективную выдачу итогового продукта, повысить его качество одновременно с уменьшением сроков выпуска новых версий.
Работа на рынок сильно отличается от работы отделов автоматизации на внутрикорпоративные заказы. Рыночные продукты в силу своей специфики содержат в себе множество разнообразных функций (выгодно или не очень отличающих их от конкурентов), возможностей настраивать их различными способами для нужд пользователя, способность работать в разнообразных операционных системах и различном окружении. И для реализации всех этих возможностей и новшеств требуется время.

Главные проблемы разработки по со сроком реализации больше шести месяцев

Главная проблема любого проекта — его выполнение в срок и в полном объеме. На реализацию программы-максимум влияет огромное количество факторов. И чем дольше срок разработки, тем больше рисков2 на пути к финишной черте. И раз фактор времени — один из важнейших, то часто проекты пытаются классифицировать на его основе. Например, в FAQ list of relcom. comp.software-eng проекты по срокам разработки делятся следующим образом: крупный — начиная от ста человеко-лет, средний — начиная от десяти-двадцати человеко-лет.
Лично мне удобнее делить проекты в «смешанном представлении», где оценочную роль играет время, но итоговая граница выставляется от возможности реализовать задачу одним человеком:

  •  маленькие проекты (до шести человеко-месяцев);
  •  средние проекты (до двух человеко-лет);

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

  •  недостаточный первичный анализ требований заказчика;
  •  неполное выделение базовых понятий для предметных областей;
  •  недостаточная квалификация набранной команды и нехватка персонала для решения текущих задач;
  •  неквалифицированная работа среднего менеджерского звена (начальники проекта и ведущие программисты направлений);
  •  отсутствие или слабая отработка методик тестирования итогового кода.
    Кроме того, нередко группы сталкиваются с подобного рода проблемами:
  •  запоздалое выявление дефектов, требующих столь значительной переработки системы, что ее внедрение и сдача заказчику заметно откладывается или переносится на неопределенный срок;
  •  из-за изменений в бизнес-логике реального производства заложенные возможности системы уже не удовлетворяют заказчика;
  •  искажение первичных требований заказчика в процессе выработки технического задания или вообще непонимание части ключевых моментов, которые в итоге приводят к неверной концепции бизнес-модели в системе;
  •  сдвиг сроков разработки по форс-мажорным обстоятельствам (из-за отсутствия «люфта» по времени, не заложенного в проект);
  •  уход ведущих разработчиков и просто текучка кадров.


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

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

 в итоге разработчиков «построили» за то, что шеф после обеда желал посмотреть «эту новую штучку, что мы уже продаем», но так и не нашел иконку запуска на своем столе.3

Использование современных алгоритмов управления
процессом разработки

А еще я знаю кучу страшных слов: uml, rose, iconix, две «мыслящие обезьяны» за клавиатурой (экстремальный программинг), MS Project и так далее…
Из эпоса перекуров

На Диком Западе не только штампуют металлических паровых пауков для нужд Голливуда, но еще и пытаются решить задачи коммерческой разработки программных продуктов с уменьшением объема финансовых и временных затрат с одновременным повышением процента успешно завершенных (и проданных) работ. Стандартом для проектирования объектных систем, объединяющим аналитику, проектирование, конструирование, документирование и др. этапы разработки, является UML (Unified Modeling Language) — унифицированный язык моделирования. Созданные с его помощью модели затем можно перенести в код конкретного языка разработки.
Наиболее развитым пакетом, включающим в себя поддержку UML и позволяющим вести на его основе полнофункциональную разработку с охватом всех особенностей построения, реализации, тестирования и поддержки программного продукта, является Rational Suite Enterprise от фирмы Rational Software.
UML используют и другие группы разработчиков, создавая и предлагая свои собственные методики. Можно отметить, что любая из методик в своей основе содержит решение главной проблемы — проблемы управления рисками и нацеленность разработки на результат — выпуск программного продукта. И не суть важно, от чего отталкиваются авторы — от анализа структур данных или предметной области, от проектирования или кодирования. Ваша задача при оценке методики заключается в проверке того, насколько предлагаемые методы ложатся на работу коллектива и насколько следование этим принципам уменьшит сумму рисков по выпуску программного комплекса.
Однако кроме самих методик выделения предметных областей, сущностей и объектов программирования, нельзя забывать о том, что разработка ПО не только работа программистов, но еще и контроль над всем этим. Для контроля используются как непрофильные программы (Excel), так и специально разработанные для этого.
Базовой системой ведения проекта считается (и используется той же Rational) Microsoft Project. Именно эту вещь я могу рекомендовать как инструмент, позволяющий решить вопросы прогнозирования сроков разработки, оценки объемов выполненных работ и отслеживания текущего положения в реализации поставленных задач. MS Project может использоваться и в небольших коллективах, и в крупных организациях (в серверном варианте). Фактически продукт является стандартом де-факто для систем управления проектами.
К следующей группе можно отнести собственные системы учета. Среди их достоинств — разработка под конкретный проект и определенные методы ведения работ фирмой, настроенность на требования именно этого менеджерского звена. Однако это является и слабой стороной подобного рода систем. Требования в изменении процесса разработки хоронят такого рода программы на корню, так как их перенастройка для новых реалий требует дополнительных финансовых и трудовых вложений.
Последним пунктом хочу отметить разнообразные системы учета рабочего времени «постфактум» («табелирование»). Табелирование работ обычно опирается на шаблонные формы (где отмечается, кто, сколько и что сделал или не сделал). Используется для контроля небольших этапов и разовых работ (включая установку ПО на площадке клиента). Удобно для последующей статистической обработки данных по выполненному проекту, но крайне неудобно для реального управления проектом.
Использование этих форм в технических отделах оправданно, однако попытка втиснуть разработку в эти «шаблоны» вызывает, по крайней мере, недоумение, хотя сталкиваюсь с подобного рода отчетностью довольно часто.

«Рыба» возможного проекта
Если вы видите эту доску уже десятый раз за полчаса, то вы не бредете вокруг бочки, просто это такой забор…
Из послезастольного эпоса

Я не собираюсь отнимать хлеб у важных ребят в свежих рубашках и неизменных галстуках, но как человек, прошедший всю цепочку разработки неоднократно в удачных (и не очень) проектах, участвовавший на разных ее этапах — от кодера и постановщика задачи до руководителя проекта, — мне очень хочется, чтобы у вас, уважаемые читатели, получилось воплотить в жизнь все то, что вы намечаете.
В настоящее время, приступая к новой работе, я следую простым принципам, которые гарантируют выполнение проекта. Рассмотрим вариант создания программного продукта с «чистого листа», когда у вас есть только контакты с возможными заказчиками, да в записной книжке несколько телефонов специалистов, которых можно взять аналитиками в будущий проект.
1 Мы нашли заказчика (или он нас нашел). Независимо от того, насколько мы понравились друг другу, важно помнить: с этим человеком (группой людей, организацией, министерством и ведомством) нам предстоит работать. Но — это не обязательная кабала. Как бы ни было плохо с деньгами, именно вам решать, принимать его заказ или нет. Рубикон будет перейден именно после того момента, как вы подпишете контракт. Вас никто не заставляет, но вот после того, как чернила на бумаге высохнут, придется выполнять обещанное.
2 До составления договора необходимо провести оценку заказа и составить смету на выполнение работ. В зависимости от объема работ проведение оценки проекта может вестись либо по принципу «сейчас предоставим смету, контракт потом» (для маленьких проектов), либо в варианте «получить финансирование под разработку проектной документации» (для средних и больших проектов). Учитывая, что разработка оценивается в человеко-годах, не надейтесь, что вам удастся за пару дней разобраться в хитросплетениях проблем фирмы, завода или домашней бухгалтерии заказчика. А потраченное время, которое вам откажутся оплатить, уже вернешь. Я знаю случаи, когда Интернет-заказчики с удовольствием собирали проекты «под аукцион» идей и отдавали их сторонним работникам как собственные наработки. Так же я видел проекты, где работа аналитиков занимала больше года. И после начала работы над проектом аналитики были еще больше загружены. Поэтому подумайте — если заказчик не хочет оплатить системный подход к решению его проблем, то будет ли он вообще платить.

Учиться, учиться и учиться
Для оценки той или иной методики надо как минимум с ней ознакомиться. Вот одна из многочисленных ссылок (www.excelsoftware.com/methods.html), где собрана информация по методикам Shlaer/Mellor, Coad/Yourdon, OMT, Booch, Fusion, Jacobson, CRC Cards и др., с перечнем выпускаемой литературы и статей по данной тематике.
Из выпущенной у нас литературы могу предложить как вводные книги [2, 3], описывающие основы данных процессов, так и более академичные вещи, собранные либо в описании конкретных продуктов, либо в виде справочников [1, 4, 5].
Кроме того, рекомендую посетить специализированные сайты, объединяющие сторонников различных школ разработки. Эти сайты содержат не только свои собственные аналитические материалы, но и множество ссылок на подборки статей по их тематике, форумы сторонников и дают возможность получить самые свежие сведения в этой области [6–12].
[1] Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. — СПб.: Питер, 2002.
[2] Фаулер М., Скотт К. UML. Основы. — Символ-Плюс, 2002.
[3] Кратчен Ф. Введение в Rational Unified Process. — Вильямс, 2002.
[4] Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. — ДМК Пресс, 2001.
[5] Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов. — ДМК Пресс, 2002.
[6] www.interface.ru/rational/rup01_t.htm (Rational Unified Process). Очень рекомендую попытаться найти авторскую статью Леонида Новикова, который ведет этот раздел на сайте. Его Введения в Rational Unified Process являются достаточно полным разбором RUP и позволяют составить представление о данной методике. Единственный минус — я не видел этой статьи в Интернете, лишь в «хождении по рукам» (архив занимает более девяти мегабайт).
[7] www.rational.com — родной сайт Rational.
[8] www.projtech.com — методика Shlaer-Mellor (сущностный анализ).
[9] www.iconixsw.com — методика ICONIX.
[10] www.extremeprogramming.org, www. xprogramming.com — Extreme Programming.
[11] ootips.org — сборник ссылок на методы разработки объектного программного обеспечения. Есть ссылки как на методики, так и на инструментарий.
[12] Из наших серверов могу порекомендовать посмотреть кое-что на www.citforum. ru, как пример — www. citforum.ru/cfin/articles/ mpis.shtml.


3 Вне зависимости от того, в каком виде вы предоставите оценочный проект заказчику (хоть на глиняных табличках), внутри фирмы вы должны использовать какой-то один подход к разработке. Утвержденный набор инструментария и методов работы с информацией — это непреложный закон, за отступление от которого необходимо карать со всей жестокостью. Нет ничего более абсурдного, чем попытка переписать половину проектной документации, оформленной в той же Rational Rose, на чем-то «попроще», так как те же диаграммы состояний вызывают ступор у новых эникейщиков. Изучение материальной части никому еще не вредило, пусть убьют неделю на освоение, зато потом будут иметь шанс «долететь к вкусностям за час».
4 После того, как достигнута договоренность, проведена проектная разработка и удалось оценить общие цели и задачи, сделана прикидка по времени и подписаны первые пилотные документы по проекту, наступает пора задействовать аналитиков в полном объеме. На этом этапе та их часть, что трудилась над общей постановкой задачи, может переключиться на выделение общих сущностей, выделение общих предметных областей и взаимосвязей в будущей системе. Одновременно, под эти направления будут наниматься начальники групп разработки (проектных направлений). Обычно группа формируется из двух менеджеров проекта (администратор и технических директор), где один отвечает за согласование проектных проблем, ведет учет потраченного времени, решает вопросы усиления группы, или вывода части сотрудников на другие проекты. Второй является ведущим программистом данного блока и отвечает за решение технических проблем, распределяет объемы и направления кодирования, отвечает за качество итогового кода и тестирование работы. От того, насколько жестко и профессионально будут работать эти люди, зависит удача работы всей группы.
5 Одновременно с наймом будущих менеджеров проекта решаются вопросы используемого инструментария. Здесь играют роль глобальные задачи проекта, объемы обрабатываемой информации, возможность найти достаточное количество людей для использования выбранной технологии. Возможно, что вам лично симпатична АДА, которая используется для расчетов алгоритмов стрельбы гаубиц армии Соединенных Штатов, но найдете ли вы столько специалистов в наших степях?
6 На момент формирования костяка разработки вы должны уже знать, сколько времени потребуется на сдачу написанного «под ключ». Возьмите лучшее из всего доступного вам. Никто не заставляет использовать тот же RUP в этом проекте, но попробуйте использовать его идеи для оценки трудозатрат и сроков, которые надо выдержать. Еще до того момента, как аналитики закончат оценку и проектную разработку бизнес-логики задачи, вы должны знать, сколько человек вам понадобится для написания основных системных вещей в проекте и кодирования экранных форм, скрывающих для заказчика всю реальную начинку программ. К сожалению, здесь обычно скрывается очень неприятный «подводный камень», когда итоговые цифры требуемых программистов приводят в ужас администрацию проекта, и они начинают их сокращать за ненадобностью. Проблема в том, что один гений еще может продвинуть разработку и завершение проекта со сроками в месяц-два, но при решении больших задач отдельно взятая гениальность меркнет перед необходимостью выполнить определенный объем работы и одиночка физически не в состоянии справиться «со всем и за всех». Левша подкует блоху за неделю, но не сможет построить небоскреб за месяц. А если еще учесть текучку кадров, драконовские требования техдиректоров работать, а не шляться по чатам, то картина софтверного апокалипсиса вырастает в полный рост.
7 Под поставленные задачи ваши менеджеры набирают людей. Администратор имеет две вводные — суммарные рамки зарплаты на отдел и объем работ, под которые и формирует с техдиректором будущий коллектив. И именно они отвечают за итоговую удачу работы этого отдела. Попытка руководства вмешиваться во внутренние взаимоотношения отдела — первый шаг к потере инициативы вашими людьми. Если они будут отвечать за свои решения, то и к своим будущим коллегам отнесутся с большим вниманием.
8 На этом же этапе аналитики заканчивают работу над бизнес-логикой экранных форм, и проводится утверждение этого материала у заказчика в виде договора.
9 К моменту, когда вы сформировали весь коллектив, включая озабоченных наличием «Lines» секретарш, для программистов уже должны быть подготовлены аналитиками общие сущности, описаны потоки информации в системе и вся бизнес-логика. После этого вы сможете или перебросить группу аналитиков на другой проект, или оставить лишь часть из них для последующей работы. Мавр сделал свое дело, построил идеологию системы, он может уходить.
10 К моменту, когда будут прописаны общие принципы системы и дело начнет подходить к наполнению жизнью форм взаимодействия с пользователем, у вас должен появиться и заработать механизм выпуска внутренних альфа-версий программного обеспечения. Все написанное за день должно собираться в одно целое и прогоняться на внутренних тестах. К утру статистика выполненных работ должна лежать на столах выпускающих данный билд (build) людей и всех менеджеров проекта. Чтобы они озаботились нестыковками, проколами и явным разгильдяйством подчиненных. Лишение сладкого и Интернета должно способствовать повышению их работоспособности.
11 И, наконец, после завершения работ по всем направлениям, после получения положительных итогов проведения тестирования, наступает радостный момент внедрения. Теперь вы должны подключить к работе тех милых людей, которые имеют железные нервы и приклеенную бесконечную улыбку, способных по двести раз на дню показать именно то место в руководстве пользователя, где говорится именно об этой кнопке, которую не может найти именно этот пользователь… Здесь и организация группы «горячих телефонов», и война менеджеров отделов между собой с выяснением главного вопроса — кто виноват в очередной выявленной ошибке и многое другое, составляющее собой часть мозаики перед полной сдачей проекта и появлением у вас желания уехать на дачу из этого Содома и Гоморры, навстречу скуке и неполотым грядкам. Откуда вы через какое-то время сбежите навстречу новому клиенту и новому проекту…
Да, надеюсь, что новость о том, что написанная вами система для Windows 2000 & MS SQL 2000 & MS Office не может почему-то быть установлена на сервера клиента под SUN и рабочие места под Linux RH не станет для вас неприятной. В жизни бывает всякое, а проектную документацию лучше все же читать и самому, а не оставлять все на откуп начальникам отделов4

«Хвост» проекта
Практика — это лучший из способов свернуть себе шею. Но не попробуешь — не узнаешь. Поэтому я могу лишь посоветовать вам занять у друзей две вещи — наличные и терпение. Первое вам понадобится для покупки литературы, аренды офиса и приобретения стильной визитницы. Второе — для воплощения в жизнь того проекта, который должен вписать ваше имя в галерею великих людей, создающих программное обеспечение, вытесняющее кухарок с мест управления государством.
А там, глядишь, и сбудется моя мечта и я смогу занять место вашего секретаря и найти наконец-то время для улучшения своего же собственного рекорда в Lines в десять очков… До встречи.

Хождение по личным граблям — дело всех и каждого
Я еду на дачу…
(С) Ленинград. «Дачники»

Ниже я перечисляю те методики, которые использовались и либо остались в нашем повседневном арсенале, либо используются ограниченно и для каких-то локальных рабочих моментов.
RUP и продукты семейства Rational — применяется в «урезанном» объеме. Используется для построения бизнес-логики системы, выделения общих сущностей и процессов взаимодействия между ними (Rational Rose). В некоторых работах мы использовали Rational до уровня генерации итогового кода. Но чаще итоговое кодирование отдавалось «на откуп» разработчикам. Используется блок тестирования (Rational Test Factory, Rational Test Manager). Некоторые «сторонние» блоки и чужой код в случае необходимости экспортировался в систему и подвергался реинжинирингу с помощью возможностей пакета.
Совместная работа аналитика и программиста имеет границу на уровне создания классов. Все, связанное с кодированием, выносится в отдельные предметные «папки», за которые отвечает только программист.
Из недостатков методики можно отметить тяжесть выполнения всего объема операций, которые требуются по умолчанию. Поэтому мы чаще используем следующий вариант.
ICONIX — ключевым пунктом которого является создание диаграмм пригодности, соединяющими модель прецедентов и диаграммы последовательностей. Главной проблемой при использовании этой методики является требование выдерживать жестко цикличность разработки и не срываться на «водопад» в случае перехода от утвержденной бизнес-логики к этапам кодирования. Вместе с тем, учитывая сложность разрабатываемых систем, объем аналитики и итогового кода, именно данная методика позволяет ориентироваться на максимально быстрое прохождение всей цепочки проекта и выпуск итогового работающего кода. В отличие от RUP, ICONIX позволяет упростить часть разработки не в ущерб конечному продукту, ускоряя весь проект и не позволяя терять его управляемость.
Из стоящих рядом по нацеленности на итог можно отметить Extreme Programming (XP). Ключевыми моментами XP является установка на использование в проектах представителя заказчика (для ускорения постановки задачи и ускорения реакции на возможные изменения требований со стороны заказчика) и нацеленность на максимальную эффективность в получении итогового кода. Это и участие программистов в анализе задачи; и парное программирование, ориентированное на взаимозаменяемость разработчиков в случае перевода кого-то из пары на другой участок; и отсутствие при этом замедления процесса разработки.
В чем-то XP похож на развитие методов решения проблемы «мозговым штурмом», вместе с тем недостатком этой методики я считаю сложность использования ее в крупных проектах, когда еще до его начала приходится вести большую аналитическую и подготовительную работу. Интересующимся я хочу предложить переводную статью моего бывшего коллеги Вячеслава Иванова, которая так и называется — «Extreme Programming» (home.comset.net/ pxsl/p_xp.htm).
Остальные методики в реальных проектах я не использовал и могу лишь рекомендовать попробовать их самостоятельно.
Частные беседы с коллегами, работающими за рубежом, позволяют добавить к сказанному несколько замечаний.
Для больших проектов необходим жесткий контроль на уровне ролей в RUP (человек, играющий роль аналитика, не лезет в разработку, вместе с тем программист понимает блоки анализа, предоставленные ему, но не пытается заниматься дополнительным анализом полученных схем). При этом методику нередко используют в «урезанном» варианте, получая UML-документы, диаграммы классов и диаграммы последовательностей. После чего готовые классы отдаются на откуп программистам.
В средних и небольших работах часто используют CRC-карточки. Диаграммы для утверждения у заказчика создаются на смеси Rational/Together/Visio/MS Word, что позволяет не тратить время на тотальное документирование кода.
Как заметил один из коллег: «Видимо проекты, выполненные 100% на Rational, существуют только в университетах. RUP — вполне здравый подход, только не нужно создавать из него религию». Эту точку зрения разделяют и те, кто часто использует в работе связку agile/XP.


1 Outsourcing — удаленная разработка программного обеспечения. Члены коллектива используют Internet для связи друг с другом и могут находиться в любой стране.
2 Под риском в данном случае понимается любой из факторов (или их совокупность), способных повлиять на итоговое выполнение работы. Они могут подразделяться на прямые и косвенные, иметь различную вероятность возникновения и осуществления, разный уровень последствий.
3 (С) австралийские разработчики, 2002 год.
4 Вспоминая знакомого, написавшего административную обвязку для сайта с использованием asp-скриптов. И который был удивлен требованием использовать для этого Perl, как и было заявлено в подписываемом договоре. «А какая разница, ведь все равно это будет работать на сервере?..» И долго еще эхо из телефонной трубки поминало поручика Ржевского.

© ООО "Компьютерра-Онлайн", 1997-2021
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.