REVISTACIENTIFICAMULTIDISCIPLINARNUCLEODOCONHECIMENTO

Revista Científica Multidisciplinar

Pesquisar nos:
Filter by Categorias
Sem categoria
Агрономия
Администрация
Архитектура
Аэронавтические науки
Биология
Богословие
Бухгалтерский учет
Ветеринар
Военно-морская администрация
География
Гражданское строительство
животноводство
Закон
Здравоохранение
Искусство
история
Компьютерная инженерия
Компьютерные науки
Кухни
лечение зубов
Литература
Маркетинг
Математика
Машиностроение
Наука о религии
Образование
Окружающая среда
Педагогика
Питание
Погода
Психология
Связь
Сельскохозяйственная техника
Социальных наук
Социология
Тексты песен
Технология
Технология производства
Технология производства
Туризм
Физика
Физического воспитания
Философия
химическое машиностроение
Химия
Экологическая инженерия
электротехника
Этика
Pesquisar por:
Selecionar todos
Autores
Palavras-Chave
Comentários
Anexos / Arquivos

Точка Анализ приложения для предоставления услуг в SOA-проектах

RC: 11648
47
5/5 - (1 голос)
DOI: ESTE ARTIGO AINDA NÃO POSSUI DOI
SOLICITAR AGORA!

CONTEÚDO

GUIMARÃES, Valéria Aparecida [1]

LARA, Alexander Prado [2]

PUTTINI, Ricardo Staciarini [3]

GUIMARÃES, Valéria Aparecida; LARA, Alexander Prado; PUTTINI, Ricardo Staciarini. Точка Анализ приложения для предоставления услуг в рамках проектов SOA. Журнал Многопрофильная научный центр знаний. Выпуск 08. Год 02, Vol. 01. С. 88-102, ноябрь 2017. ISSN:2448-0959

резюме

Расчетный размер программного обеспечения для развития имеет важное значение для получения достоверной оценки стоимости и времени. Одним из наиболее часто используемых методов измерений и задокументированы, чтобы получить размер программного обеспечения является функция анализа Point (FPA), которая, однако, имеет свою применимость к проектам, которые используют подход к сервис-ориентированной архитектуры (SOA) часто ставится под сомнение. В данной статье представлены результаты применения ПФА на системе, разработанной исключительно с использованием подхода SOA, что позволило дальнейшее сравнение оценок, полученных с APF усилий, времени и фактических затрат по проекту.

Ключевые слова: программное обеспечение Оценка, Программное обеспечение Metering, APF, SOA.

1. введение

Расчетный показатель должен быть разработан размер программного обеспечения имеет важное значение для получения достоверной оценки стоимости и времени (Уилки, 2011), но правильно выполнить этот тип оценки назначается литературы как один из самых больших проблем, с которыми сталкиваются руководители этой области (Прессмана 2011; Уилки, 2011; KAUR, 2016). Это показано, например, Roetzheim (2000), который возглавлял в течение 18 лет, обширные исследования, которые пришли к выводу, что основные причины сбоев программного обеспечения проекта связаны с плохими оценками затрат и графика реализации, а не технические проблемы, политической или развитие команды.

Хотя это и не является точной наука, так как влияние человеческого переменными, технического, экологического и политического (Соарес, 2013), методы измерения (и метрика) программное обеспечение может внести значительный вклад в генерацию более напористых оценок, которые уменьшает расхождение между тем, что было оценено и то, что было сделано и для выявления тенденций и предвидеть проблемы, обеспечивая более эффективный контроль затрат, снижение рисков, повышение качества и обеспечение того, чтобы бизнес-цели достигнуты (Флорак 1997 ; Прессман, 2008; Тиченор, 2013; SOARES, 2013).

Одним из наиболее часто используемых методов измерений и задокументировано, чтобы получить функциональный размер программного обеспечения APF (аббревиатура на английском FPA Function Analysis Точки) (IFPUG, 2010; Уилки, 2011; Соарес, 2013). Этот метод был впервые опубликован в середине 70-х годов Аллан Альбрехт (Альбрехт, 1984) и улучшена Международная функции точки Users Group (IFPUG), и уже хорошо зарекомендовали себя и широко используется во всем мире (IFPUG, 2010; CALAZANS, 2011; SISP, 2015). Метод использует точку функции (PF) в качестве меры единицы (IFPUG, 2010).

Несмотря на консолидацию APF как метода калибровки функционального размера программного обеспечения (Lindskoog, 2009; IFPUG, 2010) и продолжающихся усилий по совершенствованию и эволюции метода, существуют ситуации, в которых их применение не является прямой. программные проекты, которые следуют ориентированной архитектуры подход (SOA) – архитектура для разработки программного обеспечения, чей фундаментальный принцип заключается в создании многоразовых и взаимодействующих служб (ERL 2005), является частью списка параметров, где применение ФПА является допрошенные ,

Дискуссии о применимости метода проектов SOA были постоянными и многие проблемы, которые предстоит преодолеть для принятия. (GENCEL, 2008; Lindskoog, 2009, Gomes, 2012). Эта трудность связана с несколькими факторами, в которых мы выделим тот факт, что в проектах SOA, многие функции предназначены для повторного использования, что делает его общим для сферы проекта нарушить функциональную сферу разрабатываемого приложения ( ERL, 2005). Кроме того, SOA, сложные системы должны быть разбиты на услуги и большая часть усилий анализа и проектирования связана именно с процессом разложения и последующим восстановлением услуг. Этот процесс требует четкого применения методов и принципов для достижения слабосвязанности, способности композиции, стандартизации и сделка посредничества, среди других, которые не присутствуют в обычных разработках программного обеспечения (ERL 2008). Таким образом, показатели и оценка усилий критерии, используемые для традиционного развития не могут быть применены непосредственно в проекты SOA (Lindskoog, 2009; Farrag, 2015).

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

Эта статья организована следующим образом: в разделе 2 приведены основные понятия, связанные с PF анализа и SOA, а также большую научную работу, руководствуясь предложение. Раздел 3 представляет методологию работы, принятую, а в разделе 4 представлены полученные результаты. Наконец, в разделе 5 приносит основные выводы и заключительные замечания.

2. концепции

2.1 Функция анализа Point (FPA)

Как уже упоминалось, APF является метод измерения программного обеспечения или проекта разработки / обслуживание программного обеспечения поддерживается Международной функции точки Users Group (IFPUG) и которая направлена ​​на получение функционального размера «Функциональные очки «(PF), принимая во внимание точку зрения пользователя (IFPUG, 2010). IFPUG публиковать и поддерживать обновленную Counting Practices Руководство (CPM – Counting Practices Manual), которая содержит правила и процесс, которым необходимо следовать, чтобы обеспечить более стабильные результаты в применении APF (IFPUG, 2010).

Организации могут применять этот международный стандарт для измерения размера программного обеспечения для того, чтобы: (I) для оценки усилий, затрат и времени, необходимого для разработки, поддержания и совершенствования программного обеспечения; (Ii) обеспечивают поддержку анализа качества и производительности; (Iii) обеспечивает коэффициент нормировки для сравнения программного обеспечения (IFPUG, 2010). Его использование имеет много преимуществ, которые включают в себя: правилах цели подсчета, независимости технологического решения и языке программирования и возможность оценки поколения уже на ранних стадиях жизненного цикла программного обеспечения (SISP, 2015).

Применение метода предполагает выполнение следующих шагов, подробно описаны в CPM (2010): (I) получения имеющейся документации; (Ii) идентифицировать цель и тип оценки, определить масштаб графа и границы применения; (Iii) функции измерения данных, которые являются требованием к функциональному пользователю в отношении хранения и / или данных восстановления и классифицируются в Logical File Internal (ALI) – логические группы данных сохраняемых в пределах границ приложения, и внешний интерфейс файл (МЭА) – ссылается только приложение измеряется; (IV) измерение транзакционных функций, которые являются функциями, предоставляемых пользователя для обработки данных приложения и классифицируются в (а) Внешние входы (EE) – отвечают за обработку данных или информацию управления, которые имеют свое происхождение за пределами применение границы; (B) амбулаторные (EC) – отвечает за отправку данных или информации управления, которые приходят из приложения границы; (С) Внешние выходы (SE) – ответственные за отправку данных или информации управления, которые выходят из применения границы, в том числе дополнительной логики обработки, кроме того, идентифицированный в амбулаторных условиях; (V) вычисление функционального размера; (Vi) документы и отчетность кол. То есть, от проектной документации или программного обеспечения, и в соответствии с пользовательской точки зрения (функциональные требования) являются производными ПФ с точки зрения возможностей, предлагаемых и данных, участвующих. Имея объем ПФ и на основе таких моделей, как Оценки упрощенной модели (Васкес, 2012) или модели COCOMO II (Boehm, 2009), являются производными от усилий, времени и стоимости проекта.

2.2 Сервис-ориентированная архитектура (SOA)

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

Логика считается, когда некоторые сервис-ориентированные принципы, известные как принципы SOA применяются в значительном расширении раствора (ERL 2005). По ERL (2008) являются восемь из этих принципов: (я) контракт по стандартизации; (II), слабо связанные услуги; (III), служба абстракции; (IV) способность повторного использования услуг; (V), автономию услуг; (VI), служба государственной независимости; (VII) видимость услуг (открытие возможности); и (VIII), служба емкость композиции.

SOA стремится посредством применения принципов: повышение согласованности между бизнесом и ИТ; федерализация (доступ к услугам стандартизирован для того, чтобы объединить видение своих клиентов); разнообразие поставщиков; возврат на инвестиции (ROI); и гибкость организации; и снизить нагрузку на ИТ в организациях (ERL 2008). Таким образом, SOA позволяет создавать приложения, которые отвечают быстрее на потребности бизнеса, поскольку услуги построены в стандартизированной форме, будучи в состоянии взаимодействовать (общаться) друг с другом стандартным способом и прозрачной, независимо от платформы, поставщиков или технологий которые они были построены или бежать.

Хотя существует уже в течение некоторого времени, SOA получила известность только с середины 2000-х годов (ERL 2005). По данным недавнего опроса (грушанки, 2014), рынок SOA быстро растет. В докладе исследований показывает, что рынок SOA достиг $ 5,7 млрд в 2013 году и может достигнуть $ 16,4 млрд к 2020 году. По данным опроса, этот значительный рост обусловлен тем, что SOA предложить более эффективные автоматизированные процессы и обеспечить ему возможность вкладывать больше бюджета на развитие бизнеса. Кроме того, с развязаны программными решениями (независимыми), услуги SOA может быть повторно использованы эффективно.

3. Представление методологии работы Принято

Измерений за счет использования PF, чтобы получить функциональный размер эталонного дизайна, выполненного с применением правил подсчета, установленным в КФМ (IFPUG, 2010), направленных на определение, на основе сравнительного анализа, что было бы стоимость , время и реальные усилия разливают в реализации проекта и результаты, полученные с применением APF. Таким образом, можно было оценить, может ли использование ФПА будет лучшим выбором для измерения проекта (разработанного в рамках подхода SOA).

Выбор 3.1 проекта

Выбор конструкции используется произошло естественным образом, так как компания, в которой авторы работы был заключен контракт на структуру принятия SOA организацией по соображениям конфиденциальности информации, будет называться подрядчиком в ходе этой статьи .The Цель проекта, в целом, структура принятия SOA подрядчиком. мероприятия были разработаны для структурирования, разработки, реализации и мониторинга программы принятия SOA путем осуществления деятельности, которая включала, entres другой, создавая систему, разработанную исключительно с использованием подхода SOA и называться REFERENCE DESIGN над эта статья.

3.2 Измерение Reference Design

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

3.3 Оценка проекта Программное обеспечение усилию

Несколько моделей для оценки усилий программных проектов, основанных на PF, в настоящее время доступны, и оценка упрощенной модели (Vazquez (2012)) и модель COCOMO II (Сет, 2009) наиболее часто используемый (SISP, 2015). В данном исследовании мы использовали упрощенные оценки модели, то же самое используется SISP (2015 г.).

4. Экспериментальные результаты

4.1 Reference Design

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

4.1.1 Команда проекта

Таблица 1 показывает персонал, выделяемый на развитие решения. Они представляют информацию о количестве людей, которые принимали участие в проекте по типу ресурса / ролей, роль ресурса, выделенный в команду с их соответствующим porcentam из particação и относительной самоотверженности, в процентах, от ресурса / конкретной роли по весь проект.

Таблица 1: Команда проекта
Таблица 1: Команда проекта

4.1.2 Время и усилие Выполнено

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

Таблица 2: Reference Design усилия, предпринятые

Этап проекта часов
Бизнес-моделирование и анализ 1076
реализация +826
Тезисы и реализации 268
Общее количество часов 2170

 

4.1.3 Стоимость Held

Стоимость рассчитывались часами до преобразования единиц измерения UST (Technical Services), которая является медицинским устройством, используемым для количественной оценки работы. То есть, количество человеко-часов преобразуется в UST в качестве договорного определения для получения затрат. Расчет ЕСН принимает во внимание сложность деятельности, выполняемой (низкий, средний и высокий). Таблица 3 показывает результат преобразования часов / UST для каждого этапа проекта.

Таблица 3: Стоимость Направленный референсный дизайн

Этап проекта часов UST
Моделирование и анализ 1076 1765
реализация +826 +894
Тезисы и реализации 268 304
Общее количество часов 2170 2963

Учитывая UST контракт количество R $ 247,50, проект имел общую стоимость R $ 733,342.50

4.1.4 Общие результаты

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

Таблица 4: Общий результат

исходный проект
Усилие (часы): 2170
Срок (месяцы): 6
Стоимость (R $): R $ 733,342.50

4.2 Измерение размера Functional – IFPUG

Функциональное измерение размера программного обеспечения с помощью FP рассматривается применение в целом, с функциональной точки зрения пользователя зрения, в соответствии с рекомендацией стандарта APF IFPUG (IFPUG, 2010). Таблица 5 показывает цель (цели или цели измерения) и объем измерений (набор или подмножество приложений, которые измеряются). В Таблице 6 показан результат подсчета, соответствующего значению функционального размера опорной конструкции.  Персонал усилию перепускной период и стоимость была определена на основе упрощенных модельных оценок, которые представлены в таблице 7.

Таблица 5: Функциональный сценарий эталонного измерения КОНСТРУКЦИЯ

Функциональный сценарий
Цель измерения Измерение функционального размера (APF IFPUG) референсный дизайн разработан в качестве подрядчика программы принятия SOA.
Область измерения Применение Эталонный дизайн

 

Таблица 6: Результаты традиционного замера IFPUG
Таблица 6: Результаты традиционного замера IFPUG
Таблица 7: Выведение Срок усилию команды и стоимость
Таблица 7: Выведение Срок усилию команды и стоимость

Методика подсчета: определяет, является ли подсчет указывает оценкам или сломан. Свидетельствует подсчет основан только на информацию о функциях данных, то есть от числа логических файлов (АБИС и ОГО). Оценки счетчик считает в количестве функций данных, информация о функциях транзакций, так что таким образом, что требования пользователей должны быть более подробными. Что касается детальных подсчетов, плюс количество транзакционных функций, необходимо определить функциональную сложность (низкий, средний, высокий) каждой функции в отдельности (Nesma, 2015).

Тип Count: три возможных типа подсчета: (I) развития: Поскольку функциональные возможности, предоставляемые пользователям, рассматривающих первую установку программного обеспечения. (Ii) Улучшение / техническое обслуживание: изменения, связанные, он, добавлен, изменен или удален, к существующей функциональности программного обеспечения. (Iii) Применение: измерение функциональных возможностей, которые приложение предлагает пользователю. Приложение сплоченной набор автоматизированных процедур и данных, которая направлена ​​на поддержку бизнес-цели и состоит из одного или нескольких компонентов, модулей или подсистем (IFPUG, 2010).

Функциональный размер проекта: Относится к значению функционального размера референсного дизайна.

Производительность Night (ч): Относится к числу продуктивных часов на человека. Эта работа была считается 6 часов / день, в соответствии с рекомендациями (SISP, 2015).

Индекс производительности (часы / FP): Относится к количеству времени, затрачиваемого на производство 1 PF. Определение значения индекса производительности зависит от ряда факторов, которые могут включать в себя, среди прочего, технологической платформы, безопасность, производительность, удобство использования и проект размера. Каждая организация должна иметь свою собственную таблицу производительности, учитывая исторические данные из предыдущих проектов.

Усилие (чел / час): Это относится к количеству часов, чтобы быть дозируемого в реализации проекта или доставки определенного функционального размера. Он рассчитывается на основе функциональной конструкции и размера индекса производительности (размер (PF) х Индекс производительности (НН / ФП)).

Окружающая среда: Относится к показателю, который будет использоваться в формуле для определения рекомендованного срока. В таблице 1 показаны доступные варианты. Это был выбран «ОО System – объектно-ориентированная система», которая наиболее точно соответствует характеристикам проекта SOA.

Таблица 1: Экспонент по типу проекта. Источник: SISP, 2015 р. 45
Таблица 1: Экспонент по типу проекта. Источник: SISP, 2015 р. 45

Другой период: Он рассчитывается по формуле Кэперс Джонс[Jones,2007].

Ежемесячная рабочая нагрузка (часы): Относится к числу рабочих часов, отработанных на человека в месяц.

Команда: Относится к количеству ресурсов, необходимых для разработки проекта и должна рассматриваться как процентное распределение ресурса для проекта. В приведенном выше результате 6,2 особенности проектная группа может соответствовать, например, команда из 12 человек, с выделением 50% и руководитель проекта с 20%, выделенных на проект.

Информированный персонал: Это относится к команде, которая эффективно работала в разработке проекта. Она направлена ​​на поддержку другого моделирования усилий и время и распределения ресурсов в команде по освящению каждого к проекту.

Другие оценочные расчеты: оценки других имитаций были созданы на базе команды осознанной и учитывая перспективу сокращения. Значение точки функции используется была определена на основе исторических ссылок подрядной компании. Стоимость проекта были рассчитаны без учета периода сокращения и с учетом периода восстановления.

5. выводы

5.1 Критический анализ заявки

Из анализа результатов, полученных в результате применения ФПА и эталонного исполнения конструкции был сделан вывод о том, что фактическая стоимость проектирования SOA и получена из измерений с помощью FP привело к значительно различные значения (фактические расходы: Р $ 733342 50 и оценочная стоимость: R $ 349,600.00).  Была также существенная разница между усилиями, необходимыми для разработки проекта и реальных усилий (реальное усилие: 2170 часов и расчетное усилие: 6992 часов). Фактическая стоимость и оцениваются (фактическая стоимость: Р $ 733,342.50 по сравнению с оценочной стоимостью: Р $ 593,620.00) показали только относительно близких значений при оценке затрат метода для обхода считает сокращение времени для разработки проекта по отношению к типу, рекомендованному в идеале ( в реальном масштабе времени: 6 месяцев против рекомендуемого времени: 7,71 месяцев).

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

5.2 Ограничения и дальнейшая работа

Работа была ограничена только измерение проекта. Кроме того, он используется только один метод для получения оценок усилий, затрат и времени. В будущей работе, применение НФА в большем разнообразии проектов и использовании других методов оценки может принести пользу в том, что это обеспечит большую надежность в выводах. Он также будет иметь большое значение, чтобы предложить конкретный метод для измерения размера программного обеспечения SOA, которая стремится следовать чистейшим концепциям IFPUG относительно функционального измерения, а также рассмотреть необходимость поэлементного решения измерений, а также измерение нефункциональные требования.

ссылки

Альбрехт, IBM J Аллан СНГ и Руководящий принцип 313. AD / M Производительность 1984.

Бем, B.W. Программное обеспечение Оценка затрат с COCOMO II. Prentice Hall, Нью-Джерси, 2009.

CALAZANS Angelica; ЛИССАБОНСКАЯ Ирина; OLIVEIRA Марсело. Оценка общих характеристик систем в анализе функции точке – АПФ путем применения GQM – цели, вопросы, метрик. VII Международный симпозиум по разработке программного обеспечения процесса совершенствования. Сан-Паулу. Ноябрь 2011.

ERL, Томас. Сервис-ориентированная архитектура: концепции, технологии и дизайн. Crawfordsville: Prentice Hall PTR, август 2005.

ERL, Томас. SOA Принципы Проектирования услуг. Prentice Hall, 2008.

Фарраг, Esraa а.; Муавад Рамадан; IMAM, Ibrahim F. Подход к усилию Оценка сервис-ориентированной архитектуры (SOA) проектов. JSW, v. 11, нет. 1, стр. 44-63, 2016.

Флорак, Уильям. PARK, Роберт E. Карлтон, Анита D. Практическое программное обеспечение измерения: Измерение для управления процессами и совершенствования. Carnegie Mellon UNIV PITTSBURGH PA-SOFTWARE ENGINEERING INST 1997.

GENCEL, Cigdem; DEMIRORS, Onur. Измерение функционального размера повторно. ACM Сделки по разработке программного обеспечения и методологии (TOSEM) v. 17, нет. 3, стр. 15, 2008.

GOMES Юрий Маркс Перейра. Функциональный размер, усилия и стоимость проектов SOA с точками функции. нет. LXVIII, ноябрь 2012.

IFPUG – INTERNATIONAL USER POINT FUNCTION GROUP. Практики Руководство Количество функциональных точек. Версия 4.3.1, январь 2010.

IFPUG – INTERNATIONAL USER POINT FUNCTION GROUP. Оценка практики Руководство. Версия 2.3, май 2015.

JONES, расходы C. Оценка программного обеспечения. Второе издание, McGraw Hill, 2007.

KAUR, Prabhjot. Обзор программного обеспечения Метрика и измерения. Международный журнал компьютерных приложений и информационных технологий, Vol. 9, нет. 2, стр. 187, 2016.

Джефф Линдскоог.  Применение функций по вопросам окружающей среды В SOA. EDS, An компания HP. Санкт Е. Хоффер 1401 Kokomo, IN 46902. США. Сентябрь 2009.

Nesma – Нидерланды Функция Очки пользователей.  Главная функция Анализ точки. Июль 2015.

Прессман, Roger S. Software Engineering: профессиональный подход. 7-е издание. Ed: McGraw Hill, 2011.

ROETZHEIM, William H. Оценка затрат на программное обеспечение. РАЗРАБОТКА ПРОГРАММЫ-Сан-Франциско, v. 8, нет. 10, стр. 66-68, 2000.

SISP. Метрики сценарий Software SISP: версия 2.1, Министерство планирования, бюджета и управления. Секретарь логистики и информационных технологий. Бразилиа: MP, 2015.

SOARES DOS REIS, Julio Cesar; BARBOSA, Марсело Werneck. ПРЕДЛОЖЕНИЕ ДЛЯ ОЦЕНКИ ДЛЯ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ. Журнал систем и компьютерно-RSC, v. 3, нет. 1, 2013.

Чарли Тиченор, SNAP-Case Study 2 (ВСН 1. 0): Как использовать функции Точки и SNAP для улучшения договора программного обеспечения приобретений. IFPUG. Июнь 2014.

VAZQUEZ, Carlos E. Симойнш, Гильерме Сикейра; АЛЬБЕРТ, Ренато Мачадо. Анализ функции Точка: Измерение, оценка и управление программными проектами. 12-е издание, редактор Erica Ltda, Сан-Паулу, 2012.

Уилки Джордж Ф. и др. Значение калибровки программного обеспечения. Информация и технологии программного обеспечения, т. 53, нет. 11, стр. 1236-1249, 2011.

[1] Степень магистра в области электротехники – УНБ

[2] Доктор технических наук и управления знаниями

[3] Он имеет докторскую степень в Ecole Supérieure d’Électricité (Supelec), Ренн / Франция (2001/2002) и аспирантуру. Имеет степень кандидата технических наук в Университете Бразилиа (2004) PhD в Шведском институте информатики (SICS), Стокгольм / Швеция (2011). Он был координатором Центра информационных технологий (NTI) UnB (2006-2008) и директором Вычислительного центра (CPD) UnB (2007-2008). Он участвует в исследованиях, технологическом развитии и инновационных проектах, а также в партнерстве с различными компаниями и государственными структурами по вопросам, связанным с ИКТ, где он работает над определением стратегии, моделью управления, технологической разведкой и передачей технологий. Его текущие области включают в себя: облачные вычисления, сервис-ориентированную архитектуру, управление бизнес-процессами, распределенные системы и приложения для информационных технологий в правительственных средах.

5/5 - (1 голос)

Leave a Reply

Your email address will not be published. Required fields are marked *

POXA QUE TRISTE!😥

Este Artigo ainda não possui registro DOI, sem ele não podemos calcular as Citações!

SOLICITAR REGISTRO
Pesquisar por categoria…
Este anúncio ajuda a manter a Educação gratuita