Методические указания по выполнению лабораторных работ по дисциплине Методы разработки программного обеспечения
 Скачать 301.5 Kb.
|
Пример импульсного изменения длины программного документа Рис. Заштрихованная область представляет собой дополнение к оценке  , отражающее влияние импульсного изменения длины документов и вычисляется как Таким образом, оценка длины документа пропорциональна значению импульсного изменения длины  с коэффициентом пропорциональности  .В принципе импульсное изменение длины документа присутствует и при ai<>bi , поэтому n-1 H’n С причем Ci=min{ai,bi}. Если в процессе работы значения ai и bi неконтролируемы, изменяемое измерение длины учесть нельзя. Используя конечное значение длины документа , можно записать H’’n = H’n /ln , Программная документация неоднородна по своему содержанию . С одной стороны встречаются документы , сильно зависящие от текста программы . С другой стороны , существует документация , отражающая постановку задачи , имеются спецификации и ведомости, а также материалы , относящиеся к испытаниям программ. Целесообразно данную метрику для оценки качества прежде всего эксплуатационной документации , исключая формуляр и ведомость эксплуатационных документов. Отдельно оценивается техническое задание с пояснительной запиской и описанием программы остальные документы чаще всего отражают изменения в перечисленных документах или неявно вызывают эти изменения. Представляет интерес сам подход , дающий возможность оценивать динамику характеристик . Ведь, если вместо текущей длины документа использовать какую-либо иную характеристику, например длину программы , то все исходные предпосылки останутся в силе. Измеряя в определенные моменты времени значение исследуемой характеристики , мы можем делать выводы о ее динамке. По этим данным , выявляя резкие скачки в переходном процессе , можно судить о потере стабильности используемого ПО и о целесообразности его проектирования заново . Возможность перехода от статических оценок к динамическим в области конструктивных характеристик качества программ представляет большой интерес . Метрики использования языков программирования и технологических средств На качество ПИ влияют средства автоматизации программирования и форма организации работ по созданию программ . Это проявляется в двух направлениях : относительно уровня автоматизации работ по программированию с помощью данного средства автоматизации относительно использования данного конкретного средства создания программ При этом первое направление характеризует качество собственно технологических программных средств, а второе - степень перенесения этого качества на итоговые ПИ . Для оценки языка программирования издавна существовало понятие уровня языка. Однако оно могло иметь только относительное значение , поскольку отсутствовал абсолютный показатель. Такой измеритель был предложен Холстедом. Холстед в своем понимании уровня языка опирается на понятия заложение им в такие метрические характеристики программ как , уровень программы и объем программы. По аналогии с высказыванием , согласно которому уровень программы реализуемой конкретным алгоритмом , не зависит от используемого языка программирования, Холстед утверждает , что изменение алгоритма при кодировании на одном и том же языке , в одинаковой степени увеличивая потенциальный объем программы , снижает ее уровень. На этом основании была выведена гипотеза о постоянстве для каждого языка программирования выражения : LV’ , где - оценка уровня языка ; L - уровень программы ; V’- потенциальный объем программы ; Учитывая L=V’/V, можно записать: L²V , это выражение Холстед использует для вычисления уровня языка. На основании статистического материала им установлены следующие значения уровня для некоторых языков :
Так как характеристика уровня языка программирования вычисляется на основе объема программ (количества логических бит для описания задачи), можно сделать вывод что среднее значение характеризует сравнительную сложность программирования на разных языках , а отклонениеx для конкретной программой от ее среднего значения для данного языка программирования показывает качество использования языковых средств. Преобразуем формулу LV’ ,на основании соотношения L²V к виду: V’²/V, где - оценка уровня языка; V’- потенциальный объем программы; V - объем программы. Постоянство определяется синхронным изменением объема программы при изменении ее потенциального объема. Иными словами, увеличение объема программы должно быть на два порядка больше увеличения количества информации по внешним связям. Следовательно, алгоритмически сложные программы вычисления единичных значений переменных будут давать значительно более низкое значение чем программы вычисления большого объема информации по элементарным соотношениям. Если программ использует только стандартные конструкции языка и не связана с созданием управляющих структур (развилок и циклов), уровень языка такой программы будет значительно выше среднестатистического. Таким образом, предлагаемая М. Холстедом метрическая характеристика сильно зависит от уровня программы и ее специфики. Поэтому трактовать эту метрику следует как уровень языка программирования в контексте области применения, т.е. определять среднее значение уровня языка на основании статистических данных по программам конкретной предметной области. Только при сравнении со средним значением уровня языка можно сделать вывод о применимости языка программирования к реализации программ данной проблемной области, с одной стороны, и об уровне использования языковых средств - с другой. Оба вывода должны делаться на основании локальных средних значений для типологических рядов программ. Для определения количества ошибок Холстед вывел формулу: 2/3 В=E / 3000 = V/3000 где В - количество ошибок после реализации программы на языке программирования; Е - интеллектуальные усилия при программировании; V - объем программы; 3000 - критический уровень работы по составлению программы. Появление в языках программирования средств семантического контроля программы, таких, как пользовательские типы данных и операторов, потребовало изменения эффективности этих средств. Основным понятием при решении этой задачи является эффект программы. Дефект программы представляет собой такое искажение текста программы по сравнению с эталонной, которое не обнаруживается при компиляции, но существенно влияет на исход выполнения программы. Следует отметить, что дефект может быть и не обнаружен при выполнении программы на определенном множестве исходных данных. Поэтому автор метрики С.В. Денисенко вводит понятие множества всех потенциальных дефектов программы D и числа этих дефектов I. Выдвигается гипотеза, согласно которой количество ошибок в программе прямо пропорционально I. Тогда для какого-либо средства статистического семантического контроля можно вычислить показатель его эффективности: R1 d1 g = ------- = -------, R2 d2 где R1 - количество ошибок в программе, полученной без использования данного средства; R2 - количество ошибок в программе, полученной с использованием данного средства; d1 - количество возможных дефектов в программе, полученной без использования данного средства; d2 - количество возможных дефектов в программе, полученной с использованием данного средства. Теперь необходимо количественно оценить d1 и d2. Денисенко предлагает в качестве примера оценку эффективности контроля соответствия типов данных по всему тексту программы и ограничения области доступности переменных программы при переходе от блочной структуры к модульной. При оценке количества возможных дефектов, возникающих в тексте программы, оцениваются все случаи замены операторов и типов, приводящих к изменению смысла алгоритма. Количество дефектов для средств контроля типов данных определяется как d = d + d + d , тип т N1 N2 где d - количество дефектов от возможной замены типов данных; т d - количество дефектов от возможной замены кодов операндов; N1 d - количество дефектов от возможной замены кодов операндов; N2 Таким образом, взяв за базу сравнения полное отсутствие контроля типов данных, эффективность средства контроля типов данных можно оценить по формуле d T(T-1) + N1(1-1) + N2(2-1) g = -------- = Т ------------------------------ тип d N1(1-T) + N2(2-T) тип где T - число типов данных; N1 - число операторов; 1 - словарь операторов; N2 - число операндов; - словарь операндов; В качестве второго оцениваемого средства контроля Денисенко выдвигает ограничения доступности переменных программ путем применения модульной структуры со связью модулей через параметры. Количество возможных дефектов при использовании обычной блочной структуры, свойственной таким языкам, как алгол, паскаль, пл/1, увеличивается по сравнению с модульной структурой за счет возможного обращения к доступной, но не определенным по спецификации связи блоков переменным. Эта характеристика может быть вычислена как: dбл=dт+ dN1+ dN2+ N2nсв, где ncd- число внешних переменных, доступных, но не используемых в рассматриваемом блоке в соответствие с его спецификой. Тогда эффективность модульной реализации комплекса программ по сравнению с блочной реализацией определяется как  Анализ метрик позволяет сделать вывод о том, что оценка языков и технологий программирования в настоящее время проводится не на основе оценки синтаксиса и состава включенных средств, а на основе пригодности этих задач, точнее, на основе вариантов реализации задач с помощью данного средства программирования. Понятно, что именно эти характеристики наиболее ценны для практики. Жизненный цикл программного изделия. Сущность развития ПИ во времени отражает объективная экономическая категория «цикл жизни». Предпосылкой для введения этой категории в сферу программных разработок послужило определение ПИ как изделия, имеющего самостоятельное значение, процессы проектирования и изготовления которого аналогичны процессам связанным с производством (изготовлением). Как и любое изделие, Пи имеет свой цикл жизни, т.е. интервал времени от начального момента возникновения объективной необходимости в ПИ до момента изъятия его из эксплуатации. Следует подчеркнуть, что жизненный цикл ПИ заканчивается в результате его морального, а не физического износа (что типично для промышленных изделий). В свою очередь, говорят что ПИ морально устарело, если оно перестает удовлетворять актуальным требованиям, а дальнейшая его модификация не представляется возможной или не выгодна, что влечет за собой необходимость в разработке нового ПИ. В результате анализа проблем, требующих решения в процессе создания, изучения опыта разработок и использования различных ПИ было установлено, что независимо от специфических условий, видов и требований к конкретным ПИ можно выделить некоторую типовую последовательность этапов разработки и функционирования ПИ. В общем виде за период своего жизненного цикла ПИ проходит 3 фазы: разработку, использование, сопровождение. Фаза разработки начинается с анализа осуществимости проекта, а далее путем последовательной трансформации преобразования от требований пользователя в форму, доступную для реализации на ЭВМ. К тому же на протяжении всей фазы закладываются основные характеристики качества будущего ПИ, которые проявляются на стадии его эксплуатации. На эту фазу приходятся, как правило, 50% стоимости ПИ и 32% трудозатрат. Фаза использования начинается тогда, когда изделие передается пользователю, находится в действии и используется эффективно. В фазе использования обычно выполняются обучение персонала, внедрение, настройка, сопровождение и, возможно, расширение ПИ. Фазу сопровождения также называют фазой продолжающейся разработки. Практиками признано, что часть жизненного цикла(ЖЦ) должна приниматься во внимание с момента начала разработки с целью совершенствования ПИ в соответствии с потребностями пользователя. Процесс сопровождения, продолжающийся параллельно собственно эксплуатации ПИ, практически в течении всего времени его использования состоит из выявления и устранения ошибок в программах и изучения из функциональных возможностей. Структура трудозатрат на различные виды деятельности по сопровождению такова, что на изменение функциональных возможностей ПИ уходит около 78% времени, а на выявление ошибок –17%. Ж.Ц. ПИ образует 4 основные стадии. 1.Исследование и проектирование. Изучение и анализ существующих ПИ, документирование; анализ осуществимости; определение и спецификация требований к новому ПИ: концептуальное проектирование ПИ. 2.Реализация. Детализация проекта кодирование, тестирование, установление эксплуатационных процедур. 3.Внедрение (сдача) в опытную эксплуатацию. Приемочные тесты, обучение пользователей. 4.Эксплуатация и сопровождение. Периодические процедуры обработки информации, рабочие прогоны программ, измерение производительности и других характеристик ПИ, сопровождение и модификация по мере появления новых требований. Начальные этапы определяют качество проекта и успех разработки программных средств в целом. Для начальных этапов разработки ПС типичны ситуации; выявление и четкое формулирование проблемы в условиях значительной неопределенности; выбор стратегии исследования и разработок; точное определение ПИ как системы (границы, выходы, набор компонентов); выявление целей развития и функционирования ПИ; выявление функций и состава вновь создаваемого ПИ. В силу значимости фазы разработки в ЖЦ ПИ рассмотрим подробнее содержание отдельных ее этапов. В укрупненном виде жизненный цикл ПИ можно представить состоящим из следующих этапов: определение требований к системе; определение требований к ПО; предварительное проектирование; кодирование и отладка; тестирование ПИ и системы; эксплуатация и сопровождение. Исходным этапом создания и является этап разработки требований, в процессе которого проводятся поисковые, исследовательские работы, формируется комплекс требований выражающий потребности пользователя в конкретном ПИ. На данном этапе будущий комплекс программы тщательно анализируется с учетом выполняемых им функций и основных свойств, обосновывается целесообразность их разработки, предварительно оцениваются трудовые и стоимостные затраты и сроки создания, вырабатываются рекомендации по выбору инструментальных средств и методов, которые предполагается использовать в процессе разработки программ. Обязательным в содержании данного этапа является также формирование требований к качеству программ в соответствии с условиями их функционирования и реализации конкретных функций. Выполнение этих работ в процессе формирования требований и формирование необходимых эксплуатационных свойств в ПИ на данном и последующих этапах их разработки позволяет, предотвратить дополнительные расходы, вызванные модификацией программ при их внедрении и сопровождении. Следующим этапом в процессе создания программ является этап проектирования, в процессе которого требования пользователей формируются в более точном и конкретном виде. Проектирование программ охватывает комплекс работ по разработке структуры программ и их компонентов; выбору языка программирования и конкретной конфигурации комплекса технических средств, на котором предполагается реализация разрабатываемых программ. В процессе проектирования решается задача выбора оптимальной структуры программ, определяющая содержание и характер работ на последующих этапах разработки. На данном этапе качество ПИ обеспечивается конкретными решениями и зависит в основном от организации управления разработкой, квалификации специалистов, использования прогрессивных методов, приемов, правил и средств проектирования программ. После проектирования программ следует их кодирование. На практике эти этапы, как правило, частично перекрываются, т.е. за проектированием отдельных модулей выполняется их программирование, а затем, возможно, и предварительная проверка правильности функционирования разработанного модуля. Программирование характеризуется большим числом разнообразных правил, приемов, методов и средств его выполнения, применение которых зависит от квалификации, опыта и индивидуальных особенностей программистов. Этот этап наиболее автоматизирован в процессе разработки ПИ. В настоящее время существуют десятки языков программирования и средств автоматизации, облегчающих труд программистов и повышающих его производительность, а также создающие предпосылки унификации и стандартизации процесса создания ПИ. К тому же использование современных приемов программирования, средств автоматизации, проведения различных видов проверок и контроля программирования способствует предотвращению и выявлению значительного числа ошибок, что сокращает время и расходы на этапе отладки и тестирования программ, повышает их качество. Этап отладки и тестирования программ, следующий за этапом программирования, имеет целью выявление и устранение ошибок в них, а так же определению, в како мере разработанные программы удовлетворяют требованиям, сформированным в спецификациях. Работы по отладке и тестированию программ характеризуются большой степенью повторяемости и являются наиболее утомительными и дорогостоящими. В связи с этим уделяется большое внимание разработке и использованию различных системных и инструментальных средств, автоматизирующих выполнение работ на данном этапе, что позволяет повысить качество разрабатываемых программ и снизить Трудоемкость их создания. По оценкам специалистов на отладку и тестирование программ затрачивается до половины общих средств на разработку программ, что тем не менее не исключает наличие в них ошибок. В связи с тем, что каждая из названных стадий может быть представлена различным набором составляющих ее этапов, в настоящее время существует значительное количество моделей жизненного цикла. Разнообразие моделей с теоретической точки зрения объясняется тем, что термин «Жизненный цикл», тождественен методу жизненного цикла, а сам метод включает: идентификацию количества фаз (этапов) с указанием результатов, получаемых на каждом из них; определение числа функций и видов работ, которые должны быть выполнены на каждой фазе. отображение результатов этапов разработки, т.е. подготовка документации, которая должна быть выдана в конце каждой фазы. С практической точки зрения отсутствие в использовании единой модели объясняется тем, что ЖЦ моделируется либо порождается под воздействием определенной внешней среды, а не наоборот. К основным объектам формирующим внешнюю среду, относят организационно-технологические условия разработки ПИ; условия их сопровождения и эксплуатации; технические условия; структуру и режим использования ПИ; опыт и организацию коллектива разработчиков; класс решаемых задач с учетом их типа и прикладной области, и наконец, количество этапов и их наполнение в ЖЦ зависят от выделенных ресурсов (временных, трудовых, стоимостных). Обратим внимание, что во всех приведенных вариантах схем ЖЦ не выделен момент (что является очевидным и необходимым для промышленных изделий) их изготовления (тиражирования). Это можно объяснить двумя причинами: Невозможность разделить во времени и пространстве процесс разработки и собственно производства ПС. ПС, как уже отмечалось, не имеет физического износа. Обладая свойством фиксироваться на различных носителях, ПС не теряет и не меняет при этом свое содержание. Это особенность позволяет организовать их тиражирование и многократное применение с минимальными техническими и временными затратами. ОСНОВНАЯ ЛИТЕРАТУРА Уилсон С.Ф., Мэйплс Б., Лэндгрейв Т. Принципы проектирования и разработки программного обеспечения: Учебный курс MCSD. - М.: Рус. Редакция, 2002. Леффингуэлл Д., Уилдриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. - М.: Вильямс, 2002. Орлов С.А. Технологии разработки программного обеспечения: Разработка сложных программных систем: Учебное пособие. - СПб.: Питер , 2002. Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование. - М.: Вильямс, 2002. Кинг Д. Создание эффективного программного обеспечения. - М.: Мир, 1991. Фокс Д. Программное обеспечение и его разработка. - М.: Мир, 1985. Жаркова Г. А. Современные системы автоматизации разработки информационных систем: учебно-методическое пособие. - Ульяновск: УлГУ, 2007. СПЕЦИАЛЬНАЯ ЛИТЕРАТУРА Жаркова Г. А. Программирование на языке С++: учебное пособие для вузов. - Ульяновск: УлГУ, 2009. Липаев В.В., Потапов А.И. Оценка затрат на разработку программных средств. - М.: Финансы и статистика, 1988. Дружественное программное обеспечение: сборник под редакцией Васильева Б.М. - М.: Знание, 1989. (Новое в жизни, науке, технике. Вычислительная техника и ее применение. 3/1989). Гласс Р., Нуазо Р. Сопровождение программного обеспечения. - М.: Мир, 1983. Защита программного обеспечения: под редакцией Д. Гроувера. - М.: Мир, 1992. Б. Боэм Характеристики качества программного обеспечения. - М.: Мир, 1981. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения: анализ крупномасштабных разработок. - М.: Мир, 1981. |