Combine o que o destinatário vai aceitar
Antes do prazo, confirme a finalidade, o destinatário, a distribuição permitida, o local de entrega e o processo de aprovação. Combine o escopo do modelo, o formato, o esquema, a convenção de nomenclatura e as informações de apoio exigidas. Peça ao destinatário que teste um pacote pequeno com antecedência suficiente para corrigir problemas de compatibilidade.
Adapte este fluxo de trabalho aos requisitos de informação do projeto, ao acordo de entrega e a eventuais templates exigidos pelo cliente.
Inclua contexto suficiente para reproduzir a entrega
| Item do pacote | O que ele deve responder |
|---|---|
| Modelo e arquivos complementares | Quais arquivos precisam ficar juntos para que o destinatário consiga abrir o resultado? |
| Manifesto de entrega | Que revisão é esta, quem a preparou e qual é o uso pretendido? |
| Lista de revisões de origem | Quais modelos de disciplina e quais revisões foram incluídos ou excluídos? |
| Configuração de exportação | Quais versão do aplicativo, escopo, opções de formato e transformações foram usados? |
| Nota de coordenadas | Quais unidades, origem, convenção de eixos e referência do projeto se aplicam? |
| Evidências de validação | Quais verificações foram executadas, o que falhou e o que foi aceito como exceção? |
| Lista de alterações e problemas | O que mudou desde a última entrega e o que continua sem solução? |
| Instruções para o destinatário | Como o pacote foi testado e onde as dúvidas devem ser registradas? |
Use caminhos que continuem válidos depois que o destinatário extrair o pacote. Teste uma cópia a partir de outra pasta, para descobrir antes da entrega arquivos ausentes ou referências à sua estação de trabalho. Evite colocar tokens de acesso, senhas ou caminhos privados da estação de trabalho no manifesto.
Exemplo de manifesto de entrega
Delivery: Example project / coordination review / R03
Prepared by: [name and team]
Prepared on: [date and time zone]
Purpose: [agreed review task]
Model files: [file names and sizes]
Source revisions: [list or attached schedule]
Export application and version: [value]
Format and schema: [value]
Scope and exclusions: [value]
Units and coordinate reference: [value]
Applied transformations: [value or none]
Receiving application tested: [name and version]
Validation evidence: [report names]
Open issues and exceptions: [identifiers]
Approval status: [pending / accepted / rejected]
Reviewer and decision date: [value]
Distribution: [approved recipient group]Se forem usadas somas de verificação (checksums), informe o algoritmo e calcule-as sobre os arquivos finais. Uma soma de verificação pode ajudar a detectar um arquivo alterado ou incompleto; por si só, ela não comprova quem criou ou aprovou o pacote.
Libere o pacote em uma sequência controlada
Congele a versão candidata
Identifique as revisões de origem e a configuração de exportação. Coloque as saídas em uma nova pasta de revisão, em vez de sobrescrever a última entrega aceita.
Revise os arquivos finais
Execute as verificações nos arquivos que serão efetivamente enviados. Se a saída mudar, repita as verificações afetadas e atualize o manifesto.
Transfira pelo canal acordado
Envie o pacote completo para o local aprovado e confirme que o destinatário consegue acessá-lo.
Obtenha a decisão do destinatário
Registre o recebimento separadamente da aceitação. Peça ao destinatário que confirme o aplicativo testado e relate os problemas referenciando o identificador da entrega.
Preserve as evidências
Guarde o pacote aceito, a decisão e o histórico das revisões substituídas de acordo com o processo de retenção do projeto.
Mantenha os problemas da entrega vinculados ao modelo
O BIM Collaboration Format (BCF) permite trocar problemas relacionados ao modelo entre aplicativos. Quando as duas equipes trabalham com ele, use-o para manter o contexto dos problemas junto com a revisão acordada do modelo. Um pacote de problemas em BCF não substitui a entrega do próprio modelo.
Referências oficiais