Войти
Персональный программный процесс (PSP ) представляет собой структурированное программное обеспечение разработка процесс, призванный помочь программистам лучше понять и улучшить свою работу, привнеся дисциплинированный подход в разработку программного обеспечения и отслеживая прогнозируемую и фактическую разработку кода. Он ясно показывает разработчикам, как управлять качеством своих продуктов, как составлять продуманный план и как брать на себя обязательства. Он также предлагает им данные, чтобы оправдать их планы. Они могут оценить свою работу и предложить направление улучшения путем анализа и анализа данных о времени разработки, дефектах и размерах. PSP была создана Уоттсом Хамфри для применения основных принципов Software Engineering Institute (SEI) Модель зрелости возможностей (CMM) при разработке программного обеспечения. практики одного разработчика. Он утверждает, что дает инженерам-программистам навыки, необходимые для работы в команде групповых программных процессов (TSP).
«Персональный программный процесс» и «PSP » являются зарегистрированными знаками обслуживания Университета Карнеги-Меллона.
Цель PSP - предоставить инженерам-программистам дисциплинированные методы для улучшения разработки личного программного обеспечения процессы. PSP помогает программистам:
Обучение PSP следует эволюционному подходу к улучшению: инженер, обучающийся интегрировать PSP в свой процесс, начинает с первого уровня - PSP0 - и прогрессирует в процессе зрелость до конечного уровня - PSP2.1. На каждом уровне есть подробные сценарии, контрольные списки и шаблоны, которые помогут инженеру выполнить необходимые шаги и помогут ему улучшить свой собственный процесс разработки программного обеспечения. Хамфри призывает опытных инженеров настраивать эти сценарии и шаблоны по мере того, как они понимают свои сильные и слабые стороны.
Входными данными PSP являются требования; Документ с требованиями заполнен и передан инженеру.
PSP0 имеет 3 фазы: планирование, разработка (дизайн, код, компиляция, тестирование) и вскрытие. Устанавливается базовый уровень текущего измерения процесса: время, затраченное на программирование, введенные / устраненные ошибки, размер программы. После вскрытия инженер проверяет, чтобы все данные для проектов были должным образом записаны и проанализированы. PSP0.1 продвигает процесс, добавляя стандарт кодирования, измерение размера и разработку личного плана улучшения процесса (PIP). В PIP инженер записывает идеи по улучшению собственного процесса.
На основе исходных данных, собранных в PSP0 и PSP0.1, инженер оценивает, насколько большой будет новая программа, и готовит отчет об испытаниях (PSP1). Накопленные данные из предыдущих проектов используются для оценки общего времени. Каждый новый проект будет записывать фактическое затраченное время. Эта информация используется для планирования и оценки задач и расписания (PSP1.1).
PSP2 добавляет два новых этапа: анализ дизайна и анализ кода. Предотвращение дефектов и их устранение - в центре внимания PSP2. Инженеры учатся оценивать и улучшать свой процесс, измеряя, сколько времени занимают задачи, а также количество дефектов, которые они вводят и устраняют на каждом этапе разработки. Инженеры составляют и используют контрольные списки для проверки дизайна и кода. В PSP2.1 представлены технические характеристики проекта и методы анализа
(PSP3 - это устаревший уровень, который был заменен TSP.)
Один из основных аспектов PSP использует исторические данные для анализа и повышения эффективности процессов. Сбор данных PSP поддерживается четырьмя основными элементами:
Сценарии PSP предоставляют рекомендации на уровне эксперта по отслеживанию процесса шаги, и они обеспечивают основу для применения мер PSP. PSP имеет четыре основных показателя:
Применение стандартов к процессу может гарантировать данные точный и последовательный. Данные регистрируются в формах, обычно с помощью программного обеспечения PSP. SEI разработал инструмент PSP, а также доступны варианты с открытым исходным кодом, такие как Process Dashboard.
Ключевыми данными, собираемыми в инструменте PSP, являются данные о времени, дефектах и размере - время, затраченное на каждую фазу; когда и где дефекты были внедрены, найдены и исправлены; и размер частей продукта. Разработчики программного обеспечения используют множество других мер, которые основаны на этих трех основных показателях, чтобы понять и улучшить свою производительность. Производные меры включают:
Регистрация данных о времени, дефектах и размерах является важной частью планирования и отслеживания проектов PSP, поскольку исторические данные используются для повышения точности оценки.
PSP использует метод PROxy-Based Estimation (PROBE), чтобы улучшить навыки оценки разработчика для более точного планирования проекта. Для отслеживания проекта PSP использует метод освоенного объема.
PSP также использует статистические методы, такие как корреляция, линейная регрессия и стандартное отклонение, для преобразования данных в полезную информацию для улучшения оценки, планирования и качества. Эти статистические формулы рассчитываются с помощью инструмента PSP.
PSP призвана помочь разработчику улучшить свой личный процесс; поэтому ожидается, что разработчики PSP продолжат адаптировать процесс, чтобы он соответствовал их личным потребностям.
На практике навыки PSP используются в командной среде TSP. Команды TSP состоят из разработчиков, прошедших обучение в рамках PSP, которые добровольно работают в областях ответственности проекта, поэтому проект управляется самой командой. Использование личных данных, собранных с помощью своих навыков PSP; команда составляет планы, делает оценки и контролирует качество.
Использование методов процесса PSP может помочь командам TSP выполнять свои обязательства по графику и производить высококачественное программное обеспечение. Например, согласно исследованию Уоттса Хамфри, треть всех программных проектов терпит неудачу, но исследование SEI по 20 проектам TSP в 13 различных организациях показало, что команды TSP не выполнили запланированные сроки в среднем всего на шесть процентов.
Успешное выполнение обязательств по графику может быть связано с использованием исторических данных для более точных оценок, поэтому проекты основаны на реалистичных планах - и, используя методы обеспечения качества 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. SEI ведет FAQ по сертификации.
| work =()