Escolar Documentos
Profissional Documentos
Cultura Documentos
Alunos:
Professores:
Sumrio
ndice de Ilustraes ........................................................................................................................... 3 1. 1.1. 1.2. 1.3. 2. 3. 4. 5. 6. 7. Introduo .................................................................................................................................... 4 Propsito .................................................................................................................................. 4 Referncias ............................................................................................................................... 4 Viso Geral .............................................................................................................................. 4 Documentao gil ..................................................................................................................... 5 Definio de Papis...................................................................................................................... 5 Mtricas ........................................................................................................................................ 6 Plano de Reviso e Auditoria em Ambientes geis .................................................................. 6 Concluso ..................................................................................................................................... 6 Bibliografia .................................................................................................................................. 7
ndice de Ilustraes
Figura 1 Burn Down Chart ................................................................................................ 6
1. Introduo
Esse documento tem o propsito delinear um Planejamento de teste de instrumentao, ou Harness Test . Para facilitar a leitura o significado de alguns acrnimos, definies, e abreviaturas importantes sero colocados entre parnteses aps sua primeira apario neste documento. As referncias encontram-se na seo1.4 deste documento.
1.1.
Propsito
Desenvolver um documento que seja um norte para a aplicao do harness test no 2 Sprint Development do produto Smart Meter Residencial.
1.2.
Referncias
[1] Artefato de Viso v3.0 [2] Release e Sprints Backlog 3.0 [3] Artefato Product backlog RES v3.0 [4] Associao Brasileira de Normas Tcnicas ABNT Norma: NBR ISO/IEC 12207.
1.3.
Viso Geral
De acordo com a NBR 13596 (ISO/IEC 9126), algumas caractersticas que um software deve apresentar para ser considerado como um software de qualidade. Estas caractersticas so listadas na tabela a seguir: Caracterstica Funcionalidade Confiabilidade Usabilidade Eficincia Manutenibilidade Portabilidade Descrio Satisfaz as necessidades? imune a falhas? fcil de usar? rpido e enxuto? fcil de modificar? fcil de usar em outro ambiente?
Grande parte das caractersticas que determinam a qualidade de um software referese a boas prticas de engenharia de software e/ou eficincia da plataforma tecnolgica (Caelum). No Scrum (metodologia gil adotada pelo projeto SM-RES), procura prover qualidade no processo de desenvolvimento. Portanto em Scrum conseguimos uma melhora na qualidade atravs de diversos pontos e parar obter esta melhora na qualidade ir depender muito se Scrum est sendo bem implementado ou no. Dentre estes pontos, podemos destacar: Iteraes Remoo de impedimentos Inspeo e adaptao Autonomia Times multifuncionais
2. Documentao gil
Esta seo lista a documentao mnima que servir de base para este plano. O conjunto mnimo de artefatos neste caso so os citados abaixo:
[1] CES-63 - ARTEFATO VISAO RES v.2.0.pdf [2] CES-63 - ARTEFATO PRODUCT BACKLOG RES v.2.0.pdf [3] CES-63 - RELEASE E SPRINT BACKLOG V2.0.xls
3. Definio de Papis
Product Owner Ajuda a definir quais os requisitos do Product Backlog so necessrios para o cliente. Representa os usurios e o cliente. quem orienta a direo estratgica do produto final. Seu papel garantir que o projeto esteja progredindo. Verifica se cada membro da equipe est desempenhando seu papel e garante que ele tenha as ferramentas necessrias para isso. o responsvel por organizar as reunies, monitorar os trabalhos e facilitar o desenvolvimento do release. Ele o gerente do projeto e esta tarefa muito tediosa. Desenvolvem o produto Testa o que foi desenvolvido Utilizam o sistema Podem ser os diretores ou os donos da empresa, normalmente atrapalham todo o processo. Mas sem eles no teria projeto
Scrum Master
4. Mtricas
Ser definido pelo time a prioridade e tempo para cada User Storys e assim ser definido Release Backlog. Para realizar uma estimativa gial de cada User Story ser usado o Planning Poker, os passo so listados a seguir. L-se uma US; Estimadores fazem perguntas; Cada estimador seleciona um carto, ou anota um valor (Os valores vlidos recomendados para este uso so 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100); Verificao dos cartes revelados; Discusso sobre as diferenas.
O processo finaliza quando se chega a um consenso ou quando os estimadores decidem que uma estimativa de um determinado item deve ser adiada para assim conseguir informaes adicionais. Com o Release Backlog em mos sero definidos os Sprints Uma definio para um Sprint que ele significa um marco no desenvolvimento, so interaes curtas que permitem que o projeto sempre tenha algo pronto para entregar ao cliente. Este Sprints duram de alguns dias a no mximo 30, dependendo dos ciclos do Release do produto. Quanto mais curto for esse ciclo, mais breve o Sprint deve ser. Para cada Sprit ser criado um Burn Down Chart que prove valores dia-a-dia da quantidade de trabalho restante para liberar nossa Sprint para release. O grfico detalhado a seguir: [Burn Donw Chart]
Figura 1 Burn Down Chart
6. Concluso
7. Bibliografia
Caelum. (s.d.). Qualidade com Scrum. Acesso em 22 de Outubro de 2011, disponvel em Caelum Ensino e Inovao: http://blog.caelum.com.br/qualidade-com-scrum/