Métodos Ágeis - Aula 01
•Télécharger en tant que PPTX, PDF•
1 j'aime•511 vues
O documento discute os métodos ágeis e o gerenciamento do ciclo de vida de aplicações (ALM), apresentando os desafios comuns em projetos de software, as fases do ALM e as disciplinas envolvidas.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (8)
Similaire à Métodos Ágeis - Aula 01
Similaire à Métodos Ágeis - Aula 01 (20)
Plus de Adriano Bertucci
Plus de Adriano Bertucci (9)
Métodos Ágeis - Aula 01
- 1. MÉTODOS ÁGEIS Aula 01 Adriano Bertucci Email: adriano@bertucci.com.br Twitter: @adrianobertucci Site: www.adrianobertucci.com
- 2. TÍPICO PROJETO DE SOFTWARE “Nossa equipe não produz o quanto gostaríamos” “Nosso cronograma está atrasado” “Nossa equipe de desenvolvimento não se comunica” “Precisamos nos adequar às novas legislações” “Não conseguimos garantir a qualidade das soluções”
- 3. DESAFIOS - PROBLEMAS COMUNS Requisitos de negócios não são gerenciados de forma efetiva Ferramentas e dados dispersos Testes não alinhados aos objetivos de negócios Falta de orientações e processos definidos Problemas de comunicação entre os membros da equipe Visibilidade limitada do status do projeto para tomada de decisões
- 4. COMO ESTA A SAÚDE DO SEU PROJETO? Cronograma e controle de atividades? Controle de defeitos? Quais cenários foram testados com sucesso? Cobertura do código testado? Rotatividade do código – estabilização? Requisições de mudanças gerenciadas adequadamente? Controle sobre que fontes foram alterados por causa de determinado requisito / correção?
- 5. SOLUÇÃO? ALM! ALM (Application Lifecycle Management, Gerenciamento do Ciclo deVida de Aplicações): É a coordenação das atividades do ciclo de vida de desenvolvimento, incluindo: Requisitos Modelagem Desenvolvimento Testes Manutenção Operações
- 6. PILARES DO ALM - PESSOAS
- 7. PILARES DO ALM - PROCESSO
- 8. PILARES DO ALM - FERRAMENTAS
- 9. FASES DO ALM - DEFINIÇÃO
- 10. FASES DO ALM - CONSTRUÇÃO
- 11. FASES DO ALM - CONSTRUÇÃO
- 12. FASES DO ALM - OPERAÇÃO
- 13. FASES DO ALM - OPERAÇÃO ITIL (InformationTechnology Infrastructure Library) Gerência de Capacidades Gerência de Incidentes Gerência Financeira Gerência de Configuração Gerência de serviços de atendimento Gerência de níveis de serviço Gerência de problemas Gerência de distribuição Gerência de Mudanças
- 14. FASES DO ALM - FIM
- 15. DISCIPLINAS PRESENTES NO ALM Gerenciamento de Requisitos (Requeriments Management)
- 16. DISCIPLINAS PRESENTES NO ALM Gerenciamento da Configuração do Software (Software configuration Management)
- 17. DISCIPLINAS PRESENTES NO ALM Montagem e Integração (Build and Integration)
- 18. DISCIPLINAS PRESENTES NO ALM Engenharia de Distribuição (Release Engineering)
- 19. DISCIPLINAS PRESENTES NO ALM Gerenciamento de Defeitos (Defect Management)
- 20. DISCIPLINAS PRESENTES NO ALM Teste Unitário, Integrado e de Regressão (UnitTest, Integrated and Regression)
- 21. DISCIPLINAS PRESENTES NO ALM Análise de Código (Code Analysis)
- 22. DISCIPLINAS PRESENTES NO ALM Teste de Sistema (SystemTest)
- 23. DISCIPLINAS PRESENTES NO ALM Relatórios de Acompanhamento (Status Reports)
- 24. ADOÇÃO DO ALM quais os envolvidos na construção da aplicação; as expectativas de cada um; quais as ferramentas utilizam; como é gasto do tempo deles; onde estão localizados fisicamente; quais modelos/processos utilizam no dia-a-dia; quais os relatórios que utilizam para monitorar o projeto; qual o modelo de migração da aplicação do ambiente de desenvolvimento para o ambiente de produção; como são estruturados os projetos dentro da ferramenta de controle de código-fonte; quais as estratégias de montagem da aplicação; quais os tipos de testes empregados na construção da aplicação; como compartilham boas práticas de construção;
- 26. CAMINHO PARA O SUCESSO… Ideia Solução
- 27. O CAMINHO DA ENG. DE SOFTWARE Não é parecida com Engenharia Civil! Após construir uma casa não é fácil mudar uma parede de lugar!!! Mas em software, “mudar uma parede de lugar” é sim relativamente fácil... Tampouco é muito parecida com outras engenharias!!! Software é flexível!!!
- 28. ENGENHARIA DE SOFTWARETRADICIONAL Desenvolvimento ad-hoc de software em geral produz resultados muito ruins; Especialmente em sistemas grandes Desejo de criar uma engenharia para que se tenha controle sobre desenvolvimento de software; Engenharias tradicionais colocam grande ênfase em projetar antes de construir;
- 29. VISÃOTRADICIONAL DA EVOLUÇÃO DO SOFTWARE custo momento em que funcionalidade é adicionada
- 30. QUEREMOS PODER ALTERAR O SOFTWARE No inicio do projeto, normalmente não se sabe precisamente o que se quer Software evolui para atender ao negócio Software nunca fica “pronto” Obviamente isso só é possível porque software é uma entidade abstrata
- 31. PORTANTO… Precisamos parar de tentar evitar mudanças Mudanças são um aspecto intrínseco da vida do software Precisamos de uma metodologia de desenvolvimento que nos permita alterar constantemente o código sem comprometer sua qualidade
- 32. O QUE QUEREMOS É… custo momento em que funcionalidade é adicionada
- 33. O QUE FAZER?
- 34. RECADO IMPORTANTE! “Se não pode ser medido, não pode ser gerenciado, e se não pode ser gerenciado, para que investir?”
- 35. FERRAMENTAS
- 38. PROCESSO DETRABALHO Analista de Negócio Gerente de Projeto Time de Desenvolvimento Test Operações Requisição De Mudança Cenários Requerimentos de Negócio Bugs Tarefas Erros em Produção Itens de trabalho são a unidade de comunicação entre as pessoas do time Builds Implantação
- 39. ITENS DETRABALHO Descrição Estado Atual Atribuição de tarefas Anexos Links para outros Itens de Trabalho Histórico totalmente auditado Personalizável Encerrado Ativo Solucionado Encerrado Ativo Solucionado Proposta Caso de Uso Tarefas Bugs “Os itens de trabalho são unidades de comunicação que fazem parte do processo de desenvolvimento”
- 40. MODELOS - PLATAFORMAVISUAL STUDIO MSF for Agile -Visual StudioALM
- 41. MODELOS - PLATAFORMAVISUAL STUDIO MSF for CMMI -Visual Studio ALM
- 42. MODELOS - PLATAFORMAVISUAL STUDIO Visual Studio Scrum 2.0 -Visual Studio ALM
- 43. ALM – CÍCLO CONTINUO DE ENTREGAS
- 44. PRÓXIMO ENCONTRO… Agilidade conceitos Scrum
- 45. PRATICANDO… LOTES DE PRODUÇÃO X PRODUTIVIDADE Analista Projetista Programador Testador Cliente Æ ŒRef: Luiz Cláudio Parzianello
- 46. PRATICANDO… LOTES DE PRODUÇÃO X PRODUTIVIDADE Æ … Æ ŒÆÆ … Æ Œ ™Æ ŒÆ Œ … Æ Œ ™Æ Œ ™ … Ref: Luiz Cláudio Parzianello Æ Æ Œ Æ Œ ™ … … … … Pequenos Lotes Grandes Lotes
- 47. PRATICANDO… LOTES DE PRODUÇÃO X PRODUTIVIDADE Qual é o arranjo logístico mais rápido? Qual equipe apresentou o maior esforço por projeto? Quais as vantagens de cada abordagem? Quais as desvantagens de cada abordagem? Qual a justificativa para manter os grandes lotes?
- 48. ARTIGOS… Disserte sobre ALM demonstrando a visão do grupo sobre o assunto e os principais motivos para se adotar. O que é agilidade para grupo? Cite os ganhos do uso de um processo ágil no desenvolvimento de software.
Notes de l'éditeur
- Pilar “Pessoas” Esta figura emprega uma imagem poderosa, a participação das pessoas. Veja que o pilar “pessoas” está presente em todos os níveis. Pessoas bem treinadas e capacitadas formam a cola que une adequadamente as ferramentas e os processos do ALM. Cada uma destas pessoas possui seus objetivos, de uma maneira geral, destacamos: 1 - Analista de Negócios O objetivo do Analista de Negócios é entender as necessidades e comunicá-las para a equipe do projeto. A sua atuação se concentra junto a usuários, clientes e outros participantes, transformando suas percepções em cenários, modelos e requisitos documentados. Ele também é responsável em administrar as expectativas junto aos participantes do projeto. 2 - Gerente de Projeto O objetivo do Gerente do Projeto é entregar o projeto dentro do orçamento e prazo acordados. Seu trabalho se concentra no planejamento do projeto, elaboração do cronograma, monitoração das atividades do projeto. 3 - Arquiteto O objetivo do Arquiteto é desenhar as fundações da aplicação. Inclui estruturar tanto do ponto de vista lógico, como físico como a aplicação funcionará, bem como o seu comportamento no ambiente de produção. Em paralelo, o Arquiteto procura reduzir a complexidade da aplicação, dividindo-a em partes simples. O uso de boas práticas e modelos de mercado ajuda o Arquiteto na execução do seu trabalho. 4 - Desenvolvedor O objetivo do Desenvolvedor é transformar as especificações em código. O Desenvolvedor também ajuda na criação da especificação física de algumas funcionalidades, estimar tempo para a construção, compilar e preparar a aplicação para a distribuição. 5 - Desenvolvedor de Banco de Dados O objetivo do Desenvolvedor de Banco de Dados é implementar no banco de dados os requisitos planejados. Assim como o Desenvolvedor, este papel também ajuda na criação da específica física, estimar tempo para construção e supervisionar a construção dos modelos de banco de dados. 6 - Testador O objetivo do Testador é descobrir problemas na aplicação e informá-los para a correção. O trabalho do Testador consiste em executar testes pré-definidos, coletar as amostras dos resultados e compará-las com o esperado. Uma vez detectado um problema, o Testador deve informar à equipe as condições para reprodução do problema. 7 - Gerente de Operação O objetivo do Gerente de Operação é suportar o processo de distribuição da nova aplicação para o ambiente de produção e de usuários. 8 - DBA O objetivo do DBA é suportar a equipe na montagem do banco de dados, e criar os mecanismos para a transferência deste banco de dados para o ambiente de produção. Além disso, o DBA também é responsável em manter diariamente a saúde dos bancos de dados na produção. 9 - Escritório de Projetos O Escritório do Projeto é um departamento (alguns casos um orgão de staff) que gerencia o portfólio dos projetos da empresa. As funções de um Escritório do Projeto são monitoramento da saúde dos projetos, divulgação de padrões e guias, suportar os gerentes do projeto. 10 - Executivo Em uma perspectiva ampla, o objetivo do Executivo é buscar o alinhamento estratégico, redução de custo operacional, procura pela eficiência operacional e resultado financeiro.
- Pilar “Ferramentas” Por último, as “ferramentas” são os meios/equipamentos/tecnologias que automatizam e facilitam a condução dos processos pelas pessoas.
- Pilar “Pessoas” Esta figura emprega uma imagem poderosa, a participação das pessoas. Veja que o pilar “pessoas” está presente em todos os níveis. Pessoas bem treinadas e capacitadas formam a cola que une adequadamente as ferramentas e os processos do ALM. Cada uma destas pessoas possui seus objetivos, de uma maneira geral, destacamos: 1 - Analista de Negócios O objetivo do Analista de Negócios é entender as necessidades e comunicá-las para a equipe do projeto. A sua atuação se concentra junto a usuários, clientes e outros participantes, transformando suas percepções em cenários, modelos e requisitos documentados. Ele também é responsável em administrar as expectativas junto aos participantes do projeto. 2 - Gerente de Projeto O objetivo do Gerente do Projeto é entregar o projeto dentro do orçamento e prazo acordados. Seu trabalho se concentra no planejamento do projeto, elaboração do cronograma, monitoração das atividades do projeto. 3 - Arquiteto O objetivo do Arquiteto é desenhar as fundações da aplicação. Inclui estruturar tanto do ponto de vista lógico, como físico como a aplicação funcionará, bem como o seu comportamento no ambiente de produção. Em paralelo, o Arquiteto procura reduzir a complexidade da aplicação, dividindo-a em partes simples. O uso de boas práticas e modelos de mercado ajuda o Arquiteto na execução do seu trabalho. 4 - Desenvolvedor O objetivo do Desenvolvedor é transformar as especificações em código. O Desenvolvedor também ajuda na criação da especificação física de algumas funcionalidades, estimar tempo para a construção, compilar e preparar a aplicação para a distribuição. 5 - Desenvolvedor de Banco de Dados O objetivo do Desenvolvedor de Banco de Dados é implementar no banco de dados os requisitos planejados. Assim como o Desenvolvedor, este papel também ajuda na criação da específica física, estimar tempo para construção e supervisionar a construção dos modelos de banco de dados. 6 - Testador O objetivo do Testador é descobrir problemas na aplicação e informá-los para a correção. O trabalho do Testador consiste em executar testes pré-definidos, coletar as amostras dos resultados e compará-las com o esperado. Uma vez detectado um problema, o Testador deve informar à equipe as condições para reprodução do problema. 7 - Gerente de Operação O objetivo do Gerente de Operação é suportar o processo de distribuição da nova aplicação para o ambiente de produção e de usuários. 8 - DBA O objetivo do DBA é suportar a equipe na montagem do banco de dados, e criar os mecanismos para a transferência deste banco de dados para o ambiente de produção. Além disso, o DBA também é responsável em manter diariamente a saúde dos bancos de dados na produção. 9 - Escritório de Projetos O Escritório do Projeto é um departamento (alguns casos um orgão de staff) que gerencia o portfólio dos projetos da empresa. As funções de um Escritório do Projeto são monitoramento da saúde dos projetos, divulgação de padrões e guias, suportar os gerentes do projeto. 10 - Executivo Em uma perspectiva ampla, o objetivo do Executivo é buscar o alinhamento estratégico, redução de custo operacional, procura pela eficiência operacional e resultado financeiro.
- Na primeira fase, denominada como “Definição”, procura identificar quais as necessidades e motivações que uma empresa tem. Por exemplo, o surgimento de um mercado novo, um problema na linha de produção, busca por informações competitivas ou outras. A etapa ”iniciar” é a responsável em alocar os recursos iniciais (processos, ferramentas e pessoas). Com os recursos alocados pula para a etapa de “definir”. Ela é responsável estruturar a idéia, definir estratégias, métodos e ferramentas para guiar o surgimento de uma nova aplicação. É vital para o sucesso deste empreendimento, que estas duas etapas estejam alinhadas junto ao plano estratégico da empresa e às direções da arquitetura corporativa. Vale destacar que uma boa definição é o resultado de uma comunicação clara e eficaz com todos os envolvidos. A etapa “escolher” identifica dentro das várias opções de ferramentas, métodos e tecnologias, quais são os adequados. Seja através da construção de uma aplicação própria (aplicações internas), da aquisição de algum pacote externo (aplicações de fornecedores) ou até mesmo de uma união entre ambas. Usam-se várias técnicas para identificar, tais como: técnicas de levantamento, disciplinas de avaliação de retorno de investimentos (ROI – Return Of Investiment) e busca de referências no mercado.
- A fase “Construção” é onde ocorre a execução do plano definido nas fases anteriores. Usam-se as disciplinas de gerenciamento de projeto para conduzir o plano. Um conjunto de boas práticas em gerenciamento de projeto é o PMBoK (Project Management Base of Knowledge). O PMBok define várias áreas de atuação dentro de um projeto, cada qual com suas entradas, ações e resultados esperados. Um aspecto relevante do PMBok é a procura pelo equilíbrio entre os três principais aspectos de um projeto: recursos, tempo e funcionalidades/qualidades. O termo “Recursos” pode ser entendido como todos os recursos (pessoas, máquinas,equipamentos, tecnologias) necessários para execução do projeto. “Funcionalidades/qualidade” são os resultados esperados da execução do projeto, tangíveis ou não. E “tempo”, é o período esperado em que o projeto seja executado. CITAR O TRIANGULO DE PROJETOS
- Desde o início da computação, surgiram diversas metodologias e modelos de maturidade. Todas com o propósito direto ou indireto de garantir a entrega da aplicação dentro do tempo acordado, com os recursos planejados e atendendo as funcionalidades esperadas. Um ponto que merece destaque é que não há modelo ou metodologia perfeita, cada empresa deve procurar a que for mais adequada. Em uma avaliação da escolha de uma metodologia, podemos citar alguns fatores que são importantes ter em mãos: qual é taxa de investimento em TI da empresa, organização da equipe, modelo de negócio da empresa, métricas esperadas para o controle do projeto. Na figura 4, podemos ver uma evolução destes modelos.
- A fase “operação” se dá no momento em que a aplicação está construída, e vamos distribuí-la, além de mantê-la funcional no ambiente da empresa. Os departamentos da empresa responsáveis em manter a infra-estrutura de TI são os mais envolvidos nesta etapa. Ser capaz de monitorar, governança, suporte de fornecedores, entre outras tarefas tornam a fase de operação mais crítica para organização. Tal como a fase de “construção”, também existem no mercado diversos modelos/frameworks para operacionalizar a infra-estrutura de TI, como, COBIT, MOF,ITIL e ISO 20.000.
- Por exemplo, o ITIL [MEN1], envolve algumas disciplinas importantes para o time de infra-estrutura de TI de uma empresa, veja: - Gerência de capacidades (Capacity management): Identificar e provisionar os recursos necessários de TI em conformidade com as necessidades da empresa; - Gerência de incidentes (Incident management): O objetivo é restaurar as condições da infra-estrutura de TI o mais rápido possível, procurando minimizar os impactos sobre as operações da empresa; - Gerência financeira (Financial management): O objetivo é trazer para a empresa os custos mais efetivos dentro de uma infra-estrutura de TI; - Gerência de configuração (Configuration management): Gerar o inventário de todos os ativos de uma infra-estrutura de TI (hardware e software); - Gerência de serviços de atendimento (Service desk management): Tratar e gerenciar os incidentes e requisições que uma infra-estrutura de TI sofre durante a sua existência; - Gerência de níveis de serviços ( SLA management): O objetivo é identificar, monitorar e avaliar os níveis de serviços que foram definidos para uma infra-estrutura de TI; - Gerência de problemas (Problem management): O objetivo é identificar as raízes dos incidentes que uma infra-estrutura de TI sofre, reduzindo ou evitando que ocorram novamente; - Gerência de distribuição (Release management): O objetivo é organizar e até automatizar o processo de distribuição de ativos de uma infra-estrutura, seja tanto no aspecto de novas versões, quando nas correções ou evoluções; - Gerência de mudanças (Change management): O objetivo é controlar o processo de mudanças na infra-estrutura de TI. Os demais modelos/frameworks também utilizam algumas destas disciplinas. Se uma empresa quer adotar algum destes modelos, deve avaliar qual dos modelos está mais aderente à sua realidade.
- Finalmente temos a fase “final”, este é o momento em que a empresa pode evoluir a sua aplicação, substituindo por outra versão ou adicionando novos recursos no ambiente de produção.
- Gerenciamento de Requisitos (Requeriments Management) No contexto de construção de uma aplicação, requisitos são a expressão do que a aplicação deve fazer e o que é esperado dela em momento de execução. Um requisito pode ser entendido como a descrição do comportamento de um sistema, por exemplo, em uma aplicação de comércio eletrônico teríamos um requisito definido “durante a visita de um usuário ao site, o site deve apresentar uma série de sugestões de produtos em conformidade com comportamento de compra do mesmo.”. O gerenciamento de requisitos é a prática de documentar e manter a rastreabilidade dos requisitos ao longo do ciclo de vida da aplicação. Dentro do gerenciamento de requisitos temos algumas ações: Documentar os requisitos funcionais e não-funcionais; Identificar se os requisitos estão aderentes com as necessidades de negócio; Priorizar os requisitos; Selecionar os requisitos que serão implementados no projeto ou em fase específica; Identificar a dependência entre os requisitos; Mapear os requisitos com a arquitetura; Mapear os requisitos com as funcionalidades da aplicação; Verificar se os requisitos foram atendidos e estão em conformidade com as necessidades dos usuários; Então, pode-se notar que esta disciplina é crucial para o sucesso do projeto.
- Gerenciamento da Configuração do Software (Software configuration Management) O processo de construção de uma aplicação envolve a geração de diversos artefatos (código-fonte, documentos, planilhas, apresentações), os quais podem sofrer diversas modificações durante a sua existência. A disciplina de Configuração de Software é responsável em manter e gerenciar estes diversos artefatos, além gerar a rastreabilidade e versionamento dos mesmos. Podemos destacar algumas ações realizadas por esta disciplina: Controlar o acesso aos artefatos Armazenar as múltiplas versões de cada artefato Rastrear as modificações de cada versão Comparar versões Identificar a versão dos artefatos que estão diretamente ligadas uma versão final da aplicação Restaurar versões especificas dos artefatos basedo em uma versão específica da aplicação A disciplina de Configuração de Software talvez seja a mais utilizada nas organizações, já que é muito apoiada por ferramentas amplamente disponíveis no mercado. Porém, é importante considerar que a existência unicamente dela não garante um processo de adequado.
- Montagem e Integração (Build and Integration) Em sua maioria, os projetos atuais são compostos de diversos módulos, componentes, controles. A disciplina de Montagem e Integração consiste na prática de unir todos estes componentes em apenas um único pacote, a fim de ser testado e distribuído na infra-estrutura de TI. Algumas ações que a disciplina Montagem e Integração fazem: Recuperar todos os artefatos do repositório de código-fonte; Mapear os artefatos com a nova versão da aplicação; Compilar o código-fonte; Organizar o código compilado em um específico layout conforme definido; Criar um pacote de instalação (setup) para ser testado; Abortar o processo de build caso encontre algum erro ou inconsistência nos artefatos; É importante considerar que o processo de montagem e integração deve ser visto não apenas como uma tarefa de “compilação”, mas sim, como a integração das diversas partes, garantindo que todas estejam estáveis.
- Engenharia de Distribuição (Release Engineering) A disciplina de Engenharia de Distribuição é responsável por garantir a consistência das diversas versões da aplicação. Sabe-se que uma aplicação durante a sua construção e manutenção, terá várias versões, além de correções. Sem uma engenharia adequada, há um sério risco de indisponibilidade da aplicação, que pode causar perdas financeiras e de imagem para a empresa. A disciplina de Engenharia de Distribuição trabalha fortemente em conjunto com a disciplina de Configuração de Software para garantir que os artefatos estejam devidamente marcados e rastreáveis, tanto na produção como na construção. Destacamos abaixo algumas ações: Documentação das dependências externas de cada versão; Minimizar o downtime das atualizações de versões; Utilização de ferramentas para automatizar a distribuição das versões ou correções; Tratar rapidamente as falhas de distribuição
- Gerenciamento de Defeitos (Defect Management) A disciplina de Gerenciamento de Defeitos consiste em coletar as ocorrências e tratar como elas serão corrigidas, além, de procurar identificar as suas raízes e evitar que no futuro possam ocorrer novamente. Algumas ações da disciplina de Gerenciamento de Defeitos: Descrever o comportamento esperado; Descrever o comportamento ocorrido; Descrever os passos necessários para reproduzir o defeito; Priorizar os defeitos conforme a demanda; Direcionar o defeito para ser corrigido por um desenvolvedor; Registrar se o defeito foi corrigido;
- Teste Unitário, Integrado e de Regressão (Unit Test, Integrated and Regression) O teste unitário é o teste isolado e exercido apenas sobre um componente, que pode ser uma classe ou um método. Os testes unitários são pequenos programas que testam se os componentes estão gerando o resultado esperado, conforme um conjunto de valores de entrada. Os testes integrados atuam sobre módulos, é uma tarefa normalmente executada pelos programadores. Os testes de regressão verificam se as alterações introduzidas a cada novo build não geraram novos defeitos. O benefício de aplicar estes testes é o de garantir a qualidade do software e sua conformidade com os requisitos definidos. Detectando os defeitos ainda na fase da construção, permite que eles não se perpetuam, reduzindo assim o custo de manutenção. Algumas ações: Criação de testes unitários para cada componente; Criação dos testes integrados no nível de módulos lógicos e casos de uso; Os testes são também considerados artefatos, e assim devem ser armazenados dentro do repositório; Uso de ferramentas para automatizar a geração de relatórios e logs de erros; Nos últimos anos, os testes unitários vêem sendo usados amplamente pelos desenvolvedores, devido a sua eficiência em garantir que a aplicação tenha qualidade desde os seus componentes mais primitivos.
- Análise de Código (Code Analysis) A disciplina Análise de Código é responsável em identificar se o código escrito está aderente a padrões e políticas da empresa. Algumas ações realizadas por esta disciplina: Validar o formato e estilo de codificação; Verificar a documentação interna do código; Garantir o uso de “design patterns”; Detectar problemas de desempenho; Identificar vulnerabilidades conforme as políticas de segurança; Garantir a proteção e privacidade das informações que a aplicação manipula; Identificar a compatibilidade da aplicação em conformidade com normas de mercado;
- Teste de Sistema (System Test) A disciplina Teste de Sistema envolve o teste da aplicação quando completada. Os testes funcionais, conhecidos como testes “de caixa preta”, são executados por esta disciplina. Eles procuram identificar se a aplicação está aderente aos requisitos, além de serem usados como ferramentas para aceitação ou não da aplicação construída. Os testes de sistema são facilitados quando as disciplinas de gerenciamento de requisitos, configuração de software, análise de código e gerenciamento de defeitos são executadas corretamente. Tipicamente algumas ações desta disciplina: Detectar problemas em desempenho; Detectar se os requisitos estão presentes na aplicação;
- Relatórios de Acompanhamento (Status Reports) Conforme dito, o ALM preocupa-se em informar a todos os papéis como está o andamento do ciclo de vida da aplicação. Além de relatórios de bugs, re-trabalho, qualidade de código, serve como base os relatórios sobre a taxa disponibilidade da aplicação na produção (SLA), uso de recursos na infra-estrutura de TI, retorno sobre investimento e outros.
- Adoção do ALM Para adotar o ALM, o primeiro passo é determinar o que realmente a empresa precisa. O tamanho da empresa influencia diretamente sobre a estratégia de adoção. Sugira realizar como primeiro passo uma entrevista com os participantes. Nesta entrevista identifique: quais os envolvidos na construção da aplicação; as expectativas de cada um; quais as ferramentas utilizam; como é gasto do tempo deles; onde estão localizados fisicamente; quais modelos/processos utilizam no dia-a-dia; quais os relatórios que utilizam para monitorar o projeto; qual o modelo de migração da aplicação do ambiente de desenvolvimento para o ambiente de produção; como são estruturados os projetos dentro da ferramenta de controle de código-fonte; quais as estratégias de montagem da aplicação; quais os tipos de testes empregados na construção da aplicação; como compartilham boas práticas de construção; A próxima etapa é a execução de um projeto piloto. Um projeto piloto permite experimentar em ambiente controlado, as diversas tarefas, obstáculos e ações na implantação do ALM. O escopo do projeto piloto deve conter as principais disciplinas do ALM que a empresa necessita. É importante também, que o projeto piloto tenha uma abrangência ampla na empresa, afim que de possa envolver vários papéis. Os resultados esperados do projeto piloto incluem: Modelos de documentos e processos aderentes à realidade da empresa Matriz de papéis e responsabilidades Requisitos de hardware e software para o ambiente de produção Materiais de treinamento para as equipes que utilizarão o ALM na produção Com estes resultados em mãos, a empresa terá condições de avaliar o real esforço para implantar o ALM em toda sua estrutura. A última etapa é a migração do conhecimento gerado no projeto piloto para o seu ambiente de produção. Após a migração, procure avaliar o retorno do investimento, por exemplo, comparando as métricas de bugs detectados e tempo utilizado para resolvê-los antes do ALM e depois.