Версия программного изделия

Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом.  [c.85]


Новые редакции программного изделия, полученные после обработки заявки на исправление, а также новые версии программного изделия, появившиеся в результате обработки заявок на расширение или проверку, вызывают иногда необходимость повторного распространения в фазе использования, которое осуществляется группой обслуживания в том же порядке, как и первоначальное распространение.  [c.132]

С наибольшим риском связана эксплуатационная проверка первоначальной версии программного изделия. Эта ситуация возникает в результате передачи изделия,еще не подготовленного к распространению, в руки пользователя, который настолько нуждается в программном изделии, что не может ждать завершения  [c.185]

По мере внесения расширяющих и корректирующих изменений растет объем работы, связанной с ведением документации и выпуском печатных материалов, что вынуждает назначить руководителя, ответственного за координацию разнообразных видов деятельности по сопровождению, подобно тому как это делает руководитель проекта во время разработки изделия. Данный руководитель может быть выделен из штата группы обслуживания, если именно она, как описано в гл. 8, осуществляет административное управление сопровождением. Проводя усовершенствование изделия, следует принять меры предосторожности, чтобы не внести в него слишком большое число изменений, что неминуемо приведет к игнорированию эффективного механизма фазовых обзоров и к отставанию в работе группы выпуска документации, группы испытаний и даже группы поддержки по подготовке к освоению новой версии программного изделия.  [c.193]


Планируя создание новой версии программного изделия, в том числе деятельность, связанную с его корректировкой, проверкой и расширением, группа сопровождения подготавливает соответствующее соглашение о требованиях. Этот документ концентрирует внимание руководства на способах, сроках и причинах внесения основной массы изменений в новую версию. В соглашении о требованиях рассматриваются все поступившие запросы на расширение и приводятся соображения, подтверждающие или опровергающие целесообразность реализации каждого из них.  [c.195]

Спецификация версии программного изделия  [c.296]

В табл. 15.4 приведено оглавление стандартной спецификации версии программного изделия (СВ), отражающее описываемую ниже форму. В каждой СВ описывается только одно изделие.  [c.296]

Оглавление стандартной спецификации версии программного изделия  [c.297]

Версия программного изделия 333,  [c.381]

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

Проверка новых свойств. Этим испытаниям подвергаются только новые версии существующих программных изделий в целях оценки их новых функциональных возможностей. Функциональные свойства прежней версии проверяются только тогда, когда они взаимодействуют с новыми функциями. Проверка новых свойств обычно проводится в рамках испытаний класса А и В и выполняется в тех случаях, когда изделие подвергается лишь незначительным изменениям.  [c.154]


Механизм внесения усовершенствований в программное изделие называется системой заявок на расширение возможностей. В разд. 8.7 (гл. 8) описана роль группы обслуживания в обработке таких заявок, которая сводится к административному управлению процессом их реализации. Группа поддержки также играет административную роль. Она направляет в группу обслуживания заявки на расширение, оформленные на стандартных бланках (гл. 16, разд. 16.6), и через периферийных специалистов информирует пользователей о состоянии выполнения их запросов. Заявки на расширение иногда долго не рассматриваются или учитываются при разработке новой версии изделия, которая долго не может стать реальностью. Поэтому следует информировать пользователей о состоянии их запросов, соблюдая такт и стремясь не вызывать возможных нареканий. Центральная группа отсеивает дубликаты заявок, получаемых от периферийных специалистов, и в ходе рассмотрения запросов расширения представляет интересы группы поддержки. Обычно группа поддержки вносит предложения о сокращении поддержки, основываясь на опыте работы в условиях пользователя. Поэтому она и пересматривает, и утверждает соответствующие решения.  [c.188]

Если в основе изделия лежит какой-либо стандартный язык или код связи, следует указать документ, определяющий этот стандарт. Если выпускается новая версия существующего программного изделия, должны быть перечислены все соответствующие ему проектные документы и публикации. Если использование программного изделия связано со специальным оборудованием, необходимо указать соответствующую документацию.  [c.219]

Уровень поддержки 2 Не планируется новых версий или программных изделий-заменителей, поэтому заявки на расширение рассматриваться не должны все еще ожидается значительное количество заявок на исправление дефектов,- поэтому должны выпускаться уведомления об изменениях.  [c.252]

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

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

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

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

Разд. 3. (2,3) л. 1.3 и 3. (2,3). л. 1.4 внутренней спецификации изделия определяют программное обеспечение и оборудование, которые необходимы для обеспечения функционирования программного изделия, а разд. 5.2 внешней спецификации указывает программное обеспечение и оборудование, необходимые для ввода его в действие. В разд. 3.1 спецификации версии уточняется потребность в машинных ресурсах для внесения изменений по требованию заказчиков, или для проведения испытаний класса В. В будущем из-за скрытых дефектов могут возникать ошибки, и запись, обеспечивающая условия для нормальной эксплуатации программного изделия, будет способствовать устранению обнаруживаемых дефектов.  [c.300]

Для всех компонентов программного изделия, перечисленных в разд. 1.3, указываются модули, которые могут быть заменены непосредственно новыми модулями без ущерба для пользователя. Вводятся соответствующие перекрестные ссылки в документацию версии или нового изделия, поскольку новые компоненты по определению заменяют прежние. Рассматриваются только те модули, для которых существуют перекрестные ссылки. Произведенные замены описываются как в программных документах, так и во всей документации.  [c.300]

Ответственность за составление всех разделов спецификации версии лежит на группе разработки с того момента времени, когда программное изделие передается на испытания класса В исключение составляет разд. 2.2.2, изменения в который вносит группа испытаний при передаче программного изделия в группу обслуживания для его распространения.  [c.300]

Связующий код варианта версии (СКВ) и редакции (СКР). Эти поля идентифицируют деревья, соответствующие конкретной версии, варианту и редакции, в которые входит данный компонент. Чтобы понять необходимость этой информации, достаточно представить случай, когда новая редакция компонента, используемого в разных программных изделиях, оказывается не включенной в некоторые из них.  [c.341]

Как видно из рис. 12.1, деятельность группы сопровождения становится наиболее активной в начальный период фазы использования, когда изделие попадает в руки пользователей. Участие персонала группы разработки в исправлении первой волны ошибок (гл. 17, разд. 17.1) не снижает нагрузки на группу сопровождения, так как последняя должна работать в тесном контакте с разработчиками, чтобы обеспечить ритмичность передачи изделий группе сопровождения. Нагрузка может достигнуть пика в любое время (сразу после выпуска версии или в течение первых шести и более месяцев использования изделия), что подтверждается опытом внедрения операционных систем (обычно пользователи далеко не сразу осваивают новые программные средства).  [c.196]

Этот раздел подобен разд, 3.1, но относится к программным средствам. Ресурсы распределяются по отдельным версиям изделия и уровням изменений. Если в программное обеспечение на скорую руку вводятся временные исправления (это опасная практика, но еще встречающаяся), они должны быть тоже перечислены и пронумерованы.  [c.300]

Исправляя ошибки и совершенствуя изделие, группа сопровождения постоянно контролирует требования конфигурационного управления Каждый раз, когда пользователям направляются измененные программы, в том числе те, которые были исправлены группой сопровождения, следует убедитья в том, что все документы, исходные и объектные модули программ согласованы друг с другом. Эту задачу нелегко выполнить, потому что со временем накапливается обременительный груз в виде комплектов документации и текстов программ, соответствующих предыдущим версиям. Если же производить простую замену архивной документации новыми комплектами, то могут возникнуть серьезные трудности, когда потребуется распространить или модернизировать какую-нибудь предшествующую версию программного изделия.  [c.198]

Смотреть страницы где упоминается термин Версия программного изделия

: [c.186]    [c.334]   
Методы управления проектированием программного обеспечения (1981) -- [ c.333 , c.334 ]