Управление разработкой и аттестация программных продуктов

Управление разработкой программного средства – это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков программных средств, на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества, выполнения сроков и бюджета разработки программного средства. Эту деятельность называют управлением программным проектом. Здесь под программным проектом понимают всю совокупность работ, связанную с разработкой программного средства, а ход выполнения этих работ называют развитием программного проекта.  К необходимым условиям работы коллектива относятся помещения, аппаратно-программные средства разработки, документация и материально-финансовое обеспечение. Планирование и контроль предполагает разбиение всего процесса разработки программного продукта на отдельные конкретные работы (задания), подбор и расстановка исполнителей, установление сроков и порядка выполнения этих работ, оценка качества выполнения каждой работы. Финальной частью этой деятельности является организация и проведения аттестации (сертификации) программного продукта, которой завершается стадия разработки программного продукта. Хотя виды деятельности по управлению разработкой могут быть весьма разнообразными в зависимости от специфики разрабатываемого программного продукта и организации работ по его созданию, можно выделить некоторые общие процессы (виды деятельности) по управлению его разработкой:

• составление плана-проспекта по разработке;

• планирование и составление расписаний по разработке;

• управление издержками по разработке;

• текущий контроль и документирование деятельности коллектива по разработке;

• подбор и оценка персонала коллектива разработчиков.

Составление плана-проспекта по разработке программного продукта включает формулирование предложений о том, как выполнять разработку. Прежде всего, должно быть зафиксировано, для кого разрабатывается программный продукт:

• для внешнего заказчика,

• для других подразделений той же организации,

• или является инициативной внутренней разработкой.

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

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

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

• затраты на аппаратное оборудование;

• затраты на вербовку и обучение персонала;

• затраты на оплату труда разработчиков.

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

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

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

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

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

Рисунок 1- Структура управления разработкой программных средств.

По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему непосредственно подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет планирование и составление расписаний работы этих бригад по разработке соответствующего программного продукта.

Считается нецелесообразным разработка большого программного продукта (программной системы) одной большой единой бригадой разработчиков. Для этого имеется ряд причин. В частности, в большой бригаде время, затрачиваемое на общение между ее членами, может быть больше времени, затрачиваемого на собственно разработку. Отрицательное влияние оказывает большая бригада на строение программного продукта и на интерфейс между отдельными его частями. Все это приводит к снижению надежности программного продукта. Поэтому обычно большой проект разбивается на несколько относительно независимых подпроектов таким образом, чтобы каждый подпроект мог быть выполнен отдельной небольшой бригадой разработчиков (обычно считается, что в бригаде не должно быть больше 8-10 членов). При этом архитектура программного продукта должна быть такой, чтобы между программными подсистемами, разрабатываемыми независимыми бригадами, был достаточно простой и хорошо определенный системный интерфейс.

Наиболее употребительны три подхода к организации бригад разработчиков:

• обычные бригады,

• неформальные демократические бригады,

• бригады ведущего программиста.

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

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

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

• распорядитель бригады, выполняющий административные функции;

• технический редактор, осуществляющий доработку и техническое редактирование документов, написанных ведущим программистом;

• инструментальщик, отвечающий за подбор и функционирование программных средств, поддерживающих разработку программной подсистемы;

• тестировщик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;

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

Кроме того, к работе бригады может привлекаться для консультации эксперт по языку программированию.

Важное место в управлении разработкой программного продукта отводится управлению обеспечением качества. Для руководства этой деятельностью назначается специальный менеджер, подчиненный непосредственно директору, – менеджер по качеству. Ему непосредственно подчинены формируемые бригады по контролю качества. Эти бригады работают с отдельными проектами, но непосредственно соответствующим менеджерам проектов не подчинены, сохраняя тем самым свою независимость от них.

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

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

Различают два вида таких стандартов:

• стандарты ПС (программного продукта),

• стандарты процесса создания и использования ПС.

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

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

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

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

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

3. Планирование и составление расписаний по разработке ПС

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

Рисунок 2 - Описание на псевдокоде процесса планирования и составления расписаний по разработке ПС.

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

Далее начинается итерационный процесс, основу которого составляет повторяющиеся составления расписаний.

Составление расписания заключается

• в разделении всей работы, необходимой для выполнения проекта, на отдельные самостоятельно выполняемые задания;

• в составлении сетевого графика выполнения заданий;

• в составлении гистограммы выполнения заданий;

• в расстановке исполнителей заданий.

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

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

Завершающим этапом разработки программного продукта является его аттестация, подводящая итог всей разработке. Аттестация программного средства - это авторитетное подтверждение качества программного средства. Обычно для этого создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит приемо-сдаточные испытания программного средства с целью получения необходимой информации для оценки его качества. Под испытанием Программного продукта понимают процесс проведения комплекса мероприятий, исследующих пригодность программного средства для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. В этом процессе проверяется полнота и исследуется качество представленной программной документации, производится необходимое тестирование программ, входящих в состав программного продукта, а также исследуются и другие свойства, декларированные в его спецификации качества. На основе полученной информации комиссия должна установить, в какой степени программный продукт выполняет декларированные функции и в какой степени программное средство обладает декларированными примитивами и критериями качества. Решение аттестационной комиссии о произведенной оценке качества программного продукта фиксируется в соответствующем документе (сертификате), который подписывается членами комиссии.

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

Различают следующие группы методов оценки примитивов качества программного средства:

• непосредственное измерение показателей примитива качества;

• тестирование программ программного продукта;

• экспертная оценка на основании изучения программ и документации программного продукта.

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

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

В некоторых случаях для оценки качества программного продукта проводятся дополнительные полевые или промышленные испытания. 

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

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

Многие примитивы качества программного продукта трудно проверить с точки зрения их (объективной) оценки. В этих случаях иногда применяют метод экспертных оценок. В этом случае назначается группа экспертов. Каждый из этих экспертов в результате изучения представленной документации составляет свое мнение об обладании программным продуктом требуемым примитивом качества. Затем голосованием членов этой группы устанавливается оценка требуемого примитива качества всего программного средства, т.е. получаемая оценка является некоторым усреднением совокупности субъективных оценок. Эта оценка может производиться как по двухбалльной системе ("обладает" - "не обладает"), так по пятибальной системе в соответствии с требованиями относительно этого примитива, сформулированными в спецификации качества аттестуемого программного продукта.

Цель  аттестации - проверка и фиксация реальных показателей качества предъявленного программного продукта. Если аттестационная комиссия подтверждает, что предъявленное ПС соответствует всем требованиям относительно его качества, сформулированным во внешнем описании этого программного продукта, то считается, что его разработка завершена успешно и заказчик обязан принять это программное средство. Если же будут обнаружены отступления от этих требований, то должны приниматься определенные решения о продолжении или прекращении разработки предъявленного программного средства, но это уже вопрос взаимоотношений между заказчиком и разработчиками. Таким образом, аттестационная комиссия, подписывая документ о произведенной оценке качества программного продукта, принимает на себя определенную ответственность за гарантию качества этого программного продукта.