Introdução ao Application Lifecycle Management (ALM)

  • Artigo

Luciano Condé
Arquiteto de Soluções – Microsoft Brasil
Junho de 2009

Resumo

A atividade de construção de aplicações é executada através do emprego intenso do trabalho humano, consequentemente exige das empresas somas de investimento financeiro. Parte deste investimento é consumido por atrasos de cronograma, re-trabalho, testes inadequados e outros. Estima-se que em 2002, gastaram cerca 20 bilhões de dólares só com testes inadequados de software feito por desenvolvedores de software[7].

Em paralelo, desde a década de 90, a tecnologia da informação está cada vez mais presente dentro das empresas e na vida das pessoas. A Tecnologia da informação (TI) surgiu inicialmente dentro dos mainframes, passou pela revolução da micro-computação para as massas, até chegar na computação na nuvem. Hoje podemos ver bolsas de valores automatizadas, empresas de telecomunicações administrando milhares de chamadas simultâneas, cadeias de suprimentos totalmente integradas e tanto outros segmentos usando massivamente TI.

Com isto temos um paradoxo: de um lado há o uso contínuo e massivo de aplicações no dia-a-dia das empresas e usuários e do outro lado a dificuldade em produzir as mesmas aplicações de forma sofisticada e com a qualidade desejada. Esse desafio vem motivando o surgimento de métodos e ferramentas de trabalho para a organização dos processos de produção de aplicações e engenharia de software. O objetivo deste artigo é apresentar uma introdução sobre o gerenciamento do ciclo de vida de uma aplicação, desde sua concepção até o processo de manutenção evolutiva, também conhecido como Application Lifecycle Management (ALM).

Conteúdo

 Introdução
 Pilares do ALM
 Fases do ALM
 Disciplinas presentes no ALM
 Adoção do ALM
 Conclusão
 Referências
 Agradecimentos
 Sobre o Autor

Introdução

Em contabilidade, um ativo é todo o bem ou direito que uma empresa possui resultante de alguma transação econômica. Um ativo pode ser tangível ou intangível; o primeiro representa um bem ou direito que possui um corpo físico, por exemplo, terrenos, máquinas ou equipamentos. Já os ativos intangíveis são aqueles que não possuem um corpo físico, por exemplo, patentes, marcas ou direitos autorais. O propósito dos ativos é servir de ferramentas para que as empresas possam produzir os seus produtos ou gerar os seus serviços.

Com a incorporação de TI no dia-a-dia das empresas, as aplicações tornaram-se ferramentas para auxiliar o processo de produção de produtos ou serviços. Vemos bancos, bolsas de valores, empresas de telecomunicações, empresas de logísticas e outras, todas dependentes de aplicações especializadas para cuidar dos seus processos de negócios. Por causa desta situação, podemos considerar que as aplicações são ativos intangíveis das empresas. E como qualquer ativo, elas necessitam de cuidados na aquisição/construção, na utilização e por final na manutenção.

Podemos definir ALM como todo o processo que guia a vida útil de uma aplicação desde a sua concepção, passando pela construção, operação e evolução. O ALM não apenas observa qual é o método de construção, mas preocupa também em como a empresa está gastando o seu dinheiro no gerenciamento daquele ativo corporativo.

Um destaque importante é a diferença entre ALM e Software Development Lifecycle  (SDLC). O SDLC pode ser definido em uma tradução livre, de acordo com Jayaswal & Patton [J&P1], como “como um processo focado no desenho, criação e manutenção de aplicações”. O ALM é um guia que acompanha toda vida da aplicação, tendo o SDLC como uma das fases do ciclo de vida.

Entendido o contexto que o ALM se aplica, vamos entrar em detalhes sobre quais são os pilares do ALM.

arrow_px_up.gif Início da página

Pilares para ALM

O ALM é estruturado em cima de três pilares que se complementam, são eles: pessoas, processos e ferramentas. Quando unidos, fornecem os recursos necessários para que as empresas possam gerenciar o ciclo de vida das suas aplicações. Veja na figura abaixo:

Figura 1 - Pilares do ALM

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 “Processos”

O pilar “processos” é identificado como todo o conjunto de boas práticas, artefatos, guias e manuais que conduzem a construção e manutenção de uma aplicação. Entenda que ao falarmos de processos, estamos falando desde os processos de levantamento das necessidades, passando pela construção (SDLC) e até finalmente no monitoramento das aplicações em ambiente operacional.

Pilar “Ferramentas”

Por último, as “ferramentas” são os meios/equipamentos/tecnologias que automatizam e facilitam a condução dos processos pelas pessoas.

arrow_px_up.gif Início da página

Fases do ALM

Conforme foi dito anteriormente, o ALM abrange a vida de uma aplicação, podemos observar na figura 2 quais são as fases.

Figura 2 - Fases do ALM

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.

Figura 3 - Triângulo de gerenciamento 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.

Figura 4 - Evolução das metodologias e 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.

arrow_px_up.gif Início da página

Disciplinas presentes no ALM

O uso de disciplinas permite identificar as entradas e resultados esperados em cada etapa do ALM, bem como quem são os envolvidos. Veremos a frente quais são as disciplinas.

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.

arrow_px_up.gif Início da página

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.

Conclusão

As aplicações são parte integrante da empresas e cuidar do processo de levantamento, construção e manutenção é imprescindível para que empresas se mantenham operacionais. Como vimos ao longo deste artigo o ALM envolve diversos aspectos da organização, desde papéis, ferramentas e processos.

É importante considerar que a adoção do ALM não pode ser simplesmente restringida à aquisição de uma ferramenta e sua instalação, mas sim, ter a existência de processos claros e bem-definidos, pessoas treinadas.

Referências

[1] [J&P1] "Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software", por  Bijay K. Jayaswal, Peter C. Patton, 2007

[2] [MEN1] "ITIL and the Future of Managed Services, Part 1: Customers Speak Out", por Camille Mendler, Agosto 2007

[3] “SDLC Infrastructure: Supporting the Development Process”, por Joe Niski, Maio, 2007

[4] “What is Application Lifecycle Management?”, por Martin Fowler, Dezembro 2008

[5] “Process Templates and Tools”

Ref: https://msdn.microsoft.com/en-us/teamsystem/aa718795.aspx

[6] "PmBok: Project Management Base of Knowledge", por  PMI, Novembro de 2004

[7] "O impacto econômico da infra-estrutura inadequada de Testes de Software", por NIST, 2002

[5] “Security Development Lifecycle”

Ref: https://msdn.microsoft.com/en-us/security/cc448177.aspx

Agradecimentos

Obrigado ao Markus Christen, Otávio Pecego Coelho, Rafael Godinho e Waldemir Cambucci pelos comentários e sugestões.

Sobre o Autor

Luciano Condé (https://blogs.msdn.com/conde) trabalha na Microsoft como Arquiteto de Soluções, com foco em atendimento a produtores de software e na comunidade de arquitetos. Tem mais de 13 anos de experiência na área de TI, já atuou em diversos projetos  desde construção, design  e gerenciamento de equipes. É graduado em Tecnologia da Informação, e possui as certificações MCT, MCSD, MCAD, MCPD, MCDBA e MCSE.

arrow_px_up.gif Início da página