Технологии разработки программного обеспечения

Размещено на http://www.allbest.ru/

КУРС ЛЕКЦИЙ

по предмету «Основы программирования»

на тему: «Технологии разработки программного обеспечения»

Содержание

1. Требования к современным технологиям

2. Общие принципы разработки программных средств

3. Разработка структуры программы и модульное программирование

4. Разработка программного модуля. Структурное программирование

5. Стиль программирования. Выбор языка программирования

6. Виды ошибок. Основные принципы отладки ПС

7. Основные принципы организации тестирования ПС

8. Виды программных документов

9. Обеспечение функциональности, надежности и качества ПС. Технологии оценки качества ПС

10. Обеспечение качества программного обеспечения

11. Аттестация программного средства

1. Требования к современным технологиям

Программное средство (ПС) - это программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией.

Программная документация позволяет понять, какие функции выполняет та или иная программа, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы).

Будем считать, что в ПС имеется ошибка, если оно не выполняет функции, описанные в документации по ее применению.

Надежность ПС - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью.

Технология программирования - это система научно-обоснованных принципов, методов и средств, обеспечивающих создание и развитие ПС, в течении всего жизненного периода (жизненного цикла) программного средства.

Состав технологии программирования:

1. принципы и методы организации труда при разработке, эксплуатации ПС;

2. принципы и методы разработки самих программ;

3. средства инструментальной поддержки и автоматизации, позволяющие унифицировать разработку ПС.

2. Общие принципы разработки программных средств

Жизненный цикл ПС

Жизненный цикл ПС - период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и заканчивая прекращением всех видов его использования.

Внешнее описание ПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика).

Конструирование ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.

Кодирование: создание текстов программ на языке программирования, их отладка и тестирование ПС.

На этапе аттестации ПС производится оценка качества ПС, после успешного завершения которого, разработка ПС считается законченной.

Программное изделие (ПИ) - экземпляр или копия, снятая с разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки. Стадия производства ПС в жизненном цикле ПС является, по существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок.

Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС.

Применение ПС - это использование ПС для решения практических задач на компьютере путем выполнения ее программ.

Сопровождение ПС - это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях.

Понятие качества ПС.

Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей.

Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.

Критерии качества ПС:

- функциональность,

- надежность,

- легкость применения,

- эффективность,

- сопровождаемость,

- мобильность.

Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.

Легкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.

Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.

Обязательные критерии качества: функциональность и надежность.

3. Разработка структуры программы и модульное программирование

Приступая к разработке каждой программы ПС, следует иметь в виду, что она является большой системой, поэтому нужно принимать меры для ее упрощения. Для этого программу разрабатывают по частям, которые называются программными модулями. Такой метод программирования называют модульным программированием.

Модуль - это самостоятельная часть программы, имеющая определенное значение и обеспечивающая заданные функции обработки автономно от других программных модулей. Каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым физически разделен с другими программными модулями. Каждый программный модуль может включаться в состав разных программ, если выполнены условия его использования, описанные в документации по ее использованию. Т.е. хорошо продуманный модуль позволяет избежать дублирования в программировании.

Любое ПС имеет свою структуру, которая разрабатывается для удобства:

1. разработки

2. программирования

3. отладки

4. внесения изменений

Также структуризация ПС позволяет:

1. распределить работы по исполнителям, обеспечив их загрузку и требуемые сроки разработки

2. построить календарные графики проектных работ и осуществлять их координацию в процессе создания ПИ.

3. контролировать трудозатраты и стоимость проектных работ.

При создании ПС выделяются многократно используемые модули, их типизируют и унифицируют, за счет чего сокращаются сроки и трудозатраты на разработку ПС в целом.

Некоторые ПС используют готовые модули из библиотек стандартных процедур, функций, объектов и методов обработки данных.

Типовая структура ПС:

носитель отладка программный модуль

Таблица. Типы модулей

Наименование модуля	Описание
Головной модуль	Управляет запуском ПС (он в единственном числе)
Управляющий модуль	Обеспечивает вызов других модулей, задает последовательность вызова на выполнение очередного модуля
Рабочие модули	Выполняют функции обработки
Сервисные модули	Осуществляют обслуживающие функции

Свойства модуля:

1. один вход и один выход - на входе программный модуль получает определенный набор исходных данных, выполняет обработку данных и возвращает результат

2. функциональная завершенность - модуль выполняет перечень операций для реализации каждой отдельной функции в полном составе.

3. логическая независимость - результат работы модуля зависит только от исходных данных, и не зависит от работы других модулей.

4. слабые информационные связи с другими программными модулями - обмен информации между модулями должен быть по возможности минимизирован.

5. обозримый по размеру и сложности.

Каждый модуль состоит из спецификации и тела модуля.

Спецификация - правила использования модуля.

Тело - способ реализации процесса обработки.

Принцип модульного программирования ПС:

1. Определение состава и подчиненность функций

2. определение набора программных модулей, реализующих эти функции

При составлении алгоритма необходимо учитывать:

1. каждый модуль вызывается на выполнение вышестоящим модулем и закончив работу, возвращает управление вызвавшему модулю.

Методы разработки структуры программы.

В качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах дерева размещаются модули, а стрелки показывают подчиненность модулей (т.е. в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит).

Модульная структура программы должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит:

1. синтаксическую спецификацию его входов, позволяющую построить обращение к нему на используемом языке программирования

2. функциональную спецификацию модуля (описание всех функций, выполняемых этим модулем).

Существуют разные методы разработки структуры программы. Обычно используют 2 метода:

1. Метод восходящей разработки

2. метод нисходящей разработки

Метод восходящей разработки.

Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня, в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Не рекомендуется, т.к.:

1. для программирования какого-либо модуля совсем не требуется текстов, используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно используемые модули заменять их имитаторами (заглушками).

2. каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать.

3. при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.

Метод нисходящей разработки.

Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке.

Положительные стороны

1. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей.

2. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы. Имитатор модуля - простой программный фрагмент, сигнализирующий, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами.

Рассмотренные методы называются классическими. В них модульная древовидная структура программы должна разрабатываться до начала программирования модулей. Однако такой подход вызывает ряд возражений: маловероятно, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно.

При конструктивном и архитектурном подходах к разработке программ модульная структура формируется в процессе программирования модулей.

Конструктивный подход (Модификация нисходящей разработки)

Модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом, причем спецификация программы является одновременно и спецификацией ее головного модуля, так как последний полностью берет на себя ответственность за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются внутренние функции, в терминах которых программируется головной модуль. Это означает, что для каждой выделяемой функции создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей. Важно заметить, что здесь также ответственность за выполнение выделенной функции берет головной (может быть, и единственный) модуль этого поддерева, так что спецификация выделенной функции является одновременно и спецификацией головного модуля этого поддерева. В головном модуле программы для обращения к выделенной функции строится обращение к головному модулю указанного поддерева в соответствии с созданной его спецификацией. Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя начальная часть дерева, например, такая, которая показана на рис. 7.1.

Рис. 7.1 Первый шаг формирования модульной структуры программы при конструктивном подходе

Аналогичные действия производятся при программировании любого другого модуля, который выбирается из текущего состояния дерева программы из числа специфицированных, но пока еще не запрограммированных модулей. В результате этого производится очередное деформирование дерева программы, например, такое, которое показано на рис. 7.2.

Архитектурный подход (модификация восходящей разработки)

Модульная структура программы формируется в процессе программирования модуля. Но при этом ставится другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в этой области, и специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Так как процесс выделения таких функций связан с накоплением и обобщением опыта решения задач в заданной предметной области, то обычно сначала выделяются и реализуются отдельными модулями более простые функции, а затем постепенно появляются модули, использующие ранее выделенные функции. Такой набор модулей создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей.

Это позволяет сократить трудозатраты на разработку конкретной программы путем подключения, к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться в разных конкретных программах, то архитектурный подход может рассматриваться как путь борьбы с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры.



Рис. 7.2 Второй шаг формирования модульной структуры программы при конструктивном подходе

Метод нисходящей реализации. Каждый запрограммированный модуль начинают сразу же тестировать до перехода к программированию другого модуля.

4. Разработка программного модуля. Структурное программирование

Порядок разработки программного модуля.

1. изучение и проверка спецификации модуля, выбор языка программирования; (т.е. разработчик, изучая спецификацию, выясняет, понятна она ему или нет, достаточно ли полно она описывает модуль; затем он выбирает язык программирования, на котором будет написан модуль, хотя язык программирования может быть единым для всего ПС)

2. выбор алгоритма и структуры данных (здесь выясняется не известны ли какие-либо алгоритмы для решения поставленной задачи и если есть, то воспользоваться им)

3. программирование модуля (написание кода программы)

4. шлифовка текста модуля (редактирование имеющихся комментариев, добавление дополнительных комментариев, для того чтобы обеспечить требуемое качество)

5. проверка модуля (проверяется логика работы модуля, отлаживается его работа)

Применяются следующие методы контроля программного модуля:

- статическая проверка текста модуля (текст прочитывается с начала до конца с целью найти ошибки в модуле. Обычно для такой проверки привлекают, кроме разработчика модуля, еще одного или даже нескольких программистов. Рекомендуется ошибки, обнаруживаемые при такой проверке исправлять не сразу, а по завершению чтения текста модуля)

- сквозное прослеживание (вручную прокручивается выполнение модуля (оператор за оператором в той последовательности, какая вытекает из логики работы модуля) на некотором наборе тестов)

6. компиляция модуля.

Структурное программирование.

На сегодняшний день самой популярной методикой программирования является структурное программирование «сверху-вниз».

Структурное программирование - это процесс пошагового разбиения алгоритма на все более мелкие части, с целью получить такие элементы, для которых можно легко написать конкретные предписания.

Два принципа структурного программирования:

1. последовательная детализация «сверху - вниз»

2. ограниченность базового набора структур для построения алгоритмов любой степени сложности

Требования структурного программирования:

1. программа должна составляется мелкими шагами, таким образом, сложная задача разбивается на достаточно простые, легко воспринимаемые части.

2. логика программы должна опираться на минимальное число достаточно базовых управляющих структур (линейные, разветвляющиеся и циклические структуры)

Основные свойства и достоинства структурного программирования:

1. уменьшение сложности программ

2. возможность демонстрации правильности программ на различных этапах решения задачи

3. наглядность программ

4. простота модификации (внесения изменения) программ.

Современные средства программирования должны обеспечивать максимальную защиту от возможных ошибок разработчика.

Тут можно провести аналогию с развитием методов управления автотранспортом. Сначала безопасность обеспечивалась за счет разработки правил движения. Затем появилась система разметки дорог и регулирования перекрестков. И, наконец, стали строиться транспортные развязки, которые в принципе предотвращают пересечение потоков машин и пешеходов. Впрочем, используемые средства должны определяться характером решаемой задачи: для проселочной дороги вполне достаточно соблюдения простого правила - "смотри под ноги и по сторонам".

Основная идея структурного программирования: программа должна представлять собой множество блоков, объединенных в виде иерархической древовидной структуры, каждый из которых имеет один вход и один выход.

Любую программу можно построить, используя лишь три основных типа блоков:

1. функциональный блок - отдельный линейный оператор или их последовательность;

2. блок разветвления - If <условие> Then...Else.

3. обобщенный цикл - конструкция типа While <условие> Do <операторы> (проверка в начале цикла!);



Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход.

Структурное программирование иногда называют еще "программированием без GO TO". Однако дело здесь не в операторе GO TO, а в его беспорядочном использовании. Очень часто при воплощении структурного программирования на некоторых языках программирования оператор перехода (GO TO) используется для реализации структурных конструкций, не снижая основных достоинств структурного программирования. Запутывают программу как раз "неструктурные" операторы перехода, особенно переход на оператор, расположенный в тексте модуля выше (раньше) выполняемого оператора перехода. Тем не менее, попытка избежать оператора перехода в некоторых простых случаях может привести к слишком громоздким структурированным программам, что не улучшает их ясность и содержит опасность появления в тексте модуля дополнительных ошибок. Поэтому можно рекомендовать избегать употребления оператора перехода всюду, где это возможно, но не ценой ясности программы.

К полезным случаям использования оператора перехода можно отнести выход из цикла или процедуры по особому условию, "досрочно" прекращающего работу данного цикла или данной процедуры, т.е. завершающего работу некоторой структурной единицы (обобщенного оператора) и тем самым лишь локально нарушающего структурированность программы. Большие трудности (и усложнение структуры) вызывает структурная реализация реакции на возникающие исключительные (часто ошибочные) ситуации, так как при этом требуется не только осуществить досрочный выход из структурной единицы, но и произвести необходимую обработку этой ситуации (например, выдачу подходящей диагностической информации). Обработчик исключительной ситуации может находиться на любом уровне структуры программы, а обращение к нему может производиться с разных нижних уровней. Вполне приемлемой с технологической точки зрения является следующая "неструктурная" реализация реакции на исключительные ситуации. Обработчики исключительных ситуаций помещаются в конце той или иной структурной единицы и каждый такой обработчик программируется таким образом, что после окончания своей работы производит выход из той структурной единицы, в конце которой он помещен. Обращение к такому обработчику производится оператором перехода из данной структурной единицы (включая любую вложенную в нее структурную единицу).

Вообще говоря, главное в структурном программировании - грамотное составление правильной логической схемы программы, реализация которой языковыми средствами - дело вторичное.

5. Стиль программирования. Выбор языка программирования

Программы должны составляться так, чтобы их могли прочитать в первую очередь люди, а не машины. Помните: программы читаются людьми, т.е. удобочитаемость программ - существенна, поэтому имеет смысл говорить о стандарте стиля программ.

Легко читаемая программа создает впечатление, что ее автор хорошо знал что делал.

Программа должна передавать логику и структуру алгоритма настолько, насколько это возможно.

Один из аргументов против стандартизации стиля программирования звучит так: стиль программирования - это дело личного мнения и вкуса, поэтому не следует вводить на него каких - либо ограничений - этот аргумент, в сущности, утверждает, что хаос лучше порядка.

Правило стандартизации стиля: если существует более одного способа сделать что - либо и выбор произвольный, остановись на одном способе и всегда его придерживайся.

Легче избежать путаницы, придерживаясь стандартных приемов, хороший набор стандартных приемов позволяет сконцентрировать внимание на главной задаче.

Невозможно выработать единого промышленного стандарта для всех программ, но в пределах единого проекта, задачи, разработки - это нормальное явление.

Комментарии:

Желательность комментариев очевидна. Программы с пояснительными комментариями значительно легче отслеживать, читая чужую программу, программисты немало времени отслеживают логику чужой программы, т.е. не комментируемая программа - свидетельство дилетантского похода.

Когда следует писать комментарий? В процессе написания программы. Бессмысленно вставлять комментарии, после того, как программа завершена.

Делайте комментариев больше, чем это кажется необходимым. Т.к. цель комментариев - облегчить понимание программы. Если вы затрудняетесь в написание комментария - значит “Вы не ведаете, что творите! ”

Три типа комментариев:

1. вводные

2. оглавление

3. пояснительные.

Вводные комментарии:

Каждая программа, подпрограмма или процедура, должна начинаться с комментариев, поясняющих, что она делает. Минимальная информация, содержащаяся в вводных комментариях должна включать следующие пункты:

- Назначение программы.

- Указания по вызову программы и ее использованию.

- Список и назначение основных переменных или массивов.

- Указание по вводу - выводу. Список всех файлов.

- Список используемых подпрограмм.

- Назначение применяемых математических методов.

- (иногда) Сведения о времени выполнения программы.

- Требуемый объем памяти.

- Специальные указания оператору.

- Сведения об авторе.

- Дату написания программы.

Пояснительный комментарий:

Пояснениями нужно сопровождать те части программы, которые трудно понять без комментариев. Сопровождайте комментариями те действия, которые, с вашей точки зрения, могут быть не совсем понятны другому. Комментарии не должны объяснять синтаксис языка программирования, а должны раскрывать логику программы или цель конкретного действия. Если логика программы понятна только на основании прочтения комментариев, это качественные комментарии.

Расположение комментариев.

Комментарии легче читаются, если они отделяются пустыми строками (до и после комментариев). Дополнительный метод выделения комментариев - заключение их в прямоугольник из специальных символов (звездочки, слеши, скобки и т.д.). Располагаются комментарии т. о., чтобы это не делало программу менее наглядной. Неправильные комментарии хуже, чем их отсутствие. Делайте пробелы для улучшения читаемости программ.

Выбор имен переменных, файлов.

Имена переменных должны наилучшим образом определять те величины, которые они представляют. Если ограничения на длину имени отсутствуют, используйте имена постольку длинные, поскольку это нужно, но не длиннее, чем необходимо.

- Имена переменных не должны совпадать со служебными словами.

- Избегайте схожих по виду имен и подобных по написанию символов.

- Различие имен должно быть всегда явно ощутимым.

- Когда имена содержат лишнюю информацию это тоже плохо, т.к. программа расширяется, становится громоздкой.

- При выборе имен переменных старайтесь установить, что обозначает эта переменная на естественном языке, и выбирайте наиболее подходящее слово.

Имена файлов:

- Использование одних и тех же имен для одинаковых файлов в различных программах, обеспечивает быструю идентификацию их (узнаваемость).

- Иногда использование префикса, помогает определять, какие поля связаны логически.

- При выборе имен записей используйте имена, ориентированные на содержание записи, а не на конкретное задание.

Отступы:

При записи операторов для указания связи между ними делают одинаковый отступ от начала строки. И хотя отступы не оказывают влияния на логику программы, существенно улучшают ее читаемость. Циклы - типичный случай для использования отступов.

- Для выявления структуры программы - используйте отступы.

- Если операторы занимают несколько строк, то строки, начиная со второй, должны иметь отступ чтобы находиться справа от знака равенства.

Выбор и обоснование языка программирования.

Программа должна быть существенно коммуникативно. Успешная коммуникация достигается благодаря языку, понятному программистам и процессору. Команды, выполняемые центральным процессором компьютерной системы, должны быть выражены в машинном коде. Каждая команда при этом выступает в виде последовательности нулей и единиц. Программист, конечно, может, затрачивая огромные усилия понимать и составлять программы на машинном языке. Но для создания больших и надежных программ машинный код совершенно неприемлем.

Трансляция - один из способов преодолеть “языковый” барьер. Если воспользоваться языком, понятным программисту, а потом обеспечить перевод с него в машинный код, проблема будет решена. Может показаться, что для этой цели лучше выбрать естественный язык, например, английский, но на самом деле удобнее сконструировать особый язык. На сегодняшний день создано много таких языков, которые названы - языки программирования высокого уровня.

Хорошо сконструированные языки высокого уровня обладают целым рядом достоинств, основанных на следующих фактах:

а) Средства, предоставляемые языком, позволяют удовлетворить потребности конкретной прикладной области. Например, один язык может быть разработан для научных, преимущественно численных расчетов, другой для коммерческих приложений, обрабатывающих много нечисловой информации, третий будет применяться в других прикладных областях.

б) В визуальном отношении программа должна быть такой, чтобы ее легко было читать, и чтобы была ясна ее структура. Проектирование и написание больших программ - сложная интеллектуальная задача, и для ее успешного решения программист должен предельно сосредоточиться на том, что он делает и ясно представлять себе задачу. Это очень полезно не только тому, кто пишет программу, но и особенно программисту, которому поручено ее усовершенствовать.

в) В язык могут быть (и даже должны быть) встроены средства, помогающие выявлять и предупреждать ошибки. Учитывая важность того, чтобы законченная программа была правильной, и принимая во внимание естественную подверженность программиста ошибкам, такие средства следует признать главным достоинством языков высокого уровня.

Отношение и эффективность.

Существует три типа программ и отношение к эффективности этих программ должно быть различным.

Первый тип - это часто используемые программы: операционные системы, компиляторы, трансляторы, прикладные программы. Для таких программ эффективность является первостепенной задачей, вследствие их частого использования и специфического выполнения. Второй тип - производственные программы, написанные профессиональными программистами, эксплуатируемые долгое время. Хотя эффективность таких программ существенна, обычно большее внимание уделяется их эксплуатационным характеристикам.

Третий тип - программы, написанные не программистами, а научными сотрудниками это программы должны уместиться в заданном объёме памяти и выполняется за конкретное время. Время для них важней всего.

Следовательно: ещё до написания программы необходимо установить, насколько эффективной она должна быть.

Очевидно, что следует модифицировать только те программы, которые многократно повторяются (используются). «Не стоит экономить на спичках». Многие методы, делающие программу эффективной могут существенно влиять на ее удобочитаемость, а удобочитаемость программы более существенно, чем ее эффективность. В каком случае эффективности отдают предпочтение в ущерб удобочитаемости: если программа должна быть выточена в библиотеку часто используемых программ функции, программа не помещается в памяти, она важна, но слишком долго выполняется.

Оптимизация программ.

Если программу следует оптимизировать, необходимо тщательно проверить алгоритм.

Программу, подлежащую оптимизации следует разбить на подпрограммы (в соответствии с принципом структурного программирования). Если не возможно учесть время выполнения каждой подпрограммы подсчитайте количество операторов в подпрограмме, особенно выполненных в тело циклов. Ищите операторы, которые можно модифицировать - (do While и CASE) особенно это касается операторов цикла и ввода - вывода. Для каждой подпрограммы можно вычислить коэффициент: процент времени * процент улучшения. Программу с высоким коэффициентом следует оптимизировать в первую очередь. Здесь можно использовать два подхода: «чистка» (использование очевидных неточностей в исходной программе) и перепрограммирование (если подвергается подпрограмма существенным изменениям).

Эффективность выполнения программ.

Эффективность программы во время выполнения определяйте использованием двух ресурсов. Первый - необходимое для работы время, второй - понять, какая, требуется программа. Хорошей считается программа, которая выполняется при минимальном расходе минимального времени. Вопрос о распределении памяти не представляет интереса до тех пор, пока ее достаточно. Но когда памяти явно не хватает, вопрос об экономии становится очевидным. С широким внедрением ПК в быт, с использованием мультимедийных возможностей появилась еще больше необходимости деления памяти на участки различного размера.

6. Виды ошибок. Основные принципы отладки ПС

Виды ошибок:

1. Ошибки в описании задачи

Отсутствие взаимопонимания между программистом и заказчиком и качественное определение требований, приводит к получению нежелательных результатов, такие ошибки являются разрушительными и ведут к полному перепрограммированию.

2. Ошибки в выборе алгоритма

Неэффективный алгоритм может привести весь процесс программирования также к нежелательному результату, т.е. не эффективный метод может привести к перепрограммированию.

3. Ошибки анализа

Эти ошибки связаны с неполным учетом возникающих ситуаций (например, пренебрежение или не знание области допустимых значений переменных могут привести к нереальным результатам). Мелкие или крупные логические ошибки из которых можно выделить :

a. отсутствие заданий начальных значений

b. неверное условие окончания цикла

c. неверная индексация цикла

d. отсутствие задания обнуления циклов.

4. Ошибки общего характера - ошибки из-за не достаточного знания тонкостей языка или самой системы или машины.

5. Синтаксические ошибки - ошибки, вызванные не правильным написанием операторов.

6. Семантические ошибки - неправильное использование написанных операторов.

7. Ошибки в данных

Виды контроля ПС:

- Визуальный,

- Статический

- динамический

Визуальный контроль - это проверка программ “ за столом “, без использования компьютера.

1. сначала осуществляется чтение программы

2. затем осуществляется сквозной контроль программы (ее ручная прокрутка на нескольких заранее подобранных простых тестах).

Статический контроль - это проверка программы по ее тексту (без выполнения) с помощью инструментальных средств. Формы статического контроля:

1. синтаксический контроль программы с помощью компилятора, при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.

2. контроль правдоподобия программы, то есть выявление в ее тексте конструкций, которые хотя и синтаксически корректны, но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобные ситуации:

- использование в программе неинициализированных переменных (то есть переменных, не получивших начального значения) ;

- наличие в программе описаний переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;

- наличие в тексте программы фрагментов, никогда не выполняющихся;

- наличие в тексте программы переменных, ни разу не используемых для чтения после присваивая им значений;

- наличие в тексте программы заведомо бесконечных циклов ;

Даже если присутствие в тексте программы неправдоподобных конструкций не приводит к ее неправильной работе, исправление этого фрагмента повысит ясность и эффективность программы, т. е. благотворно скажется на ее качестве.

Основные цели и принципы отладки

Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ.

Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом.

Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки.

Отладка = Тестирование + Поиск ошибок + Редактирование.

Каждому программисту известно, сколько времени и сил уходит на отладку программ. На этот этап приходится около 50% общей стоимости разработки программного обеспечения. Тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок. Но Нельзя гарантировать, что тестированием ПС можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи:

1. подготовить такой набор тестов и применить к ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС.

2. определить момент окончания отладки ПС (или отдельной его компоненты). Отладка заканчивается, когда тестами охвачено множество различных ситуаций, возникающих при выполнении программ ПС, и относительно редко появляются ошибки в ПС на последнем отрезке процесса тестирования.

Заповеди отладки.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

Заповедь 4. Избегайте невоспроизводимых тестов, документируйте их пропуск через компьютер; детально изучайте результаты каждого теста.

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Советы по организации тестирования

- необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней;

- должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе;

- тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки;

- следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию.

7. Основные принципы организации тестирования ПС

Существует 4 этапа тестирования многомодульных ПС:

1. тестирование отдельных модулей;

2. совместное тестирование модулей;

3. тестирование функций программного комплекса;

4. тестирование всего комплекса в целом.

На первых двух этапах используются прежде всего методы структурного программирования. При структурном тестировании программа рассматривается как “белый ящик” (т.е. ее текст открыт для пользования). Происходит проверка логики программы.

Совместное тестирование модулей

Два подхода к совместному тестированию модулей:

1. Пошаговое. Каждый модуль для своего тестирования подключается к набору уже проверенных модулей. Здесь модули проверяются не изолированно друг от друга, поэтому требуются либо только ведущие модули, либо только заглушки.

2. Монолитное. Сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования. Для каждого модуля требуется модуль, имитирующий вызов тестируемого модуля, и один или несколько модулей, имитирующих работу модулей, вызываемых из тестируемого. При пошаговом тестировании

Преимущества пошагового подхода:	Преимущества монолитного тестирования:
1. меньшая трудоемкость; 2. более раннее обнаружение ошибок в интерфейсах между модулями (их сборка начинается раньше, чем при монолитном тестировании); 3. легче отладка, то есть локализация ошибок (они в основном связаны с последним из подключенных модулей); 4. более совершенны результаты тестирования (более тщательная проверка совместного использования модулей).	1. меньше расход машинного времени (хотя из-за большей сложности отладки может потребоваться дополнительная проверка программы, и это преимущество будет сведено на нет); 2. предоставляется больше возможностей для организации параллельной работы на начальном этапе тестирования.

В целом более целесообразным является выбор пошагового тестирования. При его использовании возможны две стратегии подключения модулей: нисходящая и восходящая.

Нисходящее тестирование	Восходящее тестирование
начинается с головного модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых из уже протестированных.	начинается с терминальных модулей (т.е. тех, которые не вызывают никаких других модулей программы).
Проблемы и недостатки
1. Создание заглушек. Как правило, недостаточно, чтобы в заглушке выполнялся вывод соответствующего информационного сообщения и возврат всегда одних и тех же значений выходных данных. 2. появляется соблазн совмещения нисходящего проектирования с тестированием; 3. может возникнуть желание перейти к тестированию модуля следующего уровня до завершения тестирования предыдущего по объективным причинам (необходимости создания нескольких версий заглушек, использования модулями верхнего уровня ресурсов модулей нижних уровней).	1. Проверка всей структуры разрабатываемого программного комплекса возможна только на завершающей стадии тестирования. 2. тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ); 3. большой объем отладочного программирования (при отладке одного модуля часто приходится составлять для разных тестов много ведущих отладочных модулей); 4. необходимость специального тестирования сопряжения модулей.
Достоинства
1. уже на ранней стадии тестирования есть возможность получить работающий вариант разрабатываемой программы; 2. быстро могут быть выявлены ошибки, связанные с организацией взаимодействия с пользователем; 3. большинство тестов готовится в форме, рассчитанной на пользователя; 4. во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко - для всех, тестов); 5. отпадает необходимость тестирования сопряжения модулей.	1. Нет проблемы выбора следующего подключаемого модуля - учитывается лишь то, чтобы он вызывал только уже протестированные модули. 2. В отличие от заглушек ведущие модули не должны иметь несколько версий, поэтому их разработка в большинстве случаев проще. 3. Поскольку нет промежуточных модулей (тестируемый модуль является для рабочего варианта программы модулем самого верхнего уровня), нет проблем, связанных с возможностью или трудностью задания тестов; 4. нет возможности совмещения проектирования с тестированием; 5. нет трудностей, вызывающих желание перейти к тестированию следующего модуля, не завершив проверки предыдущего. 6. простота подготовки тестов; 7. возможность полной реализации плана тестирования модуля.

Правила выбора тестируемых модулей: модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше;

Наиболее важные для программы в целом модули должны тестироваться в первую очередь.

Хотя однозначного вывода о преимуществах той или иной стратегии пошагового тестирования сделать нельзя (нужно учитывать конкретные характеристики тестируемой программы), в большинстве случаев более предпочтительным является восходящее тестирование. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования.

Тестирование функций ПС

Используются методы функционального тестирования. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации.

Тестирование всего программного комплекса

При комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС. Тестирование этих документов производится в порядке, обратном их разработке. Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые в принципе могут возникнуть у пользователя, но, возможно, в моделируемой (а не в реальной) среде. Например, некоторые недоступные при комплексной отладке устройства ввода и вывода могут быть заменены их программными имитаторами.

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием. Точность, устойчивость, защищенность, временная эффективность, в какой-то мере - эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств могут тестироваться. Легкость применения ПС оценивается при тестировании документации по применению ПС.

Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также неудобств применения ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим воспользоваться ПС так, как это будет делать пользователь. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации.

Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь ПС как один из путей преодоления барьера между разработчиком и пользователем. Обычно это тестирование производится с помощью контрольных задач - типовых задач, для которых известен результат решения. В тех случаях, когда разрабатываемое ПС должно прийти на смену другому варианту ПС, который решает хотя бы часть задач разрабатываемого ПС, тестирование производится путем решения общих задач с помощью, как старого, так и нового ПС с последующим сопоставлением полученных результатов. Иногда в качестве формы такого тестирования используют опытную эксплуатацию ПС - ограниченное применение нового ПС с анализом использования результатов в практической деятельности. По-существу, этот вид тестирования во многом перекликается с испытанием ПС при его аттестации, но выполняется до аттестации, а иногда и вместо аттестации.

8. Виды программных документов

Документация, создаваемая в процессе разработки программных средств.

При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы:

- Документы управления разработкой ПС.

- Документы, входящие в состав ПС.

Документы управления разработкой ПС, протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами - лицами, управляющими разработкой. Эти документы могут быть следующих типов:

- Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения.

- Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.

- Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка данного ПС.

- Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.

- Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.