Персональный процесс программного обеспечения

Персональный процесс разработки программного обеспечения ( PSP ) — это структурированный процесс разработки программного обеспечения , который призван помочь инженерам-программистам лучше понять и улучшить свою производительность, привнося дисциплину в процесс разработки программного обеспечения и отслеживая прогнозируемую и фактическую разработку кода. Он ясно показывает разработчикам, как управлять качеством своих продуктов, как составлять продуманный план и как брать на себя обязательства. Он также предлагает им данные для обоснования их планов. Они могут оценить свою работу и предложить направление улучшения, анализируя и анализируя данные о времени разработки, дефектах и размерах. PSP был создан Уоттсом Хамфри для применения основных принципов Института программной инженерии (CMM ) модели зрелости возможностей (SEI) к практике разработки программного обеспечения одним разработчиком. Он утверждает, что дает инженерам-программистам процессные навыки, необходимые для работы в команде командных процессов программного обеспечения (TSP).

«Personal Software Process» и « PSP » являются зарегистрированными знаками обслуживания Университета Карнеги-Меллон . ^[1]^[2]

Цели [ править ]

PSP стремится предоставить инженерам-программистам дисциплинированные методы улучшения процессов разработки личного программного обеспечения. PSP помогает разработчикам программного обеспечения:

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

Структура PSP [ править ]

Обучение PSP следует подходу эволюционного улучшения: инженер, обучающийся интеграции PSP в свой процесс, начинает с первого уровня – PSP0 – и продвигается по зрелости процесса до финального уровня – PSP2.1. На каждом уровне имеются подробные сценарии, контрольные списки и шаблоны, которые помогут инженеру выполнить необходимые шаги и помогут ему улучшить свой личный процесс разработки программного обеспечения. Хамфри призывает опытных инженеров настраивать эти сценарии и шаблоны по мере того, как они начинают понимать свои сильные и слабые стороны.

Процесс

Входными данными для PSP являются требования; Документ с требованиями заполняется и передается инженеру.

PSP0, PSP0.1 (вводит дисциплину процесса и измерения)

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

PSP1, PSP1.1 (ознакомляет с оценкой и планированием)

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

PSP2, PSP2.1 (ознакомляет с управлением качеством и дизайном)

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

(PSP3 — это устаревший уровень, который был заменен TSP.)

Важность данных [ править ]

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

Скрипты
Меры
Стандарты
Формы

Сценарии PSP предоставляют экспертное руководство по выполнению этапов процесса и обеспечивают основу для применения мер PSP. PSP включает четыре основных меры:

Размер — мера размера части продукта, например строк кода (LOC).
Усилия – время, необходимое для выполнения задачи, обычно измеряемое в минутах.
Качество – количество дефектов в товаре.
График – показатель хода реализации проекта, отслеживаемый по сравнению с запланированными и фактическими датами завершения.

Применение стандартов к процессу может обеспечить точность и согласованность данных. Данные регистрируются в формах, обычно с использованием программного обеспечения PSP. SEI разработала инструмент PSP, а также доступны варианты с открытым исходным кодом, такие как Process Dashboard.

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

точность оценки (размер/время)
интервалы прогнозирования (размер/время)
время в фазовом распределении
Распределение впрыска дефектов
распределение устранения дефектов
производительность
процент повторного использования
индекс эффективности затрат
плановая стоимость
освоенная стоимость
прогнозируемая освоенная стоимость
плотность дефектов
плотность дефектов по фазам
скорость устранения дефектов по этапам
рычаг устранения дефектов
обзор ставок
выход процесса
выход фазы
Стоимость отказа за качество (COQ)
оценка COQ
соотношение оценки/неуспеха COQ

Планирование и отслеживание [ править ]

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

PSP использует метод оценки на основе PROxy (PROBE) для улучшения навыков разработчика в оценке и более точного планирования проекта. Для отслеживания проекта PSP использует метод освоенного объема .

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

Использование PSP [ править ]

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

PSP и TSP [ править ]

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

Использование методов процессов PSP может помочь командам TSP выполнять свои обязательства по графику и производить высококачественное программное обеспечение. Например, согласно исследованию Уоттса Хамфри, треть всех программных проектов терпят неудачу. ^[3] Однако исследование SEI, посвященное 20 проектам TSP в 13 различных организациях, показало, что команды TSP не соблюдают намеченные сроки в среднем лишь на шесть процентов. ^[4]

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

PSP и другие методологии [ править ]

PSP — это персональный процесс, который можно адаптировать в соответствии с потребностями отдельного разработчика. Он не является специфичным для какой-либо методологии программирования или проектирования; поэтому его можно использовать с различными методологиями, включая гибкую разработку программного обеспечения .

Можно считать, что методы разработки программного обеспечения варьируются от прогнозирующих до адаптивных. PSP — это прогнозная методология, а Agile считается адаптивной, но, несмотря на различия, TSP/PSP и Agile разделяют несколько концепций и подходов, особенно в отношении организации команды. Оба они позволяют команде:

Определите свои цели и стандарты.
Оцените и запланируйте работу.
Определите реалистичные и достижимые графики.
Стройте планы и улучшайте процессы.

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

Качество [ править ]

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

Фазовая структура PSP позволяет разработчикам PSP обнаруживать дефекты на ранней стадии. Обнаружив дефекты на ранней стадии, PSP может сократить время, затрачиваемое на более поздних этапах, таких как тестирование.

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

Обзор дизайна
Обзор кода

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

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

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

Сертификация [ править ]

Сертификацию PSP предлагает SEI Университета Карнеги-Меллон. Чтобы стать сертифицированным SEI разработчиком PSP, необходимо: изучить PSP; сдать сертификационный экзамен; сохранять учетные данные. Экзамен для разработчиков PSP основан на концепциях, изложенных в Своде знаний PSP. ^[5] SEI поддерживает часто задаваемые вопросы ^[1] по сертификации.

См. также [ править ]

Ссылки [ править ]

^ Перейти обратно: ^а ^б «Сертифицированный SEI разработчик PSP: часто задаваемые вопросы» . Обучение СЭИ . Питтсбург, Пенсильвания: Институт программной инженерии , Университет Карнеги-Меллон . Архивировано из оригинала 29 ноября 2014 года . Проверено 17 ноября 2014 г. {{cite web}}: Внешняя ссылка в |work= ( помощь )
^ "Условия эксплуатации" . США: Институт программной инженерии , Университет Карнеги-Меллон . Проверено 14 января 2013 г.
^ Хамфри, Уоттс С. «Почему крупные программные проекты терпят неудачу: 12 ключевых вопросов». CrossTalk, март 2005 г. http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf . Архивировано 5 ноября 2019 г. на Wayback Machine.
^ Дэвис, Ноопур и Джулия Маллани. Командный программный процесс SM (TSP SM) на практике: обзор последних результатов. Питтсбург, Пенсильвания: Институт программной инженерии, сентябрь 2003 г.
^ Помрой-Хафф, Марша; Кэннон, Роберт; Чик, Тимоти А.; Маллани, Джулия; Николс, Уильям (2009). Свод знаний о персональном программном процессе (PSP), версия 2.0 (PDF) . Питтсбург, Пенсильвания: Институт программной инженерии , Университет Карнеги-Меллон . Проверено 17 ноября 2014 г. Бесплатно загружаемый специальный отчет CMU/SEI-2009-SR-018, 2009 г.

Дальнейшее чтение [ править ]

«Использование определенного и измеренного процесса персонального программного обеспечения» Уоттса С. Хамфри , опубликовано в IEEE Software , май 1996 г., страницы 77–88.
PSP: Процесс самосовершенствования для инженеров-программистов , 2005.
«Реализация успешных проектов с помощью TSP (SM) и шести сигм: практическое руководство по внедрению командного процесса разработки программного обеспечения» , Мукеш Джайн, 2008 г.
«Реализация успешных проектов с учетом проблем новых команд», Мукеш Джейн ( http://www.sei.cmu.edu/tspsymposium/2009/2006/deliver.pdf ), сентябрь 2006 г.
Программная инженерия: практический подход, 7-е издание. Роджер С. Прессман. Высшее образование МакГроу-Хилл. 2009. ISBN 0-07-337597-7 , ISBN 978-0-07-337597-7 , страницы 57–58.
«Свод знаний о персональном программном процессе (PSP)» Статья Института программной инженерии Карнеги -Меллон .
«Управление личным качеством в процессе разработки персонального программного обеспечения» . Статья

Внешние ссылки [ править ]

Программная панель управления процессами с открытым исходным кодом ( GPL3 , инструмент PSP и TSP ); предлагается как без собственных скриптов SEI, так и с ними, причем последний требует бесплатной регистрации SEI.

[:0-1] Перейти обратно: ^а ^б «Сертифицированный SEI разработчик PSP: часто задаваемые вопросы» . Обучение СЭИ . Питтсбург, Пенсильвания: Институт программной инженерии , Университет Карнеги-Меллон . Архивировано из оригинала 29 ноября 2014 года . Проверено 17 ноября 2014 г. {{cite web}}: Внешняя ссылка в |work= ( помощь )

[2] "Условия эксплуатации" . США: Институт программной инженерии , Университет Карнеги-Меллон . Проверено 14 января 2013 г.

[3] Хамфри, Уоттс С. «Почему крупные программные проекты терпят неудачу: 12 ключевых вопросов». CrossTalk, март 2005 г. http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf . Архивировано 5 ноября 2019 г. на Wayback Machine.

[4] Дэвис, Ноопур и Джулия Маллани. Командный программный процесс SM (TSP SM) на практике: обзор последних результатов. Питтсбург, Пенсильвания: Институт программной инженерии, сентябрь 2003 г.

[PSP-BOKv2-5] Помрой-Хафф, Марша; Кэннон, Роберт; Чик, Тимоти А.; Маллани, Джулия; Николс, Уильям (2009). Свод знаний о персональном программном процессе (PSP), версия 2.0 (PDF) . Питтсбург, Пенсильвания: Институт программной инженерии , Университет Карнеги-Меллон . Проверено 17 ноября 2014 г. Бесплатно загружаемый специальный отчет CMU/SEI-2009-SR-018, 2009 г.

[1]

[2]

[3]

[4]

[5]