Neste artigo reproduzo o framework para desenvolvimento ágil proposto por Jim Highsmith no livro “Agile Project Management: Creating Innovative Products, Second Edition”.
E você como tem desenvolvido os seus sistemas, ou mesmo tocados outros projetos que não de desenvolvimento? Tem adotado alguma das práticas ágeis, ou não? Utiliza-se do velho conhecido modelo “cascata”, ou alguma metodologia ágil?
Tenho buscado adotar algumas práticas propostas pelas metodologias ágeis para a gestão de projetos, pois entendo que só utilizar o PMBOK não é suficiente para um cenário de incertezas cada vez maiores nos projetos. Quando se busca abordagens para a gestão de projetos deve-se considerar que:
Para fechar 2011, segue uma lista com os cinco artigos publicados nesse ano que segundo o Google Analytics foram os mais lidos aqui no blog Qualidade de Software Ltda:
1. Visão geral: áreas de conhecimento do pmbok x cinco grupos de processos
2. Seis barreiras na elicitação de requisitos
3. Tipos de testes de software
4. Três abordagens principais para a elicitação de requisitos
5. Oito características de um bom requisito
Publico também os 10 sites que estiveram nos meus favoritos de 2011 (*em ordem alfabética)
1. Agile Testing with Lisa Crispin
3. Efetividade.net – Produtividade pessoal, lifehacking, GTD e dicas espertas
4. Gizmodo Brasil – Tech Lover
7. Mais Tempo – administração do tempo, produtividade e lifehacking
8. Presentation Software – Sliderocket
9. ScrumHalf – Ferramenta Web de Gerência de Projetos Ágeis Scrum – Brasil
10. TechCrunch
Gostaria de agradecer os mais de 21 mil visitantes que visitaram o Qualidade de Software Ltda e geraram mais 37 mil “page views”, e desejar a todos um feliz 2012 com muita saúde e realizações! E que possamos fazer nossos softwares melhores e livres de defeitos!. Até 2012..
O mercado de certificações profissionais na área de TI movimenta milhões todos os anos, e há certamente certificações para todas os tipos de necessidades, e aquelas mais reconhecidas e valorizadas e as que não fazem tanto sucesso.
Na área da engenharia de software há uma certificação que está agora sendo oferecida aqui no Brasil, e ainda pouco conhecida que é a CPRE-FL (Certified Professional Requirements Engineer – Foundation Level) . Essa certificação é mantida pelo IREB (International Requirements Engineering Board), e oferecida no Brasil pelo IBQTS (Instituto Brasileiro de Qualidade em Testes de Software).
Está disponível no site do IBQTS o material chamado de syllabus que documenta os conteúdos a serem estudados para o exame de certificação. Esse material pode ser obtido no site do IBQTS. Além do syllabus está disponível também um glossário de termos.
Por fim existe um livro recomendado para quem vai fazer o exame, que pode ser comprado na Amazon ainda só disponível em inglês. Veja mais informações na página sobre essa certificação.
Penso que todos os profissionais que trabalham com engenharia de software deveriam passar por algum tipo de certificação em engenharia de requisitos, dado a importância dessa disciplina para o desenvolvimento de um software com qualidade.
O Scrum tem sido cada vez mais adotado tanto para a gerência do desenvolvimento de software, como a gerência de projetos de modo geral. A gerência baseda no Scrum difere da escola tradicional de gestão em diversas áreas. A tabela abaixo sumariza as principais diferenças entre essas duas escolas:
Como professor da graduação do curso de tecnologia em análise e desenvolvimento de sistemas sei claramente as dificuldades que nossos alunos ainda enfrentam com a língua inglesa, o que muitas vezes acaba por limitar o acesso a bons materiais de engenharia de software.
Um outro ponto importante que sempre busco para os meus alunos são materiais de boa qualidade e de leitura leve. Acredito que isso facilite o aprendizado.
Relaciono abaixo cinco principais práticas propostas pelo Scrum:
1. Clientes devem se tornar parte do time de desenvolvimento;
2. Devem existir entregas intermediarias frequentes;
3. O time de desenvolvimento deve estar alerta aos riscos do projeto e desenvolver ações de tratamento aos riscos;
4. Não esconder problemas e riscos debaixo do tapete;
5. Deve haver transparência no planejamento e no desenvolvimento do módulo;
Ao ler essas cinco práticas propostas pelo Scrum penso: que realmente elas nos trás de novo?
Antes de conhecer os axiomas associados ao teste de software, precisamos saber que um axioma é uma sentença ou preposição que não é provada ou demonstrada e é considerada como óbvia ou como um consenso inicial necessário para a construção ou aceitação de uma teoria.
Por essa razão, é aceito como verdade e serve como ponto inicial para dedução e inferências de outras verdades (dependentes de teoria) (Fonte: Wikipédia)
Assim axiomas de testes de software são afirmações sobre testes admitidas como válidas ! Vamos então conhecer nove axiomas sobre os testes de software.
Ex.: Uma simples entrada de um número inteiro pode receber um grande número de possibilidades: número inteiros, números reais, caracteres, símbolos como “.” “,”
Assim nunca se deve dizer que em um determinado software não existem erros, mas apenas que em função dos testes realizados não foram encontrados erros!
Esse artigo faz parte da categoria de artigos conceituais e descreve os tipos de testes de software. Em outro artigo havia escrito sobre as fases de testes, e acredito que esse novo artigo contribua para o correto entendimento de conceitos fundamentais sobre testes.
Cada tipo de teste tem foco em um objetivo particular, por exemplo:
- em uma funcionalidade, a ser realizada pelo software;
–em uma característica da qualidade não-funcional, como a confiabilidade ou usabilidade,
–a estrutura ou arquitetura do software ou sistema;
– efeitos colaterais de mudanças ocorridas em partes do software, sobre as partes que não houveram mudanças.
Durante a execução dos testes funcionais por uma equipe independente do desenvolvimento, é importante estabelecer uma forma comunicação para o relato do progresso da execução dos testes.
No momento da execução a equipe já tem em mãos o total de caso de testes e se for uma equipe que possui registros históricos de outros projetos executados, terá também a produtividade dos executores medida em casos de testes executados por hora.
A partir disso suponha uma equipe com 5 executores, 8 horas de trabalho diário, com produtividade de 6 casos de testes por hora, e que estão a frente de um projeto para executar 1.000 casos de testes no prazo de 5 dias.
A tabela abaixo mostra um exemplo para o relato diário do progresso da execução dos testes funcionais para esse cenário proposto:
