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

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

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

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

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

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

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

Процесс

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

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

PSP0 состоит из 3 фаз: планирование, разработка (проектирование, кодирование, компиляция, тестирование) и постмортем. Устанавливается базовый уровень для измерения текущего процесса: время, затраченное на программирование, введенные/устраненные неисправности и размер программы. В постмортеме инженер обеспечивает надлежащую запись и анализ всех данных по проектам. 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-Based Estimation (PROBE) для улучшения навыков оценки разработчика для более точного планирования проекта. Для отслеживания проекта PSP использует метод заработанной стоимости .

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

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

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

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

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

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

Методы разработки программного обеспечения можно рассматривать как различные от прогнозных до адаптивных. 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 Developer основан на концепциях, изложенных в Своде знаний PSP. ^[5] SEI ведет FAQ ^[1] по сертификации.

• Гибкая разработка программного обеспечения
• Интеграция модели зрелости возможностей (CMMI)
• Университет Карнеги-Меллона
• Оценка на основе прокси (PROBE)
• Институт программной инженерии (SEI)
• Командный процесс разработки программного обеспечения (TSP)
• Уоттс Хамфри

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

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