19. Индивидуальный и коллективный  процессы разработки ПО.

Индивидуальный процесс разработки (Personal software process, PSP) — процесс разработки ПО, помогающий разработчикам понимать и улучшать собственную производительность. Создан для применения принципов модели зрелости процессов к практике одного разработчика.

Предоставляет разработчикам  описания методов планирования и  оценки, показывает как измерять собственную продуктивность и соотносить ее с существующим планом.

Один из основных аспектов PSP — использование накопленной статистики для анализа и улучшения показателей процесса разработки. Сбор статистики включает 4 элемента:

- Скрипты.

- Оценки. Включают 4 основных элемента:

1 Размер — оценка размера для части продукта. Например, количество строк кода (LOC — Lines Of Code).

2 Качество — количество ошибок в продукте.

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

4 Планирование — оценка хода проекта, перемещаемая между планируемыми и завершенными пунктами.

- Стандарты кодирования. Применение стандартов к процессу может обеспечить точные и постоянные данные.

- Формы.

- Цели

PSP помогает разработчикам:

1 Улучшить оценку и планирование навыков.

2 Управлять качеством проектов.

3 Снизить количество ошибок в своих разработках.

TSP это формализованный процесс разработки программного обеспечения.

Команда, использующая TSP, обычно состоит из 3-15 человек. Не все участники команды должны быть программистами

Большие проекты выполняются  несколькими командами, работающими по процессу TSPm (расширение процесса TSP для нескольких команд).

Командный процесс разработки программного обеспечения (TSP) предлагает 
большое количество методов управления программным проектом, применимых 
к любой командной деятельности. TSP обеспечивает необходимую направленность и последовательность действий после анализа требований и по ходу фаз разработки проекта. Участники TSP должны быть подготовлены с точки зрения PSP. Метод основан на итерациях водопадной последовательности и требует, чтобы команда «запускала» каждую итерацию на совещании, где уже было бы известно количество предварительно определенных задач. Хэмфри предусматривает наличие множества различных сценариев. Так как фаза может проводиться в несколько итераций, то для нее, возможно, потребуется несколько «запусков».

Перед запуском необходимо провести некоторые предварительные мероприятия:

♦ выбрать тип процесса, который будет использоваться;

♦ установить уровень качества;

♦ определить метод отслеживания уровня качества;

♦ определить, как команда  будет принимать решения;

♦ определить, что делать, если не устраивает уровень качества:

- идти на компромисс;

♦ определить, что делать, если не утвержден план:

- идти на компромисс;

♦ определить роли в команде;

♦ распределить роли.

Хэмфри рекомендует, чтобы перед запуском каждой из фаз было определено 
следующее:

1) фиксированные цели команды;

2) определенные командные роли;

3) план развития процесса;

4) план качества;

5) план обеспечения проекта: компьютеры, ПО, персонал и т. д;

6) общий план разработки и план-график;

7) детальные планы для каждого разработчика;

8) оценка рисков проекта;

9) доклад о статусе проекта.

20. Разработка технического задания  на создание автоматизированных  систем.

Разработка ТЗ включает в  себя подготовку специального документа  с аналогичным названием. В Техническом  задании обязательно должны быть описаны:

• ограничения, риски, критические факторы, влияющие на успешность проекта, например время реакции системы на запрос является заданным ограничением, а не желательным фактором;
• совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, предоставляемые системе, внешние условия её функционирования, состав людей и работ, которые обеспечивают бесперебойное функционирование системы;
• сроки завершения отдельных этапов, форма сдачи работ, ресурсы, привлекаемые в процессе разработки проекта, меры по защите информации;
• описание выполняемых системой функций;
• будущие требования к системе в случае её развития, например возможность работы пользователя с системой с помощью Интернета и т.п.;
• сущности, необходимые для выполнения функций системы;
• интерфейсы и распределение функций между человеком и системой;
• требования к программным и информационным компонентам ПО, требования к СУБД. Если проект предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие требования к абстрактной (например, распределённой) СУБД и список рекомендуемых для данного проекта СУБД, которые удовлетворяют заданным условиям;
• что не будет реализовано в рамках проекта.

Разработка ТЗ ведётся  в соответствии со стандартами:

ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

ГОСТ 34.602-89. Комплекс стандартов на автоматизированные системы. Техническое  задание на создание автоматизированной системы.

I. Общие положения 

ТЗ должно соответствовать  современному уровню развития науки  и техники, максимально точно  отражать цели, замысел и требования к создаваемой системе и при  этом не ограничивать разработчика в  поиске и реализации наиболее эффективных  технических, технико-экономических  и других решений. В соответствии с ГОСТ 34.601-90, после согласования с Заказчиком, выполняется разработка, оформление, согласование и утверждение Технического задания на АИС (при необходимости – на части АИС). Данный стандарт также определяет состав участников проектирования и реализации проектных решений, которые участвуют в составлении и (или) согласовании ТЗ. В самом общем случае к ним относятся:

1. Организация-заказчик (пользователь), для которой создаётся АИС  и которая обеспечивает финансирование, приёмку работ и эксплуатацию  как по всей АИС, так и  по отдельным её компонентам; 

2. Организация-разработчик  (генпроектировщик), осуществляющая работы по созданию АИС, представляя Заказчику совокупность научно-технических услуг на разных стадиях и этапах создания, а также разрабатывая и поставляя различные программные и технические средства АС. Данная (головная) организация может пользоваться услугами других организаций, работающих у неё на субподряде;

3. Организация-поставщик,  изготавливающая и (или) поставляющая  программные и технические средства  по заказу Разработчика или  Заказчика; 

4. Организации, выполняющие  строительные, электротехнические, санитарно-технические,  монтажные, наладочные и другие  подготовительные работы, связанные  с созданием АИС. 

ГОСТ 34.602-89 устанавливает  порядок разработки, согласования и  утверждения ТЗ на создание (развитие или модернизацию) автоматизированных систем различного назначения, а также  состав и содержание указанного документа  независимо от того, будет ли она  работать самостоятельно или в составе  другой системы. В зависимости от условий создания системы возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах  по созданию АИПС.

ТЗ на АИС разрабатываются  на основании исходных данных.

Любые изменения к ТЗ оформляются  дополнительными протоколами, подписанными заказчиком и разработчиком. Оформленные  таким образом дополнения являются неотъемлемой частью ТЗ на АИС. На титульном  листе ТЗ должна быть запись “Действует с …”.

ТЗ на АИС содержит следующие разделы:

1. Общие сведения.

2. Назначение и цели  создания (развития) системы. 

3. Характеристика объектов  автоматизации. 

4. Требования к системе. 

5. Состав и содержание  работ по созданию системы. 

6. Порядок контроля и  приемки системы. 

7. Требования к составу  и содержанию работ по подготовке  объекта автоматизации к вводу  АИС в действие.

8. Требования к документированию.

9. Источники разработки.

10. Приложения.

В зависимости от вида, назначения, специфических особенностей объекта  автоматизации и условий функционирования системы допускается оформлять  разделы ТЗ в виде приложений, вводить  дополнительные, исключать или объединять подразделы ТЗ.

 

21. Модель зрелости возможностей (СММ).

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

В 80-х годах Институт технологий разработки программного обеспечения (SEI) от имени Министерства обороны США установил простую классификацию возможностей субподрядчиков. План Министерства обороны состоял в том, чтобы давать оборонные заказы только таким подрядчикам, которые обладают определенным уровнем возможностей. Система, разработанная SEI, известна как Модель зрелости возможностей (СММ — Capability Maturity Model). СММ оказалась очень эффективной для определения уровня компетентности в разработке программного обеспечения. Многие организации, как военные, так и гражданские, использовали СММ для измерения своих усилий по улучшению процесса разработки. Например, вместо того чтобы характеризовать организацию как «достаточно хорошую» в области разработки программного обеспечения, можно точно указать, что организация «находится на уровне 3 по СММ». Среди известных автору организаций, которые намерены улучшить свои показатели по СММ, есть и мощные компании военно-промышленного комплекса, и компании, занимающиеся программным обеспечением проверки орфографии.

СММ классифицирует организации по пяти уровням следующим  образом.

Уровень 1: Начальный. Уровень 1 соответствует самому примитивному статусу организации. На этом уровне признается, что организация способна разрабатывать программное обеспечение. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. В типичном случае один из членов команды проявляет инициативу — что делать дальше, и команда следует его указаниям. Успех одного проекта не гарантирует успеха следующего (за исключением случая, когда состав команды не меняется и проект аналогичный). По завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.

Процесс: не определен; зависит от конкретной задачи.

Результат: зависит от индивидуальных способностей.

Недостаток: нет четко заданного процесса.

Уровень 2: Повторяемый. Уровень 2 соответствует организациям, которые до некоторой степени отслеживают свой процесс работы. Поддерживаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. Следовательно, возможно оценить затраты на разработку аналогичного проекта той же командой. Это заметное улучшение по сравнению с уровнем 1. Для дальнейшего улучшения необходимо иметь возможность оценивать затраты независимо от наличия или отсутствия конкретных людей в команде проекта. В середине 1999 года только 20 % организаций имели уровень 2 или выше.

Процесс: ведется документация и учет трудозатрат, отслеживается ход выполнения планов и функциональности (постфактум).

Результат: воспроизводим только для аналогичных проектов.

Недостаток: нет полного процесса.

Уровень 3: Установленный. Уровень 3 соответствует организациям, которые имеют определенный, документированный и установленный процесс работы, не зависящий от отдельных личностей. Обычно это один из процессов, описанных в данной главе: водопадный, спиральный или инкрементальный. Некоторые организации используют существующие стандарты IEEE, в то время как другие определяют свои собственные корпоративные стандарты. Грубо говоря, как только руководство вводит в действие согласованные профессиональные стандарты, а разработчики их выполняют, организация достигает уровня 3. Обычно это предполагает проведение специального обучения персонала. Допускается настройка стандартного процесса для конкретной команды применительно к конкретным обстоятельствам. Хотя организации уровня 3 в состоянии производить программное обеспечение гарантированного качества и таких организаций относительно немного, им все же не хватает возможности точно предсказывать затраты на проект. Такие организации в состоянии достаточно надежно сделать предсказание только для проектов, которые полностью аналогичны уже выполненным ранее.

Процесс: документированный; стандартный; настраиваемый.

Результат: целостность.

Недостаток: результаты не вполне предсказуемы.

Уровень 4: Управляемый. Уровень 4 соответствует организациям, которые могут точно предсказать сроки и стоимость работы. Один из способов, которым это делается, состоит в том, чтобы классифицировать работы и их части и измерять и сохранять данные о стоимости и трудозатратах на проектирование и реализацию этих частей. Такие измерения накапливаются в базе данных, и на их основе делаются оценки новых работ. Как отмечает Хэмфри, это еще не «ракетные технологии», но это требует значительных организационных возможностей.