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

21

зователям

системы.

Опыт

применения

надежного

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

обеспечения

показывает,

что

большинство

потребителей

ведет

себя

осторожно

в

отношении

внесенных

изменений.

Поэтому

потребители

II

и

III,

не

встречаясь

с

задачами,

решаемыми

по-

требителем

I,

продолжают

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

первоначальный

вари-

ант

системы,

поддерживая

принцип

«если

система

работает,

не

вмешивайся».

Спустя

некоторое

время

потребители

I

и

II

обна-

ружили

другую

ошибку

в

модуле

A.

Разработчик

должен

опре-

делить,

являются

ли

обе

обнаруженные

ошибки

одной

и

той

же,

поскольку

использовались

различные

версии

модуля

A.

Ис-

правление

ошибки

ведет

к

корректировке

модуля

A

и

A

’

,

в

ре-

зультате

чего

в

эксплуатацию

вводятся

модули

A

’’ 

и

A

’’’

.

Те-

перь

функционируют

уже

три

версии

системы

(рис.

2.7).

Рис.

2.7

—

Система

после

исправления

двух

ошибок

Во

многих

случаях

большая

часть

усилий

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

за-

трачивается

на

повторное

обнаружение

ошибок,

выявленных

ра-

нее

в

других

версиях.

Чтобы

исключить

лавинообразное

нараста-

ние

версий,

системы

обычно

корректируются

в

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

промежутки

времени,

называемые

периодами

обновления.

Многочисленные

проблемы,

возникающие

на

этапе

со-

провождения

системы,

должны

решаться

с

привлечением

кон-

цепции

«базы

данных

системы».

Формирование

такой

концеп-

ции

начинается

на

этапе

определения

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

Эта

база

данных

должна

учитывать

требования

различных

заказчиков

и

включать

средства

индикации,

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

и

устранения

оши-

бок,

применяемые

для

корректировки

систем.

Контрольные

вопросы

1.

Этапы

разработки

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

обеспечения.

2.

Анализ

требований,

предъявляемых

к

системе.

3.

Жизненный

цикл

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

обеспечения.

A

’’ 

B

C

I

A

B

C

III

A

’’’ 

B

C

II

22

4.

Функциональные

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

Определение

специ-

фикаций.

5.

Проектирование.

Кодирование.

6.

Тестирование:

программное,

системное,

оценочное

и

сравнительное.

7.

Сбой

системы,

выброс,

ошибка.

Испытания.

Верифи-

кация

системы.

8.

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

и

надежность

программ.

9.

Эксплуатация

и

сопровождение.

Периоды

обновления.

23

3 

МЕТОДЫ

РАЗРАБОТКИ

ПРОГРАММНОГО

ОБЕСПЕЧЕНИЯ

КАК

НАУЧНАЯ

ДИСЦИПЛИНА

Из

приведенного

нами

обзора

этапов

разработки

про-

граммного

обеспечения

ясно,

что

каждый

этап

разработки

ока-

зывает

влияние

на

другие

более

ранние

этапы

(технология

«синтез

—

анализ»).

Так,

процесс

написания

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

оказывает

влияние

на

анализ

исходных

требований.

На

этапе

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

вскрываются

ошибки,

допущенные

в

процессе

написания

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

На

этапах

кодирования,

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

и

эксплуатации

выявляются

проблемы,

решить

которые

можно

лишь

на

этапе

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

В

связи

со

всем

вышесказан-

ным,

основные

цели

научной

дисциплины

«методы

разработки

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

обеспечения»

можно

сформулировать

следую-

щим

образом:

1)

разработка

методов

управления

сложными

системами;

2)

повышение

надежности

и

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

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

обеспечения;

3)

развитие

методов

более

точного

прогнозирования

за-

трат

на

создание

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

обеспечения.

Совокупность

этих

проблем

разделяется

на

методы

управления

разработкой

и

методы

ведения

разработки.

Методы

управления

разработкой

имеют

отношение

к

эф-

фективной

организации

работы

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

Методы

проведения

разработки

охватывают

технические

приемы

работы

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

способствующие

повышению

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

их

труда.

3.1 

Методы

управления

разработкой

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

проекта

контролирует

два

основных

ресур-

са

—

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

и

вычислительные

средства.

Следовательно,

его

основная

цель

—

оптимизировать

эти

ресурсы.

Успех

раз-

работки

в

сильной

степени

зависит

от

того,

насколько

руково-

дитель

следит

за

ходом

разработки.

Задержка

проекта

на

год

складывается

из

множества

однодневных

задержек.

Обычно

наибольшие

трудности

возникают

при

построе-

нии

интерфейса

между

модулями,

написанными

различными

24

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

Поскольку

количество

таких

интерфейсов

при

N

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

соответствует

N(N–1)/2

и

возрастает

пропор-

ционально

квадрату

числа

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

проблема

становится

довольно

сложной

при

разработке

проекта

группой

из

4-х

и

бо-

лее

человек. 

Пример.

Программист

может

написать

в

течение

года

программу,

включающую

5000

строк,

а

проектируемая

система

должна

содержать

50000

строк,

и

ее

разработка

должна

быть

завершена

в

течение

двух

лет.

Очевидно,

что

для

создания

та-

кой

системы

достаточно

пяти

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

Однако

эти

пять

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

должны

взаимодействовать

друг

с

другом,

а

это

требует

времени

и

в

определенной

степени

снижает

производи-

тельность

труда,

поскольку

взаимное

непонимание

приводит

к

дополнительным

затратам

на

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

(рис.

3.1).

Рис.

3.1

—

Для

группы

из

5

человек

имеем

10

взаимосвязей 

Пусть

каждый

из

путей

взаимодействия

обходится

про-

граммисту

в

250

строк/год.

В

этом

случае

каждый

программист

может

составить

лишь

4000

строк/год,

а

в

течение

двух

лет

бу-

дет

составлено

лишь

40000

строк.

Это

означает,

что

для

напи-

сания

программы

из

50000

строк

нужны

8

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

каж-

дый

из

которых

пишет

3250

строк/год

(рис.

3.2).

Для

управле-

ния

их

работой

нужен

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

25

Рис.

3.2

—

8

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

—

28

связей

Однако

простой

подсчет

строк

кода

не

является

досто-

верной

оценкой

эффективности

труда

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

Учет

всех

факторов,

влияющих

на

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

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

крайне

сложен.

Следовательно,

необходимо

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

мето-

ды

и

приемы

ограничения

«коммуникационного

взрыва»

и

уве-

личения

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

труда

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

3.1.1 Выполнение проекта 

Программное

обеспечение

обычно

разбивают

на

три

кате-

гории:

−

управляющие

программы

(например,

операционные

системы

—

ОС);

−

системные

программы

(например,

компиляторы);

−

прикладные

программы

(обработка

данных,

счетная

программа

и

др.).

Статистика

показывает,

что

программист

в

течение

года

способен

написать

и

отладить

управляющую

программу

длиной

примерно

600

строк,

системную

программу

длиной

2000

строк

и

прикладную

длиной

6000

строк.

Естественно,

что

к

этим

цифрам

нужно

относиться

очень

осторожно,

т.к.

неясно,

что

понимать

под

строкой

кода.

Вклю-

чаются

ли

сюда

комментарии

и

объявления

данных?

Или

это

генерируемая

транслятором

машинная

команда?

Как

учесть