- •1.1 Программа как формализованное описание процесса обработки данных. Программное средство
- •1.2 Неконструктивность понятия правильной программы
- •1.3. Надежность программного средства
- •1.4 Технология программирования как технология разработки надежных программных средств
- •ГЛАВА 2. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ
- •2.1 Интеллектуальные возможности человека
- •2.2 Неправильный перевод как причина ошибок в программных средствах
- •2.3 Модель перевода
- •2.4 Основные пути борьбы с ошибками
- •ГЛАВА 3. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
- •3.1. Специфика разработки программных средств
- •3.2 Жизненный цикл программного средства
- •3.3 Понятие качества программного средства
- •3.5 Методы борьбы со сложностью
- •3.6 Обеспечение точности перевода
- •3.7 Преодоление барьера между пользователем и разработчиком
- •3.8 Контроль принимаемых решений
- •ГЛАВА 4. ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА
- •4.1 Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства
- •4.2 Определение требований к программному средству
- •4.3 Спецификация качества программного средства
- •4.4 Функциональная спецификация программного средства
- •4.5 Методы контроля внешнего описания программного средства
- •ГЛАВА 5. АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА
- •5.1 Понятие архитектуры программного средства
- •5.2 Основные классы архитектур программных средств
- •5.3 Архитектурные функции
- •5.4 Контроль архитектуры программных средств
- •ГЛАВА 6. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
- •6.1 Цель модульного программирования
- •6.3 Методы разработки структуры программы
- •6.4 Контроль структуры программы
- •ГЛАВА 7. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ
- •7.1 Порядок разработки программного модуля
- •7.2 Структурное программирование
- •7.3 Пошаговая детализация и понятие о псевдокоде
- •7.4 Контроль программного модуля
- •ГЛАВА 8. ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
- •8.1 Основные понятия
- •8.2 Принципы и виды отладки программного средства
- •8.3 Заповеди отладки программного средства
- •8.4 Автономная отладка программного средства
- •8.5 Комплексная отладка программного средства
- •ГЛАВА 9. ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОСТИ И НАДЕЖНОСТИ ПРОГРАММНОГО СРЕДСТВА
- •9.1 Функциональность и надежность как обязательные критерии качества программного средства
- •9.2 Обеспечение завершенности программного средства
- •9.3 Обеспечение точности программного средства
- •9.4 Обеспечение автономности программного средства
- •9.5 Обеспечение устойчивости программного средства
- •9.6 Обеспечение защищенности программных средств
- •ГЛАВА 10. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА
- •10.1 Общая характеристика процесса обеспечения качества программного средства
- •10.2 Обеспечение легкости применения программного средства
- •Графический пользовательский интерфейс обобщает такие виды пользовательского интерфейса, как интерфейс типа меню и интерфейс прямого манипулирования.
- •10.3 Обеспечение эффективности программного средства
- •10.4 Обеспечение сопровождаемости программного средства
- •10.5 Обеспечение мобильности
- •ГЛАВА 11. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
- •11.1 Документация, создаваемая и используемая в процессе разработки программных средств
- •11.2 Пользовательская документация программных средств
- •11.3 Документация по сопровождению программных средств
- •ГЛАВА 12. УПРАВЛЕНИЕ РАЗРАБОТКОЙ И АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА
- •12.1 Назначение и процессы управления разработкой программного средства
- •12.2 Структура управления разработкой программных средств
- •12.3 Планирование и составление расписаний по разработке ПС
- •12.4 Аттестации программного средства
- •Список использованной литературы
•Составьте план (включая цели и методы решения);
•Выполните план (проверяя правильность каждого шага);
•Проанализируйте полученное решение.
Подробно обсуждать этот вопрос мы здесь не будем.
3.7 Преодоление барьера между пользователем и разработчиком
Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого разработчикам необходимо правильно понять, во-первых, чего хочет пользователь, и, вовторых, его уровень подготовки и окружающую его обстановку. Ясное описание соответствующей сферы деятельности пользователя или интересующей его проблемной области во многом облегчает достижение разработчиками этой цели. При разработке ПС следует привлекать пользователя для участия в процессах принятия решений, а также тщательно освоить особенности его
работы (лучше всего − побывать в его "шкуре").
3.8 Контроль принимаемых решений
Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после ее возникновения, что, во-первых, существенно снижает стоимость ее исправления и, во-вторых, повышает вероятность правильного ее устранения.
С учетом специфики разработки ПС необходимо применять везде, где это возможно,
•смежный контроль,
•сочетание как статических, так и динамических методов контроля.
Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон:
во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут ис-
30