Консалтинг в области разработки ПО
|
|
|
Реклама:
Наши партнёры:
Наша рассылка:
Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1 - метрикиСтатьи → Управление конфигурациями и изменениями (Subversion, IBM Rational ClearCase, ClearQuest и Jira) → Метрики кода
Полезные материалы о конфигурационном управлении:
Метрики кода и их практическая реализация в Subversion и ClearCase . Часть 1 - метрики
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Пример из жизни: На наш взгляд оценка по количеству строк в коде влечёт за собой соблазн написать побольше строк, дабы взять побольше денег. Разумеется, об оптимизации в таком продукте никто уже думать не станет. Вспомним историю о том, как планетарный центр аутсорсинга - Индия, после того, как заказчики вменили им метрику LOC, на второй день показал удвоение и утроение строк кода. |
Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.
Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: «одна строка кода = одна команда языка». Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.
Потому метод LOC является только оценочным методом (который надо принимать к сведению, но не опираться в оценках) и никак не обязательным.
В зависимости от того, каким образом учитывается сходный код, выделяют два основных показателя SLOC:
- количество «физических» строк кода – SLOC (используемые аббревиатуры LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение – при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода).
- Количество «логических» строк кода – SLOC (используемые аббревиатуры LSI, DSI, KDSI, где «SI» - source instructions) – определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество «логических» SLOC будет соответствовать числу «физических», за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка.
Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:
- число пустых строк;
- число строк, содержащих комментарии;
- процент комментариев (отношение строк кода к строкам комментария, производная метрика стилистики);
- среднее число строк для функций (классов, файлов);
- среднее число строк, содержащих исходный код для функций (классов, файлов);
- среднее число строк для модулей.
2.1.1.1 Метрика стилистики и понятности программ
Иногда важно не просто посчитать количество строк комментариев в коде и просто соотнести с логическими строчками кода, а узнать плотность комментариев. То есть код сначала был документирован хорошо, затем – плохо. Или такой вариант: шапка функции или класса документирована и комментирована, а код нет.
Fi = SIGN (Nкомм. i / Ni – 0,1)
Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi
2.1.2 Итого по SLOC
Потенциальные недостатки SLOC, на которые нацелена критика:
- некрасиво и неправильно сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности. Менеджер может назначить наиболее талантливых программистов на сложнейший участок работы; это означает, что разработка этого участка займёт наибольшее время и породит наибольшее количество ошибок, из-за сложности задачи. Не зная об этих трудностях, другой менеджер по полученным показателям может решить, что программист сделал свою работу плохо.
- Метрика не учитывает опыт сотрудников и их другие качества
- Искажение: процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк (см. врезку про Индию).
- Неточность: нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы .
|
Пример из жизни : Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIP- клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало. |
Согласитесь, считать трудозатраты по данной метрике глупо – необходима комплексная оценка…
2.2 Метрики сложности
Помимо показателей оценки объема работ по проекту очень важными для получения объективных оценок по проекту являются показатели оценки его сложности. Как правило, данные показатели не могут быть вычислены на самых ранних стадиях работы над проектом, поскольку требуют, как минимум, детального проектирования. Однако эти показатели очень важны для получения прогнозных оценок длительности и стоимости проекта, поскольку непосредственно определяют его трудоемкость.
2.2.1 Объектно-ориентированные метрики
В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов.
| Метрика | Описание |
|---|---|
| Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC) | Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются. |
| Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2)) | Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются. |
| Глубина дерева наследования (Depth of inheritance tree) | Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков. |
| Количество детей (Number of children) | Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции. |
| Связность объектов (Coupling between objects) | Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода. |
| Отклик на класс (Response For Class) | Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов |
2.2.2 Метрики Холстеда
Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.
Основу метрики Холстеда составляют четыре измеряемые характеристики программы:
- NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);
- NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов);
- Noprtr (Number of Operators) — общее число операторов в программе;
- Noprnd (Number of Operands) — общее число операндов в программе.
На основании этих характеристик рассчитываются оценки:
- Словарь программы (Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd;
- Длина программы (Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd;
- Объем программы (Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc;
- Сложность программы (Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd);
- На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort): HEff = HDiff × HPVol.
2.2.3 Метрики цикломатической сложности по Мак-Кейбу
Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами – в виде дуг.
Показатель цикломатической сложности позволяет не только произвести оценку трудоемкости реализации отдельных элементов программного проекта и скорректировать общие показатели оценки длительности и стоимости проекта, но и оценить связанные риски и принять необходимые управленческие решения.
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e – n + 2,
Как правило, при вычислении цикломатической сложности логические операторы не учитываются.
В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы.
Цикломатическое число Мак-Кейба показывает требуемое количество проходов для покрытия всех контуров сильносвязанного графа или количества тестовых прогонов программы, необходимых для исчерпывающего тестирования по принципу «работает каждая ветвь».
Показатель цикломатической сложности может быть рассчитан для модуля, метода и других структурных единиц программы.
Существует значительное количество модификаций показателя цикломатической сложности.
- «Модифицированная» цикломатическая сложность – рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое.
- «Строгая» цикломатическая сложность – включает логические операторы.
- «Упрощенное» вычисление цикломатической сложности – предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.
2.2.4 Метрики Чепина
Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования – достаточно эффективный вариант этой метрики.
Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на четыре функциональные группы.
- Множество «Р» – вводимые переменные для расчетов и для обеспечения вывода. Примером может служить используемая в программах лексического анализатора переменная, содержащая строку исходного текста программы, то есть сама переменная не модифицируется, а только содержит исходную информацию.
- Множество «М» – модифицируемые или создаваемые внутри программы переменные.
- Множество «C» – переменные, участвующие в управлении работой программного модуля (управляющие переменные).
- Множество «Т» – не используемые в программе (“паразитные”) переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.
Далее вводится значение метрики Чепина:
Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.
Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку “паразитные” переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:
Q
= P + 2M +
2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы
При использовании интегрированных инструментальных средств у компаний, разрабатывающих типовые решения (под эту категорию попадают так называемые «инхаузеры» – компании, занимающиеся обслуживанием основного бизнеса) появляется возможность строить прогнозы сложности программ, основываясь на собранной статистике. Статистический метод хорошо подходит для решения подобных типовых задач и практически не подходит для прогноза уникальных проектов. В случае уникальных проектов применяются иные подходы, обсуждение которых находится за рамками данного материала.
Типовые задачи как из рога изобилия падают на отделы разработки из бизнеса, потому предварительная оценка сложности могла бы сильно упростить задачи планирования и управления, тем более что есть накопленная база по проектам, в которой сохранены не только окончательные результаты, но и все начальные и промежуточные.
Выделим типовые этапы в разработке программ:
- разработка спецификации требований к программе;
- определение архитектуры;
- проработка модульной структуры программы, разработка интерфейсов между модулями. Проработка алгоритмов;
- разработка кода и тестирование.
Теперь попробуем рассмотреть ряд метрик, часто используемых для предварительной оценки на первых двух этапах.
2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе
Для оценки по результатам работы данного этапа может быть использована метрика прогнозируемого числа операторов Nпрогн программы:
Nпрогн =NF*Nед
Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед - статистическое.
2.3.2 Предварительная оценка сложности на этапе определения архитектуры
Си = NI / (NF * NIед * Ксл)
Где:
NI – общее количество переменных, передаваемых по интерфейсам между
компонентами программы (также является статистической);
NIед–единичное значение количества переменных, передаваемых по
интерфейсам между компонентами (среднее число передаваемых по
интерфейсам переменных, приходящихся на одну среднюю функцию или
требование);
Ксл – коэффициент сложности разрабатываемой программы, учитывает рост
единичной сложности программы (сложности, приходящейся на одну функцию
или требование спецификации требований к программе) для больших и
сложных программ по сравнению со средним ПС.
2.4 Общий списочный состав метрик
Таблица 1 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.
Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.
Таблица 1 – Состав метрик их влияние и анализ эффективности использования
|
Наименование метрики |
Описание краткое |
Описание детальное |
Класс или тип метрики |
|
Метрика Майерса |
Интервальная мера |
Сложность программ определяется в виде отрезка |
Топологическая |
|
Метрика Джилба |
Логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики: CL - абсолютная сложность программы, характеризующаяся количеством операторов условия; cl - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. cl определяется как отношение CL к общему числу операторов:
|
Топологическая |
|
|
Метрика Хансена |
Пара (цикломатическое число, число операторов) |
(A , B), где A - метрика Маккейба, B - число исполняемых операторов. |
Топологическая |
|
Метрика Чена |
Топологическая метрика Чена |
M(G) = (n (G), N, Q0) |
Топологическая |
|
Метрика Вудворда |
Узловая мера (число узлов передач управления) |
На полях листинга рисуются линии передачи управления от одного оператора к другому (предполагается, что один оператор занимает ровно одну строчку). Число пересечений этих линий даёт значений метрики. |
Топологическая |
|
Метрики Харрисона, Мейджела |
Функциональное число (сумма приведенных сложностей всех вершин
управляющего графа); |
Данная мера учитывает уровень вложенности и протяженность программы. Каждой вершине присваиваем свою сложность в соответствии с оператором, который она изображает. Эта начальная сложность вершины может вычисляться любым способом, включая использование мер Холстеда. Выделим для каждой предикатной вершины подграф, порожденный вершинами, которые являются концами исходящих из нее дуг, а также вершинами, достижимыми из каждой такой вершины (нижняя граница подграфа), и вершинами, лежащими на путях из предикатной вершины в какую-нибудь нижнюю границу. Этот подграф называется сферой влияния предикатной вершины. Приведенной сложностью предикатной вершины называется сумма начальных или приведенных сложностей вершин, входящих в ее сферу влияния, плюс первичная сложность самой предикатной вершины. Функциональная мера (SCOPE) программы -— это сумма приведенных сложностей всех вершин управляющего графа. Функциональным отношением (SCORT) называется отношение числа вершин в управляющем графе к его функциональной сложности, причем из числа вершин исключаются терминальные. SCORT принимает разные значения для графов с одинаковым цякломатиче-ским числом. |
Топологическая |
|
Метрика Пивоварского |
Модифицированная цикломатическая мера сложности |
Мера Пивоварского ставит целью учесть в оценке сложности ПС различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = v*(G) + Σ Pt, где v*(G) – модифицированная цикломатичес-кая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с я-выходами рассматривается как один логический оператор, а не как п–1 оператор, Р1 – глубина вложенности i-й предикатной вершины. Для подсчета глубины вложенности предикатных вершин используется число “сфер влияния”. Под глубиной вложенности понимается число всех “сфер влияния” предикатов, которые либо полностью содержатся в сфере рассматриваемой вершины, либо пересекаются с ней. Глубина вложенности увеличивается за счет вложенности не самих предикатов, а “сфер влияния”. Сравнительный анализ цик-ломатических и функциональных мер с обсуждаемой для десятка различных управляющих графов программы показывает, что при нечувствительности прочих мер этого класса, мера Пивоварского возрастает при переходе от последовательных программ к вложенным и далее к неструктурированным. |
Топологическая |
|
Метрика Мак-Клура |
Мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных; |
Выделяются три этапа вычисления данной метрики: |
Метрика, направленная на измерение архитектуры системы |
|
Метрика Кафура |
Вводятся понятия
локального и глобального потока:
|
Метрика, основанная на учёте потока данных |
|
|
Метрика Зольновского, Симмонса, Тейера |
Взвешенная сумма различных индикаторов |
(структура, взаимодействие, объем, данные) |
Гибридная |
|
Метрика Янгера |
Сложность
проектирования |
Логическая сложность с учетом истории вычислений |
Топологическая |
|
Метрика 'Подсчет точек пересечения' |
Поток управления программы считается более сложным, если возникают точки пересечения дуг передачи управления. |
В графе программы, где каждому оператору соответствует вершина, т. е. не
исключены линейные участки, при передаче управления от вершины a к b номер оператора a равен min(a,b), а номер оператора b - max(a,b). Точка пересечения
дуг появляется, если |
Метрика сложности потока управления программ |
|
Метрика граничных значений |
Считается число входов и выходов из узловых точек графа программы. |
Пусть G=(V,E) - ориентированный
граф программы. Число входящих вершин у дуг называется отрицательной степенью
вершины, а число исходящих из вершины дуг - положительной степенью вершины.
Вершины у которых положительная степень <=1 назовем принимающими
вершинами, а вершины у которых положительная степень >=2 вершинами отбора. |
Метрика сложности потока управления программ |
|
Метрика обращения к глобальным переменным |
Пара (модуль,
глобальная переменная) (фактическая/возможная) |
Пара
"модуль-глобальная переменная" обозначается как (p,r), где p - модуль, имеющий
доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа
пар "модуль-глобальная переменная" : фактические и возможные.
Возможное обращение к r с помощью p показывает, что
область существования r включает в себя p. |
Метрика сложности потока данных |
|
Метрика спена |
Определение спена основывается на локализации обращений к данным внутри каждой программной секции. |
Спен - это число утверждений, содержащих данный идентификатор, между его первым и последним появлением в тексте программы. Следовательно, идентификатор, появившийся n раз, имеет спен, равный n-1. При большом спене усложняется тестирование и отладка. |
Метрика сложности потока данных |
|
Набор метрик Чидамбера и Кемерера (WMC, DIT, NOC, CBO, RFC, LCOM) |
Вводится ряд метрик, в сумме дающие представление о сложности ОО-кода. |
WMC - Weighted methods per class (вычисляется сложность
методов каким-либо способом и берётся сумма сложностей) |
Метрика для ООП программ |
|
Связность |
Степень зависимости каждого модуля от каждого из остальных модулей |
Content coupling (связность по содержимому) |
Топологическая |
|
Характеристический полином PCN |
Вычисляется сложность с учётом циклической структуры. |
Для управляющего графа программы строится иерархия вложенных подграфов с
одним входом и одним выходом в виде диаграммы, в которой точки на (i+1)м уровне обозначают
отдельные вершины и вложенные структуры подграфа, размещённого на i-м уровне. |
Топологическая |
|
Метрика Овиедо |
Поток данных считается более сложным, если он более сложный в составляющих частях программы, где при определённом разбиении программы он считается достаточно просто. |
Программа разбивается на линейные непересекающиеся участки - лучи -
операторов, которые образуют управляющий граф программы. |
Метрика, основанная на учёте потока данных |
|
Метрика Тая |
Улучшение метрики Маккейба. |
Сложность программы определяется измерением информационного потока данных. Метрика исследует влияние определений данных и их использование при наличии операторов if и while. |
Метрика, основанная на учёте потока данных |
|
Метрика Кокола |
Комплексная метрика, основанная на более простых. |
H_M = (M + R1 *
M(M1) + … + Rn * M(Mn)/(1 + R1 + … + Rn) |
Гибридная |
|
Метрика Деметера |
Метрика основана на предположении, что чем меньше взаимодействие между классами, тем проще, а следовательно лучше, исходный код. |
VOD - Violations of the Law of Demeter (нарушения закона Деметера) Закон Деметера пытается минимизировать взаимодействие между классами. Если класс следует этому закону, то его методы могут вызывать методы из ограниченного множества других классов. Такое множество состоит из аттрибутов объекта, классов параметров метода или классов объектов, созданных локально в процессе исполнения метода. |
Метрика для ООП программ |
|
Метрики оценки графа параллельности |
Вычисление числа вершин в задаче основано на подсчёте числа вершин ее управляющего графа. После этого легко находится число вершин графа параллельности. |
W = (N/T)^(T/2) |
Метрика сложности для распределенных систем |
2.5 Подведение итогов. Метрики и их влияние и анализ эффективности использования
Ниже, в таблице предоставлена сводная оценка по базовым метрикам в стиле: ЧТО -- ЗАЧЕМ -- НА ЧТО ВЛИЯЕТ
Таблица 2 – Состав метрик их влияние и анализ эффективности использования
| Метрика | Зачем нужна | Влияет на… | Анализ на основе статистических данных (как тренд, так и прогноз) |
|---|---|---|---|
| Усилия разработчика при реализации. | Насколько эффективен труд разработчика. | Точность прогнозов оценки трудоемкости при выполнении организацией типовых или мало отличающихся запросов | Можно анализировать усилия разработчика во временном срезе или в срезе по релизам или проектам. Выявлять, на каких задачах программист полностью выкладывается, а какие ему не по душе. Тренд позволит менеджеру лучше понимать, кто и каких задачах максимально эффективен при формировании команды нового проекта, а также какие подсистемы относительно сложны, а какие – просты. |
| Длина и объем программы |
|
Оценку объема изменений | Увеличивается или уменьшается объем программы во времени. Используем для прогноза сложности на ранних этапах на основе статистики. |
| Анализ цикломатической сложности. |
|
Оценку сложности изменений | Сложность растет или нет? Используем для прогноза сложности на ранних этапах на основе статистики. |
| Усилия программиста при разработке. | Для определения сложности реализации того или иного блока кода (класса, функции и т.д.) | Понимание того, насколько интеллектуально-затратной для разработчика была та или иная функция. | Анализируется увеличение или уменьшение усилий разработчика во времени. На предварительных этапах метрику можно использовать для прогноза. |
| Количество строк на реализацию требования. | Меряем общую температуру. Эта метрика принимается во внимание при анализе реализации запроса. | Понимание КПД.Отслеживаем всплески. | Сигнал опасности при выявлении увеличения количества строк во время выполнения типового запроса Используем для оценки сложности на ранних этапах на основе статистики. |
| Количество комментариев на единицу кода. | Код должен быть документирован. Если соотношение кода к комментарию не 1:4, то разработчик обязан доработать. | Качество кода, его прозрачность. | Общая культура разработчиков растет или нет? Если растет – хорошо. Если нет – плохо. Если скачкообразно – соотносим менеджеров\руководителей проектов со скачками. Выделяем сложные проекты, проблемные модули или подсистемы |
| Прочие количественные метрики (число функций, классов, файлов). | Отношение новых функций к измененным. | Количество добавленных, удаленных и измененных строк по отношению к предыдущей версии. | Глубокий анализ изменений по релизам (версиям, сборкам) дает понять: Количество изменений (на что угодно) – сколько раз один и тот же блок кода корректировался. Возможно выявить узкое место в программе: интенсивно меняющийся блок кода может влиять на общее качество программы (потенциальное место возникновения ошибок). Возможно, необходимо изменить архитектуру блока. |
| Плотность дефектов на единицу кода. | Количество дефектов на 1-у строку кода | Производная метрика: количество строк/число дефектов. | Данная метрика более полезна для временной оценки: Плотность увеличивается от билда к билду, от версии к версии? Плотность дефектов по подсистемам (выявляем проблемную подсистему. В этом случае показатель почти наверняка будет коррелироваться с метрикой, отвечающей за интенсивность изменений участка кода, так как в этом месте наверняка «тонко») |
Кончено же, вся информация хранится в унифицированном виде в репозитории. Анализ возможен из любой точки: как из верхней, так и из нижней, либо с любой промежуточной. В этом и состоит весь смысл трассируемости изменений (не путать с трассировкой требований).
Само хранение метрик, конечно же, хорошо, но применять его нужно вместе с процессными метриками, для анализа текущей ситуации и прогнозирования, как краткосрочного, так и долгосрочного.
В следующей части нашей статьи мы рассмотрим практические применения метрик в программных продуктах IBM Rational. Рассмотрим только один сегмент, касающийся способа хранения набора метрик в репозитории системы управления версиями ClearCase . Сразу отметим, что эта система может хранить только метрики, относящиеся к коду. Комбинированные же метрики (такие, как плотность дефектов) необходимо выводить на основе показателей из всех систем: ClearCase (количество строк) и ClearQuest (количество дефектов за единицу времени), RequisitePro (количество требований) и т.д.
Отметим, что мы не ставили перед собой глубокий и детальный анализ метрик – для этого есть специализированная литература (ссылки приводятся в конце статьи).
Продолжение статьи в Блоге Новичкова -->
3. Ресурсы интернет
- The Build Master. Microsoft Software Configuration Management Best Practices
- Steven C.McConnell "Code Complete", 2nd. Ed.
- IEEE Std 1058-1998, Standard for Software Project Management Plans.
- IEEE Std 12207-1997, Information Technology—Software Life Cycle Processes.
- IEEE Std 1045-1992, Standard for Software Productivity Metrics.
- IEEE Std 1062-1998, Recommended Practice for Software Acquisition.
- IEEE Std 1540-2001, Standard for Software Life Cycle Processes—Risk Management.
- IEEE Std 828-1998, Standard for Software Configuration Management Plans
- IEEE Std 1490-1998, Guide—Adoption of PMI Standard—A Guide to the Project Management Body of Knowledge
- ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом.
- Изосимов А.В., Рыжко А.Л. Метрическая оценка качества программ. - М.: МАИ, 1989.
- Холстед М. Начала науки о программах. - М.: Финансы и статистика, 1981.
- Вячеслав Колдовский, Разработка ПО: метрики программных проектов
- Oviedo E.J. Control flow, data flow and program complexity. - Proc. IEEE COMPSAC. - Chicago, IL, Nov. 1980. - pp. 146-152.
- http://www.giac.unibel.by/docs/pdf/1-2005/s10-1-2005.pdf
- http://www.cs.umd.edu/~basili/papers.html
- http://msquaredtechnologies.com/m2rsm/
- http://www.aivosto.com/project/help/pm-loc.html
- http://kapustin-andrey.boom.ru/Materials/Metrics2.htm
- http://kapustin-andrey.boom.ru/Materials/Metrics1.htm
- http://www.met-rix.narod.ru/index.htm
- http://www.maxkir.com/sd/newmethRUS.html
- http://www.optim.su/cs/2003/4/AOP2/AOP.asp
- http://www.mstandard.ru/certification/03/
- http://www.virtualmachinery.com/jhawkmetrics.htm
- http://msquaredtechnologies.com/m2rsm/docs/cyclocomplex/cyclo_1.htm
06.08.2008
Комментарии
- nxcEhJdTVjMkkMsT
Автор: YqL1LA , [url=http://auakhlkmvwvr.com/]auakhlkmvwvr[/url], [link=http://dqdkfynaiokr.com/]dqdkfynaiokr[/link], http://qtwtbkhmkxzu.com/ · 30.08.2011 20:35:22
YqL1LA , [url=http://auakhlkmvwvr.com/]auakhlkmvwvr[/url], [link=http://dqdkfynaiokr.com/]dqdkfynaiokr[/link], http://qtwtbkhmkxzu.com/ - tzPzZgTPfIuablCiuAi
Автор: FqOYva icujlfmojdng · 25.08.2011 13:25:53
FqOYva icujlfmojdng - oPrJtybWuwRLEq
Автор: oCoDn5 , [url=http://fbpymfccbvsa.com/]fbpymfccbvsa[/url], [link=http://eqteypbqslra.com/]eqteypbqslra[/link], http://ngbgfwzfjzih.com/ · 20.08.2011 18:07:53
oCoDn5 , [url=http://fbpymfccbvsa.com/]fbpymfccbvsa[/url], [link=http://eqteypbqslra.com/]eqteypbqslra[/link], http://ngbgfwzfjzih.com/ - rcvNXvPMnor
Автор: 8Bgm11 kwyrhinvuvrk · 20.08.2011 11:12:40
8Bgm11 kwyrhinvuvrk - HYrXTqpPQOuRAfpZs
Автор: I am toatlly wowed and prepared to take the next step now. · 19.08.2011 08:50:54
I am toatlly wowed and prepared to take the next step now.
Автор: · 24.07.2011 06:00:24
Do you recognize that this is the best time to receive the credit loans, which can realize your dreams.
Автор: · 12.06.2011 19:51:52
Профессиональный дизайн квартир на любой вкус- Subversion
Автор: Автор · 24.02.2009 21:15:53
Как видно из названия, это первая часть статьи - теория использования метрик. Практика реализации будет отдельно опубликована в следующих частях - Subversion?
Автор: Холявкин Максим Николаевич · 24.02.2009 20:36:07
А где собственно про svn?
Добавить комментарий (анонимные комментарии не публикуются!!!)
 |
 |
Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра |
Новости и пресс-релизы СМ-Консалт
08.05.2012 18:00:34
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 28-30 мая в Москве
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 28-30 мая в Москве. Проводится совместными усилиями компаний СМ-Консалт итренинговым центром КарьерЛаб. Место проведения тренинга - ул. Восьмого Марта, вл. 1, стр. 12 (схема проезда).
Продолжительность тренинга составляет 2 или 3 дня по выбору. Целевая аудитория:
начальники отделов, менеджеры проектов, директора, руководители
проектов внедрения, бизнес-аналитики, специалисты команды внедрения.
21.02.2012 14:21:11
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 марта в Санкт-Петербурге
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 марта в Санкт-Петербурге. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб и Legal SoftWave. Место проведения тренинга в данный момент уточняется.
Продолжительность тренинга составляет 2 или 3 дня по выбору. Целевая аудитория: начальники отделов, менеджеры проектов, директора, руководители проектов внедрения, бизнес-аналитики, специалисты команды внедрения.
21.02.2012 12:42:20
Новая статья: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения?
Статья, находящаяся перед вами, открывает цикл статей о человеческом
факторе, Agile-практиках и других полезных приемах, используемых при
управлении командами в ИТ. Объединяет рассматриваемые практики и приемы
одно – они позволяют проявиться положительным эффектам, связанным с
человеческим фактором. И мы объясняем, почему с точки зрения психологии,
это происходит. Так сказать, подводим теоретическую и экспериментальную
базу под то, что себя уже давно зарекомендовало и работает. Или под то,
что работает не у всех, и потому является предметом оживленных споров и
дискуссий. И начинаем мы наши исследования с рассмотрения эффекта
парного программирования через призму экспериментов социальной
психологии.
Отдельную благодарность за рецензию и время, потраченное на прочтение
первого варианта статьи, выражаем Асхату Уразбаеву,
ценные замечания которого позволили не только улучшить данную статью,
но и позволили убедиться в необходимости и востребованности именно цикла
статей!
Читать -->
16.01.2012 20:09:00
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 февраля в Новосибирске
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 14-16 февраля в Новосибирске. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб. Место проведения тренинга в данный момент уточняется.
Продолжительность тренинга составляет 2 или 3 дня по выбору. Целевая аудитория: начальники отделов, менеджеры проектов, директора, руководители проектов внедрения, бизнес-аналитики, специалисты команды внедрения.
27.12.2011 16:15:27
Компания "СМ-Консалт" получила отзыв о работах в Федеральной Налоговой Службе (ГНИВЦ ФНС)
Специалистами ООО «СМ-Консалт» в 2010-2011г. был выполнен проект
по настройке и внедрению системы управления жизненным циклом разработки
программных систем в части управления изменениями и конфигурациями на
основе Microsoft Visual Studio Team Foundation Server 2010 для
Филиала Федерального государственного унитарного предприятия «Главный
научно-исследовательский вычислительный центр Федеральной налоговой
службы» в Приволжском Федеральном округе (Филиал ФГУП ГНИВЦ ФНС России в
ПФО).
26.12.2011 21:05:28
Успешное проведение тренинга по коммуникациям и психологии для ИТ-руководителей в Санкт-Петербурге
В блоге Новичкова Александа доступен отчет авторов тренинга «Коммуникации и психология межличностных отношений в ИТ-проектах». В целом, тренинг завершился положительно - средний балл за интересность по 5 бальной шкале - 4,2 балла.
В отчете дается развернутый комментарий, подводятся итоги, рассматриваются как положительные моменты, так и элементы критики и пожеланий, собранные на основе анкет слушателей.
Читать -->
28.11.2011 20:09:21
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 19-21 декабря в Санкт-Петербурге
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» состоится 19-21 декабря в Санкт-Петербурге. Проводится совместными усилиями компаний СМ-Консалт, тренинговым центром КарьерЛаб и Legal SoftWave. Место проведения тренинга в данный момент уточняется.
Продолжительность тренинга составляет 2 или 3 дня по выбору. Целевая аудитория: начальники отделов, менеджеры проектов, директора, руководители проектов внедрения, бизнес-аналитики, специалисты команды внедрения.
28.11.2011 18:31:55
Компания «СМ-Консалт» сообщает об успешном завершении нового тренинга, проведенного совместно с компанией «Карьерлаб»!
Тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах» прошел 17-18 ноября в Москве.
Слушатели проявили большой интерес и подтвердили важность выбранного направления. Контакт с аудиторией был установлен сразу. Были проработаны такие важные аспекты необходимых навыков из области психологии и коммуникаций, как умение управлять группой, говорить с заказчиком, как донести до оппонента свое решение и многое другое, что очень важно при разработке или внедрении ИТ-проектов.
28.11.2011 15:05:11
Новая статья: "Всегда ли «Да» – это «Да»? Или как нас вынуждают принимать решения"
Мы предлагаем вашему вниманию цикл статей, в основу которых положены
психологические практики и приемы, позволяющие влиять на решения,
принимаемые людьми. Эта идея была логическим продолжением ряда
выступлений с докладами о коммуникациях в проектах разработки и
внедрения ПО. Давайте, не откладывая в долгий ящик, начнем с самого
простого приема убеждения, с которым сталкиваемся ежедневно в магазинах,
в транспорте, в разговорах с коллегами… да мало ли где еще!
Авторы: Новичков Александр и Карабанова Галина.
Читать -->
10.10.2011 11:16:06
Компания «СМ-Консалт» открывает новое направление продаж - ПО Adobe Connect
Программное обеспечение Adobe Connect является гибкой системой
web-коммуникации с высоким уровнем информационной безопасности. Adobe
Connect предоставляет такие важнейшие функции корпоративного
взаимодействия, как деловое общение и совместная работа сотрудников на
уровне предприятий, дистанционное обучение, организация широкомасштабных
сетевых семинаров и презентаций. Система Adobe Connect базируется на
технологии Adobe Flash, а также Air, и поэтому позволяет подключать
сотрудников к единому пространству взаимодействия через web-браузер с
любых устройств.
17.09.2011 21:40:22
Новая статья: "Разработка прикладного программного обеспечения с использованием Rational Unified Process на Иркутском Авиационном заводе"
На сайте СМ-Консалт открыт новый раздел Статьи наших заказчиков об успешных внедрениях IBM Rational и Microsoft. Статьи для данного раздела пишутся нашими заказчиками и рассказывают о сути проектов внедрения технологий IBM и Microsoft. Первая статья, представленная вашему вниманию написана сотрудниками Иркутского Авиационного Завода (ИАЗ).
Иркутский авиазавод имеет длительный опыт разработки программного
обеспечения для информационной поддержки ключевых бизнес-процессов
предприятия. Однако, в связи с увеличивающейся сложностью и повышением
требований к разрабатываемому программному обеспечению, возникла
настоятельная необходимость усовершенствовать процесс разработки:
повысить качество разрабатываемых программных продуктов,
стандартизировать процесс с увеличением его эффективности.
13.09.2011 12:07:29
Новый тренинг «Коммуникации и психология межличностных отношений в ИТ-проектах»
Компания «СМ-Консалт» представляет новый тренинг, организуемый совместно с компанией «КарьерKаб» - «Коммуникации и психология межличностных отношений в ИТ-проектах.
Тренинг позволит понять, насколько коммуникации в проектах важнее инструментов, что люди и их взаимоотношения зачастую оказываются решающим фактором, определяющим успех проекта. Если более пятидесяти процентов рабочего времени вы тратите на взаимодействие с заказчиком, если вам небезразлична судьба вашей команды и вы хотите, чтобы ваша команда работала как часы, реализуя проекты точно, вовремя и без перерасхода ресурсов - наш тренинг поможет в этом.
25.08.2011 13:46:04
Компания СМ-Консалт сообщает об открытии нового направления деятельности: консалтинг и внедрение систем аналитической обработки информации (Business Intelligence)
Наша компания специализируется на консалтинге и внедрении инструментов и методологий IBM Rational, Microsoft и др. для повышения эффективности процессов разработки и сопровождения программного обеспечения.
Методы и технологии Business Intelligence являются прекрасным дополнением к ряду специализированных инструментальных средств, используемых для поддержки ЖЦ разработки ПО и управления ИТ-проектами. Инструменты BI играют роль недостающего промежуточного звена между основным бизнесом организации и ИТ-процессами, и, таким образом, способствуют повышению эффективности ключевых бизнес-процессов и достижению стратегических целей компании.
03.08.2011 14:05:11
На сайте размещены мультимедиа материалы докладов семинара «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»
Компании СМ-Консалт , Legal SoftWaveTM и DNA провели бесплатный семинар-вебинар, посвященный обзору технологий и методологий, которые позволяют повысить эффективность ИТ подразделений. На семинаре были рассмотрены технологии IBM Rational, Microsoft TFS, а также системы аналитической обработки информации (Business Intelligence).
На нашем сайте размещены все мультимедийные материалы с семинара: презентации и видео-ролики с демонстрацией отдельных функций ПО IBM и Microsoft.
Перейти к просмотру: 14 июля 2011г. Семинар «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»
01.08.2011 17:44:25
Наша компания получила отзыв о сотрудничестве с ОАО «Нордеа Банк»
24.06.2011 01:27:57
Бесплатный семинар-вебинар «Повышение эффективности IT подразделений и качества разрабатываемого ПО с использованием современных методологий и технологий»
Компании СМ-Консалт , Legal SoftWaveTM и DNA приглашают Вас посетить бесплатный семинар-вебинар, посвященный обзору технологий и методологий, которые позволяют повысить эффективность ИТ подразделений. На семинаре рассматриваются технологии IBM Rational, Microsoft TFS, а также системы аналитической обработки информации (Business Intelligence) (IBM SPSS, Deductor, QlikView и другие).
Планируемая продолжительность семинара - 8 академических часов.
Место проведения: Санкт-Петербург (очно) и Интернет (для всех желающих: приходите сами и приглашайте друзей!).
Дата и время: 14 июля 2011 в 9 00.
ВНИМАНИЕ: если вы не сможете очно приехать на семинар - это не страшно, так как семинар будет транслироваться через интернет в формате вебинара и к нему, после регистрации, смогут присоединиться все желающие. Трансляция будет осуществляться посредством технологии Adobe Connect Pro , это позволит Вам присоединяться к конференции без установки дополнительного ПО - только интернет браузер.
Смотреть программу -->
07.06.2011 13:02:44
Компания "СМ-Консалт" провела серию успешных семинаров для ГНИВЦ ФНС России
Проведенные семинары были посвящены средствам разработки и тестирования программного обеспечения компании Майкрософт для сотрудников ГНИВЦ ФНС России. Слушатели семинаров отметили высокую квалификацию тренеров компании "СМ-Консалт" по организации учебного процесса и повышению квалификации специалистов, прошедших обучение.
Индивидуальный подход при решении любых вопросов, возникающих в процессе обучения, оперативность принятия решений, гарантированное выполнение взятых на себя обязательств и профессионализм позволили провести обучение на самом высоком уровне.
07.12.2010 12:28:15
Мы идем в Твиттер!
Наша компания открыла аккаунт в системе микроблоггинга Twiter.Теперь все официальные и неофициальные новости будут появляться в нашей ленте в Twitter.
Там же возможно будет задать прямые вопросы специалистам СМ-Консалт, по всем вопросам, связанным как с деятельностью компании, так и с техническими аспектов продуктов IBM и собственных решений СМ-Консалт.
Следуйте за нами!
11.11.2010 14:14:14
Осенний марафон Microsoft ALM Road Show
Компания СМ-Консалт совместно с образовательным центром Careerlab провели серию семинаров в рамках мероприятий ALM Roadshow 2.0 в крупнейших городах, расположенных на Волге, – крупных научных центрах, в которых ИТ технологии находятся на высоком уровне. Семинары прошли в Самаре, Нижнем Новгороде и Казани. Cеминары были посвящены использованию новых инструментов MS Visual Studio Team System в проектах разработки ПО.
В семинарах принимали участие представители различных ролей процесса разработки ПО: от разработчиков до руководителей предприятий различного уровня. Темы, обсуждаемые в ходе семинара, вызвали большой интерес аудитории и немалое количество вопросов, на которые были предоставлены исчерпывающие ответы. В процессе семинара также было показано большое количество примеров, которые дают представление о возможностях инструментов MS Team System. Средняя оценка за семинар составила 4,6 балла по пятибальной шкале
09.09.2010 16:11:03
Компания СМ-Консалт предлагает бесплатную настройку своих флагманских решений GanttChart и ProjectTracker.
Если вы хотите сэкономить время или у вас не получается сразу и эффективно настроить наши решения на вашу схему ClearQuest, то вы можете прислать свою схему ClearQuest нам и специалисты СМ-Консалт бесплатно в течение 3х рабочих дней:
- Проведут анализ схемы и дадут заключение по настройке схемы ClearQuest своими силами*;
- Предоставят ознакомительные лицензии на решения GanttChart и ProjectTracker сроком на один месяц;
- Предоставят файлы настроек для GanttChart и ProjectTracker, адаптированные под вашу схему.
08.09.2010 18:37:52
Скидки до 30% на программное обеспечение IBM Rational
Компания СМ-Консалт предлагает для всех желающих на льготных условиях приобрести программное обеспечение IBM Rational. Снижение цен связано с тем, что мы стараемся быть как можно ближе к нашим клиентам, многие из которых постепенно начали преодолевать последствия финансового кризиса.Наше предложение поможет с минимальными издержками приобрести ПО IBM Rational, что является хорошим капиталовложением.
Скидки до 1 декабря 2010 года:
- 20% скидки при покупке IBM Rational ClearCase, ClearQuest, CearCase LT, при приобретении пяти и более лицензий*;
- 30% скидки при покупке пяти любых продуктов IBM Rational + решение или тренинг СМ-Консалт*.
07.09.2010 13:53:40
Успешное внедрение уникального решения компании «СМ-Консалт» - GanttChart for ClearQuest в страховой компании «HUK-COBURG», Германия.
Компания «СМ-Консалт» и компания «HUK-COBURG» объявляют об успешном завершении проекта по поставке и внедрению решения «СМ-Консалт» - GanttChart for ClearQuest. Руководство «HUK-COBURG» обратилось в «СМ-Консалт» с просьбой поставки, адаптации и последующего сопровождения GanttChart for ClearQuest. С учетом требований Заказчика специалистами компании «СМ-Консалт» была выпущена и внедрена адаптированная версия GanttChart for ClearQuest, учитывающая особенности схемы процессов ClearQuest, применяемой в «HUK-COBURG», и дополнительные пожелания к функционированию GanttChart.
02.09.2010 14:41:12
Успешное внедрение Уникального решения СМ-Консалт - GanttChart for ClearQuest в Федеральном Национальном банке Бразилии
Компания СМ-Консалт и Федеральный Национальный банк Бразилии (ФНББ) объявляют об успешном завершении проекта по поставке и внедрению решения СМ-Консалт - GanttChart for ClearQuest. Руководство ФНББ, понимая ограничения использования IBM Rational ClearQuest в части проектного управления, обратилось в СМ-Консалт с просьбой поставки и адаптации GanttChart for ClearQuest под свои потребности.
С учетом требований Заказчика специалистами компании СМ-Консалт была выпущена и внедрена обновленная версия GanttChart for ClearQuest, учитывающая все особенности схемы процессов ClearQuest, применяемой в ФНББ.
По истечении срока опытной эксплуатации ФНББ приняло решение о принятии GanttChart for ClearQuest в промышленную эксплуатацию.
02.09.2010 14:17:23
Компания «СМ-Консалт» объявляет об успешном завершении обучения и консультирования IBM Rational сотрудников ЗАО «Промышленная Группа Метран» г. Челябинск.
В августе 2010 года специалистами компании «СМ-Консалт» были выполнены работы по обучению и консультированию сотрудников компании «Метран» методологии и инструментальным средствам процесса управления конфигурациями – IBM Rational Software ClearCase и ClearQuest. Был проведен тренинг-консультация «Практика и технология внедрения процесса конфигурационного управления и управления изменениями на основе IBM RUP, ClearCase и ClearQuest».
В тренинге принимали участие ведущие специалисты и руководители отделов компании «Метран».
29.06.2010 13:07:07
Успех семинара "Программное обеспечение IBM Rational для улучшения процессов разработки и сопровождения ПО" 15 июня 2010 г.
Компании "СМ-Консалт", IBM и DNA провели бесплатный семинар по теме "ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО" 15 июня 2010 года. На семинаре специалисты СМ-Консалт, IBM и UML2.RU рассказали о технологиях IBM Rational и поделились практическим опытом использования и внедрения методологии Rational Unified Process. Также были представлены отдельные решения СМ-Консалт, расширяющие функциональные характеристики IBM Rational.
