Файл: Технология раработки програмного обеспечения УП.pdf

31

Поскольку

60 %

затрат

производится

на

этапе

сопровож-

дения,

нет

ничего

удивительного,

что

максимум

кривой

близок

к

моменту

создания

системы,

т.е.

к

тому

моменту,

когда

тради-

ционно

считается,

что

работы

завершены.

Пусть

P(T > t)

вероятность

того,

что

в

интервале

[0, t]

со-

бытие

не

произошло.

Тогда

в

соответствии

с

законом

Пуассона

(

)

.

t

P T

t

e−λ

>

=

Поскольку

P(T ≤ t) + P(T > t)

=

1,

вероятность

того,

что

событие

произошло

в

интервале

[0, t],

можно

представить

в

сле-

дующем

виде:

(

)

(

)

.

1

1

t

P T

t

P T

t

e−λ

≤ = −

> = −

Частота

событий,

или

скорость

решения

задач,

выражает-

ся

как

производная

функции

распределения,

т.е.

( )

.

t

f t

e−λ

= λ

Допустим,

что

если

событие

произошло,

p

есть

вероят-

ность

решения

задачи

(вероятность

получения

правильного

ре-

шения).

Тогда

получим

следующие

соотношения:

(

)

( )

1

,

.

t

P T

t

e

p t

f t

p e

−λ

≤ = −

− λ

= λ

Положим,

что

вероятность

p

является

функцией

времени.

В

этом

случае

имеем

(

)

( )

0

,

t

p

d

P T

t

e

τ τ

∫

−λ

> =

(

)

( )

0

1

,

t

p

d

P T

t

e

τ τ

∫

−λ

≤ = −

( )

( )

( )

0

.

t

p

d

f t

p t e

τ τ

∫

−λ

= λ

Опыт

разработки

больших

программных

систем

показы-

вает,

что

зависимость

вероятности

правильного

решения

задачи

от

времени

можно

выразить

в

виде

( )

.

p t

t

= α

32

При

этом

получим

(

)

( )

2

2

1

.

at

P T

t

e

− λ

≤ = −

Вводя

обозначение

a = (λα)/2

и

умножая

последнюю

фор-

мулу

на

общую

стоимость

системы

K,

получим

приведенную

выше

формулу

для

суммарных

затрат

E(t)

к

моменту

времени

t.

Таким

образом,

для

ежегодных

затрат

имеем:

( )

( )

2

.

E t

at K

E t

′

=

−

⎡

⎤

⎣

⎦

Это

уравнение

содержит

две

переменные

величины

—

t

и

[K – E(t)].

По

мере

приближения

работ

к

завершению

(с

возрас-

танием

t)

скорость

решения

задач

f(t)

увеличивается.

Это

про-

исходит

вследствие

эффекта

«обучения»,

поскольку

по

мере

знакомства

исполнителей

с

задачами

работа

становится

более

эффективной.

Противоположную

тенденцию

имеет

выражение

[K – E(t)],

которое

определяет

незавершенную

работу.

С

приближением

работ

к

завершению

сложность

системы

увеличивается,

вслед-

ствие

чего

снижается

производительность

труда

исполнителей.

Кривая

Рэлея

имеет

два

параметра

—

K

и

a.

В

начале

работы

K

можно

оценить,

используя

величину

планируемых

затрат,

а

a

можно

определить,

исходя

из

состава

исполнителей.

Дату

за-

вершения

работ

определяют

по

достижению

максимума

расхо-

дов

(максимум

кривой

Рэлея).

3.1.3 Контрольные точки 

Контрольные

точки

указывают

на

моменты

завершения

работ;

они

позволяют

судить

о

состоянии

разработки

системы.

Контрольные

точки

планируются

руководителем

проекта

с

це-

лью

осуществления

контроля

за

разработкой.

Ситуацию

типа

«программа

завершена

на

90 %»

нельзя

отнести

к

контрольной

точке,

поскольку

руководитель

проекта

не

может

знать,

какой

объем

составляют

90 %

программы

до

тех

пор,

пока

программа

не

завершена.

Существует

большое

количество

«стандартных»

кон-

трольных

точек:

−

выпуск

функциональных

спецификаций;

33

−

завершение

проектирования

отдельных

модулей;

−

компилирование

модулей

без

ошибок;

−

успешное

проведение

тестирования

модуля

и

т.д.

В

техническом

задании,

кроме

срока

разработки

про-

грамм,

обязательно

должны

быть

указаны

контрольные

точки,

для

того

чтобы

раньше

выявить

возможные

недоработки.

Для

каждой

контрольной

точки

должны

быть

рассчитаны

общие

характеристики

системы,

такие,

как

стоимость,

сроки

завершения,

сложность.

При

работе

с

библиотекарем

должна

быть

разработана

соответствующая

форма

отчетных

документов

по

контрольным

точкам.

3.1.4 Средства разработки 

Компиляторы

и

отладочные

средства

известны

уже

доста-

точно

давно.

В

настоящее

время

создано

(и

создается)

ряд

но-

вых

программных

средств,

помогающих

разработке.

Среди

таких

средств

следует

особо

выделить

системы

управления

базами

данных

(СУБД),

которые

помогают

управ-

лять

организацией

разрабатываемого

программного

обеспече-

ния.

Весьма

удобны

для

контроля

таблицы

перекрестных

ссы-

лок,

атрибутивные

листинги,

таблицы

распределения

памяти.

Одной

из

первых

систем

управления

базой

данных

с

воз-

можностью

ведения

библиотеки

модулей

в

исходном

коде

явля-

ется

разработанная

в

Мичиганском

университете

система

ISDOS,

включающая

в

себя

язык

определения

задач

и

анализа-

тор

определения

задач

(PSL/PSA).

В

эту

систему

входит

язык

для

описания

интерфейса

при

проектировании

программ,

по-

зволяющий

осуществлять

автоматическую

проверку

взаимосвя-

зи

программ.

Схожа

с

указанной

система

RSL

(язык

определе-

ния

требований),

предназначенная

для

определения

требований

и

интерфейсов

посредством

системы

управления

данными.

Ни-

же

эти

системы

будут

рассмотрены

подробнее.

34

3.1.5 Надежность 

Одним

из

основных

параметров

надежности

разрабаты-

ваемой

программной

системы

является

концептуальная

цело-

стность,

т.е.

единообразие

стиля

и

простота

структуры.

Обыч-

но

она

достигается

за

счет

минимизации

числа

разработчиков.

Организация

бригады

главного

программиста

также

способст-

вует

концептуальной

целостности

системы,

т.к.

основная

работа

по

проектированию

в

этом

случае

выполняется

главным

про-

граммистом.

Среди

проектировщиков

этот

метод

называется

интел-

лектуальным

программированием.

Техническим

документом,

отражающим

этот

подход,

является

логическая

структура

про-

граммы

(структурная

схема).

Аттестация

системы

должна

осуществляться

на

всех

ста-

диях

разработки.

Для

каждого

уровня

проектирования,

кодиро-

вания

или

тестирования

необходимо

показать,

что

правильность

системы

сохраняется

при

добавлении

в

нее

любых

новых

час-

тей.

Это

должно

быть

отражено

в

структурной

схеме.

Для

контро-

ля

правильности

используется

так

называемый

контрольный

ана-

лиз.

Проведение

контрольного

анализа

периодически

планируется

для

всех

исполнителей.

Для

просмотра

выбирается

какая-то

часть

системы.

Каждому

участнику

анализа

выдается

необходимая

информация

(например,

ТЗ).

В

случае

необходимости

разработ-

чик

дает

пояснение.

Эксперт(ы)

должен

сделать

заключение

по

правильности

этапа

разработки.

Цель

контрольного

анализа

—

обнаружение

ошибок,

а

не

их

исправление.

Объясняя

проект

другим,

исполнитель

может

выявить

нечетко

сформулирован-

ную

спецификацию

либо

незаданное

условие.

Существенным

является

то

обстоятельство,

что

такой

анализ

не

ставит

целью

оценку

работы

исполнителя.

3.2 

Методы

проведения

разработки

программного

обеспечения

Эти

методы

наиболее

развиты,

т.к.

они

относятся

к

облас-

ти

профессиональной

деятельности

программистов:

кодирова-

ние,

тестирование,

отладка

и

др.

Средства

их

проведения

(ре-

35

шения)

известны

давно

и

динамически

развиваются.

Довольно

хорошо

формализованы

методы

определения

спецификаций.

Здесь

уже

имеется

эффективная

методология,

хотя

не

все

тех-

нические

проблемы

преодолены.

Верификация

и

испытания.

Верификация

и

испытания

за-

нимают

почти

половину

времени,

отведенного

на

создание

сис-

темы.

Для

уменьшения

затрат,

связанных

с

этими

процессами,

были

разработаны

средства

отладки,

представляющие

собой

специальные

программы

для

проверки

тех

или

иных

характери-

стик

системы.

Самыми

старыми

и

примитивными

являются

дамп

и

трассировка.

Дамп

—

это

распечатка

содержимого

памяти.

Однако

по-

иск

по

дампу

неэффективен,

т.к.

он

выдается

лишь

по

истече-

нии

некоторого

времени

после

возникновения

ошибки,

так

что

причину

последней

установить

достаточно

трудно.

Трассировка

—

это

анализ

значения

данных

переменных

после

каждого

выполнения

оператора.

В

общем

случае

трасси-

ровка

дает

очень

большой

объем

информации

при

минималь-

ных

пояснениях.

Анализаторы

графов

программы

способны

выявить

си-

туацию,

когда  либо

происходит

обращение

к

неинициирован-

ной

переменной,

либо

после

присвоения

значения

переменной

к

ней

не

обращаются.

Для

тестирования

программ

используются

генераторы

тестовых

данных.

Проверка

определенных

условий

в

заданных

точках

осуществляется

с

помощью

согласующих

компиляторов.

Для

относительно

простых

языков

разработаны

системы

авто-

матической

верификации.

В

качестве

примера

средства,

предна-

значенного

для

отработки

этапов

определения

спецификаций

и

проектирования,

можно

назвать

систему

PSL/PSA.

Применительно

к

процессу

разработки

программного

обеспечения

термин

«правильная»

программа

может

иметь

раз-

личную

интерпретацию.

Мы

будем

пользоваться

восемью

ос-

новными

положениями.

Правильная

программа:

1)

не

содержит

синтаксических

ошибок;

2)

не

имеет

ошибок,

допущенных

в

процессе

компилиро-

вания,

либо

сбоев

в

процессе

выполнения;