ВНЕШНИЕ СПЕЦИФИКАЦИИ ПРОЕКТА [c.114]
Вследствие этих трудностей и постоянного роста их значения в разработке ПО внешние спецификации проекта можно поручать для разработки такому специалисту, который должен понимать перечисленные выше области деятельности и должен быть знаком со всеми этапами проектирования и испытания ПО, чтобы понять и оценить влияние внешнего проекта на все этапы создания ПО. В качестве таких специалистов могут использоваться инженеры-экономисты по организации обработки информации, инженеры-системотехники, психологи, специалисты по исследованию операций и т. д. [c.116]
Какими должны быть ответственные исполнители внешних спецификаций Они не должны быть программистами, так как процесс внешнего проектирования не имеет ничего общего с составлением программ. Этот процесс больше связан с пониманием окружающей среды пользователей, их проблем и нужд, психологии связи человек — машина. Особенно важно то, что эта тенденция внешнего проекта возрастает с применением новых средств вычислений, касающихся большого круга конечных пользователей, не имеющих знаний в области вычислительного дела. [c.115]
Замечания по программированию. Внешняя спецификация должна описывать продукт ПО с точки зрения пользователя и избегать ограничений внутреннего проекта. Но время от времени необходимо сообщать идеи о внутреннем проекте функции. Эта практика должна быть сведена к минимуму, но, где необходимо, этот раздел используется для сообщения информации. [c.120]
Групповой контроль специалистами. Первоначальная внешняя спецификация оценивается специалистами, ответственными за цели, архитектуру системы и подробный внешний проект. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адекватности отражения цели, в спецификациях. Подробную внешнюю спецификацию должны оценивать специалисты, отвечающие за разработку первоначального внешнего проекта, проектирование [c.120]
Хорошее изделие может быть создано только на основании хорошего проекта, а для этого требуется хорошая документация, которая понятна разработчикам и удобна для использования в процессе проектирования. В том случае, когда проектные решения должны быть поняты большим числом людей, которые должны общаться между собой в ходе проектирования универсального программного обеспечения, качество проекта полностью определяется качеством положенной в его основу документации. Поэтому, чтобы успешно производить программные изделия, необходимо иметь полную документацию, охватывающую все аспекты их разработки. Вслед за принятием на вооружение соглашения о требованиях нужно позаботиться о том, чтобы спецификации изделия отражали потребности всех связанных с его созданием функциональных групп разработки, испытаний, выпуска документации и др. Обеспечить такое соответствие нетрудно, внедрив в практику проектирования программных изделий после соглашения о требованиях внешние спецификации, описываемые здесь достаточно подробно. [c.19]
Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек- [c.91]
Руководитель проекта формирует многие из документов, описанных в этой книге, такие, как соглашения о требованиях, сводки трудозатрат, внешние спецификации, сетевые графики и уведомления о календарных сроках. Он анализирует и утверждает те из документов, которые создаются без его участия, например распределение бюджета, внутренние спецификации, описание конфигурации системы, планы выпуска документации, планы испытаний и поддержки. Он также проводит анализ отчетов о ходе проектирования, делает представления на сотрудников и часто осуществляет непосредственное управление проектом. [c.98]
С учетом четкого различия между внешним и внутренним проектами следует составлять внешние и внутренние спецификации программного изделия. При этом необходимо избегать появления общих мест в разных документах. Форма внешних спецификаций, описанных в разд. 15.1, представляет собой прямую декомпозицию [c.107]
После того как внешние спецификации приобретут сравнительно стабильный характер, в рамках функции разработки производится рассылка материала со штампом Проект на рассмотрение другим функциональным группам, а также потребителям, если это необходимо. Для того чтобы провести рассмотрение этих документов тщательно и в сжатые сроки, целесообразно использовать такой формальный орган, как техническая ревизионная комиссия. Если состав комиссии хорошо продуман, то рассмотрение материалов в ней принесет большую пользу руководителю проекта. Группа разработки должна с вниманием относиться к предложениям комиссии и учитывать их во внешних спецификациях. [c.109]
Фаза проектирования заканчивается утверждением внешних спецификаций, что придает внешнему проекту постоянство и стимулирует завершение внутреннего проекта. Утверждение внешних спецификаций не означает запрещения проводить изменения внешнего проекта, а лишь сдерживает их поток и позволяет другим функциональным группам выполнять свою работу, не дожидаясь дальнейшего уточнения проекта. Для внесения новых изменений в утвержденные внешние спецификации используются заявки на расширение (разд. 16.6 и 18.4). Эти заявки необходимо тщательно изучать, чтобы не допустить нежелательных изменений календарных сроков работ, особенно тех, которые проводятся в рамках других функций, реагирующих на дополнительные изменения непредвиденным образом. [c.110]
Р10 — подготовка соглашения о требованиях Р10 — PJ1 — подготовка части внутреннего проекта для начала программирования Р10 — П20 — реакция на пересмотр соглашения о требованиях Р10 — Р20 — составление внешней спецификации И01 — И10 — рассмотрение плана испытаний Р20 — РЗО — реакция на пересмотр внешней спецификации Б01 — Б10 — рассмотрение плана выпуска документации Д01— Д10 — рассмотрение плана поддержки И11 — И13 — рассмотрение спецификации испытаний Р11 — Р31 — составление внутренней спецификации СЮ — Р40 — внесение последних обязательных изменений Р21 — Р40 — кодирование, отладка, компоновка Р40 — Р41 — подготовка и проведение демонстрации изделия в действии И20 — Р42 — прогон приемочных тестов Б02 — БП — рассмотрение чернового варианта справочных материалов Р40 — ИЗО — подготовка спецификации выпуска ДП — Д12 — рассмотрение рекламных материалов ИЗО — И31 — реакция на перечни дефектов БП — Б12 — рассмотрение первого варианта справочных материалов Б12 — Б20 — окончательное утверждение справочных материалов И32 — ПЗО — рассмотрение отчета об испытаниях класса В Р31 — П20 — рассмотрение спецификации сопровождения. [c.111]
Независимо от формы проведения корректировок или способа распространения корректирующих материалов должны соблюдаться принципы конфигурационного управления. Каждое издание документации, каждая замененная страница и каждый перечень исправлений должны содержать указания на конкретную внешнюю спецификацию и конкретный блок программы, и наоборот. Обычно конфигурационное управление осуществляется в рамках функции обслуживания, однако все остальные участки проекта также должны внимательно следить за его правильностью. [c.148]
В ходе фазового обзора III группа испытаний начинает решать свои стратегические задач , сопоставляя внешнюю спецификацию с соглашением о требованиях. На этом этапе группа испытаний как бы утверждает внешнюю спецификацию, поскольку замечает любые несоответствия между ней и соглашением о требованиях, а также осуществляет контроль качества проекта, не допуская никаких упущений в описании внешних характеристик изделия. [c.173]
Из рис, 1 3 также видно, что очередной этап деятельности группы поддержки — проверка внешних спецификаций — начинается сразу после начала проверки плана выпуска документов и заканчивается раньше, чем закончится проверка этого плана. Группа разработки представляет внешние спецификации на всеобщее обсуждение для того, чтобы получить конструктивные критические замечания. Так как в это время группа поддержки имеет последнюю возможность повлиять на проект, она самым тщательным образом изучает внешние спецификации и формулирует соответствующие предложения, касающиеся их усовершенствования. [c.183]
Деятельность группы поддержки достигает первого максимума после передачи плана поддержки на рассмотрение в другие группы (рис. 11.2). Как видно из рис. 11.3, группа поддержки одновременно занята подготовкой рекламного материала, проверкой внешних спецификаций и изучением плана выпуска документов. В этот период важно установить определенную приоритетность работ, чтобы уложиться в запланированные сроки. Лучше всего выполнять их по очереди, однако это может значительно увеличить время проектирования. Хотя календарные планы отдельных проектов в чем-то отличаются друг от друга, группа поддержки всегда стремится выполнять свои работы в следующем порядке , сначала изучить внешние спецификации, затем проверить план выпуска документов, отреагировать на замечания к плану поддержки и, наконец, подготовить рекламный материал. Эта очередность работ наилучшим образом соответствует хорошему стилю планирования и требованиям декомпозиции проекта. [c.183]
В ходе фазового обзора III группа поддержки рассматривает внешнюю спецификацию изделия с точки зрения ее совместимости с существующими требованиями пользователя. Если требования пользователя изменились таким образом, что группа разработки не может их учесть без внесения существенных изменений в проект, то группа поддержки должна оценить ситуацию и либо поднять вопрос о пересмотре соглашения о требованиях, либо предложить компромиссное решение, не нарушающее требований внешней спецификации. В этот же период группа поддержки пересматривает извещения о календарных сроках и распределение бюджета и предлагает внести изменения в эти документы. [c.189]
В конце фазы программирования группа сопровождения активно включается в работу над проектом, начиная подготовку спецификации сопровождения. Основным условием успешного завершения этой работы является наличие готовой внутренней спецификации. Спецификация сопровождения содержит внутреннюю спецификацию, дополненную техническим описанием и листингами программ (гл. 15, разд. 15.5). Как видно из рис. 12.2, другим необходимым условием завершения спецификации сопровождения является утверждение внешней спецификации в этом случае существует гарантия того, что внутренний и внешний проекты программного изделия приобрели стабильный характер. Рис. 12.2 показывает также, что ко времени составления спецификации сопровождения должен быть закончен документ, регламентирующий ввод программного изделия в действие,— так называемый информационный листок выпуска (разд. 8.6), что позволяет группе сопровождения учесть в спецификации сопровождения принятые и отклоненные заявки, замеченные, но неустраненные дефекты и гарантировать соблюдение требований к выполнению процедуры ввода программного изделия в действие. [c.196]
В соответствии с формой, представленной в предыдущем разделе, ниже дается описание информации, которая должна присутствовать в любом соглашении о требованиях. Все последующие упоминания о соглашении о требованиях (СТ) имеют в виду соглашение о требованиях, разработанное в соответствии с данным разделом. Описываемый подход предполагает также декомпозицию проекта в соответствии с табл. 13.2 и дальнейшую детализацию, отражаемую во внешней спецификации изделия согласно разд. 15.1. Материал, следующий вплоть до заголовка Календарный план , пронумерован, озаглавлен и напечатан так же, как в СТ, но с одним исключением обозначения Ок, Ч, Об и 3 указывают уровень детализации. [c.206]
Документы, целью которых является точная формулировка или определение каких-либо условий, называются спецификациями. Желательно, чтобы спецификации были удобочитаемыми и краткими, но прежде всего они должны быть точными и исчерпывающими. Двусмысленность в спецификациях более нетерпима, чем в планах. В процессе декомпозиции проекта, который для программного изделия начинается с иерархии планов, продолжается в соглашении о требованиях, внешней спецификации, внутренней спецификации и заканчивается спецификацией сопровождения, неопределенность постепенно уступает место полной определенности. [c.267]
Как отмечалось в гл. 13, выбор заголовков, которые включаются в документ, и их последовательность не произвольны. Представленные в этой главе форматы составлены в соответствии с принципом проектирования сверху вниз, т. е. наиболее важные вопросы помещаются первыми незначительные исключения составляют те случаи, где обеспечение удобства чтения текста важнее сохранения реальной схемы декомпозиции проекта. В представленных форматах используется способ нумерации, позволяющий реализовать вложенную структуру документов, удобную с точки зрения возможности дополнения и исключения отдельных разделов. Например, в гл. 13 в табл. 13.2 приведено оглавление подобной структуры для соглашения о требованиях (СТ), внешней спецификации (ВшС), внутренней спецификации (ВтС) и спецификации сопровождения (СС). Элементы каждого такого документа обозначаются следующим образом 3 — заголовок, Об— общая формулировка, Ч — частичная формулировка, Ок — окончательная формулировка. Преобразование 3->-Об->-Ч->Ок, направленное в одну сторону, осуществляется в процессе принятия проектных решений. [c.268]
Внешняя спецификация должна детализировать только свойства, указанные или подразумеваемые в соглашении о требованиях, что защитит проект от расширения масштабов разработки. Добавление или изъятие свойств, предусмотренных в соглашении о требованиях, не допускается. [c.271]
Техническая ревизионная комиссия (ТРК) является специальной комиссией, созываемой руководителем проекта для обсуждения конкретных технических вопросов и выработки по ним рекомендаций. Основное назначение ТРК—анализ внешней спецификации и выдача руководителю группы разработки рекомендации по ее утверждению или пересмотру. Необходимость ТРК обусловлена еще и тем, что многие руководители просто не имеют времени для тщательного анализа каждой проблемы, хотя некоторые из проблем требуют самой серьезной технической экспертизы. [c.355]
Анализ внешней среды проекта, анализ участников, определение целей, ограничения и сложности, системные спецификации, выбор критериев успешного завершения проекта, рассмотрение различных вариантов проекта и анализ риска, назначение цен, заключение контракта [c.34]
Ранее внешний проект представлялся как состоящий из двух процессов первоначального и подробного внешних проектов. Допуская, что спецификация является иерархически организованной, эти два процесса просто представляют контрольные точки в проектировании системы согласно иерархии. На первом этапе описываются основные средства (то, что соответствует разбиению на первом уровне), затем средства, функции пользователя и подробности для каждой функции пользователя. [c.118]
Четвертое правило — следить, чтобы все изменения были сделаны на соответствующем уровне. Программист, проектируя внутреннюю логику модуля, может внести изменения, но может не распознать, что изменение касается внешних характеристик продукта. ПО и спецификации теперь не совпадают, и это обстоятельство проявит себя в последующей работе. Не существует легкого решения данной проблемы и другого подхода, кроме уведомления каждого специалиста, связанного с проектом, о принятом решении. [c.123]
Под изменением понимается замещение одного решения другим вследствие воздействия различных внешних и внутренних факторов при разработке и реализации проекта. Изменения могут вноситься в различные разделы проекта. Инициировать изменения могут и заказчик, и инвестор, и проектировщик, и подрядчик. Заказчик, как правило, вносит изменения, улучшающие конечные технико-экономические характеристики проекта. Проектировщик может вносить изменения в первоначальную проек-тно-сметную документацию, спецификации. Подрядчик по ходу реализации проекта вносит изменения в календарный план, методы и технологии производства работ, последовательность (технологическую, пространственную) возведения объектов и т. д. [c.428]
Деятельность, связанная с разработкой изделия, достигает своего пика в фазе программирования, когда планы испытаний дополняются спецификациями испытаний. Внутренняя структура изделия полностью описывается внутренней спецификацией, которая содержит сведения о том, как строится изделие, как формируется план обеспечения функционирования программного обеспечения и становятся доступными аппаратные ресурсы. В то время как группа разработки преобразует внешний и внутренний проекты в основное тело программ, т. е. в начальное воплощение изделия, группа испытаний трансформирует их с помощью спецификации испытаний в контрольные примеры группа выпуска документации создает справочные материалы группа поддержки программного обеспечения создает рекламные материалы и материал для обучения персонала. Эти последние действия начинаются с середины фазы программирования и продолжаются почти до конца фазы оценки. В самом конце фазы оценки группа обслуживания подготавливает руководство по вводу программного обеспечения в действие, называемое информационным листком выпуска, и вместе с группой сопровождения заносит в сопроводительную документацию все, что потребуется в будущем. Фаза использования начинается тогда, когда изделие объявлено готовым к передаче пользователям. Все, что остается после этого на рис. 2.3, — это периодическое создание корректирующих программ, предназначенных для исправления ошибок, обнаруженных пользователями, и обеспечения функционирования изделия в реальных условиях эксплуатации. [c.34]
Чтобы еще более уточнить понятия внешнего и внутреннего проектов, обратимся к рис. 7.7 и 7.8. Древовидная структура, изображенная на рис. 7.7, построена по схеме, представленной на рис. 7.6, и показывает, где используется каждый модуль. Будем считать, что а внешний контур каждого блока из рис. 7.7 отображается совокупность параметров, принадлежащих соответствующему модулю. Контур Р, изображенный на рис. 7.8, на который отображаются все параметры, видимые при рассмотрении программного изделия извне, соответствует внешнему проекту. Внутренний проект образуется объединением всех параметров, отображения которых не попали во внешний контур Р. Внутренние спецификации описывают параметры, принадлежащие остальным контурам блоков. [c.107]
Продолжим изучение рис. 7.8. Отметим, что контур модуля А — высшего в иерархии модулей — полностью проецируется на внешний контур программного изделия Р. Это является прямым следствием нисходящего проектирования, в соответствии с принципами которого модуль высшего уровня лишь инициирует и прекращает работы программного изделия, устанавливает другие виды взаимодействия изделия с пользователем и синхронизирует выполнение модулей более низкого уровня. Вследствие такой декомпозиции модуль А не имеет внутреннего проекта и внутренних спецификаций. [c.107]
В то время, когда в рамках функции разработки создаются внешние и внутренние спецификации, в рамках других функций ведется подготовка плана выпуска документации и плана испытаний. Эти документы рассылаются на рассмотрение в конце фазы конструирования. Руководитель проекта лично изучает и утверж- [c.109]
Воздействие закупочных операций на работу компании можно выявить благодаря трем стратегическим функциям закупки рациональности, развитию и структурированию. Функция рациональности охватывает многочисленные повседневные действия, предпринимаемые для изменения структуры затрат. Можно выделить три типа рациональности. Первый касается спецификации требований к предмету или продукту, который будет куплен. Это важнейший момент, требующий решения, следует ли изготовить нужный продукт на своих мощностях или купить его у внешних поставщиков (решения сделать или купить ), а также решений относительно конструкции или проекта продукта. Эффективность этого процесса значительно возрастет, если закупки будут осуществляться согласованно с исследовательским, проектным и производственным отделами, а также если закупщики будут иметь надежную информацию о возможностях и способностях различных поставщиков. Одна из методик, применяемых для этого, называется анализом стоимости ее задача состоит в том, чтобы снизить затраты при сохранении необходимых уровней доступности и надежности продукта (см. РАЗРАБОТКА НОВЫХ ТОВАРОВ ТОВАРНАЯ ПОЛИТИКА). [c.167]
В графике контроля должны быть перечислены все документы, формирующие полную спецификацию. Это включает чертежи, слишком большие, чтобы их можно было удобно подшить вместе с основным текстом, и другие внешние документы, имеющие отношение к правильному определению проекта (например, стандартные технические спецификации или законодательные положения). [c.24]
Таким образом, необходимо знать некоторые критерии и основные правила, определяющие, в какой момент процесса разработки должна быть начата формальная процедура внесения изменений. Необходимо задать следующий вопрос Повлечет ли предлагаемое изменение в проекте необходимость внести поправки в инструкции, спецификации, план или бюджет проекта, которые уже были согласованы с другими отделами, заказчиком или другими внешними организациями Если ответ на этот вопрос утвердительный, то, вероятнее всего, понадобится официальное одобрение комитета по изменениям. [c.202]
Для проверки правильности проведения работ по проектированию системы могут быть применены различные способы Одним из них может быть проверка проект ной документации автором архитектуры системы (авто ром внешних спецификаций) и проектировщиком после дующего процесса (разработчиком модулей) с целью обеспечения работоспособности, понятности, соответствия используемому языку программирования, а также совмес тимости с общей системой, частью которой является проект. [c.138]
ПШ —распределение бюджета утверждено П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]
Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента — внутренний и внешний. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — это совокупность характеристик программного изделия, скрытых от любого пользователя. На первый взгляд это разделение кажется искусственным, однако это не так, поскольку такая классификация характеристик программного изделия дает много преимуществ. Она хорошо согласуется с рядом практических методов программирования, таких, как нисходящее программирование [14], метод утаивания информации (information hiding) [15], композиционное проектирование [16] и структурное проектирование 17]. С точки зрения руководителя несомненным достоинством такой классификации является то, что пользователи могут критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. Другими словами, можно во внешних спецификациях описать, что делает программное изделие, а во внутренних спецификациях указать, каким образом оно должно быть сконструировано. Внеш- [c.105]
Должностные обязанности. Организует редактирование научной и методической литературы, а также информационных и нормативных материалов. Возглавляет разработку проектов перспективных и годовых тематических планов издания литературы с учетом спроса на рынках ее сбыта, планов редакционно-подготови-тельных работ и графиков редакционных и производственных процессов издания. Осуществляет контроль за соблюдением установленных сроков представления рукописей, сдачей их в набор, обработки корректурных оттисков и выпуска литературы в свет, а также за научным и литературным содержанием изданий и качеством их полиграфического исполнения. Подготавливает материалы для заключения издательских договоров с авторами и трудовых договоров (контрактов) с внешними редакторами, рецензентами, художниками и другими лицами, привлекаемыми к выполнению работ по изданию литературы, участвует в оформлении документов по расчетам за выполненные ими работы. Организует проведение консультаций авторов с целью оказания им помощи в работе над рукописями. Принимает поступающие рукописи, проверяет соответствие их оформления установленным правилам и условиям, предусмотренным издательскими договорами, направляет рукописи на рецензирование и редактирование. Рассматривает вопросы, связанные с выполнением авторами договорных условий, заключения редакторов по рукописям и принимает решения об одобрении или отклонении их издания, разрешает разногласия между авторами и редакторами, обеспечивает равномерную и ритмичную загрузку редакторов, распределяет между ними работу и устанавливает сроки редактирования изданий в соответствии с действующими нормативами. Осуществляет контрольное чтение рукописей, подготовленных к сдаче в производство, организует обсуждение качества отредактированного материала. Участвует в разработке проектов художественного и технического оформления изданий. Определяет качество поступающих корректурных оттисков и в случае несоответствия требованиям технической издательской спецификации принимает решение о возвращении,их в установленном порядке полиграфическому предприятию на дополнительную правку. Подписывает издания в производство, в печать и на выпуск в свет. Устанавливает причины ошибок, опечаток в изданиях и виновных в этом лиц. Осуществляет мероприятия, направленные на сокращение сроков прохождения рукописей, экономное расходование средств при издании литературы, улучшение качества полиграфического исполнения. Содействует повышению квалификации ра- [c.319]
На точность расчетов также сильно влияет уникальность проекта. Например, время на внедрение новой технологии, как правило, увеличивается не линейно. Иногда плохо написанные спецификации масштаба для новых технологий приводят к ошибкам в расчетах времени и затрат. Внешние и внутренние условия тоже могут давать ошибки Проекты, выполнение которых требует длительного времени, увеличнаают неточность расчетов, Заранее установленное время реализации может сильно повлиять на расчеты времени и затрат, [c.96]
Проекты, связанные со строительством, - это еще один пример работ, которые должны быть описаны с помощью спецификации. Все строительные подрядчики с любой репутацией работают с использованием подробных спецификаций. Требования законодательных структур лвляк УГСЯ одной из причин для документирования спецификаций, описываюшихвыбор места строительства для здания, его расположение, цели использования, способы эвакуации в случае пожара, внешний вид здания и многие другие факторы. Без сомнения, есть много деталей, касающихся сооружения, которые могут существенно повлиять на его стоимость, включая, например, стиль внутренней отделки, качество гарнитуры и встроенного оборудования, стандарты по освещенности и кондиционирование воздуха. [c.16]