ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10754
Скачиваний: 8
41
При
использовании
SADT
каждый
разработчик
наделен
строго
определенными
полномочиями.
Авторы.
Разработчики,
занятые
изучением
требований
и
ограничений
системы
и
их
описаний
с
помощью
системы
SADT.
Комментаторы.
Обычно
это
проектировщики,
анализи-
рующие
работу
своих
коллег
(авторов)
и
подготавливающие
замечания
по
ней.
Читатели.
Лица,
занятые
анализом
проектов,
разрабаты-
ваемых
другими
специалистами,
но
не
обязанные
их
комменти-
ровать.
Технический
комитет.
Группа
опытных
технических
спе-
циалистов,
анализирующих
проект
на
высших
уровнях
его
опи-
сания.
Библиотекарь
проекта.
Лицо,
отвечающее
за
ведение
фай-
лов
проекта.
Руководитель
проекта.
Лицо,
несущее
основную
ответст-
венность
за
техническую
разработку
проекта.
Главный
аналитик.
Основной
консультант
по
использова-
нию
SADT.
Он
хорошо
понимает
особенности
использования
системы
SADT
и
выдает
рекомендации
по
ее
применению.
Инструктор.
Лицо,
обучающее
исследователей
пользова-
нию
SADT.
К
основным
достоинствам
SADT
можно
отнести следующие:
1)
система
способствует
организации
коллективной
рабо-
ты,
а
также
установлению
соглашений
относительно
спецификаций
на
ранних
этапах
проектирования;
2)
письменные
отчеты
технических
комитетов
позволяют
проводить
непрерывный
контрольный
анализ
системы,
что
немаловажно
при
осуществлении
испытаний
сис-
темы;
3)
эффективным
средством
получения
специальной
ин-
формации
являются
доклады
экспертов;
4)
система
позволяет
на
ранних
этапах
принять
основные
решения
высокого
уровня,
что
создает
прочный
фун-
дамент
для
вырабатывания
последующих
решений
бо-
лее
низкого
уровня;
42
5)
использование
SADT
дает
возможность
осмыслить
разрабатываемую
систему
лицам,
не
являющимся
спе-
циалистами
по
программному
обеспечению;
6)
предусмотрены
легкодоступные
средства
контроля
хо-
да
проектирования.
Основным
и
главным
недостатком
этой
системы
является
тот
факт,
что
она
не
автоматизирована.
3.3.3 Система SREM
Система
SREM
используется
для
автоматизации
этапа
анализа
требований,
предъявляемых
к
программному
обеспе-
чению.
Она
включает
в
себя
язык
определения
требований
(RSL),
посредством
которого
устанавливаются
связи
между
объектами.
Проверка
последовательности
предложений
на
язы-
ке
RSL
осуществляется
с
помощью
процессора
REVS.
При
ис-
пользовании
системы
SREM
выполняются
следующие
шаги:
•
Трансляция.
Разрабатывается
система
требований,
включающая
описатели
данных
и
этапы
их
обработки.
•
Декомпозиция.
Разрабатываются
подробные
проекты.
•
Распределение.
С
помощью
процессора
REVS
модели-
руются
отдельные
аспекты
проектных
решений
с
уче-
том
принятых
допущений.
В
результате
имеем
множе-
ство
требований
к
построению
системы,
генерируемых
REVS.
•
Анализ.
Пользователь
проверяет
все
требования,
предъявляемые
к
будущей
системе.
3.3.4 Методика Джексона
Разработанная
М.
Джексоном
методика
включает
нисхо-
дящее
проектирование,
структурное
программирование
и
структурный
контрольный
анализ.
В
соответствии
с
этой
мето-
дикой
строятся
иерархически
структурированные
программы,
имеющие
четыре
компонента,
подобные
структурам
управления
в
структурном
программировании.
Элемент.
Функция,
которая
не
может
быть
разбита
на
бо-
лее
простые
функции.
43
Последовательность.
Ряд
функций,
реализуемых
последо-
вательно
и
однократно.
Выборка.
Одна
из
возможных
последовательностей.
Итерация.
Функция,
выполняемая
заданное
число
раз,
включая
нулевое.
Базовая
идея
метода
состоит
в
том,
что
структура
систе-
мы
должна
быть
идентична
структуре
используемых
данных.
Следовательно,
древовидная
схема
организации
системы
долж-
на
отражать
структуру
данных:
в
противном
случае
проект
бу-
дет
неправильным.
3.4
Выводы
Проведенный
обзор
методов
проектирования
показал,
что
всем
этим
методам
присущи
общие
черты.
Хотя
такие
методы
и
способствуют
получению
рациональной
структуры
системы,
тем
не
менее
они
не
исключают
необходимость
в
творческом
процессе
вырабатывания
основополагающих
на
этапах
анализа
требований,
определения
спецификаций
и
проектирования.
Бла-
годаря
использованию
этих
методов
становится
возможным
уделять
больше
времени
профессиональной
стороне
разработки
программного
обеспечения.
Существует
ряд
стратегий
объединения
различных
мето-
дов
в
единую
методологию.
Наиболее
эффективную
стратегию
создал
Боэм,
который
сформулировал
семь
принципов
разра-
ботки
программного
обеспечения:
1)
управление
разработкой
на
основе
последовательной
реализации
отдельных
этапов
жизненного
цикла
про-
граммного
обеспечения.
Применение
этого
принципа
позволяет
на
каждом
этапе
принимать
обоснованные
ре-
шения
с
учетом
результатов,
достигнутых
на
предыду-
щих
этапах,
и
способствует
использованию
контрольных
точек
для
оценки
состояния
разработки
проекта;
2)
выполнение
испытаний.
На
каждом
шаге
совершенст-
вования
модуля
осуществляется
его
аттестация;
3)
осуществление
строгого
контроля
над
ходом
разра-
ботки.
Вся
выходная
документация
—
проекты
про-
грамм,
исходные
программы,
инструкции
пользовате-
44
лю
и
т.д.
—
должна
быть
формально
утверждена.
Вне-
сение
любых
изменений
в
документацию
и
библиотеки
программ
должно
строго
контролироваться
и
осущест-
вляться
лишь
с
разрешения
соответствующих
должно-
стных
лиц;
4)
использование
всего
диапазона
средств
структурного
программирования.
По
возможности
желательно
при-
менять
языки,
позволяющие
реализовать
удобные
структуры
управления
и
данных.
Для
описания
про-
цессов
желательно
использовать
технику
пошагового
совершенствования;
5)
строгий
учет.
Для
учета
достигнутого
прогресса
в
разработке
системы
необходимо
использовать
кон-
трольные
точки,
а
для
проверки
работы
каждого
ис-
полнителя
—
системный
журнал;
6)
использование
немногочисленного
штата,
укомплек-
тованного
квалифицированными
работниками.
Хоро-
шие
результаты
работы
дает
использование
принципа
организации
бригады
главного
программиста;
7)
высокий
уровень.
Необходимо
использовать
имеющие-
ся
достижения
в
области
технологии
и
разработки
про-
граммного
обеспечения,
не
забывая
при
этом
о
надеж-
ности
и
возможности
модификации
программ.
Средства
управления
и
контроля
над
разработкой
про-
граммного
обеспечения
еще
требуют
совершенствования,
одна-
ко
сам
процесс
управления
при
этом
приближается
к
уровню,
свойственному
другим
техническим
областям.
Контрольные
вопросы
1.
Методы
разработки
программного
обеспечения
как
научная
дисциплина.
2.
Организация
интерфейса
между
модулями,
написан-
ными
разными
программистами.
3.
Выполнение
проекта.
Бригада
главного
программиста.
4.
Методика
оценки
затрат.
Методика
инженерно-техни
-
ческой
оценки
затрат.
45
5.
Методика
экспертных
оценок.
Метод
алгоритмическо-
го
анализа.
Пошаговый
анализ.
Закон
Паркинсона.
6.
Затраты
на
завершение
разработки.
7.
Оценка
длительности
разработки
на
основе
распреде-
ления
Рэлея.
8.
Контрольные
точки.
Средства
обработки.
Надежность.
Концептуальная
целостность.
9.
Верификация
и
испытания.
Дамп.
Трассировка.
Анализ
графов
программ.
10.
«Уровни
правильности»
программ.
11.
Методы
программирования.
Эффективность
программ.
12.
Определение
спецификаций.
Язык
определения
задач
и
анализатор
определения
задач
(PSL/PSA).
13.
Система
структурного
проектирования
SADT.
14.
Структурное
проектирование.
Методика
Джексона.
15.
Стратегия
объединения
различных
методов
проектиро-
вания.