Atividade:
|
Finalidade
|
|
Função: Implementador | |
Freqüência: Esta atividade normalmente é executada várias vezes durante a criação ou modificação de um elemento de implementação. | |
Etapas
|
|
Artefatos de Entrada: | Artefatos Resultantes: |
Informações Adicionais: | |
Mentores de Ferramentas: |
Detalhes de Workflow: |
Finalidade: | Identificar o caminho de execução que estimulará o comportamento de tempo de execução desejado |
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 de serem explorados 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 de serem explorados costumam refletir todos ou parte daqueles que o usuário final 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 final 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 disponíveis do usuário final que oferecem uma explicação textual do caminho pelo qual o usuário final navegará através dos vários fluxos de eventos na especificação do 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 ator 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 esta atividade é motivada por um defeito reportado, 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.
Finalidade: | Garantir que o componente esteja pronto em um estado apropriado para permitir o tempo de execução |
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.
Finalidade: | Garantir que a configuração dos pré-requisitos do ambiente de destino tenha sido concluída da forma satisfatória. |
É 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 inaproveitado 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.
Finalidade: | Observar e capturar o comportamento do tempo de execução do componente. |
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.
Finalidade: | Identificar defeitos e anomalias no comportamento do tempo de execução dos componentes |
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.
Finalidade: | Entender a causa raiz de qualquer defeito e anomalia |
Utilize suas descobertas para começar a investigar falhas encobertas ou a causa raiz de cada defeito.
Finalidade: | Sugerir ações adicionais de investigação ou correção |
Depois de rever 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.
Finalidade: | Verificar se a atividade foi concluída de modo adequado e se os artefatos resultantes são aceitáveis. |
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, use 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 atividades 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 artefatos de entrada para certificar-se de que eles foram representados ou considerados de modo exato e suficiente. Talvez seja conveniente que o autor do artefato informado revise o seu trabalho nesse sentido.
Não se esqueça que o RUP é um processo iterativo e que, em muitos casos, os artefatos evoluem com o tempo. Como tal, nem sempre é necessário, e em muitos casos é contraproducente, formar completamente um artefato 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 artefato, e de os pressupostos feitos durante a criação do artefato estarem incorretos, antes do artefato ser utilizado, resultando em esforço perdido e retrabalho dispendioso.
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 liberado do projeto, convém utilizar um recurso administrativo ou inovador para fazer o trabalho em um artefato para aprimorar sua apresentação.
Rational Unified Process
|