Файл: Программа, комплекс программ, программное средство, программное обеспечение, программный продукт. Концепция программного изделия непосредственная производительная сила,.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 272
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Проверка допустимости промежуточных результатов. Проверки промежуточных
результатов позволяют снизить вероятность позднего проявления не только ошибок неверного
определения данных, но и некоторых ошибок кодирования и проектирования. Для того чтобы
такая проверка была возможной, необходимо, чтобы в программе использовались переменные, для
которых существуют ограничения любого происхождения, например, связанные с сущностью
моделируемых процессов.
Однако следует также иметь в виду, что любые дополнительные операции в программе
требуют использования дополнительных ресурсов (времени, памяти и т. п.) и могут также
содержать ошибки. Поэтому имеет смысл проверять не все промежуточные результаты, а только
те, проверка которых целесообразна, т. е. возможно позволит обнаружить ошибку, и не сложна.
Например:
• если каким-либо образом вычисляется индекс элемента массива, то следует проверить, что
этот индекс является допустимым;
• если строится цикл, количество повторений которого определяется значением переменной,
то целесообразно убедиться, что значение этой переменной не отрицательно;
Предотвращение накопления погрешностей. Чтобы снизить погрешности результатов
вычислений, необходимо соблюдать следующие рекомендации:
• избегать вычитания близких чисел (машинный ноль);
• избегать деления больших чисел на малые;
• сложение длинной последовательности чисел начинать с меньших по абсолютной величине;
• стремиться по возможности уменьшать количество операций;
• использовать методы с известными оценками погрешностей;
• не использовать условие равенства вещественных чисел;
• вычисления производить с двойной точностью, а результат выдавать с одинарной.
Обработка исключений. Поскольку полный контроль данных на входе и в процессе
вычислений, как правило, невозможен, следует предусматривать перехват обработки аварийных
ситуаций.
Сквозной структурный контроль
Сквозной структурный контроль представляет собой совокупность технологических операций контроля, позволяющих обеспечить как можно более раннее обнаружение ошибок в процессе разработки. Термин «сквозной» в названии отражает выполнение контроля на всех этапах разработки. Термин «структурный» означает наличие четких рекомендаций по выполнению контролирующих операций на каждом этапе.
Сквозной структурный контроль должен выполняться на специальных контрольных сессиях, в которых, помимо разработчиков, могут участвовал специально приглашенные эксперты. Время между сессиями определяет объем материала, который выносится на сессию: при частых сессиях материал рассматривают небольшими порциями, при редких - существенным фрагментами. Материалы для очередной сессии должны выдаваться участникам заранее, чтобы они могли их обдумать.
Одна из первых сессий должна быть организована на этапе определения спецификаций. На
этой сессии проверяют полноту и точность спецификаций, при этом целесообразно присутствие
заказчика или специалиста по предметной области, которые смогут определить, насколько
правильно полно определены спецификации программного обеспечения.
На этапе проектирования вручную по частям проверяют алгоритмы разрабатываемого
программного обеспечения на конкретных наборах данных и сверяют полученные результаты с
соответствующими спецификациями. Основная задача - убедиться в правильности понимания
спецификаций и проанализировать достоинства и недостатки концептуальных решений, закладываемых в проект.
На этапе реализации проверяют план (последовательность) реализации модулей, набор тестов, а также тексты отдельных модулей. Для всех этапов целесообразно иметь списки наиболее часто встречающихся ошибок, которые формируют по литературным источникам и исходя из опыта предыдущих разработок. Такие списки позволяют сконцентрировать усилия на конкретных моментах, а не проверять все подряд. При этом все найденные ошибки фиксируют в специальном документе, но не исправляют их. Помимо раннего обнаружения ошибок, сквозной структурный контроль обеспечивает своевременную подготовку качественной документации по проекту.
-
Разработка и анализ требований к программному обеспечению: определение целей проектируемого программного обеспечения, определение целей управления проектом; техническое задание и спецификации программного обеспечения; функциональные и нефункциональные требования.
Постановка задачи. В процессе постановки задачи четко формулируют назначение
программного обеспечения и определяют основные требования к нему. Каждое требование
представляет собой описание необходимого или желаемого свойства программного обеспечения.
Различают функциональные требования, определяющие функции, которые должно выполнять
разрабатываемое программное обеспечение, и эксплуатационные требования, определяющие
особенности его функционирования.
Требования к программному обеспечению, имеющему прототипы, обычно определяют по
аналогии, учитывая структуру и характеристики уже существующего программного обеспечения.
Для формулирования требований к программному обеспечению, не имеющему аналогов, иногда
необходимо провести специальные исследования, называемые предпроектными. В процессе таких
исследований определяют разрешимость задачи, возможно, разрабатывают методы ее решения
(если они новые) и устанавливают наиболее существенные характеристики разрабатываемого
программного обеспечения. Для выполнения предпроектных исследований, как правило,
заключают договор на выполнение научно-исследовательских работ. В любом случае этап
постановки задачи заканчивается разработкой технического задания, фиксирующего
принципиальные требования, и принятием основных проектных решений (см. гл. 3).
Анализ требований и определение спецификаций. Спецификациями называют точное
формализованное описание функций и ограничений разрабатываемого программного
обеспечения. Соответственно различают функциональные и эксплуатационные спецификации.
Совокупность спецификаций представляет собой общую логическую модель проектируемого программного обеспечения.
Для получения спецификаций выполняют анализ требований технического задания,
формулируют содержательную постановку задачи, выбирают математический аппарат
формализации, строят модель предметной области, определяют подзадачи и выбирают или
разрабатывают методы их решения. Часть спецификаций может быть определена в процессе
предпроектных исследований и, соответственно, зафиксирована в техническом задании.
-
Технологические требования: выбор архитектуры ПО, выбор типа пользовательского интерфейса, выбор подхода к разработке, выбор языка и среды программирования.
На начальных этапах процесса проектирования должны быть приняты принципиальные решения, во многом определяющие этот процесс, а также качество и трудоемкость разработки. К
таким решениям относят:
• выбор архитектуры программного обеспечения;
• выбор типа пользовательского интерфейса и технологии работы с документами;
• выбор подхода к разработке (структурного или объектного);
• выбор языка и среды программирования.
Выбор архитектуры программного обеспечения. Архитектурой программного обеспечения
называют совокупность базовых концепций (принципов) его построения. Архитектура ПО определяется сложностью решаемых задач, степенью универсальности разрабатываемого ПО и числом пользователей, одновременно работающих с одной его копией. Различают:
• однопользовательскую архитектуру, при которой программное обеспечение рассчитано на
одного пользователя, работающего за персональным компьютером;
• многопользовательскую архитектуру, которая рассчитана на работу в локальной или глобальной сети.
Кроме того, в рамках однопользовательской архитектуры различают:
• программы;
• пакеты программ;
• программные комплексы;
• программные системы.
Программой называют адресованный компьютеру набор инструкций, точно описывающий
последовательность действий, которые необходимо выполнить для решения конкретной задачи.
При структурном подходе программы представляют собой иерархию подпрограмм, вызывающих
друг друга в процессе решения поставленной задачи, при объектном подходе - совокупность
обменивающихся сообщениями объектов, для реализации которых разработаны специальные
классы. Программа в этом случае представляет собой отдельно компилируемую программную
единицу, которая может использовать стандартные библиотеки подпрограмм, но, как правило, не
организует свои. Это самый простой вид архитектуры, который обычно используется при решении
небольших задач.
Пакеты программ представляют собой совокупность программ, решающих задачи некоторой
прикладной области. Например, пакет графических программ, пакет математических программ.
Программы такого пакета связаны между собой только принадлежностью к определенной
прикладной области. Пакет программ реализуют как набор отдельных программ, каждая из
которых сама вводит необходимые данные и выводит результаты.
Программные комплексы представляют собой совокупность программ,
совместно
обеспечивающих решение небольшого класса сложных задач одной прикладной области. Для
решения такой задачи может потребоваться решить несколько подзадач, последовательно вызывая
программы комплекса. Вызов программ в программном комплексе осуществляется специальной
программой - диспетчером, который обеспечивает несложный интерфейс с пользователем и,
возможно, выдачу некоторой справочной информации. От пакета программ программный
комплекс отличается еще и тем, что несколько программ могут последовательно или циклически
вызываться для решения одной задачи, и, следовательно, желательно хранить исходные данные и
результаты вызовов в пределах одного пользовательского проекта. Программы в этом случае
могут реализовываться как отдельно, так и как совместно компилируемые программные единицы,
а исходные данные храниться в оперативной памяти или в файлах.
Программные системы представляют собой организованную совокупность программ
(подсистем), позволяющую решать широкий класс задач из некоторой прикладной области.
Выбор типа пользовательского интерфейса. Различают четыре типа пользовательских
интерфейсов:
• примитивные - реализуют единственный сценарий работы, например, ввод данных - обработка - вывод результатов;
• меню - реализуют множество сценариев работы, операции которых организованы в
иерархические структуры, например, «вставка»: «вставка файла», «вставка символа» и т. д.;
• со свободной навигацией - реализуют множество сценариев, операции которых не привязаны
к уровням иерархии, и предполагают определение множества возможных операций на конкретном
шаге работы; интерфейсы данной формы в основном используют Windows-приложения;
• прямого манипулирования - реализуют множество сценариев, представленных в операциях
над объектами, основные операции инициируются перемещением пиктограмм объектов мышью,
данная форма реализована в интерфейсе самой операционной системы Windows альтернативно интерфейсу со свободной навигацией.
Тип пользовательского интерфейса во многом определяет сложность и трудоемкость разработки, которые существенно возрастают в порядке перечисления типов.
Выбор подхода к разработке.