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

Инспектирование программных систем

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

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

Доказано, что инспектирование является эффективным методом обнаружения ошибок. Также немаловажно, что инспектирование значительно дешевле экстенсивного тестирования программ. В экспериментах, сравнивалась эффективность инспектирования и тестирования. Инспектирование программного кода оказалось более эффективным и менее дорогостоящим, чем тестирование. Более 60% ошибок в программах можно обнаружить с помощью неформального исследования (инспектирования) программ. При более формальном подходе, использующем математические методы, в программе можно обнаружить более 90% всех ошибок. Такая проверка используется в процессе разработки систем методом «чистая комната». Процесс инспектирования также может оценить другие качественные характеристики систем: соответствие стандартам, переносимость и удобство сопровождения.

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

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

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

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

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

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

Дата добавления: 2015-08-14 ; просмотров: 3197 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник

Инспектирование кода: лучшая практика

Рассказывает Кевин Лондон, автор блога kevinlondon.com

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

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

На что смотреть во время инспекции

Архитектура/Дизайн

Стиль

Тестирование

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

Перед совершением коммита просмотрите свой код на следующие вещи:

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

Как проводить инспектирование кода

Человеческий фактор при инспектировании порой приносит не меньше проблем, чем само инспектирование. Я сам еще только учусь проведению таких мероприятий. Вот несколько приемов, которые всегда мне помогают:

Не забывайте о своих обязанностях

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

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

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

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

Дополнительно

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

Также рекомендую несколько видео, идеи из которых я держал в уме, когда писал эту статью:

Источник

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

Инспектирование программ – это просмотр и проверка программ с целью обнаружения в них ошибок. Идея формализованного процесса проверки программ была сформулирована корпорацией IBM в 1970-х годах. В настоящее время данный метод верификации получил широкое распространение. На его базе разработано множество других методов, но все они основываются на базовой идее метода инспектирования, согласно которому группа специалистов выполняет тщательный построчный просмотр и анализ исходного кода программы. Главное отличие инспектирования от других методов оценивания качества программ состоит в том, что его цель – обнаружение дефектов, а не исследование общих проблем проекта. Дефектами являются либо ошибки в исходном коде, либо несоответствия программы стандартам.

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

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

Рис. 2.2. Процесс инспектирования

На рис. 2.2 показан общий процесс инспектирования. Он адаптирован к требованиям организаций, использующих инспектирование программ.

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

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

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

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

Предмет: Технология разработки программных продуктов.

Тема: Тестирование ПО.

Ознакомление с принципами тестирования ПО.

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

Воспитывать чувство значимости предмета в профессиональной деятельности, аккуратности в работе

— Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

— Проверка готовности кабинета

2. Постановка цели урока

3.Повторение пройденного материала

Назначение аттестации программного средства.

Виды испытаний программного средства.

Методы оценки качества программного средства.

Введение в верификацию и аттестацию

Планирование верификации и аттестации

Инспектирование программных систем

4.Сообщение новых знаний

1. Уровни тестирования.

2. Термины и определения.

3. Тестирование «белого ящика» и «черного ящика»

4. Порядок разработки тестов

5. Автоматизация тестирования

6. Модульное тестирование

7. Интеграционное тестирование

8. Системное тестирование

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока и постановка домашнего задания

Выучить содержимое темы

Гагарина Л.Г. стр. С.199-214.

Ответить на вопросы:

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

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

Уровни тестирования:

• модульное тестирование. Тестируется минимально возможный для тестирования компонент, например отдельный класс или функция;

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

• системное тестирование. Тестируется интегрированная система на ее соответствие исходным требованиям:

— альфа-тестирование — имитация реальной работы с системой штатными разработчиками либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внут-

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

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

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

Дата добавления: 2015-04-11 ; просмотров: 78 ; Нарушение авторских прав

Источник

Формальные инспекции (окончание)

16.2. Формальные инспекции программного кода

16.2.1. Особенности этапа просмотра инспектируемого кода

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

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

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

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

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

16.2.2. Особенности этапа проведения собрания

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

16.2.3. Особенности этапа завершения и повторной инспекции

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

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

16.3. Формальные инспекции проектной документации

16.3.1. Особенности этапа просмотра документации

16.3.2. Особенности этапа завершения

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

Источник

Фонд оценочных средств по МДК.02.01. Технология разработки программных продуктов

Фонд оценочных средств предназначен для оценки результатов освоения дисциплины МДК.02.01 Технология разработки программного обеспечения по специальности 09.02.07 Информационные системы и программирование. Данный материал предназначен для преподавателей спец.дисциплин.

Просмотр содержимого документа
«Фонд оценочных средств по МДК.02.01. Технология разработки программных продуктов»

Министерство образования Пензенской области

Государственное автономное профессиональное образовательное учреждение

Пензенской области «Пензенский колледж информационных и промышленных

ФОНД ОЦЕНОЧНЫХ СРЕДСТВ

МДК.02.01. Технология разработки программного обеспечения

по специальности 09.02.07 Информационные системы и программирование

Фонд оценочных средств рассмотрен и одобрен методической цикловой комиссией название комиссии

Председатель методической цикловой комиссии
Ф.И.О.

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

Зам. директора по ОПП:

_______________ Е.А. Волобуева

« ___ » ___________ 2021 г.

ФОНД ОЦЕНОЧНЫХ СРЕДСТВ УЧЕБНОЙ ДИСЦИПЛИНЫ МДК.02.01 Технология разработки программного обеспечения для специальности 09.02.07 Информационные системы и программирование

© ГАПОУ ПО «Пензенский колледж информационных и промышленных технологий (ИТ-колледж)»

1.Паспорт фонда оценочных средств

1.3 Периодичность текущей и промежуточной аттестации…………………

1.4 Порядок проведения текущей и промежуточной аттестации………………

1.5 Результаты освоения дисциплины, подлежащие контролю……………

1.6 Распределение типов контрольных заданий по элементам знаний и умений

2. Фонд оценочных средств дисциплины………………………………

2.1. Фонд оценочных средств текущей аттестации………………………………………….7

2.2. Фонд оценочных средств промежуточной аттестации

Основной целью оценки освоения дисциплины является оценка умений и знаний.

Фонд оценочных средств предназначен для оценки результатов освоения дисциплины МДК.02.01 Технология разработки программного обеспечения по специальности 09.02.07 Информационные системы и программирование

ФОС по МДК формируется из двух частей ФОС: текущей аттестации (ФОС ТА) и ФОС промежуточной аттестации (ФОС ПА).

1.2. Формы аттестации

Текущая аттестация осуществляется с использованием следующих форм и методов текущего контроля:

— оценка результатов тестирования;

— оценка результатов выполнения лабораторных работ;

— оценка результатов выполнения самостоятельной работы;

Промежуточная аттестация проводится в форме дифференцированного зачета

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

1.3 Периодичность текущей и промежуточной аттестации

Текущая аттестация (ТА) проводится в соответствии с календарно-тематическим планом (КТП) и планами занятий. Периодичность проведения ТА не реже 1-2 раз в неделю (за каждое теоретическое занятие и за каждую лабораторную работу.

Промежуточная аттестация проводится на последнем занятии в форме дифференцированного зачета.

1.4 Порядок проведения текущей и промежуточной аттестации

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

Продолжительность промежуточной аттестации:

1.5. Результаты освоения дисциплины, подлежащие контролю Таблица 1

У1. Разрабатывать и оформлять требования к программным модулям по модели процесса разработки программного обеспечения;

У2. Использовать выбранную систему контроля версий;

У3. Использовать методы для получения кода с заданной функциональностью и степенью качества;

У4. Выполнять интеграцию модулей в программное обеспечение;

У5. Выполнять отладку программного модуля с использованием специализированных программных средств;

У6. Осуществлять разработку тестовых наборов и тестовых сценариев для программного обеспечения;

У7. Производить инспектирование компонент программного обеспечения на предмет соответствия стандартам кодирования.

З1. Модели процесса разработки программного обеспечения;

З2. Основные принципы процесса разработки программного обеспечения;

З3. Основные подходы к интегрированию программных модулей;

З4. Основы верификации и аттестации программного обеспечения

Наименование результата обучения

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

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

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

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

Производить инспектирование компонент программного обеспечения на предмет соответствия стандартам кодирования.

Выбирать способы решения задач профессиональной деятельности, применительно к различным контекстам.

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

Планировать и реализовывать собственное профессиональное и личностное развитие.

Работать в коллективе и команде, эффективно взаимодействовать с коллегами, руководством, клиентами.

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

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

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

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

Использовать информационные технологии в профессиональной деятельности.

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

Планировать предпринимательскую деятельность в профессиональной сфере.

Распределение типов контрольных заданий по элементам знаний и умений

Основной целью оценки освоения дисциплины является оценка умений и знаний.

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

Содержание учебного материала по рабочей программе учебной дисциплины

Источник