Организация поддержки программного изделия 175 [c.175]
Организация поддержки программного изделия в фазах конструирования и программирования [c.180]
Организация поддержки программного изделия в фазе оценки [c.184]
Перечисляются все вспомогательные средства освоения и ввода в действие, разработанные специально для данного изделия сведения о них содержатся в плане организации поддержки программного изделия. Указываются и все другие аналогичные средства, которые являются обязательными для организации использования изделия или описываются далее в разделе, касающемся процедур внедрения, даже если эти средства не являются новыми. Указываются развернутые идентификационные номера соответствующих средств. [c.298]
Эту книгу можно прочитать от начала до конца и тем самым полностью ознакомиться с методологией организации проектирования программных изделий. Если же читателя интересуют не все аспекты управления, то можно прочитать лишь отдельные главы (часть II построена по функциональному принципу) и изучить только требуемые функции управления планирование, разработку, обслуживание, выпуск документации, испытания, организацию поддержки или сопровождение. В книге очень широко используется специальная терминология, однако ключевые термины выделяются курсивом и включены в предметный указатель. В каждой главе можно также найти ссылки на литературу для более глубокого обсуждения сложных вопросов, что повышает возможность использования книги в качестве справочного пособия. [c.17]
Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний. [c.89]
Использование программного изделия продолжается до тех пор, пока оно отвечает интересам производителя программных средств, и в это время производитель должен быть готов к соответствующей поддержке программного изделия. Для группы обслуживания это означает главным образом организацию исправления ошибок, редактирования и расширения возможностей программного изделия. [c.130]
Термины документация и справочные материалы относятся к печатной продукции, предназначенной для пользователей программного изделия. Термин документы используется по отношению к планам и спецификациям, которые изготавливаются для сотрудников, участвующих в проектировании плановиков, разработчиков, редакторов, испытателей, персонала групп поддержки и сопровождения. Это различие вносит ясность во взаимоотношения отдельных подразделений организации, проектирующей программные изделия. [c.135]
Имеются весьма основательные доводы в пользу отделения друг от друга некоторых из функций, правильное выполнение которых способствует успешному выпуску изделия. К тому времени, когда почерпнутые из этой книги методы и средства будут введены в действие, такое разграничение функций наверняка можно будет реализовать. И тогда следует удовлетвориться, что группа испытаний работает независимо от группы разработки и потому не подчинена и не может ей подчиняться. Затем следует обособить функцию обслуживания, которая должна в равной степени охватывать обеспечение нормальной деятельности всех остальных групп. При этом, однако, нельзя забывать о планировании, организации поддержки, документирования и сопровождения программных изделий в целях лучшего удовлетворения потребностей пользователя. Если потребности пользователя изменяются, следует без колебаний преобразовывать и эти функции. Приняв такую стратегию, можно-смело приступать к более полной реализации принципов проектирования программного обеспечения и применять методы управления этим процессом точно так же, как их применяют в целом или по частям преуспевающие. руководители. [c.20]
Управление проектированием программного изделия включает семь функций планирование, разработку, обслуживание, выпуск документации, испытания, поддержку и сопровождение. На рис. 5.1 показан возможный вариант иерархической декомпозиции этих функций. Такая идеализированная организация вряд ли может существовать, поскольку она предполагает полную обособленность процессов, связанных с проектированием программных изделий, от других видов деятельности и изолирование всех функций друг от друга. Однако эта идеализация облегчает последующее рассмотрение. Необходимость в том или ином организационном подразделении [c.49]
По окончании фазы исследований группа планирования первым делом рассматривает и утверждает планы организации поддержки для каждого изделия или совокупности изделий. В течение всей фазы конструирования группа выпуска документации и группа испытаний готовятся к рассмотрению плана изданий документов и плана испытаний. Группа планирования (обычно под руководством администратора планирования) анализирует эти планы главным образом на их соответствие предписываемым формам и совместимость с соглашением о требованиях, конфигуратором и планом выпуска программного изделия. В течение фазы программирования группа поддержки готовит свой план, а группа планирования рассматривает его в том же порядке, в каком до этого рассматривались план изданий и план испытаний. [c.79]
Помимо кодирования, отладки и компоновки, деятельность группы разработки связана с демонстрацией работающего программного изделия в конце фазы программирования и организацией взаимодействия группы разработки с другими функциональными группами. Сначала на рассмотрение поступает план поддержки. В группе разработки должна прежде всего существовать уверенность в обоснованности плановых сроков и правильности предположений группы поддержки, касающихся описания программного изделия. Любые ошибки в описании характеристик программного изделия или определении сроков его готовности, которые могут дойти до пользователя через рекламные материалы, способны породить недоразумения или, хуже того, штрафы за невыполнение [c.112]
Процесс выполнения многочисленных обязанностей, о которых шла речь в предыдущем разделе, можно организовать различными способами. В гл. 5 предполагается, что все или большая часть соответствующих услуг сосредоточены в рамках одного организационного подразделения. Если разработка изделия ведется для замкнутого круга потребителей, так что не требуется специальная организация сбыта, функция поддержки может осуществляться в рамках сектора программных изделий. Если объем услуг по поддержке невелик и соответствующее подразделение нецелесообразно выделять в виде автономной организационной единицы, лучше всего поручить выполнение обязанностей по поддержке изделия группе сопровождения. Сопровождению и поддержке не свойственны напряженные планы, имеющие место при разработке изделия эти две функции тесно связаны с деятельностью по обнаружению ошибок и коррекцией программных средств. Следует всячески избегать передачи функции поддержки изделия разработчикам, ибо это может привести к срыву плановых сроков разработки. Так как основная задача поддержки — удовлетворение запросов пользователя, то последние должны иметь более высокий приоритет, чем любая другая работа, иначе возникнет угроза самому существованию функции поддержки как воплощения честного отношения к потребителю. [c.175]
Если выпускаемые программные изделия предназначены для продажи пусть даже по самой низкой цене (как это имеет место в случае совместной поставки аппаратных и программных средств), то в составе проектной организации должен быть отдел сбыта. Тогда лучше всего передать функцию поддержки именно этому подразделению, что обеспечит сохранение контроля над отношениями с потребителями. Конкретное распределение обязанностей внутри подразделения сбыта диктуется размерами организаций-потребителей и их географическим положением. [c.175]
Тот факт, что документы, рекомендации по выпуску программного изделия и решения об организации поддержки до их утверждения рассматриваются линейным руководством, считается само собой разумеющимся. Однако повышенное внимание, уделяемое в предлагаемой методологии фазовым обзорам, проводимым совместно несколькими группами, и объединенному рассмотрению внешних спецификаций, может вызвать недоумение. Причиной нашего интереса к обзорам является данное в начале этой книги определение программного изделия как универсального программного обеспечения. Программное изделие должно удовлетворять многим требованиям, и для его создания необходима работа самых различных функциональных групп. Вследствие этого требуется, некоторый формальный механизм, который учитывал бы требования многих заинтересованных лиц, иначе эти требования можно упустить из виду или выделить для их согласования слишком мало времени в календарном графике разработки. [c.352]
Достижение целей отчасти гарантируется включением общих целей создания изделия в индивидуальные рабочие планы и организацией текущего контроля за их достижением. Существуют такие средства, помогающие достичь цели путем управления по методу исключения. Как будет показано ниже, соглашение о требованиях, план поддержки, распределение бюджета и другие средства уста--навливают те границы, в пределах которых не требуется использование обратной связи однако при нарушении таких границ необходимы немедленные управляющие воздействия. Существуют три основных критерия оценки эффективности той или иной деятельности конкретные свойства, затрачиваемое время и стоимость. Каждый из этих критериев имеет определенные границы действия, по достижении которых обязательно представляется отчет руководству о результатах. Фазовые обзоры, рассматриваемые в гл. 6, предусматривают периодический анализ процесса создания программного изделия даже в том случае, когда заданная граница еще не достигнута. [c.56]
Если применить все средства и методы, описанные в этом разделе, то конфигурационное управление должно давать удовлетворительные результаты, не будучи ни избыточным, ни чересчур узким. Конфигурационное управление имеет настолько большое значение для разработки программных изделий, что следует обеспечить по крайней мере ту степень управляемости, которая представлена здесь. Реализация многих из рассмотренных здесь мероприятий облегчается введением должности администратора библиотеки поддержки [6]. Удобным средством конфигурационного управления является разработанная фирмой Bell Laboratories система контроля исходных программ [66]. Большие военные проекты автоматизации, подобные системам навигации, перевозок и снабжения, предполагают применение тщательно разработанных систем конфигурационного управления описание таких систем можно найти в работах [67—73] знакомство по этим работам с существующими методами и средствами поможет решить вопрос о целесообразности их включения в собственную систему конфигурационного управления в той или иной организации. [c.344]