Process Личные Software ( PSP ) является структурированная разработка программного обеспечения процесса , который предназначен для помощи инженеров программного обеспечения лучше понять и улучшить их производительность за счет чего дисциплины , как они разрабатывают программное обеспечение и отслеживания их прогнозируемое и фактическое развитие кода. Он ясно показывает разработчикам, как управлять качеством своих продуктов, как составлять продуманный план и как брать на себя обязательства. Он также предлагает им данные, чтобы оправдать их планы. Они могут оценить свою работу и предложить направление улучшения путем анализа и анализа данных о времени разработки, дефектах и размерах. PSP была создана Уоттсом Хамфри, чтобы применить основные принципыМодель зрелости возможностей (CMM) Института программной инженерии (SEI) применима к практике разработки программного обеспечения одним разработчиком. Он утверждает, что дает инженерам-программистам навыки, необходимые для работы в команде командного процесса разработки программного обеспечения (TSP).
"Personal Software Process" и " PSP " являются зарегистрированными знаками обслуживания по Carnegie Mellon University . [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 ведет FAQ [1] по сертификации.
Смотрите также
Рекомендации
- ^ a b «Сертифицированный SEI разработчик PSP: часто задаваемые вопросы» . SEI Training . Питтсбург, Пенсильвания: Институт программной инженерии , Университет Карнеги-Меллона . Архивировано из оригинального 29 ноября 2014 года . Проверено 17 ноября 2014 года . Внешняя ссылка в
|work=
( помощь ) - ^ «Условия использования» . США: Институт программной инженерии , Университет Карнеги-Меллона . Проверено 14 января 2013 года .
- ^ Хамфри, Уоттс С. "Почему большие программные проекты терпят неудачу: 12 ключевых вопросов". CrossTalk, март 2005 г. http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf Архивировано 5 ноября 2019 г. на Wayback Machine
- ^ Дэвис, Noopur и Джулия Mullaney. Командный программный процесс 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) и Six Sigma: Практическое руководство по внедрению командного программного процесса , Мукеш Джайн, 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)» из Института программной инженерии в Карнеги-Меллон .
- Статья "Персональное управление качеством с помощью процесса персонального программного обеспечения" .
Внешние ссылки
- Панель управления программным процессом, инструмент PSP и TSP с открытым исходным кодом ( GPL3 ); предлагается как без, так и с проприетарными сценариями SEI, для последних требуется бесплатная регистрация SEI.