Se a observação e análise do comportamento do tempo de execução precisar fornecer a percepção desejada para o comportamento do software, será necessário considerar quais caminhos de execução através do aplicativo serão importantes para explorar e, destes, quais oferecerão maior oportunidade de entender o comportamento do tempo de execução do software.

Em geral, os cenários mais úteis para explorar costumam refletir todos ou parte daqueles que o usuário normalmente utilizará. Como tal, sempre que possível, será útil identificar os cenários, questionando ou então consultando um especialista em domínio, como um usuário representante do software que está sendo desenvolvido.

Os casos de uso oferecem um conjunto valioso de artefatos dos quais cenários úteis podem ser identificados e explorados. Para um desenvolvedor, o mais familiar deles será provavelmente as realizações de casos de uso com as quais você deverá começar, se disponíveis. Na ausência de realizações de casos de uso, identifique todos os cenários de casos de uso disponíveis que ofereçam uma explicação textual do caminho pelo qual o usuário navegará através dos vários fluxos de eventos no caso de uso. Finalmente, os fluxos de eventos dos casos de uso podem ser consultados para que forneçam informações das prováveis sugestões de cenários que possam ser identificadas. O sucesso dessa última abordagem é aprimorado pela consulta com um representante para obter o agente de casos de uso ou outro especialista em domínio.

Os testadores são outro recurso útil a ser consultado, ao tentar identificar cenários úteis para análise de tempo de execução. Geralmente, os testadores têm percepção e experiência no domínio devido aos esforços de testes que os tornam especialistas em pseudo-domínio. Em muitos casos, o estímulo em observar o comportamento do tempo de execução do software virá dos resultados do próprio esforço de teste.

Se essa tarefa for motivada por um defeito relatado, o foco principal será reproduzi-lo em um ambiente controlado. Com base nas informações registradas quando o problema ocorreu, vários casos de teste precisam ser identificados como potenciais sugestões para provocar a ocorrência do defeito com segurança. Talvez seja necessário refinar alguns dos testes ou elaborar novos, mas lembre-se de que a reprodução do defeito é uma etapa essencial e, para os casos mais difíceis, levará mais tempo para estabilizar o defeito do que para corrigi-lo.

Para permitir que o tempo de execução do componente produza resultados com precisão, tenha cuidado de preparar o componente de forma satisfatória para que nenhum resultado anormal ocorra, como um subproduto de erros de implementação, compilação ou vínculo.

Muitas vezes, será necessário utilizar componentes em stub, para que a observação do tempo de execução possa ser concluída em tempo oportuno ou para que possa de fato ser conduzida em situações nas quais o componente depende de outros componentes que ainda não foram implementados.

Você precisará também preparar todas as ferramentas de suporte ou estrutura necessárias para executar o componente. Em alguns casos, isso pode significar a criação do driver ou do código de proteção para suportar a execução do componente; em outros casos, pode significar a instrumentação do componente de maneira que as ferramentas de suporte externas possam observar e possivelmente controlar o comportamento dos componentes.

É importante considerar todos os requisitos e limitações que devem ser tratados para o ambiente de destino no qual ocorrerá a análise do tempo de execução. Em alguns casos, será necessário simular um ou mais dos ambientes de implementação pretendidos, no qual a execução do componente enfim será exigida. Em outros casos, será suficiente executar a observação do comportamento do tempo de execução na máquina dos desenvolvedores.

Em qualquer dos casos, será importante configurar o ambiente de destino, para obter uma observação satisfatória do tempo de execução, de forma que o teste não seja desperdiçado pela inclusão de "contaminantes" que possivelmente invalidarão a análise subseqüente.

Outra consideração é utilizar as ferramentas que geram limitações ambientais ou condições de exceção que, por outro lado, são difíceis de reproduzir. Tais ferramentas são inestimáveis no isolamento de defeitos ou anomalias que ocorrem no comportamento do tempo de execução sob essas condições.

Tendo preparado o componente e o ambiente no qual ele será observado, comece agora a executar o componente no cenário escolhido. Dependendo das técnicas e das ferramentas empregadas, essa etapa poderá ser executada basicamente de forma não assistida ou poderá oferecer (ou mesmo exigir) atenção contínua conforme a progressão no cenário.

Durante cada etapa ou na conclusão do cenário que estiver observando, procure por defeitos ou anomalias no comportamento esperado. Tome nota de cada observação feita ou das impressões que você teve e que talvez estejam relacionadas ao comportamento anormal.

Utilize suas descobertas para começar a investigar falhas encobertas ou a causa raiz de cada defeito.

Depois de revisar todas as descobertas feitas, provavelmente você terá uma lista de idéias ou cogitações que exigirão investigação adicional e possivelmente ações corretivas específicas que serão propostas. Se você não for tomar uma ação imediata sobre esses itens por conta própria, anote suas propostas de maneira apropriada e comunique-as aos membros de sua equipe que podem aprovar ou encarregar-se delas.

Agora que o trabalho foi concluído, é recomendável verificar se o trabalho foi vantajoso. Você deve avaliar se o trabalho é de qualidade adequada e se ele é completo o suficiente para ser útil aos membros da equipe que o utilizarão em seguida como entrada para o trabalho deles. Onde for possível, utilize listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência são "suficientemente boas".

Permita que as pessoas que utilizarão seu trabalho como entrada, durante a execução das tarefas de recebimento de dados, façam parte da revisão do trabalho provisório. Faça isso enquanto você tiver tempo disponível para tomar alguma ação para resolver os problemas delas. Você também deve avaliar seu trabalho em relação aos principais produtos de trabalho de entrada, para certificar-se de que eles foram representados ou considerados de forma precisa e suficiente. Pode ser conveniente que o autor do produto de trabalho de entrada revise o seu trabalho nesse sentido.

Não se esqueça que o RUP é um processo de entrega iterativo e que, em muitos casos, os produtos de trabalho evoluem com o tempo. Como tal, nem sempre é necessário e, em muitos casos, é contraproducente, formar completamente um produto de trabalho que será utilizado apenas parcialmente ou que nem será utilizado imediatamente no trabalho subseqüente de recebimento de dados. Isso acontece porque há uma grande probabilidade de alteração na situação em torno do produto de trabalho e de que as suposições feitas durante a criação do produto de trabalho estejam incorretas, antes do produto de trabalho ser utilizado, resultando em retrabalho e, portanto, em esforço em vão.

Evite também a armadilha de gastar muitos ciclos na apresentação em detrimento do valor do próprio conteúdo. Em ambientes de projeto, onde a apresentação tem importância e valor econômico como um produto distribuível, você pode considerar a utilização de um recurso administrativo ou junior para executar o trabalho em um produto de trabalho, a fim de aprimorar sua apresentação.