1. Сущность и актуальность дисциплины «Технологии программирования», основные понятия и определения дисциплины. Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Как любая другая технология, технология программирования представляет собой набор технологических инструкций, включающих: • указание последовательности выполнения технологических операций; • перечисление условий, при которых выполняется та или иная операция; описания самих операций, где для каждой операции определены исходные данные, результаты, а также инструкции, нормативы, стандарты, критерии и методы оценки и т. п.
Программный продукт — программа, которую можно запускать, тестировать, исправлять и развивать. Программное изделие — программа на носителе данных, являющаяся продуктом промышленного производства. Программное обеспечение автоматизированных систем — совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности автоматизированных систем. Автоматизированная система (АС) — организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности. Проектирование — это разработка проекта, процесс создания спецификации, необходимой для построения в заданных условиях еще несуществующего объекта на основе первичного описания этого объекта. Спецификация в сфере проектной деятельности — это какое-либо описание в точных терминах. Проектным документом называют документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение. В программировании проектные решения оформляются в виде программной документации. Проект (от лат. projectus — брошенный вперед) — совокупность проектных документов в соответствии с установленным перечнем, которая представляет результат проектирования. Проектной ситуацией называют реальность (ситуацию), в которой ведется проектирование. Методики проектирования излагаются в виде описаний проектных процедур и проектных операций. Методология программирования изучает методы с точки зрения основ построения. 2. Жизненный цикл программного средства. Жизненный цикл программного средства – это совокупность процессов (software process), которая отражает его различные состояния, начиная с момента принятия решения о необходимости создания программного средства и заканчивая его полным изъятием из эксплуатации. Состав процессов жизненного цикла регламентируется стандартами. Международными организациями, такими, как: IEEE — Институт инженеров по электротехнике и электронике; • ISO —Международная организация по стандартизации; • EIA —Ассоциация электронной промышленности; • IEC —Международная комиссия по электротехнике; а также некоторыми национальными и региональными институтами и организациями: • ANSI —Американский национальный институт стандартов; • SEI —Институт программной инженерии; • ECMA —Европейская ассоциация производителей компьютерного оборудования;
Структура жизненного цикла базируется на трёх группах процессов: Основные процессы. Вспомогательные процессы. Организационные процессы Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными и результатами. Основные процессы: • приобретение, • поставка, • разработка, • эксплуатация, • сопровождение. Вспомогательные процессы (обеспечивающие выполнение основных процессов): • документирование, • обеспечение качества, • управление конфигурацией, • верификация, • аттестация. Организационные процессы: • управление проектами, • создание инфраструктуры проекта, • определение, • оценка и улучшение самого жизненного цикла, • обучение. По стандарту процесс разработки включает следующие действия: • подготовительную работу • анализ требований к системе • проектирование архитектуры • анализ требований к программному обеспечению • проектирование архитектуры программного обеспечения • детальное проектирование программного обеспечения • кодирование и тестирование программного обеспечения • интеграцию программного обеспечения; • квалификационное тестирование программного обеспечения • интеграцию системы • квалификационное тестирование системы; • установку программного обеспечения • приемку программного обеспечения. Жизненный цикл состоит из логически завершённых частей, называемых стадиями. Каждая стадия порождает определённый набор документов и технических решений. Различают следующие стадии жизненного цикла ПС: разработка ПС, производство программных изделий (ПИ) и эксплуатация ПС. 3. Модели жизненного цикла ПО. Под моделью жизненного цикла программного средства понимается структура, определяющая последовательность выполнения стадий, и взаимосвязи стадий на протяжении жизненного цикла. Различают три модели жизненного цикла по: каскадная, модель с промежуточным контролем и спиральная. 4. Каскадная модель предполагала что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии. Достоинствами такой схемы являются: • получение в конце каждой стадии законченного набора проектной документации, отвечающего требованиям полноты и согласованности; • простота планирования процесса разработки.
Каскадная схема разработки программного обеспечения Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности разработки. Однако данная схема оказалась применимой только к созданию систем, для которых в самом начале разработки удавалось точно и полно сформулировать все требования. Это уменьшало вероятность возникновения в процессе разработки проблем, связанных с принятием неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне редко. В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами: • неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений; • изменение требований заказчика непосредственно в процессе разработки; • быстрое моральное устаревание используемых технических и программных средств; • отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования. 5. Модель с промежуточным контролем Схема, поддерживающая итерационный характер процесса разработки, была названа схемой с промежуточным контролем (рис. 2.3). Контроль, который выполняется по данной схеме после завершения каждого этапа, позволяет при необходимости вернуться на любой уровень и внести необходимые изменения.
Схема разработки программного обеспечения с промежуточным контролем Основная опасность использования такой схемы связана с тем, что разработка никогда не будет завершена, постоянно находясь в состоянии уточнения и усовершенствования. 6. Спиральная модель Для преодоления перечисленных проблем в середине 80-х годов XX в. была предложена спиральная схема. В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов.
Спиральная или итерационная схема разработки программного обеспечения
Прототипом называют действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения. На первой итерации, как правило, специфицируют, проектируют, реализуют и тестируют интерфейс пользователя. На второй – добавляют некоторый ограниченный набор функций. На последующих этапах этот набор расширяют, наращивая возможности данного продукта. Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на которой обеспечена определенная функциональная полнота, продукт можно предоставлять пользователю, что позволяет: • сократить время до появления первых версий программного продукта; • заинтересовать большое количество пользователей, обеспечивая быстрое продвижение следующих версий продукта на рынке; • ускорить формирование и уточнение спецификаций за счет появления практики использования продукта; • уменьшить вероятность морального устаревания системы за время разработки. Основной проблемой использования спиральной схемы является определение моментов перехода на следующие стадии. Для ее решения обычно ограничивают сроки прохождения каждой стадии, основываясь на экспертных оценках. 7. Изменение жизненного цикла программного обеспечения при использовании CASE-технологий. CASE-технологии представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, основанных как на структурном, так и на объектном подходах, которые поддерживаются комплексом взаимосвязанных средств автоматизации. В основе любой CASE-технологии лежит парадигма методология/метод/нотация/средство. Методология строится на базе некоторого подхода и определяет шаги работы, их последовательность, а также правила распределения и назначения методов. Метод определяет способ достижения той или иной цели – выполнение шага работы. Нотацией называют систему обозначений, используемых для описания некоторого класса моделей. Нотации бывают графические (предоставление моделей в виде графов, диаграмм, таблиц, схем и т. п.) и текстовые (описания моделей на формальных и естественных языках). В CASE-технологиях нотации используют для описания структуры проектируемой системы, элементов данных, этапов обработки и т. п. Средства – инструментарий для поддержки методов: средства создания иедактирования графического проекта, организации проекта в виде иерархии уровней абстракции, а также проверки соответствия компонентов разных уровней Автоматизируя трудоемкие операции, современные CASE-средства существенно повышают производительность труда программистов и улучшают качество создаваемого программного обеспечения. Они: • обеспечивают автоматизированный контроль совместимости спецификаций проекта; • уменьшают время создания прототипа системы; • ускоряют процесс проектирования и разработки; • автоматизируют формирование проектной документации для всех этапов жизненного цикла в соответствии с современными стандартами; • частично генерируют коды программ для различных платформ разработки; • поддерживают технологии повторного использования компонентов системы; обеспечивают возможность восстановления проектной документации по имеющимся исходным кодам. Использование CASE-средств позволяет существенно снизить трудозатраты на разработку сложного программного обеспечения в основном за счет автоматизации процессов документирования и контроля. Однако следует иметь в виду, что современные CASE-средства дороги, а их использование требует более высокой квалификации разработчиков. Следовательно, их имеет смысл использовать в сложных проектах, причем, чем сложнее разрабатываемое программное обеспечение, тем больше выигрыш от использования CASE-технологий. На сегодняшний день практически все промышленно производимое сложное программное обеспечение разрабатывается с использованием CASE-средств. 8. Качество программного обеспечения. Качество ПО – набор характеристик продукта или сервиса, которые характеризуют его способность удовлетворить установленным или предполагаемым потребностям заказчика. Понятие качества имеет разные интерпретации в зависимости от конкретной системы и требований к программному продукту. Кроме того, в разных источниках таксономия и модели качества отличаются. Каждая модель имеет различное число уровней и общее число характеристик качества. Стандарт ISO 9126-01 рассматривает внешние и внутренние характеристики качества. Внутренние характеристики качества и внутренние атрибуты ПО используются при составлении плана достижения необходимых внешних характеристик качества для конечного программного продукта. Внешние и внутренние характеристики качества отображают свойства самого ПО (работающего или не работающего), а также взгляд заказчика и разработчика на это ПО. Концепция качества ПО включает внешние и внутренние характеристики качества, их метрики, а также модели качества, определенные на множестве внешних и внутренних характеристик, которые определены в стандартах качества – это шесть характеристик и для каждого из них 4-5 атрибутов. К характеристикам качества относятся: • функциональность, • надежность, • удобства использования, • эффективность, • сопровождаемость, • переносимость. Определение и планирование качества ПО основывается на положениях стандартов в этой области, составлении планов графиков работ и процедурах проверки и др. План обеспечения качества включает набор действий для проверки процессов обеспечения качества (верификация, валидация и др.) и формирование документа по управлению качеством. Деятельности и техники гарантии качества включают: инспекцию, верификацию и валидацию ПО. Инспекция ПО – анализ и проверка различных представлений системы и ПО (спецификаций, архитектурных схем, диаграмм, исходного кода и др.) и выполняется на всех этапах ЖЦ разработки ПО. Верификация ПО – процесс обеспечения правильной реализации ПО, которое соответствует спецификациям, выполняется на протяжении всего жизненного цикла. Верификация дает ответ на вопрос, правильно ли создана система. Валидация – процесс проверки соответствия ПО функциональным и нефункциональным требованиям и ожидаемым потребностям заказчика. Измерение в анализе качества ПО основывается на: сборе данных при выполнении процессов создания продукта на заданных ресурсах; определении метрик оценки процессов, ПО и моделей их измерения; документировании измерений и др. Для оценки фактических характеристик качества продукта проводится тестирование ПО путем исполнения кода на тестовых данных, сбора статистики и проведения анализа выходных результатов и полученных рабочих характеристик ПО. 9. Модели качества ПО Качество ПО было предметом стандартизации, создан стандарт ГОСТ 28195–89, в котором дано определение качества ПО, как совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика, в соответствии с назначением. Этот стандарт регламентирует базовую модель качества и его показатели, главным среди них является надежность. На этапах ЖЦ проводится анализ качества ПО, ориентированный на: • достижение качества ПО в соответствии с требованиями и критериями; • верификацию и аттестацию (валидацию) промежуточных результатов ПО на этапах ЖЦ и измерение степени достижения отдельных его показателей; • тестирование готовой ПС, сбор данных об отказах, дефектах и др. ошибках в системе и оценивание надежности по соответствующим моделям надежности. Качество ПО характеризуется тремя главными аспектами: качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения
Рис. 3.1 Основные аспекты качества ПО
Рис. 3.2. Модель характеристик качества Модель качества ПО имеет следующие четыре уровня детализации. Первый уровень соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную точку зрения пользователя на качество. Согласно стандартов ISO/IEC 9126, ГОСТ 2895 – 89 определено шесть характеристик или шесть показателей качества в стандартной модели качества: 1. функциональность (functionality), 2. надежность (realibility), 3. удобство (usability), 4. эффективность (efficiency), 5. сопровождаемость (maitainnability), 6. переносимость (portability). Второму уровню соответствуют атрибуты качества для каждой характеристики, которые детализируют разные аспекты конкретной характеристики. Набор атрибутов характеристик качества используется при оценки качества. Третий уровень предназначен измерения качества с помощью метрик, каждая из них определяется как комбинация метода измерения атрибута и шкалы измерения значений атрибутов. Для оценки атрибутов качества на этапах ЖЦ (при просмотре документации, программ и результатов тестирования программ) используются метрики с заданным оценочным весом для нивелирования результатов метрического анализа совокупных атрибутов конкретного показателя и качества в целом. Атрибут качества определяется с помощью одной или нескольких методик оценки на этапах ЖЦ и на завершающем этапе разработки ПО Четвертый уровень задает оценочный элемент метрики для оценки количественного или качественного значения отдельного атрибута показателя ПО с учетом его веса. 10. Метрики качества программного обеспечения. Система измерения ПО включает метрики и модели измерений, которые используются для количественной оценки его качества. При определении требований к ПО задаются соответствующие им внешние характеристики и их подхарактеристики (атрибуты), определяющие разные стороны функционирования и управления продуктом в заданной среде. Существует три типа метрик: • метрики программного продукта, которые используются при измерении его характеристик – свойств; • метрики процесса, которые используются при измерении свойства процесса, используемого для создания продукта. • метрики использования. Метрики программного продукта включают: • внешние метрики, обозначающие свойства продукта, видимые пользователю; • внутренние метрики, обозначающие свойства, видимые только команде разработчиков. Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам. Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования способов достижения качества конечного программного продукта. Метрики процессов включают метрики: стоимости, определяющие затраты на создание продукта или на архитектуру проекта с учетом оригинальности, поддержки, документации разработки; • оценки стоимости работ специалистов за человеко-дни либо месяцы; • ненадежности процесса – число не обнаруженных дефектов при проектировании; • повторяемости, которые устанавливают степень использования повторных компонентов. В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования и др. Практически используются следующие метрики процесса: • общее время разработки и отдельно время для каждой стадии; • время модификации моделей; • время выполнения работ на процессе; • число найденных ошибок при инспектировании; • стоимость проверки качества; • стоимость процесса разработки. Метрики использования служат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации – эксплуатационное качество. 11. Измерение и оценка качества ПО, стандартный метод оценки значений показателей качества. Оценка качества ПО согласно четырех уровневой модели качества начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленных мер. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя анализируемого ПО, включенного в требования. По определению стандарта ISO/IES 9126–2 метрика качества ПО представляет собой “модель измерения атрибута, связываемого с показателем его качества”. Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер: • меры размера в разных единицах измерения (количество функций, размер программы, объем ресурсов и др.); • меры времени – периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.); • меры усилий – продуктивное время, затраченное на реализацию проекта (производительность труда отдельных участников проекта, коллективная трудоемкость и др.); • меры интервалов между событиями, например, время между последовательными отказами; • счетные меры – счетчики для определения количества обнаруженных ошибок, структурной сложности программы, числа несовместимых элементов, числа изменений (например, число обнаруженных отказов и др.). Для изложения оценки значений показателей качества используется стандарт [4] в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов). Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др. Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения. Расчетный метод базируется на статистических данных, собранных при проведении испытаний, эксплуатации и сопровождении ПО. Расчетными методами оцениваются показатели надежности, точности, устойчивости, реактивности и др. Экспертный метод осуществляется группой экспертов – специалистов, компетентных в решении данной задачи или типа ПО. Их оценка базируются на опыте и интуиции, а не на непосредственных результатах расчетов или экспериментов. Для оценки значений показателей качества в зависимости от особенностей используемых ими свойств, назначения, способов их определения используются шкалы: • метрическая (1.1 – абсолютная, 1.2 – относительная, 1.3 – интегральная); • порядковая (ранговая), позволяющая ранжировать характеристики путем сравнения с опорными; • классификационная, характеризующая только наличие или отсутствие рассматриваемого свойства у оцениваемого программного обеспечения.
12. Управление качеством ПС. Под управлением качества понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством – SQM (Software Quality Management) базируется на применении стандартных положений по гарантии качества – SQA (Software Quality Assurance). Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности: • внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ; • оценка соблюдения положений этих стандартов и процедур. Гарантия качества состоит в следующем: • проверка непротиворечивости и выполнимости планов; • согласование промежуточных рабочих продуктов с плановыми показателями; • проверка изготовленных продуктов заданным требованиям; • анализ применяемых процессов на соответствие договору и планам; • среда и методы разработки согласуются с заказом на разработку; • проверка принятых метрик продуктов, процессов и приемов их измерения в соответствии с утвержденным стандартом и процедурами измерения. Для организации, которая занимается разработкой ПС в том числе из компонентов, инженерия качества ПС должна поддерживаться системой качества, управлением качеством (планирование, учет и контроль). Инженерия качества включает набор методов и мероприятий, с помощью которых программные продукты проверяются на выполнение требований к качеству и снабжаются характеристиками, предусмотренными в требованиях на ПО. Система качества – это набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством.
Требования стандарта к организации системы качества Важное место в инженерии качества отводится процессу измерения характеристик процессов ЖЦ, его ресурсов и создаваемых на них рабочих продуктов. Этот процесс реализуются группой качества, верификации и тестирования. В функции этой группы входит: планирование, оперативное управление и обеспечение качества. Планирование качества представляет собою деятельность, направленную на определение целей и требований к качеству. Оперативное управление включает методы и виды деятельности оперативного характера для текущего управления процессом проектирования, устранения причин неудовлетворительного функционирования ПС. Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству. 13. Диалоговые программы, типы диалога, формы диалога. Диалог – это процесс обмена информацией между пользователем и программной системой, осуществляемый через интерактивный терминал и по определенным правилам. Различают тип диалога и его форму. Тип диалога определяет, кто из «собеседников» управляет процессом обмена информацией. Соответственно различают два типа диалога: управляемые программой и управляемые пользователем. Диалог, управляемый программой, предусматривает наличие жесткого, линейного или древовидного, т. е. включающего возможные альтернативные варианты, сценария диалога, заложенного в программное обеспечение. Диалог, управляемый пользователем, подразумевает, что сценарий диалога зависит от пользователя, который применяет систему для выполнения необходимых ему операций. Описание языка, на котором ведется диалог, включает определение его синтаксиса – правил, определяющих допустимые конструкции (слова, предложения) языка или его форму, и семантики – правил, определяющих смысл синтаксически корректных конструкций языка или его содержание. В зависимости от вида используемых в конкретном случае синтаксиса и семантики различают три формы диалога: • фразовую, • директивную, • табличную. Фразовая форма предполагает «общение» с пользователем на естественном языке или его подмножестве. Содержание диалога в данной форме составляют повелительные, повествовательные и вопросительные предложения и ответы на вопросы. Общение может осуществляться в свободном формате, но возможна и фиксация отдельных фраз. Основными недостатками фразовой формы при использовании подмножества естественного языка являются: • большие затраты ресурсов; • отсутствие гарантии однозначной интерпретации формулировок; • необходимость ввода длинных грамматически правильных фраз. Основное достоинство фразовой формы состоит в относительно свободном общении с системой. Директивная форма предполагает использование команд (директив) специально разработанного формального языка. Командой в этом случае называют предложение этого языка, описывающее комбинированные данные, которые включают идентификатор инициируемого процесса и, при необходимости, данные для него. Табличная форма предполагает, что пользователь выбирает ответ из предложенных программой. Язык диалога для табличной формы имеет простейший синтаксис и однозначную семантику, что достаточно легко реализовать. Следует иметь в виду, что типы и формы диалога выбирают независимо друг от друга: любая форма применима для обоих типов диалогов (рис. 4.1).
Рис 4.1. Соответствие типов диалогов и его форм 14. Спецификация ПС. Разработка ПС начинается с этапа формулирования требований к ПС, на котором, исходя из довольно смутных пожеланий заказчика, должен быть получен документ, достаточно точно определяющий задачи разработчиков ПС. Этот документ мы называем внешним описанием ПС (в литературе его часто называют спецификацией требований). Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Исходным документом для разработки внешнего описания ПС являются определение требований к ПС. В определении внешнего описания легко бросаются в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели, которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС. Структуру внешнего описания ПС можно выразить формулой: Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС Таким образом, внешнее описание определяет, что должно делать ПС и какими внешними свойствами оно должно обладать. Оно не отвечает на вопрос, как должно быть устроено это ПС и как обеспечить требуемые его внешние свойства. Оно должно достаточно точно и полно определять задачи, которые должны решить разработчики требуемого ПС. 15. Определение требований к программному средству. Определение требования к ПС являются исходным документом разработки ПС – заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования. Неправильное понимание потребностей пользователя трансформируются в ошибки внешнего описания. Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними. Известны три способа определения требований к ПС: • управляемый пользователем, • контролируемый пользователем, • независимый от пользователя. В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемые требования действительно выражали его потребности в ПС. В независимой от пользователя разработке требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчете на то, разработанное им ПС найдет спрос на рынке программных средств.
16. Спецификация качества программного средства. Разработка спецификации качества сводится, по-существу, к построению своеобразной модели качества разрабатываемой ПС. В этой модели должен быть перечень всех тех достаточно элементарных свойств, которые требуется обеспечить в разрабатываемом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС, однозначно интерпретируемых разработчиками. Ниже приводится зависимость критериев качества от примитивов качества ПС. Функциональность: завершенность. Надежность: завершенность, точность, автономность, устойчивость, защищенность. Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам. Модифицируемость: расширяемость, структурированность, модульность. Мобильность: независимость от устройств, автономность, структурированность, модульность. Ниже даются определения используемых примитивов качества ПС. Завершенность – свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций. Точность – мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования. Устойчивость – свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных. Автономность – свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения. Коммуникабельность – свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, а также обеспечивает выдачу полезных сведений в форме и с содержанием, простыми для понимания. Временная эффективность – мера, характеризующая способность ПС выполнять возложенные на него функции за определенный отрезок времени. Расширяемость – свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент. Модульность – свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты. 17. Функциональная спецификация программного средства. Функциональная спецификация состоит из трех частей: • описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС; • определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС); • описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы. В первой части должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. Во второй части вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты. В третьей части должны быть перечислены все существенные с точки зрения внешнего наблюдателя (пользователя) случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (например, при обнаружении ошибки во время взаимодействия с пользователем, или при попытке применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в ее спецификации, или при получении результата, нарушающего заданное ограничение). Для каждого такого случая должна быть определена (описана) реакция ПС. 18. Методы контроля внешнего описания программного средства. Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля правильности внешне
