Правильность, универсальность, надежность ПО.
правильность — функционирование в соответствии с техническим заданием. Это требование является обязательным для всякого программного продукта, но поскольку никакое тестирование не дает гарантии 100%-ной правильности, речь может идти об определенной вероятности наличия ошибок. Вероятность сбоя системы управления космическими полетами должна быть близка к нулю;
Универсальность - также входит в группу обязательных требований. Ничего хорошего нет, если разработанная система выдает результат для некорректных данных или аварийно завершает свою работу на некоторых наборах данных. Но доказать универсальность программы, как и ее правильность, невозможно, поэтому говорят о степени универсальности программы.
Чем выше требования к правильности и универсальности ПО, тем выше и требования к его надежности.
Источниками помех могут являться все участники вычислительного процесса: технические и программные средства, люди.
Технические средства подвержены сбоям (из-за резких скачков напряжения питания или помех при передаче информации по сетям).
ПО может содержать ошибки. Люди могут ошибаться при вводе исходных данных.
надежность— обеспечение полной повторяемости результатов, т. е. обеспечение их правильности при наличии различного рода сбоев. Источниками помех могут являться технические и программные средства, а также люди, работающие с этими средствами. В настоящее время существует достаточное количество способов избежать потерь информации при сбоях. Например, прием «создания контрольных точек», при котором сохраняются промежуточные результаты, что позволяет после сбоя программы продолжить работу с данными, записанными в последней контрольной точке. Возможно также уменьшить количество ошибок, используя дублирование систем или ввод избыточной информации;
30.Проверяемость, точность, защищенность, совместимость, адаптируемостьПО.
Проверяемость – возможность проверки получаемых результатов;
Точность результатов – обеспечение заданной погрешности результатов;
Защищенность – обеспечение конфиденциальности информации;
Программная совместимость – возможность совместного функционирования с другим ПО;
Аппаратная совместимость – возможность совместного функционирования с некоторым оборудованием;
Адаптируемость – возможность быстрой модификации с целью приспособления к изменяющимся условиям функционирования;
31.Предпроектные исследования предметной области
Целью предпроектных исследований является преобразование общих нечетких знаний о предназначении будущего программного обеспечения в сравнительно точные требования к нему. Существуют два варианта неопределенности:
•неизвестны методы решения формулируемой задачи - такого типа не определенности обычно возникают при решении научно-техническихзадач;
•неизвестна структура автоматизируемых информационных процессов - обычно встречается при построении автоматизированных систем управления предприятиями.
В первом случае во время предпроектных исследований определяют возможность решения поставленной задачи и методы, позволяющие получить требуемый результат, что может потребовать соответствующих научных исследований как фундаментального, так и прикладного характера, разработки и исследования новых моделей объектов реального мира.
Во втором случае определяют:
•структуру и взаимосвязи автоматизируемых информационных процессов;
•распределение функций между человеком и системой, а также между аппаратурой и программным обеспечением;
•функции программного обеспечения; внешние условия его функционирования и особенности его интерфейсов, как с пользователями, так и при необходимости - с аппаратной частью;
•требования к программным и информационным компонентам, необходимые аппаратные ресурсы, требования к базам данных и физические характеристики программных компонент.
Результаты предпроектных исследований предметной области используют в процессе разработки технического задания.
32.Техническое задание, основные разделы. Стандарт ГОСТ 19.201-78.
ТЗ - документ, в котором сформулированы основные цели разработки, требования к программному продукту, сроки и этапы разработки и регламентирован процесс приемно-сдаточных испытаний.
ТЗ должно содержать разделы: введение; основания для разработки; назначение разработки; требования к программе или программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки.
| Обозначение: | ГОСТ 19.201-78 |
| Название: | Единая система программной документации. Техническое задание. Требования к содержанию и оформлению |
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
33. Выбор языка и среды программирования.
Выбор языка программирования. В большинстве случаев проблемы выбора ЯП реально не существует. Язык может быть определен:
• - организацией, ведущей разработку;
• - программистом, который по возможности будет использовать знакомый язык;
• - устоявшимся мнением и т.п.
• ЯП можно разделить на группы:
• универсальные языки высокого уровня;
• специализированные языки разработчика программного обеспечения;
• специализированные языки пользователя;
• языки низкого уровня.
Выбор среды программирования.Среда программирования - программный комплекс, который специализированный текстовый редактор, встроенные компилятор, компоновщик, отладчик, справочную систему и другие программы, использование которых упрощает процесс написания и отладки программ.
• Распространены среды визуального программирования (Delphi, C++ Builder, VisualC++, VisualStudio), в которых программист получает возможность визуального подключения к программе некоторых кодов из специальных библиотек компонентов, что стало возможным с развитием ООП.
• Выбор между этими средами должен определяться характером проекта.
34. Выбор или формирование стандартов разработки.
Современная технология проектирования должна обеспечивать соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).
Реальное применение любой технологии проектирования ПО требует формирования или выбора ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта.
Стандарты:
• стандарт проектирования;набор необходимых моделей;правила именования объектов и соглашения по терминологии;требования к конфигурации рабочих мест разработчиков;механизм обеспечения совместной работы над проектом.
• стандарт оформления проектной документации;комплектность, состав и структуру документации на каждой стадии;требования к оформлению документации;правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков на каждой стадии;требования к настройке CASE.
• стандарт интерфейса пользователя.-правила оформления экранов (шрифты и цветовую палитру);правила пользования клавиатурой и мышью;правила оформления текстов помощи;перечень стандартных сообщений;правила обработки реакции пользователя.
35. Структурный подход. Средства описания структурных алгоритмов.
Сущность структурного подхода - декомпозиция программы или программной системы по функциональному принципу.
Все методы декомпозиции рассчитаны на анализ и проектирование структур данных и обрабатывающих их программ.
Первичным считают проектирование обрабатывающих компонентов, проектирование структур данных выполняют параллельно.
Альтернативный подход - первичным считают проектирование данных, а обрабатывающие программы получают, анализируя полученные структуры данных.
В любом случае проектирование ПО начинают с определения его структуры.
Линейная структура - для получения результата необходимо выполнить некоторые операции в определенной последовательности.
Разветвленная структура- конкретная последовательность операций зависит от значений одной или нескольких переменных.
Циклическая структура - для получения результата некоторые действия необходимо выполнить несколько раз.
Для изображения схем алгоритмов таких программ разработан ГОСТ 19.701-90, согласно которому каждой группе действий ставится в соответствие специальный блок
Для описания алгоритмов можно использовать псевдокоды – формализованное текстовое описание алгоритма (текстовая нотация)., Flow-формы- представляют собой графическую нотацию описания структурных алгоритмов, которая иллюстрирует вложенность структур. и диаграммы Насси-Шнейдермана- являются развитием Flow-форм. Основное их отличие от Flow-форм заключается в том, что область обозначения условий и вариантов ветвления изображают в виде треугольников.
36. Основные и вспомогательные конструкции структурного программирования.
Базовые управляющие конструкции:
• следование - последовательное выполнение действий
• ветвление- выбор одного из двух вариантов действий
• цикл-пока- повторение действий, пока не будет нарушено условие, выполнение которого проверяется в начале цикла
Еще три конструкции, которые можно составить из базовых:
• выбор- выбор одного варианта из нескольких в зависимости от значения некоторой величины;
• цикл-до- повторение некоторых действий до выполнения заданного условия, проверка которого осуществляется после выполнения действий в цикле;
• цикл с заданным числом повторений(счетный цикл) - повторение некоторых действий указанное количество раз.