The user interface for the system must:

7. Prioritize graphical application implementations over text-based displays wherever possible and appropriate. A particular example is selecting a physical or logical component below the node level in order to perform a snapshot, create a trouble ticket, run a test, etc.; the operator should be able to click on the component (or representation) rather than typing in component identifiers.

8. Ensure that window multiple active applications simultaneously, without restrictions; any performance issues relative to multiple applications are clearly documented for uses.

9. Support active applications as icons; i.e., running without an active window.

10. Support cut and paste between all management applications; e.g., the ability to paste test results, event text, snapshot data, or configuration information into a trouble ticket.

11. Synchronize real-time data between applications; i.e., if multiple status windows are active simultaneously, a parameter of status change in one window will be immediately updated in all other windows.

12. Update all windows while displayed, even though only one window will accept user input.

13. Allow simultaneous access to any and all system capabilities for multiple operators at one or many locations.

14. Minimize the use of «locking» features, which restrict multiple operators from using the same applications.

15. Support an optional text-entry interface with scripting and programming capability.

16. Demonstrate a common look and feel for all functions without the use of text-based files.

17. Provide a customer-usable audit trial of all operator actions, with the option to save and view multiple session files; the trial must not be limited to disruptive operations, but rather must contain a listing of all operator activity.

18. Provide «Tutor mode» with simulation.

19. Provide status of ongoing actions and background tasks such as downloads, uploads, and archives.

20. Multiple device actions (views, aggregates, and multiple mouse selections); use for event logs and queries, tests on multiple devices, stats collection setups, trouble tickets, extraction filters, etc.

21. Support customization where possible (help text, event text, tags and priorities, icons, screens, etc.)

Определите, какие управленческие и поддерживающие процессы необходимы в Вашей организации-разработчике, и дайте обоснование Вашего перечня.

Представьте Ваш пошаговый план перехода на требующийся Вашему проекту процесс разработки и обоснуйте его.

3. Модели зрелости способностей cmm/cmmi

Модель зрелости способностей к разработке программного обеспечения CMM (Capability Maturity Model) была разработана Институте технологии программирования (Software Engineering Institute – SEI) в начале 1980-х годов в ответ на запрос Правительства США: «Почему разработка программного обеспечения обходится так дорого, а качество поставляемого программного продукта и сроки его разработки часто не соответствуют заявленным ожиданиям?» Ответом SEI стала первая тщательно проработанная им модель процесса разработки ПО, получившая название CMM.

Уже в течение первых 5 лет после своего появления эта модель была внедрена в более чем 300 тысячах организаций-разработчиков программных продуктов по всему миру и получила практическое подтверждение своей ценности и полезности. С конца 1980-х годов обязательным условием участия компании разработчика в тендере на получение госзаказа в США стало наличие подтвержденного уровня зрелости не ниже 2 или 3 по этой модели. В последствии она была дополнена рядом других производных от нее моделей, а в начале 2000-х годов эта модель была преобразована в CMMI (где I от Integrated), охватывающая не только производственные процессы по разработке ПО, но и сопровождающие разработку бизнес-процессы.

Подтверждение уровня зрелости осуществляется экспертами, получившими соответствующую подготовку и сертификат от SEI. Такое официальное оценивание (formal assessment) проводится на площадке предприятия группой экспертов, в которую, кроме того, обязательно включается представитель оцениваемой организации (обычно руководитель группы обеспечения качества).

В соответствии с установленными процедурами и планом оценивания, эксперты опрашивают разработчиков, изучают представленные документы по разработке и через 2-3 дня работы выносят свое предварительное заключение, которое можно [частично] оспорить, представив дополнительные документы по отдельным проектам. После рассмотрения представленных дополнительных документов и, при необходимости, после связанных с этим дополнительных вопросов к разработчикам, экспертная комиссия выносит свое окончательное суждение об уровне зрелости данной организации по модели CMM и предлагает рекомендации по дальнейшему совершенствованию ее процесса.

Главное достижение моделей CMM/CMMI – это выявление тех производственных деятельностей, которые необходимы для качественного и предсказуемого выполнения программных проектов при заданных условиях на качество, сроки и бюджет (Рис. 1), и выработка рекомендаций по улучшению процесса в данной организации.

Каждая частная деятельность в общем объеме работ по разработке ПО имеет несколько целей, характерных именно для этой деятельности, на достижение которых нацелен весь ход ее исполнения, и базируется на обязательстве исполнить (commitment to perform) и возможности исполнить (ability to perform) данную деятельность назначенными исполнителями. Ход исполнения каждой такой деятельности должен регулярно проверяться, а текущие промежуточные результаты измеряться и анализироваться по объективным показателям и в сравнении с заданными целевыми (плановыми) значениями (Рис. 20).

Конкретный состав и формулировка целей, обязательств и возможности исполнения, конкретные способы проверки исполнения, измерения и анализа результатов этих деятельностей могут различаться в проектах и организациях, в свой совокупности отражая уровень зрелости исполнителя как профессионального разработчика ПО.

Рис. 20. Мета-модель деятельностей

14. Ключевые области процесса в модели cmm

Модель CMM (Рис. 21) определяет 5 уровней зрелости, с 1-го по 5-й; по мере подъема по этим уровнем повышается зрелость процесса разработки и он становится все более предсказуемым. На каждом уровне, начиная со 2-го, определяется ряд «ключевых областей процесса» (Key Process Area – KPA), представляющих собой группы взаимосвязанных деятельностей, необходимых для выполнения разработки на данном уровне зрелости, причем каждый последующий уровень включает в себя все ключевые области процесса предыдущего уровня – строится на его базе. Важно не только исполнять указанные деятельности, но исполнять их с высокой оценкой соответствия поставленным целям и другим атрибутам данной ключевой области процесса.

Всего модель CMM определяет 18 ключевых областей процесса. Для каждой из этих ключевых областей модель CMM называет деятельности, которые должны исполняться (от 3 до 5), формулирует их цели (от 2 до 4) и конкретизирует, в чем именно должны проявляться желание исполнить и возможность исполнить данную ключевую область процесса.

Модель CMM не формулирует, как именно должна выполняться та или иная определенная в модели деятельность; она только называет эти деятельности, оставляя порядок и методику их исполнения на усмотрение разработчиков. Единственное, что требуется – это наличие подтверждающих документов (evidences), свидетельствующих о совершении данной деятельности и позволяющих судить о качестве ее исполнения в свете сформулированных в модели целей для ключевой области процесса, к которой данная деятельность относится.

Первый уровень зрелости называется начальным (initial), потому что не предполагает никаких знаний о процессе разработки; все деятельности в нем выполняются ad hoc (как придется, для данного случая), поэтому на этом уровне отсутствует какая-либо предсказуемость результата разработки. Это не значит, что на первом уровне не бывает удачных проектов, однако сказать что-либо определенное о продукте можно только по завершении разработки (если только она будет завершена).

Рис. 21. Уровни и ключевые области процесса в модели CMM

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

(1). Управление требованиями (Requirements Management). Основной целью данной ключевой области является обеспечение возможности установления единого с заказчиком понимания требований к разрабатываемому программному продукту. Именно этот этап является наиболее сложным, поскольку заказчик в начале работы над проектом часто имеет только более или менее определенные пожелания, что должно делать проектируемое программное изделие. Кроме того, в процессе выполнения проекта изменяются представления о самом продукте и у заказчика, и у разработчика. Поэтому в ключевой области «Управление требованиями» предусмотрена работа с требованиями заказчика по исключению из них неопределенностей и неоднозначностей и преобразованию исходных требований в более или менее формализованную спецификацию требований. Это дает возможность составлять такую спецификацию требований, в которой установлено однозначное определение всех деталей, касающихся будущего продукта, и определены эффективные методы его тестирования.

(2) Планирование проекта (Software Project Planning). Цель данной ключевой области заключается в создании условий для составления реально выполнимого проектного плана и реального графика выполнения проекта и собственно разработка этих документов. Результатом деятельностей в этой ключевой области является проектный план и график его выполнения. Под проектным планом понимается один план или совокупность связанных планов по реализации различных компонентов проекта в соответствии с процессом. В этой ключевой области осуществляется некоторая совокупность деятельностей, связанных с разработкой установленного набора согласованных планов, которые в дальнейшем постоянно используются как средство отслеживания хода разработки продукта и управления программным проектом.

(3) Отслеживание проекта (Software Project Tracking and Oversight). Цель данной ключевой области – установление верной отображаемости хода выполнения проекта, которая должна быть организована так, чтобы обеспечивалась возможность наглядного обнаружения отклонений от планов на ранней стадии их возникновения и имелась наглядная картина хода выполнения проекта. Такая организация отображаемости проекта придает руководителям всех уровней потенциал своевременного принятия корректирующих действий для предотвращения возможных надвигающихся проблем.

(4) Управление субподрядчиками (Subcontractor Management). Целью данной ключевой области является определение правил выбора подрядчиков и субподрядчиков для выполнения тех видов работ по разработке программного продукта, которые по разным причинам нецелесообразно выполнять внутри организации-исполнителя. Организация-исполнитель в этом случае обеспечивает эффективное управление своими субподрядчиками, координирует их деятельности по разработке программного продукта и включению получаемых рабочих продуктов в состав создаваемого программного продукта и несет полную ответственность перед заказчиком за соблюдение всех условий и требований к разработке и конечному продукту.

Эта область имеет в себе элементы всех ключевых областей второго уровня зрелости. Однако деятельности в этой области могут отсутствовать в стандартном процессе предприятия, если программный проект выполняется целиком силами данного предприятия и внутри него.

(5) Обеспечение качества (Software Quality Assurance). Цель данной ключевой области – создание условий для поддержания надлежащего качества разработки и поставляемого продукта. Деятельности в этой ключевой области обеспечивают требуемые эффективность процесса и качество выпускаемого продукта и осуществляются в соответствии со специальным планом по обеспечению качества, в котором эти деятельности должны быть определены и взаимоувязаны с остальными рабочими планами.

(6) Управление конфигурацией (Software Configuration Management). Цель данной ключевой области заключается в обеспечении единой системы идентификации компонентов программного продукта, включая среду его разработки, контроля над изменениями и управления изменениями этих компонентов и обеспечении целостности всего продукта. Эти деятельности должны выполняться на протяжении всего жизненного цикла разработки. Как и в случае обеспечения качества, управление конфигурацией осуществляется по специальному плану, в котором взаимоувязан весь предусмотренный для этого перечень деятельности.

Третий уровень зрелости называется определенным (defined), потому что для процесса этого уровня каждая деятельность определена в книге процесса предприятия, и все участники проекта обязаны строго следовать ее предписаниям. К предыдущим шести ключевым областям добавляются еще семь:

(7) Нацеленность процесса (Organization Process Focus). Цель ключевой области заключается в выделении набора компонентов конкретной реализации процесса, который обусловил бы требуемые способности данного предприятия по разработке программных продуктов. Результатом является выделение некоторого набора компонентов процесса для его дальнейшего определения. Кроме того, в этой ключевой области явно формулируются цели, ради которых процесс третьего уровня вводится. При этом для всех сотрудников предприятия должно быть обеспечено ясное понимание всех преимуществ, которые будут достигнуты в результате успешной аттестации предприятия на заданный уровень зрелости.

(8) Определение процесса (Organization Process Definition). Цель – окончательное определение каждого компонента конкретной реализации процесса из набора компонентов, выделенных в ключевой области “Нацеленность процесс”, так, чтобы обеспечивалась эффективность процесса по всем проектам, выполняемым на предприятии. В результате происходит определение стандартного процесса данного предприятия. Основным итогом является перечень технологических и организационных деятельностей, набор механизмов, формальных процедур и стандартов, которые должны быть описаны в книге процесса таким образом, чтобы обеспечивалась их однозначное понимание. Определенный таким образом стандартный процесс подлежит внедрению на предприятии и последующему систематическому совершенствованию.

(9) Программа обучения (Training Program). Цель данной ключевой области – создания необходимых условий для развития навыков и знаний у исполнителей проектов для более эффективного выполнения поставленных перед ними задач. Непрерывное плановое повышение квалификации является важным элементом организационной дисциплины. В каждом проекте отдельно должно быть определено, какие навыки, в каком объеме и для каких деятельностей нужны данному проекту, должно быть обеспечено необходимое обучение в соответствии с выявленными пробелами в знаниях. На предприятии должна быть постоянно действующая эффективная в смысле минимизации затрат при получении заданной выгоды программа повышения квалификации, должны быть соответствующие этой программе планы, организационное и ресурсное обеспечение.

(10) Интегрированное управление (Integrated Software Management). Цель этой ключевой области состоит в том, чтобы обеспечить соединение всех технологических и организационных процессов, протекающие на предприятии (технический процесс разработки ПИ, процесс управления проектом, процесс управления предприятием в целом и другие процессы) в единый согласованный и эффективный (интегрированный) процесс управления. Первоначально интегрированный процесс должен строиться исходя из тех компонентов стандартного процесса, которые определены для третьего уровня зрелости. В дальнейшем он должен совершенствоваться и включать в себя компоненты процессов более высоких уровней зрелости. Из стандартного интегрированного процесса путем подгонки создается проектный процесс, наилучшим образом приспособленный для выполнения конкретного проекта.

(11) Технология разработки продукта (Software Product Engineering). Цель данной ключевой области – определение технологического процесса разработки программного продукта. Технологический процесс предприятия должен задавать всю технологическую деятельность по результативной разработке качественных программных продуктов от начала и до конца. Он должен включать стандарты и описания всех технических видов деятельности, таких как анализ и составление требований, высокоуровневое и детальное проектирование, кодирование и отладка, системное тестирование и т.п. Определенный таким образом технологический процесс обязателен к соблюдению в каждом проекта. Если для какого-либо проекта необходима так называемая «подгонка» стандартного процесса предприятия (process tailoring), то она осуществляется в соответствии с принятой процедурой и документированием всех отклонений от стандартного процесса с обязательным обоснованием всех отклонений.

(12) Межгрупповая координация (Intergroup Coordination). Цель этой ключевой области заключается в обеспечении условий для активного повторного использования знаний, продуктов и технологических приемов, накопленных на предприятии отдельными группами исполнителей при выполнении разных проектов. Активизация повторного использования достигается путем деятельного взаимодействия отдельных групп исполнителей друг с другом. Взаимодействие между всеми группами разработчиков исполняется в соответствии с планом, координируется и управляется. Обычные формы межгупповой координации – общие семинары, операционные обзоры и научно-практические конференции сотрудников, часто с участием заказчиков и приглашенных лиц.

(13) Товарищеские обзоры (Peer Reviews). Цель ключевой области – обеспечение условий для раннего обнаружения и наиболее действенного устранения ошибок и дефектов, обнаруженных в продуктах проекта. Важным результатом деятельностей в этой ключевой области является выявление и анализ причин, вызвавших дефекты, выработка эффективных мероприятий по предотвращению выявленных причин в будущем. Обзоры с коллегами – это важный и эффективный технологический прием, который является компонентом технологического процесса разработки программного продукта. Обязательному товарищескому обзору подлежат низкоуровневый проект и программный код, но желательно, чтобы такой обзор проходили, как минимум, все поставки заказчику.

Четвертый уровень зрелости получил название управляемый (managed), потому что процесс этого уровня обеспечивает возможность реального управления производительностью, длительностью жизненного цикла разработки и качеством выпускаемого программного продукта на основе постоянных измерений и анализа различных метрик, характеризующих процесс разработки и создаваемые в нем рабочие продукты. На этом уровне к 13 ключевым областям двух предыдущих уровней добавляются еще две.