Персональный программный процесс - Personal software process

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

"Персональный программный процесс" и "PSP"зарегистрированы знаки обслуживания из Университет Карнеги Меллон[1].[2]

Цели

PSP стремится предоставить разработчикам программного обеспечения дисциплинированные методы для улучшения процессов разработки личного программного обеспечения. 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 использует Оценка на основе прокси (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] по сертификации.

Смотрите также

Рекомендации

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

дальнейшее чтение

внешняя ссылка