ФЭНДОМ



RAD технологии

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

RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

 С конца XX века RAD получила широкое распространение и одобрение.


 Концепцию RAD также часто связывают с концепцией визуального программирования.

История

Концепция RAD стала ответом на неуклюжие методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада».

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

Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца.

 А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения.

В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

Назначение

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

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

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

Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше.

Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.

Применение

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

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

2) Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.

3) Проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.

4) Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

5) Возможно разбиение проекта на функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы её можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD-групп).

6) Низкая вычислительная сложность ПО.

Принципы RAD технологии направлены на обеспечение трех основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества.

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

Основные принципы:

1) Инструментарий должен быть нацелен на минимизацию времени разработки.

2)Создание прототипа для уточнения требований заказчика.

3) Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.

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

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

6) Управление проектом должно минимизировать длительность цикла разработки.

7)Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн и перепихивания.

Фазы разработки:

1) Планирование — совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.





ž

2) Пользовательское проектирование — на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счете выбрать рабочую модель, отвечающую их требованиям.





ž

3) Конструирование — этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии «реализация» в SDLC. В RAD, однако, пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование.

ž4) Переключение — включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.


Технология RAD в создании сайтов и web-проектов

Пример технологии RAD в создании сайтов это визуальные редакторы html, такие, например как программа Dreamweaver.В этой программе вы можете перетаскивать те или иные компоненты на вашу страницу и html код генерируется автоматически.

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

Те кто работали в этой или подобных программах знают какое удовольствие делать html страничку именно таким способом.

До недавнего времени не было разработано технологии RAD применительно к созданию web-приложений на php. Но, начиная с 2007 г. появился первый продуктDelphi for php, который с 2010 года стал называться RADphp.

Преимущества:

Технология быстрой разработки приложений (RAD) позволяет обеспечить:





žбыстроту продвижения программного продукта на рынок;žинтерфейс, устраивающий пользователя;žлегкую адаптируемость проекта к изменяющимся требованиям;žпростоту развития функциональности системы.žБыстрота создания приложений.žЛегче разбираться в коде.

Недостатки:

žПриложение, написанное по RAD технологии, работает более медленно.žКомпоненты, имеющиеся в программе разработки, могут только то, что в них изначально вложено, что якобы серьёзно ограничивает возможности программиста.

CASE-Технологии

CASE (Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.

Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.

КЛАССИФИКАЦИЯ

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

CASE-инструменты классифицируются по типам и категориям.

·         мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

·         интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

·         использование специальным образом организованного хранилища проектных метаданных (репозитория).

·         Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

·         графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

·         средства разработки приложений, включая языки 4GL и генераторы кодов;

·         средства конфигурационного управления;

·         средства документирования;

·         средства тестирования;

·         средства управления проектом;

·         средства реинжиниринга.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

·         средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

·         средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

·         средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

·         средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

·         средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

·         средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

·         средства конфигурационного управления (PVCS (Intersolv));

·         средства тестирования (Quality Works (Segue Software));

·         средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

·         Vantage Team Builder (Westmount I-CASE);

·         Designer/2000;

·         Silverrun;

·         ERwin+BPwin;

·         S-Designor;

·         CASE.Аналитик.

Технология внедрения CASE-средств

Приведенная в данном разделе технология базируется в основном на стандартах IEEE (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин "внедрение" используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов:

·         определение потребностей в CASE-средствах;

·         оценка и выбор CASE-средств;

·         выполнение пилотного проекта;

·         практическое внедрение CASE-средств.

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

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

Определение потребностей в CASE-средствах

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

Анализ возможностей организации

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

Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов.

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

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

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

Общие вопросы

·         используемая модель ЖЦ (каскадная или спиральная);

·         используемые методы (структурные, объектно-ориентированные). Степень адаптации метода к потребностям организации; квалификация сотрудников;

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

·         количественные метрики, используемые в процессе разработки ПО, их использование;

·         виды документации, выпускаемой в процессе ЖЦ ПО;

·         наличие группы поддержки средств проектирования.

·         Проекты, ведущиеся в организации

·         средняя продолжительность проекта в человеко-месяцах;

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

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

Технологическая база

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

·         доступные вычислительные ресурсы, платформа разработки;

·         уровень доступности ресурсов, узкие места, среднее время ожидания ресурсов;

·         ПО, используемое в организации, и его характер (готовые программные продукты, собственные разработки);

·         степень интеграции используемых программных продуктов, механизмы интеграции (существующие и планируемые);

·         тип и уровень сетевых возможностей, доступных группе разработчиков;

·         используемые языки программирования;

·         средний процент вновь разрабатываемых, повторно используемых и реально эксплуатируемых приложений.

Персонал

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

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

·         наличие лидеров, способных серьезно повлиять на отношение к новым средствам;

·         наличие стремления "снизу" к совершенствованию средств и технологии;

·         объем обучения, необходимого для ориентации пользователей в новой технологии;

·         стабильность и уровень текучести кадров.

Готовность

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

·         поддержка проекта со стороны высшего руководства;

·         готовность организации к долгосрочному финансированию проекта;

·         готовность организации к выделению необходимых специалистов для участия в процессе внедрения и к их обучению;

·         готовность персонала к существенному изменению технологии своей работы;

·         степень понимания персоналом масштаба изменений;

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

·         готовность руководства к долговременному ожиданию отдачи от вложенных средств.

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

Критерии оценки эффективности ИС

Качество разработанной АИС во многом зависит от того, как осуществлялись выявление и формулировка целей автоматизации:  1. Был ли обеспечен доступ разработчиков АИС к высшему руководству организации заказчика, и были ли в результате получены все необходимые сведения и данные о целях и реальных проблемах организации. Решение этих задач является итерационным процессом, требующим нетривиальных усилий, специальных знаний и применения специальной техники по выработке согласованного видения решаемой задачи у участников проекта АИС.  2. Имелись ли у разработчика АИС специалисты, компетенции и технологии выявления и формулировки задач заказчика.  3. Провёл ли разработчик в ходе системно-аналитического обследования организации необходимые опросы с целью выявления и анализа требований заказчика; были ли полученные результаты и предложения зафиксированы заказчиком и др.

Несомненно, что качество созданной АИС зависит от уровня знаний разработчиков в области технологий БД и СУБД, от степени понимания ими современных и будущих (перспективных) прикладных задач пользователей.

Для оценки качества созданной АИС ещё в процессе её создания проводятся различные виды испытаний. К ним, в частности, относят опытную эксплуатацию самой системы и её компонентов (модулей, подсистем и т.п.). В дальнейшем, в течение согласованного с заказчиком периода времени (как правила одного года) в процессе промышленной эксплуатации АИС, она может дорабатываться.

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

Одним из вариантов оценки качества разработанной системы является сравнение её с подобным программным продуктом (если таковой имеется). На основе такого сравнения целесообразно произвести расчёт основных показателей. Общие критерии, применяемые при сравнении ПО, включают проверку: 

совокупной стоимости системы;

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

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

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

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

Инвариантность по отношению к бизнесу – это возможность поддержки программным обеспечением разных видов бизнеса. Например, производства продуктов питания и оказания автотранспортных услуг. Этот критерий особенно важен для корпоративных структур с различными видами деятельности.

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

Эффективность означает сопоставление полученных полезных результатов и соответствующих затрат всех видов ресурсов с целью выявления оптимальных решений.


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

Модели жизненного цикла


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

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

Каскадная модель или «водопад» используется в технологиях, ориентированных на переход к следующему этапу после полного окончания работ на предыдущем этапе. Каскадная схема разработки ПО.

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

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

Методика оценки трудоемкости разработки ПО на основе функциональных точек.

Анализ функциональных точек — стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group — IFPUG), которая опубликовала несколько ревизий метода.

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

При анализе методом функциональных точек надо выполнить следующую последовательность шагов:

1. Определение типа оценки.

2. Определение области оценки и границ продукта.

3. Подсчет функциональных точек, связанных с данными.

4. Подсчет функциональных точек, связанных с транзакциями.

5. Определение суммарного количества не выровненных функциональных точек (UFP).

6. Определение значения фактора выравнивания (FAV).

7. Расчет количества выровненных функциональных точек (AFP).

Определение типа оценкиПервое, что необходимо сделать, это определить тип выполняемой оценки. Метод предусматривает оценки трех типов:

1. Проект разработки. Оценивается количество функциональности поставляемой пользователям в первом релизе продукта.

2. Проект развития. Оценивается в функциональных точках проект доработки: добавление, изменение и удаление функционала.

3. Продукт. Оценивается объем уже существующего и установленного продукта.Определение области оценки и границ продуктаВторой шаг — это определение области оценки и границ продукта.

В зависимости от типа область оценки может включать:

• Все разрабатываемые функции (для проекта разработки)

• Все добавляемые, изменяемые и удаляемые функции (для проектов поддержки)• Только функции, реально используемые, или все функции (при оценке продукта и/или продуктов).

Третий шаг. определяют:

• Что является «внешним» по отношению к оцениваемому продукту.

• Где располагается «граница системы», через которую проходят транзакции передаваемые или принимаемые продуктом, с точки зрения пользователя.

• Какие данные поддерживаются приложением, а какие — внешние. К логическим данным системы относятся:

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

• Внешние интерфейсные файлы (EIFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, на которые ссылается продукт, но которые поддерживаются вне продукта.Примером логических данных (информационных объектов) могут служить: клиент, счет, тарифный план, услуга.Подсчет функциональных точек, связанных с даннымиТретий шаг — подсчет функциональных точек, связанных с данными.

Сначала определяется сложность данных по следующим показателям:

• DET (data element type) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's

• RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности. Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs)  в зависимости от их сложности

.Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 неповторяемых уникальное полей данных. Согласно матрице, нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно Таблица  его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.

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

В методе различаются следующие типы транзакций

• EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.

• EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.

• EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.Оценка сложности транзакции основывается на следующих ее характеристиках:

• FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.

• DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.



АЛГОРИТМИЧЕСКОЕ МОДЕЛИРОВАНИЕ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.3.1.

ТЕОРЕТИЧЕСКИЕ (МАТЕМАТИЧЕСКИЕ) МОДЕЛИ Математическое моделирование трудоемкости разработки ПО основано на сопоставлении экспериментальных данных с формой существующей математической функции. В начале 1960-х годов Питер Норден из фирмы IBM пришел к выводу, что в проектах по исследованию и разработке может применяться хорошо прогнозируемое распределение трудовых ресурсов, основанное на распределении вероятности, называемом кривой Рэлея (Rayleigh distribution). Позднее, в 1970-х годах Лоуренс Патнэм из компании Quantitative Systems Management применил резуль­таты Нордена к разработке ПО. Используя статистический анализ проектов, Патнэм обнаружил, что взаимосвязь между тремя основными параметрами проекта (размером, временем и трудоемкостью) напоминает функцию Нордена-Рэлея, отра­жающую распределение трудовых ресурсов проекта в зависимос­ти от времени.

Функция Рэлея моделируется дифференциальным уравнением:

где dy/dt — скорость роста персонала проекта; / — время, прошед­шее от начала проекта до изъятия продукта из эксплуатации; К — область под кривой ~ представляет полную трудоемкость в течение всего жизненного цикла (включая сопровождение), выраженную в человеко-годах; а —константа, которая определяет форму кривой (фактор ускорения) и вычисляется по формуле a=\/2t, где t^ - время разработки. Приняв ряд допущений, Патнэм получил следующее уравне­

ние: где Е — трудоемкость разработки ПО, S — размер ПО в LOC, t^ —планируемый срок разработки, С — технологический фактор,учитывающий различные аппаратные ограничения, опыт персонала и характеристики среды профаммирования. Он определяется на основехронологических данных по прошлым проектам и,согласно рекомендациям Патнэма определяется для различныхтипов проектов следующим образом:

• проект, внедренный в сжатые сроки без детальной прора­ботки, - 1500;

• проект, выполненный в соответствии с четким планом, —5000;

• проект, предусматривающий оптимальную организацию иподдержку, — 10000.

Оптимальный срок разработки определяется какчто хорошо согласуется с большинством статистических моделей.Более подробное описание модели Патнэма приведено в книге Фатрелл Р., Шафер Д., Шафер Л. Управление программнымипроектами: достижение оптимального качества при минимумезатрат: Пер. с англ. — М.: Вильяме, 2003.

6.3.2.

СТАТИСТИЧЕСКИЕ (РЕГРЕССИОННЫЕ) МОДЕЛИ

Статистические модели используют накопленные хронологи­ческие данные, чтобы получить значения для коэффициентов модели. Для определения соотношений между параметрами модели и трудоемкостью разработки ПО используется рефессион-ный анализ. Существуют две формы статистических моделей: линейные и нелинейные.Линейные статистические моделиимеют следующий вид:Трудоемкость = Ль + S А- ^^tгде X/ - факторы, влияющие на трудоемкость, Ь^ — коэффициен­ты модели. Линейные модели работают не слишком хорошо,поскольку практика показывает, что соотношения между трудо­емкостью и размером ПО нелинейны.

По мере роста размера ПОвозникает экспоненциальный отрицательный эффект масштаба.Нелинейные статистические модели имеют следующий вид:Трудоемкость = у4*(Размер ПО)^.где А — комбинация факторов, влияющих на трудоемкость; b —экспоненциальный коэффициент масштаба.Статистические модели просты для понимания, но имеютследующий недостаток: результаты справедливы в основномтолько для конкретной ситуации.

Другой недостаток — при уве­личении количества входных параметров количество данных,не­обходимых для калибровки модели, также возрастает.Статистическая модель СОСОМОIIМодель СОСОМО^ (Constructive COst Model — конструктив­ная модель стоимости), разработанная Барри Боэмом, является одной из самых известных и хорошо документированных моделей оценки трудоемкостиразработки ПО.

Исходная модельСОСОМО основывалась на базе данных по 56 выполненнымпроектам, а ее различные варианты отражали различия междупроцессами в различных областях ПО.В модели СОСОМО используется ряд допущений.

• Исходный код конечного продукта включает в себя все(кроме комментариев) строки кода.

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

• Виды деятельности включают в себя только непосредствен­но направленные на выполнение проекта работы, в них невходят обычные вспомогательные виды деятельности, та-кие, как административная поддержка, техническое обеспе­чение и капитальное оборудование.

• Человеко-месяц состоит из 152 ч.

• Проект управляется надлежащим образом, в нем использу­ются стабильные требования.

Проект СОСОМО П (современный вариант модели СОСО-МО) был выполнен в Центре по разработке ПО Южно-Калифор­нийского университета (USC Centre for Software Engineering).Этот проект преследовал следующие цели.

• Разработать модель для оценки трудоемкости и сроков соз­дания ПО для итерационной модели жизненного цикла ПО которая будет применяться в 1990-х и 2000-х годах.

• Создать базу данных по трудоемкости ПО.

• Разработать инструментальную поддержку для усовершен­ствования модели.

• Создать количественную аналитическую схему для оценки

технологий создания ПО и их экономического эффекта.

EMi — мультипликативные коэффициенты трудоемкости;

SFj — экспоненциальные коэффициенты масштаба;

Size — размер ПО, выраженный в тысячах строк исходного

кода или количестве функциональных точек без учета поправоч­

ных коэффициентов (UFP), определенном по методике 1FPUG,

с последующим преобразованием в количество строк кода. Калибровочные переменные А, В, С иВ в модели СОСОМО

II версии 2000 г. принимают следующие значения: А = 2.94, В =

0.91, С= 3.67,/) = 0.28.

Коэффициенты ЕМ^ отражают совместное влияние многихпараметров. Они позволяют характеризовать и нормировать среду разработки по параметрам, содержащимся в базе данных проектов модели СОСОМО II (в настоящее время более 160 проектов).

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

Результат учета этих 17 коэффициентов используется при вычислении в уравнении трудоемкости.Показатель экспоненты процесса Е может изменяться в диа­пазоне от 0.91 до 1.23 и определяется как сочетание следующих

параметров.

1. Наличие прецедентов у приложения: степень опытностиорганизации-разработчика в данной области.

2. Гибкость процесса: степень строгости контракта, порядокего выполнения, присущая контракту свобода внесения измене­ний, виды деятельности в течение всего жизненного цикла и взаимодействие между заинтересованными сторонами.

3. Разрешение рисков, присущих архитектуре: степень техни­ческой осуществимости, продемонстрированной до перехода кполномасштабному внедрению.

4. Сплоченность команды: степень сотрудничества и того,насколько все заинтересованные стороны (заказчики, разработ­чики, пользователи, ответственные за сопровождение и другие) разделяют общую концепцию.

5. Зрелость процесса: уровень зрелости организации-разра­ботчика, определяемый в соответствии с моделью СММ.В табл. 6.9 приведены возможные значения экспоненциаль­

ных коэффициентов масштаба, составляющих в сумме показа­тель Е. Суммарное влияние этихкоэффициентов может оказать­ся весьма существенным.Пример экспоненциального коэффициента масштаба — коэф­фициент зрелости процессов (РМАТ— Process Maturity).Значениекоэффициента РМАТ зависит в основном от уровнязрелости процессов в соответствии с моделью СММ.

Процедураопределения значения РМАТ основана на определении процентасоответствия для каждой из 18 основных групп процессов (keyprocess areas — КРА), определенных в СММ. Процент соответ­ствия вычисляется на основе групп процессов (подробно описано 8 групп из 18).

1])уппа процессов

КРА 1 — Управление требованиями

• Требования к системе контролируются и служат основой для разработ­ки ПО и управления проектом

• Планы создания ПО, продукты и виды деятельности согласованы стребованиями к ПОКРА 2 — Планирование проекта

• Оценки ПО документируются и используются для планирования иотслеживания проекта

• Проектные виды деятельности и обязанности планируются и доку­ментируются

• Участники проекта (группы и индивидуумы) придерживаются своих обязанностей по отношению к проекту КРА 3 — Отслеживание и контроль проекта

• Текущие результаты и продуктивность отслеживаются на предмет со­ответствия планам

• В случае существенного отклонения от планов предпринимаются кор­ректирующие действия

• Изменения в обязанностях согласовываются с соответствующими

группами и индивидуумами

КРА 4 — Управление контрактами

КРА 5 — Обеспечение качества продукта

КРА 6 — Управление конфигурацией ПО

• Управление конфигурацией планируется

• Обеспечивается идентификация, контроль и доступ к выбранным ра­бочим продуктам

• Изменения, вносимые в конкретные рабочие продукты, контролиру­ются

• Участники проекта информируются о состоянии содержания базовых версий ПО

КРА 7 — Координация процессов организации

КРА 8 — Стандартизация процессов организации

КРА 9 - Обучение

КРА 10 — Интегрированное управление созданием ПО

• Процессы создания ПО в рамках конкретного проекта являются адап­тированной версией стандартных процессов, принятых в организации

• Проект планируется и управляется в соответствии с установленным в проекте процессом создания ПО КРА 11 — Разработка программного продукта

• Задачи разработки продукта четко определены, интегрированы и пос­ледовательно реализуются

• Рабочие продукты согласованы друг с другом

КРА 12 — Межгрупповая координация

КРА 13 — Экспертные оценки КРА 14 — Количественное управление проектом

КРА 15 — Управление качеством продукта

КРА 16 — Предотвращение дефектов

КРА 17 — Управление изменениями в технологии

• Изменения в технологии планируются

• Новые технологии оцениваются на предмет их воздействия на качест­во и продуктивность

• Подходящие новые технологии внедряются в обычную практику орга­низации

КРА 18 — Управление изменениями в процессах

• Планируется постоянное совершенствование процессов

• В совершенствовании процессов участвует вся организация

• Стандартные процессы организации и процессы конкретных проектов постоянно совершенствуются Оценочный уровень зрелости процессов (EPML) вычисляет­ся следующим образом:




Пример мультипликативного коэффициента трудоемкости — коэффициент использования инструментальных средств В целом модель СОСОМО II является хорошим усовершен­ствованием традиционных и устаревших моделей трудоемкости. Она вполне соответствует принципам итерационной разработки и современным технологиям создания ПО.

В частности, СОСОМО II активно используется в технологии Rational Unified Process. Вместе с тем она постоянно развивается, поскольку ее база данных пополняется сведениями о разнообразных проектах

Материалы сообщества доступны в соответствии с условиями лицензии CC-BY-SA , если не указано иное.