Этапы разработки программного продукта 2


главная страница Рефераты Курсовые работы текст файлы добавьте реферат (спасибо :)Продать работу

поиск рефератов

Реферат на тему Этапы разработки программного продукта 2

скачать
похожие рефераты • Точное совпадение: 2 реферата
подобные качественные рефераты

Размер: 30.25 кб.
Язык: русский
Разместил (а): Адвокат
07.07.2011
1 2 3    



Этапы разработки программных продуктов.

1.Кодирование программы.

Написание технического задания

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

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

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

Кодирование — процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программирования.

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

В узком смысле слова, программирование рассматривается как кодирование алгоритмов на заданном языке программирования. Под программированием также может пониматься разработка логической схемы для программируемой логической интегральной схемы, а также процесс записи информации в ПЗУ. В более широком смысле программирование — процесс создания программ, то есть разработка программного обеспечения.
1.1. Понятие кодирования и декодирования.

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

Принципиальная схема обработки информации состоит из поиска, сортировки и упорядочения , в которой кодирование является частью операции ввода данных в виде входных кодов. В результате обработки информации получаются выходные коды, которые после их декодирования выдаются как результат проведенной обработке. Декодирование является операцией, обратной кодированию. Если при кодировании происходит преобразование информации в сигналы в виде определенного сочетания символов , соответствующих данному объекту или его характеристике , то при декодировании , наоборот , по заданному коду определяется соответствующий объект или его признаки. Например, в телефонном справочнике указан код , т.е. номер телефона , связанный с некоторым элементом (лицом или учреждением ). Операция декодирования состоит из набора кода номера телефона , который в виде сигналов поступает в АТС, где декодируется с помощью электрической схемы.
1.2. Процесс кодирования.

Процесс кодирования информации может производиться либо ручным , либо автоматическим способом. При ручном , неавтоматическом способе кодирования вручную отыскивается нужный код в предварительно составленном каталоге кодов и записывается в документе в виде цифровых или алфавитно-цифровых символов. Затем документ поступает в вычислительный центр , где оператор с помощью клавишного устройства перфорирует записанную информацию на перфокарте или перфоленте. Затем перфокарты или перфоленты вводятся в ЭВМ , информация кодируется в машинный (двоичный) код. Таким образом информация дважды кодируется вручную : при записи ее на документ и при переноски данных на машинные носители. При автоматическом способе кодирования человек производит запись на естественном языке в виде слов, цифр и общепринятых обозначений в документе , который читается специальным автоматом. Этот автомат предварительно кодирует документ и записывает все данные на магнитную ленту в двойном коде. Лента затем вводится в ЭВМ, где информация с помощью “машинного словаря “ снова кодируется в более короткий машинный код, удобный для ее поиска, сортировки и обработки. Ввод информации в ЭВМ в виде буквенно-цифрового текста на естественном языке и кодировании в машине требует хранения в памяти ЭВМ словаря, в котором каждому слову соответствует определенный код.По этому словарю машина сама кодирует текст. При этом отпадает необходимость в классификации и кодировании информации по ее смысловому содержанию, так как котируются сами слова, выражающие определенные характеристики предметов. Большое разнообразие технических характеристик и других данных, относящихся к производству и потреблению многочисленных видов продукции, не позволяет включить все необходимые данные для их производства в код продукции, так как этот код содержал бы большое число символов. Поэтому задача кодирования продукции заключается в том, чтобы иметь возможно более короткий код, по которому в памяти машины можно было бы найти подробную информацию о всех необходимых данных, относящихся к каждому изделию. Таким кодом является ключевой код.
Для каждого ключевого кода в памяти ЭВМ должен храниться массив данных, которые извлекаются из памяти и используются для решения различных задач. Этот массив информации должен быть единым для всех решаемых задач, например каталогом продукции, где в одном месте хранятся все необходимые данные о каждом предмете. Разделение его на ряд отдельных массивов, записанных, например, на различных участках магнитной ленты, нецелесообразно, так как это привело бы к повторению одной и той же информации и увеличению объема хранимой информации. Основное требование к ключевому коду - однозначный поиск ЭВМ признаков, относящихся к данному предмету, для которого ключевой код является адресом. Ключевой код может быть просто порядковым регистрационным номером и не нести какой-либо конкретной информации о продукции или, наоборот, может быть построен по определенной системе классификации и содержать конкретную информацию об основных признаках продукции, вполне ее определяющих. Второй способ кодирования более эффективен, так как регистрационный код не дает возможности осуществить предварительную сортировку информации по ее содержанию. Ключевой код позволяет производить сортировку карточек продукции по главным определяющим признакам. Детальная спецификация и ее остальные характеристики находятся в предварительно отсортированных карточках.
1.3. Виды кодов.

Код , символы которого соответствуют определенным предметам или характеристикам , называется прямым кодом . Если код непосредственно не содержит информацию о предмете или его признаках , а представляет адрес , указывающий местоположение информации , где содержится необходимые сведения , то он называется адресным кодом. Адресный код применяется для сокращения кода и быстрого поиска больших массивов информации. За единицу количества информации принимается 1 бит, т.е. один двоичный разряд (0 или 1). Буквы, десятичные цифры и другие символы внутри ЭВМ представляются в виде групп двоичных разрядов. Операция представления их в таком виде называется двоичным кодированием. Группа из n двоичных чисел позволяет закодировать 2n различных символов. Такая группа называется байтом.

Более крупной единицей информацией является машинное слово , представляющее собой последовательность символов , занимающих одну ячейку в памяти машины. В зависимости от ЭВМ машинного слова может колебаться в пределах— от 16 до 64 двоичных разрядов. машинное слово может быть командой , числом или буквенно-цифровой последовательностью. Обычно машинное слово используется как единое целое в ЭВМ , хотя на некоторых машинах допускается обработка частей машинного слова. Массив информации, содержащий 1024 машинных слова , называется страницей. Каждый отдельный блок памяти содержит обычно 16 и более страниц. Местоположение (адрес) слова в памяти определяется кодом адреса, содержащим номер блока, страницы и номера слова в этой странице. Для упорядочения информации о множестве объектов , а также для облегчения их поиска и сортировки по заданным признакам или характеристикам применяется классификация этого множества.

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

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

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

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

Важно отметить, что эта формулировка устанавливает требование, но не тип тестирования или формат документации. Данное предложение необходимо включить в правила для всего программного обеспечения и в процедуры.
2.1.Тестирование программного обеспечения.
Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после «основательного тестирования».

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

«Тестирование — процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет.» Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Читатель с некоторым опытом программирования уже, вероятно, понимает, что невозможно продемонстрировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успехом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование — процесс выполнения программы с намерением найти ошибки.

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

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

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

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

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

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

Тестирование (testing), как мы уже выяснили,—процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.

Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию — взгляд во многом ошибочный; более подробно это обсуждается в гл. 17.

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

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

Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы извесной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.

Тестирование сопряжении (integration testing) — контроль сопряжении между частями системы (модулями, компонентами, подcистемами).

Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соотетствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Отношения между этими типами тестов и проектной документацией, на которой основывается тест.
2.3. Философия тестирования
Тестирование программного обеспечения охватывает целый ряд видов деятельности, весьма аналогичный последовательности процессов разработки программного обеспечения. Сюда входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов и, наконец, выполнение тестов и изучение результатов тестирования. Решающую роль играет проектирование теста. Возможен целый спектр подходов к выработке философии, или стратегии проектирования тестов, изображенный на рис.2. Чтобы ориентироваться в стратегиях проектирования тестов, стоит рассмотреть два крайних подхода, находящихся на границах спектра. Следует отметить также, что многие из тех, кто работает в этой области, часто бросаются в одну или другую крайность.

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

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

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

Эти рассуждения приводят ко второму фундаментальному принципу тестирования: тестирование — проблема в значительной степени экономическая. Поскольку исчерпывающее тестирование невозможно, мы должны ограничиться чем-то меньшим. Каждый тест должен давать максимальную отдачу по сравнению с нашими затратами. Эта отдача измеряется вероятностью тою, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что затраты ограничены бюджетом и графиком, можно утверждать, что искусство тестирования, по существу, представляет собой искусство отбора тестов с максимальной отдачей. Более того, каждый тест должен быть представителем некоторого класса входных значений, так чтобы его правильное выполнение создавало у нас некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры программы, и мы, таким образом, смещаемся к правому концу спектра.
    продолжение
1 2 3    

Добавить реферат в свой блог или сайт
загрузка...
Удобная ссылка:

Скачать реферат бесплатно
подобрать список литературы


Этапы разработки программного продукта 2


Постоянный url этой страницы:
Реферат Этапы разработки программного продукта 2


Разместите кнопку на своём сайте:
Рефераты
вверх страницы


© coolreferat.com | написать письмо | правообладателям | читателям
При копировании материалов укажите ссылку.