Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей . Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть, прежде всего, фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС принято считать :
функциональность,
надёжность,
лёгкость применения,
эффективность,
сопровождаемость,
мобильность.
Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.
Надежность подробно обсуждалась в первой лекции.
Лёгкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определённого или подразумеваемого пользователя.
Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нём ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надёжность являются обязательными критериями качества ПС, причём обеспечение надёжности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС - их обеспечение будет обсуждаться в подходящих разделах курса.
Рассмотрим теперь общие принципы обеспечения надёжности ПС, что, как мы уже подчёркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности :
предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах, в нашем случае - в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
борьбе со сложностью;
обеспечении точности перевода;
преодоления барьера между пользователем и разработчиком;
обеспечения контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к её усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.
Методология разработки программного обеспечения
Электронное пособие Карпович Е.Е.
Введение. 1
1. Программное обеспечение как промышленная продукция. 2
1.1 Основные понятия. 2
1.2. Характеристики качества программного обеспечения. 3
2. Жизненный цикл программного обеспечения. 5
2.1. Понятие жизненного цикла программного обеспечения. 5
2.2. Процессы жизненного цикла программного обеспечения. 6
2.3. Модели жизненного цикла программного обеспечения. 11
2.4. Стратегии проектирования программного обеспечения. 15
3. Методологии разработки программного обеспечения. 19
3.1 Структурный подход к разработке программного обеспечения. 19
3.2 Модульное программирование. 22
3.3. Объектно-ориентированный подход к разработке программного обеспечения. 31
3.3. Методология визуального программирования. 33
4. Тестирование программного обеспечения. 34
4.1. Общие положения. 34
4.2. Цели и задачи. Основные определения. 34
4.3. Организация процесса тестирования программного обеспечения 35
4.4. Стратегии тестирования программного обеспечения. 36
4.5. Уровни тестирования программного обеспечения. 38
5. Документирование программного обеспечения. 39
5.1. Общие положения. 39
5.2. Программа и методика испытаний. 39
5.3. Описание программы.. 40
5.4. Пояснительная записка. 41
5.5. Текст программы.. 42
5.6. Описание применения. 42
5.7. Руководство системного программиста. 42
5.8. Руководство программиста. 43
5.9. Руководство оператора. 43
Литература. 44
Введение
Программное обеспечение (ПО) вычислительных систем (ВС) становится все более значительным, сложным и опасным и его все труднее разрабатывать, но в то же время ПО все время упрощается, уменьшается в размерах, все легче поддается управлению и его все легче разрабатывать.
С одной стороны, возрастают требования к программному обеспечению, связанные с усовершенствованием и усложнением операционных систем, аппаратных средств и интерфейса пользователя и с необходимостью внедрения современных информационных технологий, в первую очередь, сетевых. Внутреннее устройство программ в связи с этим становится все более сложным, и возрастают требования к их надежности.
С другой стороны, накапливается и обобщается опыт разработки ПО, появляются все более гибкие и мощные методологии и средства, поддерживающие все этапы разработки ПО. Развивается методология визуального программирования и совершенствуются языки программирования. Совершенствование аппаратных средств ускоряет процессы компиляции, а также позволяет зачастую не беспокоиться об эффективности создаваемых программ.
Цель дисциплины «Методология разработки программного обеспечения» – научить студентов основным принципам конструирования программного обеспечения, ознакомить с концепциями, методологиями разработки, тестирования и документирования программного обеспечения.
Программное обеспечение как промышленная продукция
Основные понятия
Принято выделять семь видов обеспечения вычислительных систем:
· математическое;
· лингвистическое;
· информационное;
· программное;
· техническое;
· методическое;
· организационное.
Из всех видов обеспечении программное обеспечение (ПО) занимает особое место, поскольку основная доля затрат на оснащение и эксплуатацию ВС приходится именно на ПО. Определим такие основные понятия, как программа, программный комплекс, программная система, программный продукт и программное обеспечение.
Под программой будем понимать:
1) совокупность кода и данных, пригодных для исполнения процессорам (исполняемая программа);
2) самостоятельный компонент относительно небольшого размера, предназначенный для решения локальной задачи (программа как компонент системы).
Программный комплекс или программная система - это совокупность согласованно работающих программ под общим управлением, предназначенная для решения сложной задачи или ряда взаимосвязанных задач.
Прошедший испытания программный комплекс, полностью готовый для продажи (поставки) и снабженный всей необходимой документацией, называется программным продуктам (изделием) или программным средством.
Программное обеспечение - наиболее общее понятие, под которым понимают программы, программные системы или продукты в совокупности или по отдельности, в зависимости от контекста использования этого термина.
Будем условно делить программные продукты на небольшие, средние и крупные. Объем исходного текста небольших программ составляет несколько сот операторов языка высокого уровня, средних - до десятков тысяч и крупных - до миллиона.
Во многих случаях программы создаются в единственном экземпляре для решения частных исследовательских задач, для ускорения вычислений, моделирования процессов и т.д. Такие программы не имеют массового применения и доступны только тем, кто их разработал. Они являются объектами научно-технического творчества и только в исключительных случаях становятся промышленными изделиями.
Совершенно иным классом программ являются полновесные программные средства, которые в настоящее время принято квалифицировать как продукцию производственно-технического назначения. В этом качестве программные продукты являются непосредственной производительной силой и не отличаются от любой другой промышленной продукции.
Создание хорошего программного продукта является весьма трудоемкой задачей, решение которой, как правило, не под силу одному человеку. Программисты-одиночки (“хакеры”) могут обладать гениальным даром к быстрой алгоритмизации и кодированию нетривиальных задач, созданию новых методов и идей программирования, приобретая при этом значительную известность. Однако не в их силах в одиночку решать весь комплекс проблем разработки средних и крупных программных продуктов за приемлемые сроки.
Таким образом, в настоящее время сколько-нибудь значимые продукты создаются коллективами программистов. В таких коллективах в программисте-разработчике ценятся такие качества, как грамотность, дисциплинированность, надежность и коммуникабельность. Под грамотностью понимается знание и понимание передовых методов и средств разработки ПО, их назначения и особенностей, а также умение применять эти знания на практике.
Характеристики качества программного обеспечения
Совокупность свойств ПО, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПО, т.е. от позиции, с которой должно рассматриваться качество этого ПО. Поэтому при описании качества ПО, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПО. В настоящее время критериями качества ПО (criteria of software quality) принято считать:
Функциональность;
Надежность;
Легкость применения;
Эффективность;
Сопровождаемость;
Мобильность.
Функциональность - это способность ПО выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПО.
Надежность (reliability) ПО - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. При этом под отказом в ПО понимают проявление в нем ошибки. Таким образом, надежное ПО не исключает наличия в нем ошибок - важно лишь, чтобы эти ошибки при практическом применении этого ПО в заданных условиях проявлялись достаточно редко. Убедиться, что ПО обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПО.
При оценке степени надежности ПО следует также учитывать последствия каждого отказа. Некоторые ошибки в ПО могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПО иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.
Легкость применения - это характеристики ПО, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПО и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.
Эффективность - это отношение уровня услуг, предоставляемых ПО пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость - это характеристики ПО, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность - это способность ПО быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надежность являются обязательными критериями качества ПО, причем обеспечение надежности будет красной нитью проходить по всем этапам и процессам разработки ПО. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПО. Для конкретизации качества ПО по каждому из критериев используется стандартизованный набор достаточно простых свойств ПО, однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПО . Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПО.
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость, защищенность.
Легкость применения: П-документированность, информативность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость.
Изучаемость - это характеристики ПО, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПО.
Модифицируемость - это характеристики ПО, которые позволяют автоматически настраивать на условия применения ПО или упрощают внесение в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность.
Ниже даются определения используемых примитивов качества ПО.
Завершенность (completeness) - свойство, характеризующее степень обладания ПО всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность (accuracy) - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПО результатах с точки зрения предполагаемого их использования.
Автономность (self-containedness) - свойство, характеризующее способность ПО выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость (robustness) - свойство, характеризующее способность ПО продолжать корректное функционирование, несмотря на неправильные (ошибочные) входные данные.
Защищенность (defensiveness) - свойство, характеризующее способность ПО противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
П-документированность (u. documentation) - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПО.
Информативность (accountability) - свойство, характеризующее наличие в составе ПО информации, необходимой и достаточной для понимания назначения ПО, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.
Коммуникабельность (communicativeness) - свойство, характеризующее степень, в которой ПО облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием.
Временнáя эффективность (time efficiency) - мера, характеризующая способность ПО выполнять возложенные на него функции в течение определенного отрезка времени.
Эффективность по ресурсам (resource efficiency) - мера, характеризующая способность ПО выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency) - мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
С-документировапнность (documentation) - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПО и результаты различных этапов разработки данной ПО, включающие возможности, ограничения и другие черты ПО, а также их обоснование.
Понятность (understandability) - свойство, характеризующее степень, в которой ПО позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации.
Структурированность (structuredness) - свойство, характеризующее программы ПО с точки зрения организации взаимосвязанных их частей в единое целое определенным образом (например, в соответствии с принципами структурного программирования).
Удобочитаемость (readability) - свойство, характеризующее легкость восприятия текста программ ПО (отступы, фрагментация, форматированность).
Расширяемость (augmentability) - свойство, характеризующее способность ПО к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент.
Модифицируемость (modifiability) - мера, характеризующая ПО с точки зрения простоты внесения необходимых изменений и доработок на всех этапах и стадиях жизненного цикла ПО.
Модульность (modularity) - свойство, характеризующее ПО с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств (device independence) - свойство, характеризующее способность ПО работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).
Разработка программного средства завершается его аттестацией. Аттестация программного средства- это авторитетное подтверждение его качества. Как правило, для аттестации создается комиссия экспертов. Эта комиссия проводит приемо-сдаточные испытания программного средства с целью получения необходимой информации для оценки его качества. При этом оцениваются только установленные критерии качества и примитивы качества.
Подходы к качеству программного обеспечения
Проведем классификацию различных подходов к качеству программного обеспечения, используя два измерения .
Первое измерение ориентировано либо на продукт, либо на процесс. Для повышения качества программного обеспечения можно сосредоточиться на качестве самого продукта, например, делая его более дружественным пользователю. Альтернативный подход заключается в совершенствовании процесса разработки, предполагая при этом, что чем лучше процесс, тем лучше качество программного обеспечения.
Второе измерение связано либо с соответствием, либо с усовершенствованием. Под соответствием будем понимать соответствие какому-либо стандарту. Усовершенствование имеет своей целью переход на более совершенные методы и лучшую практику для повышения качества.
ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик;
"усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;
ISO 9000 - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" ;
методы усовершенствования процесса разработки программного обеспечения предлагают некоторую шкалу уровней и требования соответствия, согласно которым можно определить место компьютерной компании на этой шкале. Наиболее известны и популярны два метода:
модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);
определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).
Два важнейших утверждения лежат в основе достижения качества.
Подходы к достижению качества таковы:
Характеристики качества программного обеспечения
В настоящее время не существует общепринятых критериев качества программного обеспечения.
Стандарт ISO 9000-3, п. 6.4.1
Классическое определение качества заключается в том, что разработанный программный продукт подтверждает свою спецификацию, при этом спецификация должна быть ориентирована на характеристики, которые желает получить клиент.
Современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Перечислим ряд таких характеристик [Жоголев 1996].
Функциональность (пригодность, точность, интероперабельность, согласованность, безопасность). Функциональность - это способность программного продукта выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор таких функций определяется во внешнем описании программного продукта.
Надежность (завершенность, устойчивость, восстанавливаемость).
Удобство (понимаемость, эффективность освоения, эргономичность). Удобство - это характеристики программного продукта, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.
Эффективность (по времени и по ресурсам). Эффективность - это отношение уровня услуг, предоставляемых программным продуктом пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемостъ (простота анализа, изменяемость, стабильность, проверяемость). Сопровождаемость - это характеристики программного продукта, позволяющие минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Переносимость (адаптируемость, гибкость инсталляции, согласованность со стандартами и правилами, заменяемость). Переносимость - это способность программного продукта быть перенесенным из одной среды в другую, в частности, с одной аппаратной архитектуры на другую.
Добротность (рациональная организация, продуманность). Две наиболее интересные характеристики рассмотрим подробнее.
Надежность - это способность программы безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. Надежный программный продукт не исключает наличия в нем ошибок. Здесь важно, чтобы ошибки при практическом применении в заданных условиях проявлялись достаточно редко. Степень надежности характеризуется вероятностью работы программного продукта без отказа в течение определенного периода времени.
Существуют следующие подходы по обеспечению надежности:
Добротность программы заключается в том, что программа разумно и рационально организована, с достаточно продуманной организацией потоков управления и информационных потоков, не слишком переусложнена. Понятие добротности введено Поттосиным [Поттосин 1997] для оценки внутренних достоинств реализации программы с технической стороны. Поттосин вводит четыре класса критериев добротности программ.
Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик.
Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.
Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.
Оценка модульного разбиения программы. Такая оценка должна состоять из множества критериев. Например, сложность модуля оценивается совокупностью сложности определяемых в нем процедур и сложности связей модуля с другими модулями по импорту и экспорту определяемых сущностей.
Генетические критерии, связанные с происхождением программы и дисциплиной ее создания.
Структурные критерии, связанные с оценкой организации управления в программе и отражением организации управления в программном тексте.
Прагматические критерии, связанные с оценкой того, насколько программный текст соответствует цели программы. Формулируется список излишеств, которых не должно быть в добротных программах, например - вычислительной избыточности.
Оценка качества процесса разработки
Требовать и эффективности и гибкости от одной и той же программы -
все равно, что искать очаровательную и скромную жену.
По-видимому, нам следует остановиться на чем-то одном из двух.
Д. Вейнберг
В начале данного раздела мы отметили, что существует два подхода, которые могут применяться для оценки качества программного продукта.
Оценить качество конечного продукта можно тестированием и эксплуатацией. На это должно быть отведено время после завершения основной работы над программой. А вот второй подход должен стать частью долговременной стратегии компании.
Модель зрелости процесса разработки программного обеспечения
В модели определено пять уровней зрелости организации (http://www.sei.cmu.edu/cmm).
Начальный уровень. На этом уровне процесс разработки характеризуется практическим отсутствием процессов управления. Успех проекта зависит от индивидуальных усилий, личных качеств и даже героизма участников проекта.
Повторяемый уровень. На этом уровне зрелости в компании должны быть внедрены основные процессы управления для отслеживания стоимости, графика проекта и его функциональности. Уровень характеризуется тем, что управление проектами основывается на накопленном опыте и ранее достигнутые успехи будут повторены на подобных приложениях.
Определенный уровень. Процесс разработки программного обеспечения (как на уровне управленческой, так и инженерной деятельности) документирован, стандартизован и интегрирован на уровне всей организации. Процесс перестает зависеть от индивидуальных качеств отдельных разработчиков и не может скатиться на более низкие уровни в кризисных ситуациях.
Управляемый уровень. В компании устанавливаются детальные количественные показатели на процесс разработки и качество продукта. И процесс разработки, и продукты - понимаемы и контролируемы.
Оптимизирующий уровень. Продолжающееся совершенствование процесса разработки на основе анализа текущих результатов процесса и применения инновационных идей и технологий.
Определение возможностей и улучшение процесса создания программного обеспечения
Данная модель очень близка к модели зрелости, но уровни возможностей могут быть применены не только к организации в целом, но и к отдельно взятым процессам. Модели такого типа часто называют непрерывными. В непрерывных моделях один процесс может находиться на низком уровне зрелости, а другой - на высоком уровне. Стандарт определяет шесть уровней зрелости процесса.
Уровень 0. Процесс не выполняется.
Уровень 1. Выполняемый процесс.
Уровень 2. Управляемый процесс.
Уровень 3. Установленный процесс.
Уровень 4. Предсказуемый процесс.
Уровень 5. Оптимизирующий процесс.
Во время оценки и улучшения качества процессов выполняются задачи [Терехов, Туньон 1999], описанные ниже.
Сравнение процесса разработки программного обеспечения, существующего в данной организации, с описанной в стандарте моделью. Анализ результатов дает возможность определить сильные и слабые стороны процесса, его внутренние риски.
Оценка возможности улучшения данного процесса на основе определения текущих возможностей.
Техническая реализация поставленных задач на основе сформулированных целей совершенствования процесса. После этого весь цикл работ начинается сначала.
О роли министерства обороны
Заметим, что исторически модели оценки качества процесса разработки создавались с целью получения обоснованных процедур оценки и последующего развития технологических процессов в тех организациях, которые претендуют на получение заказов по разработке проектов, имеющих оборонное значение. Модели применимы к компаниям, разрабатывающим сложные и работающие в режиме реального времени системы. Это системы с длительным временем жизненного цикла, где дефекты в программном обеспечении могут иметь критическое значение.
"Достаточно хорошее" программное обеспечение
Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии
новой программы компании Microsoft произошло землетрясение.
Пользователи с ужасом ждут объявления о выходе финальной версии продукта.
Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.
Оказывается, что даже "достаточно хорошее" программное обеспечение создать сложно. Приведем часть из совокупности причин, дающих этому объяснение [Йордон 2001].
Часто качество стремятся определить только в терминах дефектов (ошибок). С точки зрения пользователя не менее важны такие стороны, как готовность к определенной дате.
Предполагается, что малое количество ошибок равносильно лучшему качеству, и пользователь предпочитает именно такое качество. Однако иногда пользователь готов идти на компромиссы и примириться с некоторыми ошибками в обмен на более скорое выполнение работы.
Игнорирование таких факторов, как моральное состояние команды разработчиков и адекватные условия для работы.
Джеймс Бах (James Bach) указывает следующие необходимые условия для создания "достаточно хорошего" программного обеспечения:
К сожалению, "достаточно хорошее" программное обеспечение редко бывает действительно достаточно хорошим. Никлаус Вирт отмечает, что это "следствие грустного проявления духа нашего времени, в котором исчезает личная гордость за свою работу". По его мнению, "нельзя ожидать качественно выполненной работы, если не отдавать ей себя полностью, если нет личного удовлетворения, более того - удовольствия от нее".
Интересное наблюдение, заключающееся в том, что некоторые компании стремятся к понижению интеллектуального уровня пользователей своей продукции, сделано многими программистами. Компаниям чрезвычайно выгодно иметь дело с людьми, техническая квалификация которых не позволяет определить реальные аспекты (например, качество, сложность, ценность) программного продукта. Прикрываясь "упрощением" работы и повышением доступности компьютеров для пользователей, компании многократно перегружают и усложняют программное обеспечение таким образом, чтобы пользователю было крайне трудно понять - каким образом оно работает на самом деле и стать профессионалом.
Стандартизация информационных технологий
Стандарт - общепринятое определение компонента технических или программных средств, являющихся результатом соглашения. Профиль - набор юридических и/или фактических стандартов, ориентированных на выполнение конкретной задачи [Козлов 1999].
Стандарты можно классифицировать следующим образом:
Процесс стандартизации информационных технологий поддерживают три основные группы организаций. Международные организации, входящие в структуру ООН. International Organization for Standardization (ISO) - международная организация по стандартизации.
Об ISO
В 1947 году представители 25 стран решили создать организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). Несоответствие полного названия и аббревиатуры объясняется тем, что "ISO" - это греческий префикс, означающий "равный".
International Electrotechnical Commision (IEC) - международная электротехническая комиссия.
International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.
Промышленные профессиональные или административные организации.
Institute of Electrical and Electronic Engineers (IEEE) - институтинженеровпоэлектротехникеиэлектронике.
Internet Activity Board (IAB) - совет управления деятельностью Интернета.
Промышленные консорциумы.
Object Management Group (OMG) - группа управления объектами.
Х/Open - консорциум, организованный группой поставщиков компьютерной техники.
Open Software Foundation (OSF) - фонд открытого программного обеспечения.
В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий.
Ка́чество програ́ммного обеспечения - характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001 , согласно которому качество есть «степень соответствия присущих характеристик требованиям».
Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода , определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность - степень логического разбиения кода на ряд управляемых блоков.
Методы улучшения качества кода: рефакторинг .
Фактор качества ПО - это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества:
Понятность Назначение ПО должно быть понятным, из самой программы и документации. полнота Все необходимые части программы должны быть представлены и полностью реализованы. краткость Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации. портируемость Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии. согласованность По всей программе и в документации должны использоваться одни и те же соглашения, форматы и обозначения. сопровождаемость Насколько сложно изменить программу для удовлетворения новых требований. Это требование также указывает, что программа должна быть хорошо документирована, не слишком запутана, и иметь резерв роста по использованию ресурсов (память, процессор). тестируемость Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности. удобство использования Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя. надёжность отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок: структурированность эффективность Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач. безопасность
Помимо технического взгляда на качество ПО, существует и оценка качества с позиции пользователя. Для этого аспекта качества иногда используют термин «юзабилити ». Довольно сложно получить оценку юзабилити для заданного программного продукта. Наиболее важные из вопросов, влияющий на оценку:
| Известные деятели |
|
|---|---|
| Процесс | |
| Концепции | |
| Направления | |
| Модели разработки |
|
| Другие модели | |
| Прочее | |
Wikimedia Foundation . 2010 .
Качество программного обеспечения - способность программного продукта подтвердить свою спецификацию при условии, что спецификация ориентирована на характеристики, которые желает получить пользователь. См. также: Качество программного обеспечения Программное обеспечение Финансовый… … Финансовый словарь
Разработка программного обеспечения - Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Тестирование программного обеспечения - Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия
Производитель программного обеспечения - Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
Кризис программного обеспечения - «Кризис программного обеспечения» термин, некогда использовавшийся в информатике для описания последствий быстрого роста вычислительной мощности компьютеров и сложности проблем, которые могут быть решены с их помощью. В сущности, это… … Википедия
Инженерия программного обеспечения - Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
Мобильность программного обеспечения - способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем. Синонимы: Переносимость программного обеспечения См. также: Качество программного обеспечения Открытые системы… … Финансовый словарь
Удобство программного обеспечения - характеристики программного продукта, которые: позволяют минимизировать усилия пользователей по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также позволяют вызывать положительные эмоции… … Финансовый словарь
Сопровождаемость программного обеспечения - характеристики программного продукта, позволяющие минимизировать усилия по внесению в него изменений: для устранения ошибок; или для модификации в соответствии с изменяющимися потребностями пользователей. См. также: Качество программного… … Финансовый словарь
Функциональность программного обеспечения - способность программного продукта выполнять набор функций: определенных в его внешнем описании; и удовлетворяющих заданным или подразумеваемым потребностям пользователей. Синонимы: Интероперабельность программного обеспечения См. также: Качество… … Финансовый словарь
Аннотация: Рассматриваются характеристики качества программных продуктов. Отмечается, что вопросы качества должны решаться на протяжении всего жизненного цикла. Показано, тестирование программного продукта позволяет гарантировать заданные параметры качества. Рассматриваются различные типы тестов и инструментарий тестирования в VisualStudio 2012. Показано, что рефакторинг кода улучшает качество программного продукта.
Презентацию к данной лекции Вы можете скачать .
Цель лекции:
Получить представление о способах и инструментарии обеспечения качества программных продуктов.
Качество программного продукта определяется по нескольким критериям. Качественный программный продукт должен отвечать функциональным и нефункциональным требованиям, в соответствии с которыми он создавался, иметь ценность для бизнеса, отвечать ожиданиям пользователей .
В жизненном цикле управления приложениями качество должно отслеживаться на всех этапах жизненного цикла ПО . Оно начинает формироваться с определения необходимых требований. При задании требований необходимо указывать желаемую функциональность и способы проверки её достижения.
Качественный программный продукт должен обладать высоким потребительским качеством, независимо от области применения: внутреннее использование разработчиком, бизнес, наука и образование, медицина, коммерческие продажи, социальная сфера, развлечения, веб и др. Для пользователя программный продукт должен удовлетворять определенному уровню его потребностей.
Важным аспектом создания качественного ПО является обеспечение нефункциональных требований, таких как удобство в эксплуатации, надежность , производительность , защищенность, удобство сопровождения . Надежность ПО определяет способность без сбоев выполнять заданные функции в заданных условиях и в течение заданного отрезка времени. Производительность характеризуется временем выполнения заданных транзакций или длительных операций. Защищенность определяет степень безопасности системы от повреждений, утраты, несанкционированного доступа и преступной деятельности. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты исправления дефектов, внесения корректив для соответствия новым требованиям, управления измененной средой.
Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться создания качественного ПО , избегать потерь времени на переделку, повторное проектирования и перепрограммирование ПО .
Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. Главная цель тестирования - определить отклонения в реализации функциональных требований, обнаружить ошибки в выполнении программ и исправить их как можно раньше в процессе выполнения проекта.
На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты.
| Модульное тестирование | предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных. |
| предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. | |
| Интеграционное тестирование | используется для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | предназначено для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками. |
Для разработчика программного обеспечения в VisualStudio 2012 предоставлена возможность создавать модульные и нагрузочные тесты, а также тесты пользовательского интерфейса. В VisualStudio 2012 имеются следующие шаблоны тестовых проектов:
Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг . MTM интегрирован с TeamFoundationServer. С помощью Microsoft TestManager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft TestManager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения. При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены.
Для тестировщиков и разработчиков программного обеспечения VisualStudio 2012 включает диспетчер виртуальной среды LabManagement. Инструментарий тестирования LabManagement позволяет создать инфраструктуру, которая максимально близко эмулирует реальную среду планируемого использования программного продукта. Такие среды могут использоваться для выполнения автоматических построений, автоматизации тестов и выполнения разработанного кода.
Качество кода программного продукта во многом определяется тем, насколько трудно или легко вносить изменения в код, а также тем насколько доступен код для понимания. Созданное программное приложение может выполнять требуемые функции, но иметь проблемы с внесением изменений или пониманием созданного кода. В этом случае такое ПО нельзя назвать качественным, так как на этапе его сопровождения могут возникнуть проблемы с его модификацией при изменении пользовательских требований.
Для улучшения качества кода программных приложений применяют рефакторинг [ , ]. По определению Фаулера М. рефакторинг определяется как "процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается". Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода.
Некачественный дизайн кода определяется по ряду признаков :
Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО [ , ].
Принцип единственной обязанности определяет, что у класса должна быть только одна причина для изменения. Из этого принципа следует, что классу целесообразно поручать только одну обязанность.
Принцип открытости/закрытости определяет, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.
Принцип подстановки Лисков определяет, что должна быть возможность вместо базового класса подставить любой его подтип .
Принцип инверсии зависимостей определяет два положения:
Принцип разделения интерфейсов определяет, что клиенты должны знать только об абстрактных интерфейсах, обладающих свойством сцепленности.
Паттерны проектирования предлагают универсальные, проверенные практикой решения. В приведен обширный перечень паттернов. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда , Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/ шлюз , Заместитель и Шлюз , Посетитель и Состояние.
Использование паттернов при разработке позволяет создавать программное обеспечение , которое легко модифицировать и сопровождать.
Следует отметить, что для проведения рефакторинга необходимо иметь надежные тесты, которые обеспечивают контроль соблюдения функциональных требований при улучшении дизайна кода программного обеспечения.
| Модульное тестирование | тестирование, предназначенное для проверки правильности функционирования методов классов ПО. |
| Исследовательское тестирование | тестирование, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. |
| Интеграционное тестирование | тестирование, предназначенное для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | тестирование, предназначенное для проверки конкретных требований к ПО, которое проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | тестирование, предназначенное для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | тестирование, применяемое при внесении изменений в программное обеспечение, с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | тестирование, предназначенное для проверки соответствия функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | тестирование, представляющее собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. |
| MicrosoftTestManager | инструментарий Microsoft, предназначенный для управления жизненным циклом тестирования программного обеспечения. |
| LabManagement | диспетчер виртуальной среды тестирования. |
Вопросы
Упражнения
