Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

16.01.2017

Google
WWW CITForum.ru
С Новым годом!
2006 г.

Качественный успех

Артём Ваулин,
Руководитель группы тестирования,
КОРУС Консалтинг

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

Существует множество различных способов для достижения этих целей. В рамках же данного монолога хотелось бы немного поговорить о КАЧЕСТВЕ. Не о каком-то абстрактном качестве из Большой Советской Энциклопедии (или из Модных Западных Стандартов), а о том реальном КАЧЕСТВЕ производимых, разрабатываемых и внедряемых нами продуктов и услуг, которое позволяет сделать эти самые продукты и услуги лучшими и, как следствие, приближает нас к заветным целям.

Я попытаюсь рассмотреть два аспекта:

  1. Как качественный продукт сможет помочь в достижении обозначенных выше целей.
  2. Как сделать продукт качественным.

Но сначала буквально несколько слов о КАЧЕСТВЕ. Что же это собственно такое, какова цена качества и с помощью чего оно достигается?

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

Взгляд Заказчика на качество:«Должно быть удобным в использовании» ( Joseph Juran ).
Взгляд Исполнителя на качество:«Должно удовлетворять требованиям» ( Phillip Crosby ).

Из чего же складывается цена этого самого КАЧЕСТВА?

  1. Цена сбоев — это цена, определяющаяся затратами на выявление и исправление ошибок и выхода из строя. Такие затраты бывают внутренними и внешними: внутренние связаны с проблемами, выявленными до отправки заказчику (сюда входит переработка продукта и тестирование), внешние — уже отправленный продукт (простои, затраты на восстановление, сопровождение и поддержку).
  2. Цена оценки качества — издержки на контроль качества: издержки на тестирование продукта.
  3. Цена превентивных усилий — затраты на обучение, затраты на проектирование процесса, затраты на планирование качества, затраты на предотвращение ошибок.

То, с помощью чего достигается достойное качество, видно из перечисленных выше составляющих: превентивные меры и тестирование.

Так что же выгоднее компании и Заказчику? Ошибки до отправки (когда они еще не приносят никаких убытков) или после (когда низкое качество продукта негативно влияет на бизнес Заказчика — и он несет убытки)? Об этом ниже.

Как качественный продукт сможет помочь в достижении обозначенных выше целей

Итак, каким же образом разработка качественного продукта сделает жизнь наших Заказчиков и, как следствие, нашу жизнь лучше?

В качестве ответа на этот вопрос я вижу следующие возможности:

  1. Тестирование ПО снизит количество его возвратов на доработку разработчикам (в том числе и возвратов от Заказчика и от конечных пользователей) во время внедрения и, что особенно важно, когда продукт находится в промышленной эксплуатации. Это позволит:
    • сократить трудозатраты разработчиков на доработки, исправление и сопровождение продукта;
    • сократить отвлечение разработчиков и консультантов (для этих самых доработок) от других проектов;
    • как следствие двух вышеперечисленных пунктов — проект будет укладываться в выделенный бюджет и сроки (если сейчас с этим есть проблемы) — это ли не мечта любого руководителя?
  2. Тестирование на проектах приведет к значительному снижению как ошибок, так и запросов, поступающих в группу тех. поддержки. Это позволит:
    • сократить трудозатраты специалистов группы тех. поддержки, а также людей, которые будут заниматься исправлением возникающих ошибок;
    • повысить удовлетворенность и лояльность Заказчика, что, между прочим, дорогого стоит.
  3. Тестирование на проектах позволит снизить риски возникновения сбоев ПО у Заказчика, из-за которых он может терять реальные деньги.

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

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

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

Как сделать продукт качественным

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

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

Ниже лишь тезисно обозначу основные моменты такого процесса тестирования.

I Необходимые изменения процесса тестирования на проектах (если они еще не реализованы)

1. Персонал

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

Это чисто психологический момент — человек, создавший что-то (в нашем случае разработчики и консультанты) не склонен специально разрушать свои творения. А у тестировщиков работа такая!

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

2. Организация процесса тестирования

  • разработать/применять единую программу/методику/план тестирования;
  • тестирование обязательно должно быть выделено в отдельный этап, в отдельный вид деятельности;
  • обязательно должно быть организовано специальное тестовое окружение (тестовая лаборатория).

3. Документирование

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

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

4. Управление ошибками

  • использование системы отслеживания проблем (BTS — Bug Tracking System);
  • формализация процесса управления ошибками.
II Виды проводимого тестирования

1. Тестирование требований (документации)

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

При тестировании и анализе документации следует уделять внимание на следующие критерии качества требований:

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

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

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

2. Приемочное тестирование

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

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

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

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

Ряд приемочных тестов можно автоматизировать.

3. Функциональное (ручное) тестирование

Основной вид тестирования, направленный на проверку всех требований Заказчика.

4. Регрессионное (автоматизированное) тестирование

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

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

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

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

5. Тестирование производительности (нагрузочное тестирование, стрессовое тестирование)

Тестирование производительности (Performance testing) — любое тестирование, при котором производится оценка характеристик производительности (таких как скорость работы, использование ресурсов и т.п.) и сравнение их с ожидаемыми.

Нагрузочное тестирование (Load testing) — испытание системы под большой нагрузкой. При этом могут проверяться как функциональные характеристики (корректность работы под большой нагрузкой), так и характеристики производительности.

Стресс-тестирование (Stress testing) — разновидность нагрузочного тестирования, испытание системы под большой пиковой нагрузкой (в противоположность большой продолжительной загрузке).

III Возможная схема этапов разработки и тестирования

11.gif

Возможная схема этапов разработки и тестирования [ открыть крупнее ]

IV Обязательные документы

1. Регламент тестирования

Целью регламента тестирования является:

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

2. План тестирования

План тестирования разрабатывается один раз для каждого проекта (обычно его разработка начинается на ранних стадиях проекта). Во время выполнения проекта план тестирования корректируется, дополняется и углубляется по мере необходимости.

Цель плана тестирования — обеспечить полноту процесса тестирования.

План тестирования разрабатывается на основе технического задания — требований к продукту.

В плане тестирования описываются способы, виды и критерии тестирования для всех требований, необходимые ресурсы и порядок выполнения тестирования.

План тестирования согласуется со всеми ключевыми членами рабочей группы и утверждается менеджером проекта.

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

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

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

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

4. Спецификация тестов

Разрабатывается отдельно для тестирования каждой функциональности.

Цель — дать полное определение тестов, определяемых спецификацией проектирования тестов.

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

5. Спецификация проектирования процедуры тестирования

Цель — определить набор последовательных действий для полного тестирования определенного набора требований для определенного тестируемого элемента. Тестовая процедура определяет действия для выполнения набора тестовых спецификаций.

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

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

6. Отчеты тестирования

Отчеты тестирования заполняются в процессе проведения тестирования.

Целью отчетов тестирования является отслеживание состояния качества тестируемого программного продукта.

V Количественная оценка процесса тестирования

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

Наименование метрики Описание Классификация
Количество ошибок В процессе тестирования производится вычисление количества выявленных ошибок, включая количество разрешенных и оставшихся ошибок. Качество
Степень серьезности ошибок Количество ошибок, распределенных по уровням приоритета. Эта метрика показывает количество проблем продукта, о которых были составлены отчеты, перечисляемые согласно приоритетам. Качество
Тестовое покрытие Общее количество тестов / общее количество требований. Измерение тестового покрытия показывает плановое тестовое покрытие. Покрытие
Статус выполнения тестов Количество выполненных тестов / общее количество тестов. Статус тестов показывает объем еще не выполненных работ по тестированию. Ход выполнения работ
Коэффициент обнаружения ошибок Общее количество найденных дефектов / количество выполненных тестов. Эта метрика используется для анализа и поддержки решения о целесообразности выпуска продукта. Ход выполнения работ
Коэффициент состояние качества Количество успешно выполненных тестов (без обнаружения дефектов) по отношению к общему количеству тестов. Коэффициент состояние качества показывает, какая часть функция приложения продемонстрировала успешную работу. Качество
Плотность дефектов Общее количество найденных дефектов / количество тестов на функцию (т.е. на сценарий использования системы или на требование к тестам). Плотность дефектов помогает обнаружить тот факт, что в одной из частей тестируемой функциональности появляется особенно большое число ошибок. Качество

2. Тестирование производительности

— стандартные метрики

Измерение Описание

Время отклика на команду
(Response time per command)

Трассировка времени отклика для каждой отдельной команды, которая посылается через сеть на сервер.

Время отклика на таймер
(Response time per timer)

Высокоуровневое время отклика, основанное на выполнении конкретных бизнес-функций и/или сценариев.

— метрики аппаратного обеспечения

Измерение Описание

Время отклика на команду
(Response time per command)

Трассировка времени отклика для каждой отдельной команды, которая посылается через сеть на сервер.

Время отклика на таймер
(Response time per timer)

Высокоуровневое время отклика, основанное на выполнении конкретных бизнес-функций и/или сценариев.
VI Возможности при использовании системы отслеживания проблем
  • удобный веб-доступ для совместной работы
  • создание/хранение запросов (ошибка, задача, новая функциональность, предложение, информация)
  • группировка запросов (по компонентам, по версиям)
  • назначение запросов исполнителям
  • настройка жизненного цикла запроса
  • настройка политики безопасности (доступа)
  • настройка системы оповещения
  • настройка необходимых полей
  • отслеживание текущего состояния (статуса) запросов
  • построение различных выборок по интересующим запросам (по любым параметрам)
  • выгрузка выборок в Excel
  • консолидированные сводки по компонентам, версиям
VII Преимущества централизованной группы тестирования перед локальными группами тестирования (или специально назначенными для этого людьми) из числа проектной команды.
Положительные стороны
Централизованная группа Внутри проектных команд
  • Есть сотрудник, который отвечает за поддержание уровня квалификации группы тестирования
  • Группа тестирования включает специалистов – тестировщиков с разнообразными умениями и навыками в программировании и тестировании
  • Централизованная группа может назначать сотрудников в проект на условиях неполной загрузки
  • Специалисты – тестировщики могут назначаться в проект для выполнения работ на начальном этапе
  • Опытные тестировщики могут обучать начинающих тестировщиков
  • Тестировщики получают опыт работы с различными технологиями и инструментами
  • Улучшается обмен опытом и технологиями среди тестировщиков
  • Поддерживаются репозиторий процессов тестирования, результатов оценки инструментов тестирования и программы библиотек автоматизированного тестирования
  • Полное управление тестированием сохраняется в рамках проектной группы
  • Возможность привлечения консультантов на кратковременной основе

Отрицательные стороны

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

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

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

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...