Организация планирования процесса создания программного изделия в фазах оценки и использования

из "Методы управления проектированием программного обеспечения "

Группа планирования осуществляет текущий контроль за изделием в фазе использования, непрерывно наблюдая за уведомлениями о дефектах и запросами на расширение. При этом кто-то должен определять истинную необходимость внесения изменений, связанных с устранением ошибок и дефектов, или целесообразность создания новой версии с целью реализации требуемого расширения возможностей. Следует также пересматривать и постепенно снижать уровень поддержки, в результате чего должна быть выработана рекомендация о снятии программного изделия с производства. Таким лицом может быть администратор планирования, который способен оценить целесообразность того или иного предложения, поэтому именно он рассматривает все рекомендации, касающиеся текущего контроля за изделием в фазе использования. [c.80]
Рекомендация о снятии изделия с производства и обслуживания может поступить от любой функциональной группы группа разработки может предложить заменить его новым изделием, группы сопровождения и поддержки могут предложить высвободить ресурсы. Однако независимо от первоисточника рекомендации последнее слово принадлежит группе планирования. Никакая другая группа не имеет такого круга обязанностей, который необходим для ответственного принятия подобного решения. Поэтому только группа планирования определяет, когда дать жизнь программному изделию и когда положить ей конец. [c.80]
Вполне естественно для администратора планирования (а еще более естественно для руководителя целевой программы) выступать в роли организатора некоторых из фазовых обзоров, однако эту роль могут исполнять и другие лица, в частности представители групп, ответственных за организацию обсуждения важнейшей документации. [c.81]
Независимо от того, кто проводит обзор, группа планирования обладает решающим голосом в фазовых обзорах I, II, V и VI. [c.81]
Р10 — П20 — анализ соглашения о требованиях, И01 — И10 — анализ плана испытаний, Б01 — Б10 — анализ плана выпуска документации, Д01 — Д10 — анализ плана поддержки, Д11 — Д12 — анализ рекламных материалов, И32 — ПЗО — анализ отчета об испытаниях класса В. [c.84]
Фазовый обзор VI проводится каждый раз, когда на повестку дня ставится вопрос о дальнейшем снижении уровня поддержки программного изделия. Это можно делать через регулярные интервалы времени (вероятно, не чаще, чем ежеквартально, но и не реже, чем один раз в год) и несомненно по истечении гарантийного срока, разумеется, в предположении, что изделие поставляется с конечным гарантийным сроком. Фазовый обзор VI целесообразно основывать на конфигураторе (табл. 6.1) это идеальное средство для определения целесообразных уровней поддержки, и оно хорошо подходит для периодических рассмотрений и проверок. [c.85]
Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом. [c.85]
Роль группы планирования в фазовых обзорах в упрощенном виде отражена в табл. 6.3. На рис. 6.6 в терминах сетевого планирования (разд. 14.6) представлена деятельность группы планирования в период от начала фазы анализа осуществимости до окончания фазы оценки. [c.85]
Функция разработки охватывает то, что большинство людей подразумевает, говоря о программах или о процессе программирования. Это верно потому, что функция разработки включает ответственность за проектирование, создание спецификаций, документирование, кодирование и отладку любой программы для ЭВМ, в том числе и программных изделий. Если здесь читатель усомнится в том, что для создания программного изделия требуется еще что-то, кроме перечисленных выше этапов, то ему следует вернуться к чтению гл. 2 и лишь затем двигаться дальше, поскольку очень важно четко представлять себе место функции-разработки в общем процессе. Несмотря на перечисленные выше многочисленные обязанности, выполняемые в рамках этой функции, для того чтобы создать программное изделие, требуется проделать и много другой работы. [c.86]
Эта глава в основном о том, как надо управлять проектом. С точки зрения функции разработки необходимость руководства проектом является наиболее существенным отличием процесса создания программного изделия от процесса программирования. Как и в любом виде программирования, основная ответственность за успех или неудачу программного обеспечения лежит на тех, кто его проектирует и внедряет. Поэтому именно функция разработки предусматривает ответственность за правильную организацию процесса создания программного изделия. [c.86]
Поскольку темой книги является не собственно программирование, а руководство этим процессом, взгляд на разработку, изложенный в данной главе, мало чем может помочь в изучении таких вопросов, как проектирование или внедрение программного обеспечения. Но эти вопросы имеют жизненно важное значение для понимания программирования как инженерной дисциплины, и поэтому читателю следует дополнить сведения, полученные из этой книги, чтением работ, приведенных в библиографии к работе [38], или любых других книг на аналогичные темы. [c.86]
Организуя процесс разработки программного изделия, необходимо иметь в виду основную идею иерархической декомпозиции проекта, при которой всегда сохраняется завершенность (с точки зрения учета всех аспектов проектирования) на различных этапах все более увеличивающейся детализации. Декомпозиция проекта является вторым этапом в цепочке, включающей три этапа декомпозиции, следующих друг за другом. Первый этап — декомпозиция плана, третий—программная декомпозиция, часто называемая программированием сверху вниз или нисходящим программированием. [c.87]
При тщательном выполнении декомпозиции проекта удается выделить задачи анализа осуществимости проекта, внешнего и внутреннего проектирования, программирования и компоновки. При этом предполагается вертикальная организационная структура группы разработки, в которой предусматривается старший управленческий персонал, ориентированный на выполнение анализа осуществимости проекта (т. е. определяющий назначение программного изделия и требования к нему), а также старший технический персонал, создающий внешние и внутренние проекты, и младший технический персонал, участвующий в написании, отладке и компоновке программ. Такое разделение труда способствует проявлению творческих способностей в любой фазе разработки, помогает избежать излишних затрат ресурсов на заведомо бесперспективные проекты, открывает для сотрудников наиболее заманчивые пути административного и технического роста и, кроме того, представляет возможность контроля за упорядоченным переходом от одной фазы проекта к другой. [c.87]
Какой же состав группы разработки программного изделия является наиболее подходящим Тесное взаимодействие с другими функциональными группами, опыт, необходимый для выполнения большинства видов Деятельности, относящихся к разработке, а также необходимость обеспечения наивысшей производительности труда (без чрезмерного сужения обязанностей) —все это предполагает невысокую степень соподчиненности. В проектах первого уровня должны участвовать 1—5 человек. В зависимости от сложности в проектах или функциональных подразделениях второго уровня должно быть занято 6—15 участников. В проектах или функциональных подразделениях третьего уровня должно быть занято 20—60 человек в зависимости от сложности задач. Руководителю разработки программного обеспечения следует стремиться к тому, чтобы непосредственно управлять деятельностью группы, состоящей не более чем из семи человек в противном случае он рискует потерять способность к осмыслению технического существа работ, за выполнение которых он несет ответственность. Используя терминологию из теории информации, можно сказать, что в этом случае он рискует превысить пропускную способность своих каналов связи [9]. [c.88]
Тип человека, наиболее подходящего для осуществления разработки систем программного обеспечения, — это высокообразованный, проницательный, энергичный, настойчивый человек. Он хорошо соответствует принципам целевого управления, поскольку всегда хочет знать, что ожидают от него и когда именно, каким образом он может превзойти ожидания и почему его деятельность оценивается хорошо или плохо, т. е. предпочитает знать, от чего зависит его продвижение по службе. [c.88]
Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний. [c.89]
Другие приемы структурного программирования обычно связаны с приведенным выше ограничением логической структуры программ. Один из них заключается в выделении с помощью отступов логической структуры в исходном тексте программы, что облегчает чтение листинга, а другой — в разбиении программы на функциональные блоки таким образом, чтобы текст каждого из них занимал не более одной страницы и мог быть охвачен одним взглядом. Очевидно, что применение этих приемов требует последовательного документирования блок-схем алгоритмов. Как правило, реализация концепций структурного программирования требует наличия администратора библиотеки поддержки разработки, что отчасти объясняется увеличением числа обслуживаемых модулей и, кроме того, просто является хорошим практическим правилом. [c.90]
Наконец, в вершине иерархии методов проектирования помещается концепция бригады главного программиста, в состав которой входят главный программист, его помощник, администратор библиотеки, а также от одного до пяти проблемных программистов. Главный программист является старшим техническим руководителем группы, который управляет ею и вместе со своим помощником проектирует, кодирует и объединяет модули высокого уровня или наиболее важные модули. Помощник главного программиста, на котором лежит ответственность за разработку некоторых из этих модулей, также является старшим техническим экспертом, он, кроме того, всегда должен быть готов взять на себя роль главного программиста бригады. Администратор библиотеки, являющийся высококвалифицированным секретарем, осуществляет функции, связанные с библиотекой поддержки разработки. Проблемные программисты составляют младший технический персонал, который по указанию главного программиста занимается написанием и отладкой отдельных модулей, не играющих критической роли в системе. Используя методы нисходящего проектирования, структурного программирования, а также библиотеку поддержки разработки, главный программист и его помощник тщательным образом проверяют тексты программы, написанные проблемными программистами с точки зрения функциональной полноты этих программ и их соответствия правилам структурного программирования. [c.91]
Обозначения Р — группа разработки О — группа обслуживания И — группа испытаний. [c.92]

Вернуться к основной статье