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

Размещено на http://www.allbest.ru/

1. Цели и задачи технологий разработки ПО. Особенности современных крупных проектов ИС

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

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

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

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

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

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

- функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

2. Основные определения. Программные средства. Программное обеспечение (ПО). Программный продукт. Проектирование ПО

Введение в процесс разработки программного обеспечения.

Разработка программного обеспечения является очень молодой и быстро развивающейся отраслью инженерной науки. Она подвержена постоянным и быстрым изменениям. Так, всего лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Society) начало присваивать разработчикам программ звание инженера (Chartered Engineer), а в Соединенных Штатах только в 1998 году стало возможным хоть где-то (а точнее, в штате Техас) зарегистрироваться в качестве профессионального инженера программного обеспечения.

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

Основные понятия и определения.

Программное обеспечение (Software) - полный набор или часть программ, процедур, правил и связанной с ними документации системы обработки информации. (ИСО/МЭК 2382-1 1993) Примечание. ПО - интеллектуальный продукт, не зависящий от среды, на которой он записан.

Программные средства (Software product) - набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных. Примечание. Объем понятия, выражаемого термином "программные средства" включает в себя как частный случай объем понятия 'программное обеспечение" определяемого по Г'ОСТ 19781.

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

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

3. Классификация типов программного обеспечения

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

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

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

Автономное:

- устанавливаемое на одиночный компьютер;

- не связанное с другим программным и аппаратным обеспечением;

- пример - текстовый редактор.

Встроенное:

- часть уникального приложения с привлечением аппаратного обеспечения;

- пример - автомобильный контроллер.

Реального времени:

- должны выполнять функции в течение малого интервала времени, обычно нескольких микросекунд;

- пример - программное обеспечение радиолокатора.

Сетевое:

- состоит из частей, взаимодействующих через сеть;

- пример - основанная на веб технологии видеоигра.

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

4. Жизненный цикл (ЖЦ) ПИ. Процессы ЖЦ ПИ

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту:

- основные процессы ЖЦ ПО: приобретение (заказ), поставка, разработка, эксплуатация, сопровождение;

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

- организационные процессы: управление, создание и сопровождение инфраструктуры, усовершенствование, обучение.

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

Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

5. Модели ЖЦ ПО. Каскадная модель. Содержание этапов создания ПИ

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО.

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

Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки.

Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 гг.);

- спиральная модель (86-90 гг.);

- инкрементальная модель.

6. Каскадная модель процесса

Рис. 1. - Каскадная схема разработки ПО:

Анализ требований - сбор требований к продукту. Результатом анализа, как правило, является некоторый текст/документ (ТЗ).

Проектирование - описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов.

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

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

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

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

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

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

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

7. Модели ЖЦ ПО. Спиральная модель. Содержание этапов создания ПИ

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО.

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

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

Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки.

Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 гг.);

- спиральная модель (86-90 гг.);

- инкрементальная модель.

Спиральная модель процесса.

В случае спирального процесса (автор Барри Боэм,1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

Версии продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

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

Рисунок 2:

Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).

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

Минусы:

1. Требуется более искусное управление;

2. Необходимость поддержки целостности документации, которая должна быть полностью сформирована к концу каждой версии;

3. Трудность в определении момента перехода на следующий этап;

4. Переход осуществляется в соответствии с планом даже если не все работы выполнены;

5. Слишком большое количество витков потребует увеличения затрат, больших затрат.

Типичный проект:

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

Затраты на проведение большего числа шагов могут просто перевесить выгоду от дополнительных итераций.

8. Модели ЖЦ ПО. Инкрементальная модель. Содержание этапов создания ПИ

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 гг.);

- спиральная модель (86-90 гг.);

- инкрементальная модель.

Инкрементальная модель.

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

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

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

Рисунок 3:

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

Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314.

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

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

1. План управления программным проектом;

2. Проектная документация программного обеспечения;

3. Спецификация требований к программному обеспечению.

9. Развитие инкрементального подхода. XP-процессы

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности;

- модель быстрой разработки приложений RAD (Rapid Application Development). RAD-модель обеспечивает эстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет группе создать полностью функциональную систему за 60-90 дней.

Выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бизнес-функциями;

- моделирование данных. Информационный поток отображается в набор объектов данных;

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

- генерация приложения. Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации;

- тестирование и объединение. Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD:

1. Для больших проектов требуются значительные людские ресурсы для создания групп;

2. Модель применима только для тех систем, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной;

3. Не применима в условиях высоких технических рисков, т. е., при использовании новой технологии.

В современной программной инженерии выделяют два семейства процессов разработки:

- прогнозирующие (predictive) или тяжеловесные (heavyweight) процессы - прогнозируется весь объем работ, большой объем документации, строгий порядок разработки, фиксированные требования и многочисленная группа разработчиков разной квалификации;

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

Экстремальное программирование - это облегченный процесс (Кент Бек, 1999). Он ориентирован на группы малого и среднего размера, работающие в условиях неопределенных и быстро изменяющихся требований. В группу входит до 10 сотрудников, работающих в одном помещении.

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

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

- непрерывная связь с заказчиком;

- простота (всегда выбирается минимальное решение);

- быстрая обратная связь (модульное и функциональное тестирование);

- смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

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

2. Частая смена версий новые версии каждые 2 недели;

3. Метафора - вся разработка проводится на основе простой общедоступной истории о том как работает система. Истории обеспечивают заказчики;

4. Простое проектирование;

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании;

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость;

7. Парное программирование -весь код пишется двумя программистами, работающими на одном компьютере.. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%;

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

9. Непрерывная интеграция - интегрирование системы несколько раз в день по мере завершения каждой задачи;

10. Локальный заказчик - в группе все время должен находиться представитель заказчика, готовый отвечать на все вопросы;

12. Стандарты кодирования - правила, обеспечивающие одинаковое представление программного кода.

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

К таким стандартам относятся следующие:

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Над данными стандартами работает ISO/IEС JTC1/SC7 - международный технический комитет стандартов под контролем ИСО (ISO - Международная организация по стандартизации) и МЭК (IEС - Международная электротехническая комиссия).

Стандарт проектирования устанавливает (ISO/IEC 2382-20: 1990, Information technology ~ Vocabulary - Part 20: Systems development. (Разработка систем).):

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации устанавливает ИСО 6592:1985, Обработка информации. Руководящие указания по документированию автоматизированных прикладных систем:

- комплектность, состав и структуру документации на каждой стадии проектирования;

- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.);

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

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

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

Стандарт интерфейса пользователя устанавливает (ИСО 6385:1981, Эргономические принципы проектирования рабочих систем):

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя.

11. Измерения, меры и метрики. Размерно-ориентированные метрики. Функционально-ориентированные метрики

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

Измерения при разработке ПО необходимы для того, чтобы:

- определить или показать качество продукции;

- оценить производительность труда персонала, занятого разработкой;

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

- сформировать основу (базовую линию) для последующих оценок;

- получить данные для обоснования запросов на дополнительные средства, обучение и т. п.

Измерения бывают прямые и косвенные. Результаты прямых измерений процесса разработки и сопровождения программного изделия: трудозатраты и стоимость, число строк кода (LOC - lines-of-code), размер требуемой памяти, скорость выполнения программы, число ошибок (дефектов), обнаруженных за определенный период времени. Косвенные измерения дают оценку функциональных возможностей, показателей качества программного продукта (надежность, эффективность, пригодность к сопровождению и т. п.).

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

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

Вторая классификация метрик - классификация по признаку их ориентации:

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

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

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

Размерно-ориентированные метрики.

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка - это количество строк в программном продукте. Принято регистрировать следующие показатели:

- общие затраты (в чел./мес.);

- объем программного изделия (в тысячах строк исходного кода -KLOC);

- стоимость разработки (в тыс.рублей или в долларах $);

- объем документации (в страницах документов - СД);

- ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО);

- число людей, работавших над изделием (человек);

- срок разработки (в календарных месяцах).

На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества:



Достоинства размерно-ориентированных метрик:

1) широко распространены;

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1) зависимы от языка программирования;

2) требуют исходных данных, которые трудно получить на начальной стадии проекта;

3) не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики.

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

1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

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

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

Количество функциональных указателей вычисляется по формуле:

Где:

Fi - коэффициенты регулировки сложности.

После вычисления FP на его основе формируются метрики производительности, качества и т. д.

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

Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points).

Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО.

Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов.

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

Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки.



программирование компьютерный интерфейс

Достоинства функционально-ориентированных метрик:

1. Не зависят от языка программирования;

2. Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Размещено на Allbest.ru

...