Jump to content

Командный процесс разработки программного обеспечения

В сочетании с процессом персонального программного обеспечения (PSP) процесс командного программного обеспечения ( TSP ) обеспечивает определенную структуру операционного процесса, которая предназначена для того, чтобы помочь группам менеджеров и инженеров организовывать проекты и создавать программное обеспечение для продукты, размер которых варьируется от небольших проектов в несколько тысяч строк кода (KLOC) до очень крупных проектов, объем которых превышает полмиллиона строк кода. TSP предназначен для повышения уровня качества и производительности проекта разработки программного обеспечения, чтобы помочь им лучше соответствовать обязательствам по затратам и графикам разработки программной системы. [1] [2] [3] [4]

Первоначальная версия TSP была разработана и опробована Уоттсом Хамфри в конце 1990-х годов. [5] и Технический отчет [6] для TSP, спонсируемого Министерством обороны США, была опубликована в ноябре 2000 года. Книга Уоттса Хамфри, [7] Введение в командный процесс разработки программного обеспечения представляет собой представление о TSP, предназначенном для использования в академических условиях, в котором основное внимание уделяется процессу создания команды по производству программного обеспечения, установлению командных целей, распределению командных ролей и другим действиям, связанным с командной работой.

Введение в TSP [ править ]

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

TSP работает Как

Прежде чем инженеры смогут участвовать в TSP, необходимо, чтобы они уже узнали о PSP, чтобы TSP мог работать эффективно. Обучение также требуется для других членов команды, руководителя группы и руководства. Цикл разработки программного обеспечения TSP начинается с процесса планирования, называемого запуском, который возглавляет специально обученный тренер, сертифицированный или предварительный. [8] [9] Запуск предназначен для начала процесса построения команды, и в течение этого времени команды и менеджеры устанавливают цели, определяют командные роли, оценивают риски, оценивают усилия, распределяют задачи и составляют командный план. На этапе выполнения разработчики отслеживают запланированные и фактические усилия, график и регулярное собрание дефектов (обычно еженедельно), чтобы сообщать о состоянии и пересматривать планы. Цикл разработки заканчивается анализом результатов для оценки производительности, пересмотра параметров планирования и учета извлеченных уроков для улучшения процесса.

Роль тренера направлена ​​на поддержку команды и отдельных членов команды в качестве эксперта по процессам, будучи независимым от прямой ответственности за управление проектом. [10] [11] Роль лидера команды отличается от роли коуча тем, что лидеры команд несут ответственность перед руководством за продукты и результаты проекта, а коуч отвечает за развитие индивидуальной и командной производительности. [12] [13]

Последние разработки [ править ]

TSP адаптирован для работы с другими видами научной работы , включая системное проектирование. [14] и услуги. [15] [16]

Сопоставление TSP с практикой интегрированной модели зрелости возможностей (CMMI) было задокументировано в 2010 году. [17] и опробован в качестве альтернативного пути внедрения улучшения процесса CMMI. [18] [19] Свод знаний (BOK) был выпущен в 2010 году. [20] Руководство по программе коуч-наставников было выпущено в 2010 году. [21]

Согласно исследованию Capers Jones, TSP является одной из наиболее успешных методологий разработки с точки зрения графика, качества и бюджета (TCO). [22]

Публикации [ править ]

  • TSP: Руководство командой разработчиков, 2005 г.
  • TSP: Коучинг команд развития, 2005 г.

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

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

  1. ^ Джонс, Каперс (2009). Лучшие практики разработки программного обеспечения . МакГроу-Хилл. п. 11. ISBN  9780071621618 .
  2. ^ Киндлер, Нош Б; Кришнакантан, Васантха; Тинаикар, Ранджит. Применение бережливого производства в разработке приложений . Ежеквартальный журнал McKinsey, май 2007 г.
  3. ^ «Аджил Капитал Консалтинг» . Архивировано из оригинала 3 февраля 2018 года . Проверено 3 июля 2017 г.
  4. ^ Кер, Дж.И., Ван, Ю., Хаджли, М.Н., Сонг, Дж., и Кер, CW (2014). «Внедрение бережливого производства в здравоохранении: оценка эффективности информационных технологий в больничных аптеках США». Международный журнал управления информацией , 34 (4), 556–560.
  5. ^ МакЭндрюс, Дональд (1998). «Командное программное обеспечение ProcessSM (TSPSM): обзор и предварительные результаты использования дисциплинированных практик» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  6. ^ Хамфри, Уоттс. «Командный процесс разработки программного обеспечения» (PDF) . Институт программной инженерии.
  7. ^ Хамфри, Уоттс (1999). Введение в командный процесс разработки программного обеспечения . Эддисон Уэсли.
  8. ^ Хамфри, Уоттс (2018). «Свод знаний о процессах группового программного обеспечения» . Институт программной инженерии. дои : 10.1184/R1/6584825.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  9. ^ Чик, Тимоти (2010). «Руководство по программе наставничества для тренеров Team Software Process (TSP), версия 1.1» . Институт программной инженерии. дои : 10.1184/R1/6584810.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  10. ^ Хамфри, Уоттс (2018). «Свод знаний о процессах группового программного обеспечения» . Институт программной инженерии. дои : 10.1184/R1/6584825.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  11. ^ Хамфри, Уоттс (2005). TSP: Коучинг команд разработчиков . Эддисон Уэсли.
  12. ^ Хамфри, Уоттс (2018). «Свод знаний о процессах группового программного обеспечения» . Институт программной инженерии. дои : 10.1184/R1/6584825.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  13. ^ Хамфри, Уоттс (2005). TSP: Коучинг команд разработчиков . Эддисон Уэсли.
  14. ^ Карлтон, Анита . «Расширение процесса группового программного обеспечения (TSP) на системную инженерию: отчет об опыте NAVAIR» (PDF) . Институт программной инженерии.
  15. ^ Бэттл, Эд. «Лидерство и обучение – использование TSP на уровне MSG» (PDF) . Военно-морское океанографическое управление.
  16. ^ «Консалтинг по программному обеспечению: как убедиться, что консалтинговая компания по программному обеспечению, которую вы ищете, надежна» . Проверено 23 апреля 2019 г.
  17. ^ Джеймс Макхейл; Тимоти А. Чик; Евгений Милюк (декабрь 2010 г.). «Руководство по внедрению метода ускоренного улучшения (AIM)» (PDF) . Институт программной инженерии . Проверено 11 октября 2016 г.
  18. ^ Уэбб, Дэвид (апрель 2007 г.). «Уровень CMMI 5 и процесс группового программного обеспечения» (PDF) . Перекрестный разговор . Архивировано из оригинала 9 октября 2012 года.
  19. ^ Мондрагон, Оскар. «Пример AIM» (PDF) . Центр передового опыта в области разработки программного обеспечения.
  20. ^ Хамфри, Уоттс (2018). «Свод знаний о процессах группового программного обеспечения» . Институт программной инженерии. дои : 10.1184/R1/6584825.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  21. ^ Чик, Тимоти (2010). «Руководство по программе наставничества для тренеров Team Software Process (TSP), версия 1.1» . Институт программной инженерии. дои : 10.1184/R1/6584810.v1 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  22. ^ Джонс, Каперс (2013). «Оценка десяти методологий разработки программного обеспечения» . Архивировано из оригинала 29 июня 2013 года.

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

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: edb8e8b93359c62b46d7970cd0115695__1683489420
URL1:https://arc.ask3.ru/arc/aa/ed/95/edb8e8b93359c62b46d7970cd0115695.html
Заголовок, (Title) документа по адресу, URL1:
Team software process - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)