Нормальное завершение проекта наступает на этапе фазового обзора V, когда принимается решение о выпуске программного изделия. Группа разработки составляет заключительный отчет как можно быстрее, прежде чем сотрудники проекта окажутся слишком занятыми своими новыми обязанностями. Она также выпускает заключительное уведомление о календарных сроках и просит о закрытии финансового счета. Эти последние действия можно выполнить и позже, после завершения составления спецификации сопровождения, выпускаемой группой сопровождения, однако, выполнив их, можно считать проект законченным. [c.116]
Вопрос, какими силами осуществляется сопровождение, разрешается по-разному, в зависимости от таких факторов, как размер проектной организации, стабильность уровня трудовых затрат, соотношение видов изменений (корректирующих или расширяющих) в общем процессе усовершенствования изделия, длительность срока гарантийных обязательств, взятых производителем, и, наконец, качество испытаний, которое играет далеко не последнюю роль в этом списке. Размеры проектной организации определяют, представляется ли возможным создать автономное подразделение, специализирующееся на сопровождении изделий. Если такая возможность есть, ее необходимо использовать. Создание самостоятельной группы обеспечивает четкое взаимодействие между группами разработки и сопровождения, ускоряет подготовку полных спецификаций сопровождения, гарантирует надзор за соответствующими выпущенными программными изделиями, создает основу для обучения программистов, способствует выполнению гарантийных обязательств, дает возможность легко подсчитывать затраты на сопровождение. Если выделение автономной группы сопровождения невозможно, тогда в обязанность каждой группы разработчиков входит сопровождение своего изделия. Такое решение позволяет снизить накладные расходы, привлечь к сопровождению квалифицированных специалистов, способных быстро отыскать ошибку, и равномерно распределить работу между разработчиками. Однако оно имеет и недостатки сопровождение может со временем приобрести небрежный характер когда кто-ни будь из разработчиков увольняется, возможности сопровождения сокращаются исправление ошибок часто становится второстепенной работой и, наконец, иногда недостаточно тщательно анализируется целесообразность внесения тех или иных изменений. Если в работе над усовершенствованием изделия проводится много расширяющих изменений, то появляется естественное желание привлечь к этой деятельности опытных разработчиков вполне возможно, что наиболее эффективным решением будет исправление дефектов программ этими специалистами. Если сотрудники, работающие над проектами, часто переключаются с одного вида деятельности на другой, потери от этих переключений могли бы быть сведены к минимуму путем создания автономной группы сопровождения, располагающей хорошей методикой работы и исчерпывающей документацией. Если гарантийные обязательства по проекту кратковременны или вообще отсутствуют, сопровождение изделия можно обеспечить за счет незначительной дополнительной нагрузки на его разработчиков. Наконец, если группа разработки хорошо справляется со своей работой, число дефектов изделия будет небольшим и можно соответствующим образом уменьшить численность группы сопровождения. [c.192]
В формулировках целей, преследуемых при создании изделия, должен быть точно определен сопровождающий персонал и описаны уровни поддержки. Во время подготовки и утверждения соглашения о требованиях группы разработки н сопровождения совместно обсуждают вопросы влияния на проект таких факторов, как производственная база пользователя, планы выпуска новых версий, сложность изделия и уровень квалификации персонала сопровождения. Пример окончательного соглашения о требованиях для продукта ASK представлен в приложении (стр. 358), где дано описание уровня поддержки изделия ASK (в примере указан уровень 1) и определены обязанности группы сопровождения, связанные с подготовкой спецификации сопровождения. [c.195]
В конце фазы программирования группа сопровождения активно включается в работу над проектом, начиная подготовку спецификации сопровождения. Основным условием успешного завершения этой работы является наличие готовой внутренней спецификации. Спецификация сопровождения содержит внутреннюю спецификацию, дополненную техническим описанием и листингами программ (гл. 15, разд. 15.5). Как видно из рис. 12.2, другим необходимым условием завершения спецификации сопровождения является утверждение внешней спецификации в этом случае существует гарантия того, что внутренний и внешний проекты программного изделия приобрели стабильный характер. Рис. 12.2 показывает также, что ко времени составления спецификации сопровождения должен быть закончен документ, регламентирующий ввод программного изделия в действие,— так называемый информационный листок выпуска (разд. 8.6), что позволяет группе сопровождения учесть в спецификации сопровождения принятые и отклоненные заявки, замеченные, но неустраненные дефекты и гарантировать соблюдение требований к выполнению процедуры ввода программного изделия в действие. [c.196]
Этот раздел должен быть расширен в спецификации сопровождения, поэтому в СТ содержится только один подраздел. [c.219]
Разработка спецификации сопровождения [c.230]
НТИ 4. Исходная и машинная программы листинги 7. Спецификации сопровождения [c.230]
Р31 С20 с Подготовка спецификации сопровождения [c.256]
РЗО [С20 Спецификация сопровождения должна соответствовать внеш- [c.259]
С20 Подготовка спецификации сопровождения ПП [c.264]
Документы, целью которых является точная формулировка или определение каких-либо условий, называются спецификациями. Желательно, чтобы спецификации были удобочитаемыми и краткими, но прежде всего они должны быть точными и исчерпывающими. Двусмысленность в спецификациях более нетерпима, чем в планах. В процессе декомпозиции проекта, который для программного изделия начинается с иерархии планов, продолжается в соглашении о требованиях, внешней спецификации, внутренней спецификации и заканчивается спецификацией сопровождения, неопределенность постепенно уступает место полной определенности. [c.267]
Как отмечалось в гл. 13, выбор заголовков, которые включаются в документ, и их последовательность не произвольны. Представленные в этой главе форматы составлены в соответствии с принципом проектирования сверху вниз, т. е. наиболее важные вопросы помещаются первыми незначительные исключения составляют те случаи, где обеспечение удобства чтения текста важнее сохранения реальной схемы декомпозиции проекта. В представленных форматах используется способ нумерации, позволяющий реализовать вложенную структуру документов, удобную с точки зрения возможности дополнения и исключения отдельных разделов. Например, в гл. 13 в табл. 13.2 приведено оглавление подобной структуры для соглашения о требованиях (СТ), внешней спецификации (ВшС), внутренней спецификации (ВтС) и спецификации сопровождения (СС). Элементы каждого такого документа обозначаются следующим образом 3 — заголовок, Об— общая формулировка, Ч — частичная формулировка, Ок — окончательная формулировка. Преобразование 3->-Об->-Ч->Ок, направленное в одну сторону, осуществляется в процессе принятия проектных решений. [c.268]
ВтС имеет много назначений. Начинается она как рабочий журнал проекта, который показывает, как создается программное изделие, каковы его функции и что представляют собой алгоритмы, используемые для реализации этих функций. Без такого рабочего журнала мало надежды на сохранение информации о сложной внутренней структуре при уходе основного персонала, занимающегося проектом, или при отсрочке работы над проектом даже на месяц. По мере развития проекта и его ВтС последняя может использоваться как субъективный индикатор текущего состояния проекта. Позже ВтС включается в спецификацию сопровождения (разд. 15.3) в этом случае трудно переоценить ее значение для быстрой коррекции ошибок. Наконец, ВтС является широко используемым справочным документом, содержащим описания идей проекта, алгоритмов и даже модулей, которые могут быть полезны в последующих разработках. [c.283]
При составлении описания любого раздела или подраздела следует давать структурную диаграмму, подобную показанной на рис. 15.1. Она является своего рода путеводителем по подразделам. В каждом подразделе п описывается один физический модуль. Структурная диаграмма здесь играет очень важную роль она не только каталогизирует модули, но и описывает их связи Кто кого вызывает . Модули более высоких уровней могут иметь свойства, характерные и для некоторых модулей более низкого уровня. Такие свойства должны описываться только один раз на самом высоком обладающем этими свойствами уровне древовидной структуры и в дальнейшем ссылаться на это описание из модулей более низких уровней. Такой способ дает два преимущества не приходится несколько раз описывать одно и то же и соответственно можно избежать описаний одного и того же объекта. Последнее особенно помогает при обновлении устаревших ВтС (имеющих форму спецификаций сопровождения) в фазе использования. [c.285]
Листки состояния модуля продолжают заполняться и в течение фазы его использования, но уже в составе спецификации сопровождения. [c.290]
| Таблица 15.3. Оглавление стандартной спецификации сопровождения |  |
Из информационного листка выпуска приводятся сведения о носителях информации, в частности, о количестве и длине бобин ленты или числе пакетов дисков. Если носители для архивного хранения информации отличаются от представленных в этом листке, они тоже должны быть здесь описаны. В течение фазы использования программного изделия спецификация сопровождения постоянно изменяется. Конфигурационное управление требует, чтобы изменения контролировались и записывались. Поэтому изменение не вносится в СС, если оно не отражено в заявке на проверку, расширение или внесение исправлений. Каждое такое изменение должно маркироваться следующим образом [c.296]
Когда программное изделие передается из группы разработки в группу испытаний, а затем в группу обслуживания, оно сопровождается документом, который называется спецификацией версии. Спецификация версии содержит следующую информацию точный идентификатор изделия, включая полную структурную диаграмму,. охватывающую все модули требования к оборудованию, включая допустимые замены имеющуюся по данному изделию документацию и перечень наиболее существенных дефектов. Группа обслуживания составляет информационный листок выпуска изделия на основе спецификаций версий входящих в него других программных изделий. Группа сопровождения дополняет каждую спецификацию сопровождения информацией из соответствующих спецификаций версий. [c.296]
Хотя описанные выше рекомендации довольно многочисленны, отчет следует делать максимально лаконичным, охватывая только наиболее важные события и проблемы. Необходимо, однако, гарантировать, что все важные вопросы освещены, даже если они считаются общеизвестными. Отчет о ходе проектирования должен быть полным, так как он становится постоянно действующим документом, на который в дальнейшем следуют ссылки, например в спецификации сопровождения при занесении в нее хронологической информации. [c.311]
Подсистема производство объединяет следующие блоки управление производством и планирование производства (управление выполнением заказов, отпуском материалов, подготовка отчетов о выполнении операций, учет выпуска продукции, времени работы персонала и оборудования, анализ состояния незавершенного производства), учет затрат (расчет нормативной себестоимости продукции), спецификация изделий (сопровождение изготавливаемых и закупаемых элементов изготавливаемых изделий), планирование потребности в мощностях (планирование потребности в материалах, узлах, загрузке оборудования). При многозвенном производстве эта подсистема позволяет вести управление серийным выпуском изделий, отслеживать работу каждого подразделения предприятия. [c.261]
Особо следует остановиться на этапе сопровождения ПО САПР, т. е. изменения ПО при сохранении его основных функций. Это такие работы, как перепроектирование небольших частей ПО (не более 50% общего объема закодированного ПО),, проектирование небольших интерфейсных программ и пакетов (не более 20%), модификации кода, документации или структуры базы данных программного изделия. Различают два главных вида сопровождения ПО — обновление, приводящее к изменению функциональной спецификации программного изделия, и исправление, не изменяющее функциональной спецификации (корректирование ошибок, адаптация к программному окружению и совершенствованию характеристик). [c.89]
Таким образом, профиль конкретной системы не является статичным, он развивается, конкретизируется (возможно, во взаимодействии с заказчиком) в процессе проектирования ИС и оформляется в составе документации проекта системы. В профиль конкретной системы включаются спецификации компонентов, разработанных в составе данного проекта, и спецификации использованных готовых программных и аппаратных средств, если эти средства не специфицированы соответствующими стандартами. После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и развитии. [c.71]
Результатами работ на этой стадии являются функциональная и информационная модели организации и спецификации требований к предполагаемой системе, служащие в качестве исходных данных для проектирования системы. Желательно, чтобы функциональная и информационная модели и спецификации требований были выполнены с помощью формализованных методов их описания, например с использованием средств описания моделей в известных методологиях структурного или объектно-ориентированного проектирования и языков спецификаций. В этом случае в ТЗ, разрабатываемом по результатам стадии предпроектного обследования, должно быть указание на имеющиеся исходные данные и средства описания исходных данных. Ссылки в ТЗ на документы, определяющие выбранные средства описания исходных данных, — часть профиля инструментальной среды, поддерживающей основные процессы проектирование, разработку, сопровождение и развитие прикладного программного обеспечения ИС. [c.79]
Группа планирования определяет необходимость в программном изделии, устанавливает возможность его реализации и осуществляет слежение за ним вплоть до конца его использования. Группа разработки составляет спецификации, конструирует, документирует, создает, отлаживает и собирает изделия. Группа обслуживания предоставляет средства вычислительной техники для обеспечения всех названных функций, для осуществления конфигурационного управления, распространения и разнообразной административной поддержки. Группа выпуска документации обеспечивает пользователей руководствами и другими справочными материалами. Группа испытаний дает независимую оценку как программному обеспечению, так и документации до их передачи пользователю. Группа поддержки обеспечивает распространение изделия и обучение пользователей, установку изделия на месте его использования и постоянную связь между отдельными группами и пользователями. Последняя, но не менее важная, чем остальные группы, — группа сопровождения — обеспечивает исправление ошибок и некоторые улучшения в фазе использования. [c.29]
ПШ —распределение бюджета утверждено П20 — соглашение о требованиях утверждено ПЗО —изделие готово к распространению Р10 — соглашение о требованиях составлено Р11 — составление внутренних спецификаций начато Р20 — внешние спецификации составлены Р21-. кодирование начато РЗО — внешние спецификации утверждены Р31 — составление внутренних спецификаций завершено Р40 — начаты испытания класса А Р41—демонстрация изделия проведена Р42 — приемочные испытания проведены О10— требуемые по проекту средства установлены ОН — информационный листок выпуска готов к печати О12 — информационный листок выпуска издан О20 — изделие передано на распространение Б01 — план выпуска документации составлен Б02 — подготовка справочных материалов начата Б10 — план выпуска документации утвержден Б11 — техническое редактирование начато Б12 —утверждение справочных материалов начато Б20 — справочные материалы готовы к печати Б21 — справочные материалы изданы И01 — план испытаний составлен И10 — план испытаний утвержден И11—спецификации испытаний составлены- И12 — разработка контрольных примеров начата И13 — спецификации испытаний утверждены ИД) — состав приемочных испытаний определен ИЗО - начаты испытания класса В И31 - последний цикл испытаний начат И32 — отчет об испытаниях класса В издан Д01 — план поддержки составлен Д1С — план поддержки утвержден Д11 — рекламные интервалы подготовлены Д12 —рекламные материалы сданы в печать Д13 —план обучения издан Д20 — рекламные материалы распространены Д21 —учебные пособия подготов-лены ДЗО —обучение закончено С10 —внесение изменений запрещено С20 — спецификация сопровождения готова. [c.102]
СС создается группой сопровождения в фазе оценки на основе внутренней спецификации (ВтС) путем добавления к ней нескольких разделов и изменения некоторых уже написанных. В табл. 15.3 представлено оглавление стандартной спецификации сопровождения (СС). Ниже рассматривается содержание тех разделов4, которые служат основой преобразования ВтС в СС. [c.293]
На основе данной спецификации предприятие может реализовать важнейший принцип всеобщего менеджмента качества (TQM), заключающийся в организации взаимодействия поставщик — потребитель как непрерывной цепи изготовления высококачественного продукта (при этом потребители и поставщики рассматриваются как обитатели единого информационного пространства). При внедрении ALS-технологии решаются проблемы перевода конструкторской документации в электронный вид, ее дальнейшего сопровождения и использования для подготовки производства. [c.131]
Современная практика подобных разработок базируется на технологиях открытых систем класса клиент-сервер с использованием международных стандартов и протоколов. В соответствии с определением Комитета IEEE POS1X 1003.0 под открытой системой понимается система, реализующая открытые спецификации на интерфейсы, сервисы и поддерживаемые форматы данных, достаточные для того, чтобы обеспечить должным образом разработанным приложениям возможность переноса с минимальными изменениями на широкий диапазон систем, совместной работы с другими приложениями на локальной и удаленных системах и взаимодействия с пользователями в стиле, облегчающем переход от системы к системе. При этом создание системы выполняется с использованием методов проектирования и инструментальных средств, обеспечивающих итерационный процесс построения адаптивных систем, быстро настраиваемых на изменения предметной области и допускающих сопровождение и развитие, независимое от непосредственного разработчика. [c.335]
Такого рода документация и обучение касаются внешних свойств изделий. Другие виды документации и обучения раскрывают внутренние свойства изделия, показывая, как оно работает, как оно было создано и из каких частей состоит. Для изделий промышленного изготовления подобное документирование предусматривает создание рабочих чертежей и спецификаций, перечней материалов и источника поступления комплектующих изделий и сырья. Для программного обеспечения документация содержит спецификации, листинги, генераторы программ и данных, а также перечни материалов. Кроме того, необходима внутренняя документация для организации сопровождения изделия. Эта часть документации содержит описание принципов работы изделия, которое должщо удовлетворять потребностям лица, выполняющего сопровождение. В нее включены специальные инструкции на случай возникновения аварийных ситуаций и устранения простых неполадок. В течение всей полезной жизни изделия пользователь должен иметь возможность обратиться к службе сопровождения или быть подготовлен самостоятельно обеспечивать эксплуатацию изделия. [c.23]
Смотреть страницы где упоминается термин Спецификация сопровождения
: [c.116] [c.197] [c.197] [c.197] [c.206] [c.256] [c.259] [c.271] [c.283] [c.285] [c.290] [c.293] [c.334] [c.361] [c.376] [c.75] [c.402]Смотреть главы в:
Методы управления проектированием программного обеспечения -> Спецификация сопровождения