Технологией программирования называют совокупность методов и средств, используемых в процессе разработки программного обеспечения. Как любая другая технология она представляет собой набор технологических инструкций, включающих:
— указание последовательности выполнения технологических операций;
— перечисление условий, при которых выполняется та или иная операция;
— описания самих операций, где для каждой операции определены исходные данные, результаты, а также инструкции, нормативы, стандарты, критерии и методы оценки и т.п.
Кроме того, технология программирования определяет способ описания модели, используемой на конкретном этапе разработки проектируемой системы.
Различают технологии, используемые на конкретных этапах разработки или для решения отдельных задач этих этапов, и технологии, охватывающие несколько этапов или весь процесс разработки. В основе первых, как правило, лежит ограниченно применимый метод, позволяющий решить конкретную задачу. В основе вторых обычно лежит методология, определяющая совокупность методов, используемых на разных этапах разработки.
Python как сделать красивую программу под ПК за 10 минут?
Первый этап – «стихийное» программирование (от появления первых вычислительных машин до середины 60-х годов XX в). Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных (рис. 1). Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение данных при программировании.
Появление ассемблеров позволило вместо двоичных или 16-ричных кодов использовать символические имена данных и мнемоники кодов операций. В результате программы стали более «читаемыми».
Создание языков программирования высокого уровня, таких, как FORTRAN и ALGOL, существенно упростило программирование вычислений, снизив уровень детализации операций, что позволило увеличить сложность программ.
Появление в языках средств, которые могли оперировать подпрограммами (отдельными блоками программного кода), позволило создать огромные библиотеки расчетных и служебных подпрограмм, которые можно было вызвать из разрабатываемой программы. Типичная программа того времени состояла из основной программы, области глобальных данных и набора подпрограмм (в основном библиотечных), выполняющих обработку всех данных или их части
Слабым местом такой архитектуры было то, что при увеличении количества подпрограмм возрастала вероятность искажения части глобальных данных какой-либо подпрограммой. Например, подпрограмма поиска корней уравнения на заданном интервале по методу деления отрезка пополам меняет величину интервала. Если при выходе из подпрограммы не предусмотреть восстановления первоначального интервала, то в глобальной области окажется неверное значение интервала. Чтобы сократить количество таких ошибок, было предложено в подпрограммах размещать локальные данные (рис. 3).
Архитектура программы использующей подпрограммы с локальными данными
Появление средств поддержки подпрограмм позволило осуществлять разработку программного обеспечения нескольким программистам параллельно.
В начале 60-х разразился «кризис программирования». Фирмы, взявшиеся за разработку сложного программного обеспечения, например, операционных систем, срывали все сроки завершения проектов. Проект устаревал прежде, чем был готов к внедрению, увеличивалась его стоимость, и в результате многие проекты так и не были завершены.
Это объяснялось прежде всего тем, что вначале проектировали и реализовывали сравнительно простые подпрограммы, из которых затем пытались построить сложную программу, т.е. использовался подход «снизу-вверх» (восходящее проектирование). Интерфейсы подпрограмм получались сложными, и при сборке программного продукта выявлялось большое количество ошибок согласования, исправление которых, как правило, требовало серьезного изменения уже разработанных подпрограмм. При этом в программу часто вносились новые ошибки, которые также необходимо было исправлять. В конечном итоге процесс тестирования и отладки программ занимал более 80% времени разработки, если вообще когда-нибудь заканчивался.
Анализ причин возникновения большинства ошибок позволил сформулировать новый подход к программированию, который был назван «структурным».
Второй этап – структурный подход к программированию (60-70-е годы XX в.). В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40-50 операторов) подпрограмм. При таком подходе задача представляется в виде иерархии подзадач простейшей структуры. Проектирование осуществляется «сверху вниз» и подразумевает реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм (нисходящее проектирование). Одновременно вводятся:
— ограничения на конструкции алгоритмов;
— формальные модели их описания;
— метод пошаговой детализации проектирования алгоритмов.
Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Как правило, они включали основные «структурные» операторы передачи управления, поддерживали вложение подпрограмм, локализацию и ограничение области «видимости» данных. Среди наиболее известных языков этой группы стоит назвать PL/1, ALGOL-68, Pascal, С.
Дальнейший рост сложности и размеров разрабатываемого программного обеспечения потребовал развития структурирования данных, в языках появляется возможность определения пользовательских типов данных. Стремление разграничить доступ к глобальным данным программы, чтобы уменьшить количество ошибок, возникающих при работе с ними привело к возникновению технологии модульного программирования.
Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули (библиотеки подпрограмм), например, модуль графических ресурсов, модуль подпрограмм вывода на принтер и т.п. (рис. 4).
Архитектура программы, состоящей из модулей
Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации самого модуля (телам подпрограмм и некоторым «внутренним» переменным) запрещен. Эту технологию поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.
При таком подходе разработка программного обеспечения несколькими программистами значительно упрощается. Каждый разрабатывает свои модули независимо, обеспечивая взаимодействие через специально оговоренные межмодульные интерфейсы. Созданные модули в дальнейшем без изменений можно использовать в других разработках, что также повысило производительность труда программистов.
Узким местом модульного программирования является то, что ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы (из-за раздельной компиляции модулей обнаружить эти ошибки раньше невозможно). При увеличении размера программы обычно возрастает сложность межмодульных интерфейсов, и с некоторого момента предусмотреть взаимовлияние отдельных частей программы становится практически невозможно. Для разработки программного обеспечения большого объема было предложено использовать объектный подход.
Третий этап – объектный подход к программированию (с середины
80-х до конца 90-х годов ХХ века). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений рис. 5.
Объектная структура программы впервые была использована в языке имитационного моделирования сложных систем Simula (60-е годы XX в.), в специализированном языке моделирования Smalltalk (70-е годы XX в.), а затем в новых версиях универсальных языков программирования, таких, как Pascal, C++, Modula, Java.
Основным достоинством объектно-ориентированного программирования по сравнению с модульным является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Это приводит к более полной локализации данных и интегрированию их с подпрограммами обработки, что позволяет вести практически независимую разработку отдельных частей (объектов) программы. Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения. Эти механизмы позволяют конструировать сложные объекты из сравнительно простых. В результате существенно увеличивается показатель повторного использования кодов и появляется возможность создания библиотек классов для различных применений.
Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т.д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например,
интерфейсы будущего продукта с применением визуальных средств добавления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в которую уже внесены соответствующие коды.
Архитектура программы при объектно-ориентированном программировании
Использование объектного подхода имеет много преимуществ, однако его конкретная реализация в объектно-ориентированных языках программирования, таких, как Pascal и C++, имеет существенные недостатки:
— необходимость разработки программного обеспечения с использованием средств и возможностей одного языка программирования высокого уровня и одного компилятора;
— наличие исходных кодов используемых библиотек классов, так как изменение реализации одного из программных объектов, как минимум, связано с перекомпиляцией соответствующего модуля и перекомпоновкой всего программного обеспечения, использующего данный объект.
Таким образом, при использовании этих языков программирования сохраняется зависимость модулей программного обеспечения от адресов экспортируемых полей и методов, а также структур и форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга. Связи модулей нельзя разорвать, но можно попробовать стандартизировать их взаимодействие, на чем и основан компонентный подход к программированию.
Четвертый этап – компонентный подход и CASE-технологии (с середины 90-х годов XX до нашего времени). Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию.
Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model – компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации.
Технология СОМ фирмы Microsoft является развитием технологии OLE (Object Linking and Embedding – связывание и внедрение объектов), которая используется в Windows. Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы. Т.е. позволяет одной части программного обеспечения использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах (рис. 6). Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM – распределенная СОM).
Взаимодействие программных компонентов различных типов
По технологии СОМ приложение предоставляет свои службы, используя специальные объекты – объекты-СОМ, которые являются экземплярами классов-СОМ. Объект-СОМ включает поля и методы так же, как и обычный объект, но может реализовывать несколько интерфейсов, обеспечивающих доступ к его полям и функциям.
Объект всегда функционирует в составе сервера – динамической библиотеки или исполняемого файла, которые обеспечивают функционирование объекта. Различают три типа серверов:
— внутренний сервер – реализуется динамическими библиотеками, которые подключаются к приложению-клиенту и работают в одном с ними адресном пространстве. Это наиболее эффективный сервер, он не требует специальных средств;
— локальный сервер – создается отдельным процессом (модулем, ехе), который работает на одном компьютере с клиентом;
— удаленный сервер – создается процессом, который работает на другом компьютере.
Например, Microsoft Word является локальным сервером. Он включает множество объектов, которые могут использоваться другими приложениями.
Для обращения к службам клиент должен получить указатель на соответствующий интерфейс. Перед первым обращением к объекту клиент посылает запрос к библиотеке СОМ, хранящей информацию обо всех, зарегистрированных в системе классах СОМ-объектов, и передает ей имя класса, идентификатор интерфейса и тип сервера. Библиотека запускает необходимый сервер, создает требуемые объекты и возвращает указатели на объекты и интерфейсы. Получив указатели, клиент может вызывать необходимые функции объекта.
Взаимодействие клиента и сервера обеспечивается базовыми механизмами СОМ или DCOM, поэтому клиенту безразлично местонахождение объекта. При использовании локальных и удаленных серверов в адресном пространстве клиента создается proxy-объект – заместитель объекта-СОМ, а в адресном пространстве сервера СОМ – заглушка, соответствующая клиенту. Получив задание от клиента, заместитель упаковывает его параметры и, используя службы операционной системы, передает вызов заглушке. Заглушка распаковывает задание и передает его объекту-СОМ. Результат возвращается клиенту в обратном порядке.
На базе технологии СОМ и ее распределенной версии DCOM были разработаны компонентные технологии, решающие различные задачи разработки программного обеспечения.
OLE-automation или просто Automation (автоматизация) – технология создания программируемых приложений, обеспечивающая программируемый доступ к внутренним службам этих приложений. Вводит понятие диспинтерфейса (dispinterface) – специального интерфейса, облегчающего вызов функций объекта. Эту технологию поддерживает, например, Microsoft Excel, предоставляя другим приложениям свои службы.
ActiveX – технология, построенная на базе OLE-automation, предназначена для создания программного обеспечения как сосредоточенного на одном компьютере, так и распределенного в сети. Предполагает использование визуального программирования для создания компонентов – элементов управления ActiveX. Полученные таким образом элементы управления можно устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код
зависит от используемой операционной системы. Это позволяет применять элементы управления ActiveX в клиентских частях приложений Интернет.
Основными преимуществами технологии ActiveX, обеспечивающими ей широкое распространение, являются:
— быстрое написание программного кода – поскольку все действия, связанные с организацией взаимодействия сервера и клиента берет на программное обеспечение СОМ, программирование сетевых приложений становится похожим на программирование для отдельного компьютера;
— открытость и мобильность;
— возможность написания приложений с использованием знакомых средств разработки;
— большое количество уже существующих бесплатных программных элементов ActiveX (к тому же, практически любой программный компонент OLE совместим с технологиями ActiveX и может применяться без модификаций в сетевых приложениях);
— стандартность – технология ActiveX основана на широко используемых стандартах Internet (TCP/IP, HTML, Java), с одной стороны, и стандартах, введенных в свое время Microsoft и необходимых для сохранения совместимости (COM, OLE).
MTS (Microsoft Transaction Server – сервер управления транзакциями) технология, обеспечивающая безопасность и стабильную работу распределенных приложений при больших объемах передаваемых данных.
MIDAS (Multitier Distributed Application Server – сервер многозвенных распределенных приложений) – технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети.
Все указанные технологии реализуют компонентный подход, заложенный в СОМ. Так, с точки зрения СОМ, элемент управления ActiveX – внутренний сервер, поддерживающий технологию OLE-automation. Для программиста же элемент ActiveX – «черный ящик», обладающий свойствами, методами и событиями, который можно использовать как строительный блок при создании приложений.
Технология CORBA, разработанная группой компаний ОМС (Object Management Group – группа внедрения объектной технологии программирования), реализует подход, аналогичный СОМ, на базе объектов и интерфейсов CORBA. Программное ядро CORBA реализовано для всех основных аппаратных и программных платформ и потому эту технологию можно использовать для создания распределенного программного обеспечения в гетерогенной (разнородной) вычислительной среде. Организация взаимодействия между объектами клиента и сервера в CORBA осуществляется с помощью специального посредника, названного VisiBroker, и другого специализированного программного обеспечения.
Отличительной особенностью современного этапа развития технологии программирования, кроме изменения подхода, является создание и внедрение автоматизированных технологий
разработки и сопровождения программного обеспечения, которые были названы CASE-технологиями (Computer-Aided Software/System Engineering – разработка программного обеспечения /программных систем с использованием компьютерной поддержки). Без средств автоматизации разработка достаточно сложного программного обеспечения на настоящий момент становится трудно осуществимой: память человека уже не в состоянии фиксировать все детали, которые необходимо учитывать при разработке программного обеспечения. На сегодня существуют CASE-технологии, поддерживающие как структурный, так и объектный (в том числе и компонентный) подходы к программированию.
Появление нового подхода не означает, что отныне все программное обеспечение будет создаваться из программных компонентов, но анализ существующих проблем разработки сложного программного обеспечения показывает, что он будет применяться достаточно широко.
Источник: megalektsii.ru
Технология разработки программного обеспечения
Технология разработки программного обеспечения — это набор методик формирования программного приложения.
Работа по формированию программных приложений состоит из нескольких этапов, которые в любом случае необходимо пройти при проектировании любого значительного по размерам программного обеспечения. Главным понятием в технологии проектирования программного обеспечения считается понятие жизненного цикла программы.
Жизненный цикл программы
Основными этапами жизненного цикла программы являются следующие события:
- Приобретение программного продукта. Этот процесс является действиями заказчика проектирования программного продукта, и состоит в свою очередь из:
- Выработка требований и граничных условий. В качестве ограничений могут выступать условия выбора архитектуры программы, её быстродействие и так далее.
- Подписание договора о проектировании программного продукта.
- Выполнение анализа и проверки работы исполнителя. В завершение этого действия заказчик принимает готовую программу.
- Поставка программного продукта. Состоит из мероприятий, осуществляемых исполнителем по поставке программного продукта.
- Эксплуатация программного продукта. После окончания установки программы, начинается её эксплуатация фирмой, которая её заказывала, и её сотрудниками.
- Сопровождение программного продукта. Исполнитель, как правило, выполняет поддержку заказчика программы и, если возникают какие-либо проблемы с использованием программы, а тем более ошибки, то исполнитель их устраняет.
Сдай на права пока
учишься в ВУЗе
Вся теория в удобном приложении. Выбери инструктора и начни заниматься!
Замечание 1
Эксплуатация и сопровождение программы являются параллельными процессами.
Вспомогательные процессы
Технология проектирования программного продукта в границах его жизненного цикла имеет в своём составе несколько вспомогательных процессов. Это следующие процессы:
- Документирование. При проектировании программы и в дальнейшем исполнитель формирует пакет документов и инструкции для заказчика к формируемому программному обеспечению. Эта документация должна помогать проектировщикам ориентироваться в структурной организации и кодах формируемой программы, поскольку с течением времени можно забыть некоторые детали, тем более в глобальных разработках. Пользователям документы оказывают помощь в освоении взаимодействия с программой.
- Управление конфигурацией. Этот процесс состоит из работ по коррекции наборов проектируемых элементов программы и версий программного продукта.
- Обеспечение качественных показателей. Этот процесс служит для того, чтобы проектируемая программа отвечала всем требованиям, предъявляемым к ней, а также выдерживал стандарты компаний заказчика и исполнителя.
- Верификация. Этот процесс требуется для обнаружения ошибок, допущенных при написании программы, в также выявления возможных несоответствий проектируемой программы требуемому архитектурному построению.
- Аттестация. Целью этого процесса является подтверждение выработанных значений эталонным. Это означает, что погрешность выходных данных должна удовлетворять заложенным требованиям и необходимым стандартам.
- Совместная оценка. Этот процесс требуется для выполнения проверок уровня персонала и проектируемой программы. Осуществляется совместно исполнителем и заказчиком в течение всего проекта.
- Аудит. Этот процесс служит для выработки справедливой оценки текущего положения дел на проекте, отчётов и документов. Осуществляется сравнение положениями договора и документацией, формирующей стандарты. Аудит тоже может осуществляться представителями обеих сторон.
- Разрешение проблемных ситуаций. На этом процессе устраняются недочёты, которые были выявлены при процессах контроля и оценки.
«Технология разработки программного обеспечения»
Готовые курсовые работы и рефераты
Решение учебных вопросов в 2 клика
Помощь в написании учебной работы
Организационные процессы жизненного цикла программы
Есть некоторый комплекс мер, которые направлены на улучшение организации и качественных показателей проектирования программного продукта. Их называют процессами организации жизненного цикла, и они состоят из;
- Управленческий процесс, направленный на оптимальное управление специалистами фирмы, являющейся исполнителем. За ход этого процесса должны отвечать назначенные руководители и отдельное подразделение в компании.
- Формирование инфраструктурных объектов. Проектирование программного обеспечения должно быть обеспечено большим числом элементов инфраструктуры, таких как компьютерное оборудование, серверы, набор вспомогательных программ и так далее. Помимо этого, законченная программа должна быть обеспечена вспомогательными средствами для её работы. Этот процесс требуется, чтобы подготовить аппаратуру и программы для помощи проектировщикам, а также для качественной работы разработанной программы у заказчика.
- Модернизация программного продукта. Этот процесс служит для улучшения работы всех других процессов, составляющих жизненный цикл программного продукта. Благодаря этому процессу, возможно повышение эффективности труда проектировщиков и увеличение прибыли от осуществления заказа по проектированию программы.
- Обучение персонала. Процесс непрерывного обучения работников и повышение уровня их квалификации является непременным условием формирования отличных программных продуктов. Этот процесс служит для организации получения новых знаний и умений специалистами фирмы, которая является разработчиком.
Модель жизненного цикла
Модель жизненного цикла программного продукта выражает подходы группы разработчиков к проектированию программного продукта. Она показывает основные приоритетные направления во всех этапах реализации программного продукта, а также очерёдность осуществления этапов проектирования программы. На текущий момент есть много моделей жизненного цикла реализации программы. Одной из основных является каскадная или водопадная модель, приведённая ниже:
Рисунок 1. Каскадная модель жизненного цикла. Автор24 — интернет-биржа студенческих работ
Источник: spravochnick.ru
Этапы разработки сложных программ
Отдельный человек не в состоянии полностью осмыслить и построить программное обеспечение большой системы. В данном контексте под построением программного обеспечения большой системы мы подразумеваем разработку сложной прикладной программы. Сложная программа- это программа, состоящая из многих программных единиц (модулей). Обычно считается, что сложная программа — это программа, в которой от нескольких тысяч до десятков тысяч строк.
В настоящее время сложилась парадоксальная ситуация с литературой по данному вопросу. На полках книжных магазинов практически по любому программному продукту, мало-мальски используемому у нас, можно гарантированно найти по крайней мере две-три книги.
Однако трудов, посвященных современным проблемам разработки программного обеспечения, принципам построения сложных систем, таких, как компиляторы, СУБД, операционные системы, антивирусные комплексы и т.п., нет. Приятно удивило выступление на эту тему такого уважаемого издания, как PC Magazine/Russion Edition, который в своем спецвыпуске № 5 за декабрь 1997г. опубликовал статью Евгения Зуева “Профессия редкая”. В ней автор делится своим опытом работы над крупными программными проектами. Статья отражает современное состояние вопроса и может быть рекомендована всем, кто занимается разработкой сложных программных комплексов.
Так как современных книг по разработке программных средств нет, а книги, изданные в 70-80-х годах, стали библиографической редкостью, то в рамках данного пособия постараемся осветить вопрос разработки программ.
О терминологии. В литературе 70-80-х годов, посвященной разработке программных средств, в основном используются термины “разработка”, “создание”, “проектирование” и гораздо реже термин “конструирование” программных средств [8]. Если первые два термина употребляются почти как синонимы, то термин “проектирование” уже, а “конструирование” по контексту понимается обычно как еще более узкий термин, означающий создание программы из отдельных конструктивов — “кубиков” программы.
Для лучшего управления ходом разработки больших программных проектов выделяются шесть этапов, составляющих цикл разработки (“цикл жизни”) программ (в скобках показано приблизительное распределение временных затрат на данный этап):
1) анализ требований, предъявляемых к системе (10%);
2) определение спецификаций (10%);
3) проектирование (15%);
4) кодирование (20%);
5) тестирование автономное (25%), тестирование комплексное (20%);
6) эксплуатация и сопровождение.
Анализ требований, предъявляемых к системе. Этот этап часто неоправданно опускается, а именно на нем определяются требования, выполнение которых позволяет получить приемлемое решение проблемы. Необходимо делать различие между жесткими требованиями и требованиями, выполнение которых не является строго обязательным. Следует выявить пространственно-временные ограничения, налагаемые на систему, средства системы, которые в будущем могут претерпеть изменения, а также средства, используемые в различных версиях системы для разных применений.
Важной задачей является определение ресурсов, требуемых для реализации системы. При этом решаются экономические вопросы, вопросы о требованиях к аппаратным средствам, о квалификации и обучении пользователя, о потребности в повседневном обслуживающем персонале и персонале сопровождения программного продукта, о возможности использования существующих пакетов программ. После того как все эти вопросы выяснены, переходят к планированию работ. Решаются вопросы управления развитием системы, устанавливаются показатели оценки достигнутого уровня.
Определение спецификаций. Здесь описываются подробно и точно все функции, реализуемые на компьютере. Задается структура входных и выходных данных. Определяется возможность использования базы данных. Если система создается на основе существующего процесса, то необходимо предусмотреть возможность ее модернизации при изменении процесса.
Все эти вопросы должны быть отражены вфункциональных спецификациях, которые представляют собой документ, отображающий реализацию системы программирования. На этих данных базируется разработка системы тестирования программы. В общем, чем подробнее составлены спецификации, тем меньше вероятность возникновения ошибок, путаницы или взаимных обвинений заказчиков и разработчиков. Спецификации лишь определяют те функции, которые система должна выполнять, не указывая, каким образом это достигается. Составление подробных алгоритмов реализации функций системы на данном этапе преждевременно и может вызвать нежелательные осложнения.
Проектирование. На этом этапе разрабатываются алгоритмы, задаваемые спецификациями, и формируется общая структура вычислительной системы. Систему необходимо разбить на небольшие части таким образом, чтобы ответственность за реализацию каждой такой части можно было возложить либо на одного разработчика, либо на группу исполнителей. При этом для каждого определенного таким образом блока системы должны быть сформулированы предъявляемые к нему требования: реализуемые функции, размеры, время выполнения, особенности процесса обработки информации.
Поскольку в начале этапа проектирования решение задачи может быть не определено, разбиение задачи на подзадачи (блоки) может оказаться весьма сложным. Обычной является ситуация, когда заказчик системы точно не знает, чего он хочет. Поэтому по мере разработки проекта заказчик часто меняет спецификацию. К этому надо быть готовым, но все равно разработка усложняется.
Кодирование- перевод алгоритмической структуры на язык программирования. Данный этап обычно является наиболее простым, а его реализация облегчается при использовании алгоритмических языков высокого уровня и методов структурного программирования. Кодирование — это этап разработки программного обеспечения, доставляющий наименьшее беспокойство разработчикам. По некоторым опубликованным данным 64% всех ошибок вносится на этапе проектирования и лишь 36% — на этапе кодирования. Так, при разработке проекта НАСА “Аполлон” 73% ошибок было связано с проектированием интерфейса.
Тестирование — выполнение действий, предусмотренных задачей контроля правильности функционирования программы. Этап тестирования может повлечь затраты, которые составят половину общих расходов на создание системы. Плохо спланированное тестирование приводит к увеличению затрат и времени тестирования.
В процессе тестирования используются данные, характерные для системы в рабочем состоянии. Большую часть тестовых данных следует определить на этапе проектирования системы.
Последний пример неполного тестирования — операционная система “Windows-95”, в которой пользователи обнаружили более десятка значительных ошибок функционирования.
Тестирование подразделяется на три стадии: автономное, комплексное и системное. Приавтономном тестировании каждая часть программы проверяется с помощью данных, подготавливаемых программистом. При этом программная среда имитируется с помощью программы управления тестированием, содержащей фиктивные программы вместо реальных подпрограмм, к которым имеются обращения из данной части. Подобную процедуру иногда называют программным тестированием, а программу, подлежащую тестированию, — тестирующей программой. Часть программы, прошедшая автономное тестирование, подвергается комплексному тестированию.
В процессекомплексного тестирования производится совместная проверка групп программных компонентов. В результате имеем полностью проверенную систему. На данной стадии тестирования часто обнаруживаются ошибки, пропущенные на предыдущей стадии автономного тестирования. Исправление этих ошибок может вызвать до четверти общих затрат.
Системное или оценочное тестирование- это завершающая стадия проверки системы, т.е. испытание системы в целом с помощью независимых тестов. Независимость тестов является существенным обстоятельством. Заказчик при приемке может настоять на проведении своего собственного системного тестирования. Для случая, когда сравниваются характеристики нескольких систем (например, когда требуемое программное обеспечение поставляется различными изготовителями), такая процедура известна как сравнительное тестирование.
В процессе тестирования для определения правильности выполнения программы используются различные критерии, наиболее важными из которых являются следующие:
1. Каждый оператор должен быть выполнен по крайней мере один раз для заданного набора тестовых данных, и программа должна выдать правильные результаты.
2. Каждая ветвь программы должна быть опробована, и программа при этом должна выдать правильные результаты.
3. Каждый путь в программе должен быть испытан хотя бы один раз с использованием набора тестовых данных, и программа должна выдать правильные результаты.
4. Для каждой спецификации программы необходимо располагать набором тестовых данных, позволяющим установить, что программа правильно реализует данную спецификацию.
Хотя на первый взгляд пп.1 и 2 могут показаться схожими, в действительности они сильно разнятся. Например, для сложного оператора
критерий 1 лишь подразумевает, что IF выполнен, в то время как в соответствии с критерием 2 различные наборы тестовых данных должны вызвать передачу управления на операторы 1, или 2, или 3, или 4.
Этот пример показывает, что не существует единого критерия, определяющего “хорошо проверенную программу”.
Тесно связаны с тестированием понятия “верификация” и “испытания”.
Испытания системы осуществляются посредством её тестирования. Цель проведения такой проверки заключается в том, чтобы показать, что система функционирует в соответствии с разработанными для нее спецификациями.
Верификация системы заключается в выполнении доказательства, что программы удовлетворяют своим спецификациям. Современный процесс разработки программ не позволяет реализовать полностью обе указанные концепции. Для ситуаций, не контролируемых тестовыми данными, система, прошедшая испытание, может выдавать неверные результаты. После проведения верификации система работает правильно лишь относительно первоначальных спецификаций и допущений о поведении окружающей среды; формальные доказательства правильности программ весьма длинны и могут содержать ошибки. Общий процесс создания правильных программ с помощью процедур испытания и верификации называютаттестацией.
Различают три вида отклонений от нормальной работы системы. Сбой системы- это явление, связанное с нарушением системой установленных на нее спецификаций. Данные, при обработке которых правильными алгоритмами системы происходит сбой, называют выбросом. Исправление выброса можно предусмотреть в программе (например, с помощью оператора ON в языке ПЛ1, так что не каждый выброс приводит к сбою).Ошибка- это механический или алгоритмический дефект, который создает выброс (например, программная ошибка).
Не следует путать понятия надежности и правильности программы. Правильная программа- это такая программа, для которой доказано, что она удовлетворяет своим спецификациям. Что касаетсянадежной программы, то она не обязательно является правильной, но выдает приемлемый результат даже в том случае, когда входные данные либо условия ее использования не удовлетворяют принятым допущениям. Естественно стремление иметь живучую систему, т.е. систему, способную воспринимать и правильно обрабатывать широкий спектр входных данных при неблагоприятных условиях. Обычно работа системы считается правильной, если в ней нет ошибок, а ее внутренние данные не содержат выбросов; система является надежной, если, несмотря на сбои, она продолжает удовлетворительно функционировать.
Различие между надежностью и правильностью можно понять на примере операционных систем, включающих процедуры обработки сбоев. При обнаружении выброса такая система прекращает работу с сохранением текущей информации и возможности продолжения работы после устранения выброса. Подобная система может не быть правильной, поскольку она подвержена воздействию выбросов; однако благодаря последовательному характеру функционирования система является надежной. Программа, работающая в реальном времени, может быть правильной до тех пор, пока датчик выдает точную информацию; однако эта программа может оказаться ненадежной, если неверные показания датчика не учтены в спецификациях (и, следовательно, при реализации программы).
Статьи к прочтению:
- Этапы развития информационных систем
- Этапы развития информационных технологий
СДЕЛАЙ САМЫЙ СЛОЖНЫЙ ВЫБОР. ВИДЕО ТЕСТ
Похожие статьи:
- Этапы разработки программного обеспечения Существует государственный стандарт, который устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и…
- Классификация, этапы и средства разработки экспертных систем Существует множество признаков, по которым можно (весьма условно) классифицировать ЭС [49]. По степени сложности различают поверхностные и глубинные ЭС,…
Источник: csaa.ru