23. Длительность разработки программных средств, распределение затрат по этапам разработки.

Диапазон приемлемых длительностей разработок T_р ограничен сверху 10 годами (рациональными сроками создания самых сложных ИС), а снизу – 1 – 3,5 года (сроками естественного технологического процесса).

Среднюю длительность разработки можно аппроксимировать зависимостью

Т_р = 0,8 Пк1/3, или Т_р = 1,4 Пк¼ лет, где Пк – объём ПС в тысячах команд.

По опыту эксплуатации трудоёмкость отдельных этапов разработки различается в 2 – 4 раза, а загрузка отдельных категорий специалистов на них – в 3 – 5 раз. Это надо учитывать при планировании и организации проектирования ПС, а также при прогнозировании затрат на непосредственную разработку программ. Так же неравномерно в зависимости от этапов изменяется и потребность в машинном времени С_4р, причём для разных ЭВМ (моделирующих, технологических, реализующих) эта потребность находится в широком диапазоне и является максимальной для этапа динамической отладки. Такие оценки затрат машинного времени позволяют рационально планировать и прогнозировать необходимую аппаратную оснащённость разработок по этапам и в целом на весь ЖЦ. Упорядоченный подход к организации проектирования сложных ПС с учётом вышеизложенного позволяет создавать ПС с высоким качеством и допустимыми затратами, если использовать современные технологии, методы и системы автоматизации проектирования, выбирая их на основе системного и технико-экономического анализа достигаемого эффекта и ресурсов на весь ЖЦ.

27.Показатели качества ПО.

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

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

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

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

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

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

Примечание: правильнее эту характеристику называть производительностью (performance); тогда как эффективность должна также зависеть от затрат на создание и внедрение ПО.

5. Сопровождаемость (maintainability)- совокупность свойств ПО, характеризующая усилия, которые необходимы для его модификации. Модификация, может осуществляться для устранения дефектов, усовершенствования ПО или его адаптации к изменениям в условиях функционирования, a также в составе и особенностях требуемых функций.

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

26. Порядок и методология проведения статического анализа программных средств.

Статический анализ проводится в соответствии со стандартом, все положения которого подлежат обязательному применению в испытательных центрах (лабораториях), аккредитованных в системе РОСИНФОСЕРТ. Данный стандарт распространяется на все программные средства независимо от их назначения и области применения. Проведение СА начинается обычно с построения графа вызовов, который отражает модульную структуру ПС. Вершины графа изображаются в виде прямоугольников, содержащих имена компонент (модулей), ребра – в виде стрелок. Затем формируется список путей вызовов.

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

Обычно в списке путей вызовов представлены все пути, которые подлежат тестированию.

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

одна из них непосредственно вызывает другую;

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

Строки и столбцы матрицы содержат имена компонент в иерархии вызовов и упорядочены по иерархическим уровням сверху вниз.

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

Оценка тестируемости ПС–(T) может быть проведена с использованием формул

Nв

Т = [(1 / Nв) · (∑1 / Pi)]-1,

i=1

где NВ – количество путей вызовов в графе вызовов модулей;

Pi – тестируемость i-го пути вызовов, равная

k

Pj = [∑1 / A(Mj)]-1,

j=1

где k – количество модулей в пути вызовов; А (Мj) – доступность модуля

Мj, принадлежащего пути Рi, определяется следующим образом:

n

А (Мj) = ∑ А (Мx) / C (Мx),

x=1

где А (Мx) – доступность x-го модуля, вызывающего Мj;

C (Мx) – количество всех модулей, которые вызывает Мx;

n – количество модулей, которые вызывают Mj;

А(М) = 1, если модуль М является самым верхним (головным) модулем.

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

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

требует привлечения эксперта высокой квалификации (как программиста и как эксперта качества);

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

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

Независимо от способа проведения СА (автоматизированного или ручного) следует учитывать особенности СА на различных этапах.