UNIVERSIDADE DO SUL DE SANTA CATARINA CARLOS DOS SANTOS CADAVEZ
GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE
FLORIANÓPOLIS 2014
GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE
Trabalho de Conclusão de Curso apresentado ao Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientadora: Prof.ª Maria Inés Castiñeira, Dra.
Florianópolis 2014
GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina.
Aos meus pais, irmãs, minha namorada Carolina que, com muito carinho e incentivo, não mediram esforços para que eu chegasse até esta etapa de minha vida.
Agradeço à minha mãe Raquel, heroína que sempre me apoiou, incentivo em todas as horas.
À minha namorada Carolina, pela paciência, incentivo, pela força e carinho. À minha orientadora Maria Inês, pela paciência na orientação e incentivo que tornaram possível a conclusão deste trabalho.
O processo de desenvolvimento de software é uma atividade bastante complexa e tem aumentado muito com as necessidades cada vez maior por sistemas computacionais. Essa demanda crescente traz consigo a preocupação em maximizar os resultados através de um controle eficaz das aplicações de software, controle que permita a escalabilidade dos sistemas e o acompanhamento de todo o seu ciclo de vida. Para um acompanhamento eficaz processos e metodologias existem como forma de oferecer auxílio, utilizando para isso muitas ferramentas. Com o intuito de oferecer uma solução que possa auxiliar essas necessidades foi desenvolvida esta monografia. Neste trabalho é apresentada uma proposta de solução para o gerenciamento do ciclo de vida das aplicações (Application Lifecycle Management ou ALM), utilizando para isso um conjunto formado por ferramentas de software livre. Esse conjunto oferece suporte a diversas etapas presentes no desenvolvimento de software e pode ser aplicado a diferentes linguagens de desenvolvimento. É apresentado também uma descrição de algumas das ferramentas que compõem o processo, dando uma visão geral de algumas de suas funcionalidades e de como estas podem trabalhar em conjunto, conformando uma solução de ALM. Concluindo percebe-se que a adoção do conjunto de ferramentas proposto serve para solucionar muitos dos problemas encontrados no processo de desenvolvimento de software, observa-se também que essa implementação de ferramentas e práticas pode ser feita de forma gradual. Finalizando são apresentadas algumas sugestões para prosseguimento à partir deste trabalho.
Palavras-chave: Gerenciamento do ciclo de vida das aplicações. ALM. Ferramentas open-source.
Figura 1 – Fases da engenharia de software ... 19
Figura 2 – Classificação funcional das ferramentas CASE. ... 26
Figura 3 – Classificação de ferramentas CASE com base em atividades. ... 27
Figura 4 – Os cinco estágios do processo de testes. ... 31
Figura 5 – Etapas metodológicas. ... 44
Figura 6 – Interface novo usuário. ... 50
Figura 7 – Interface de usuários. ... 51
Figura 8 – Interface de criação de novo papel. ... 51
Figura 9 – Interface de projetos. ... 52
Figura 10 – Interface para criação de projeto. ... 52
Figura 11 – Interface para criação de tarefa. ... 53
Figura 12 – Interface de tarefas do projeto. ... 53
Figura 13 – Gráfico de Gantt. ... 54
Figura 14 – Interface de relatório de tempo gasto. ... 54
Figura 15 – Pastas criadas nos diretórios. ... 56
Figura 16 – Tela projeto Subversion. ... 56
Figura 17 – Tela Subversion, arquivo criado. ... 57
Figura 18 – Tela Subversion novo arquivo. ... 57
Figura 19 – Interface Eclipse, integrando com Subversion. ... 58
Figura 20 – Interface Eclipse com projeto Subversio ... 59
Figura 21 – Integração Redmine com Subversion. ... 59
Figura 22 – Arquivos integrados. ... 60
Figura 23 – Arquivo pom. ... 60
Figura 24 – Arquétipos disponíveis. ... 61
Figura 25 – Configuração projeto Maven. ... 62
Figura 26 – Arquivos pom gerado. ... 63
Figura 27 – Fases do ciclo de vida Maven. ... 64
Figura 28 – Eclipse, arquétipos disponíveis. ... 65
Figura 29 – Estrutura do projeto Maven gerado. ... 66
Figura 32 – Tela inicial Jenkins. ... 69
Figura 33 – Tela de configuração Jenkins. ... 70
Figura 34 – Tela new job. ... 71
Figura 35 – Tela configuração do repositório. ... 71
Figura 36 – Tela de projeto, build bem sucedido. ... 72
Figura 37 – Interface build periódico. ... 72
Figura 38 – Interface build com problemas. ... 73
Figura 39 – Classe de testes JUnit. ... 74
Figura 40 – Codificação da classe de teste. ... 74
Figura 41 – Codificação classe Data. ... 75
Figura 42 – Resultado do teste. ... 76
Figura 43 – Resultado do build no Jenkins. ... 76
1 INTRODUÇÃO ... 12 1.1 PROBLEMÁTICA ... 14 1.2 OBJETIVOS ... 15 1.2.1 Objetivo geral ... 15 1.2.2 Objetivos específicos ... 16 1.3 JUSTIFICATIVA ... 16 1.4 ESTRUTURA DO TRABALHO ... 17 2 REVISÃO BIBLIOGRÁFICA ... 18 2.1 ENGENHARIA DE SOFTWARE ... 18 2.1.1 Processo ... 19 2.1.2 Métodos ... 20 2.1.3 Ferramentas ... 20 2.2 FERRAMENTAS CASE ... 21
2.3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ... 27
2.3.1 Especificação de software ... 28
2.3.2 Projeto e implementação de software ... 29
2.3.3 Validação de software ... 31
2.3.4 Evolução de software ... 32
2.4 GERENCIAMENTO DO CICLO DE VIDA DAS APLICAÇÕES ... 33
2.4.1 Pilares da ALM ... 34
2.4.2 Disciplinas ALM ... 36
2.4.2.1 Gerenciamento de Requisitos (Requeriments Management) ... 36
2.4.2.2 Gerenciamento de configuração de software (Software configuration Management) ... 36
2.4.2.3 Montagem e integração (build and integration) ... 37
2.4.2.4 Gerenciamento de Defeitos (Defect Management) ... 38
2.4.2.5 Teste unitário, Integrado e de Regressão (Unit test, Integrated and Regression) ... 38
2.4.2.6 Análise de Código (code analysis) ... 39
2.4.2.7 Teste de Sistema (System test) ... 39
2.4.2.8 Relatórios de Acompanhamento (Status Report) ... 40
3 MÉTODO DE PESQUISA ... 41
3.1 CARACTERIZAÇÃO DO TIPO DA PESQUISA ... 41
3.2 ETAPAS METODOLÓGICAS ... 43
APLICAÇÕES ... 47
4.1 PESQUISA DAS FERRAMENTAS DE ALM ... 47
4.2 DESCRIÇÃO DAS FERRAMENTAS ... 49
4.2.1 Gerenciamento de requisitos com Redmine ... 49
4.2.2 Controle de versões com Subversion ... 55
4.2.3 Gerenciamento de dependências e builds com Maven ... 60
4.2.4 Integração contínua com Jenkins ... 67
4.2.5 Testes unitários com JUnit ... 73
4.2.6 Considerações sobre o uso das ferramentas no ciclo de vida das aplicações ... 77
4.2.7 Relato de experiências ... 80
5 CONCLUSÕES E TRABALHOS FUTUROS ... 84
5.1 CONCLUSÕES ... 84
1 INTRODUÇÃO
A demanda por soluções computacionais aumentou consideravelmente, devido à competitividade cada vez maior entre as empresas, bem como à sociedade, que exige sistemas a cada dia mais sofisticados. Alguns sistemas assumiram muita importância, como por exemplo os encontrados nos smartphones, que se popularizaram e estão presente nas mãos de muitas pessoas. Segundo pesquisa de eMarketer.com, “Até, 2017, o Brasil terá 70,5 milhões de usuários de smartphones em uso” (de LUCA, 2014). Diante dessa demanda sempre crescente de sistemas informatizados, diversos métodos, ferramentas e todo um corpo de conhecimento têm sido criados ao longo dos anos, visando guiar o processo de desenvolvimento de software. A disciplina mãe dessa área, e de todos os novos conceitos relacionados que vão surgindo, é a “Engenharia de Software”. Ela foi proposta em 1968, em um momento histórico conhecido como ‘crise de software’. Segundo Sommerville (2007, p. 5), “A engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que entrar em operação”.
Esta importante disciplina está delimitada, segundo o guia de engenharia de software (Software Engineering Body of Knowledge - Swebok), em 10 áreas de conhecimento, que são:
• requisitos de software: trata do levantamento, análise, especificação e validação dos requisitos de software, bem como o gerenciamento deles durante todo o ciclo de vida do produto. (SWEBOK, 2014);
• design de software: etapa em que são analisados os requisitos de software, definindo a arquitetura. Nesta fase são descritos os componentes em um nível de detalhe que permita a sua construção. (SWEBOK, 2014);
• teste de software: segundo o (SWEBOK, 2014):
Teste de software é uma atividade executada para avaliar a qualidade do produto, e para melhorá-lo pela identificação de defeitos e problemas. Teste de software consiste da verificação dinâmica do comportamento de um programa em um conjunto finito de casos de teste, adequadamente selecionados de um domínio de execução, usualmente infinito, contra o comportamento esperado;
refere-se a criação detalhada do software, através da combinação da codificação, verificação, testes unitários, testes de integração e depuração;
• manutenção de Software: atividades de suporte custo-efetivo a um sistema de software, que podem ocorrer antes e após a entrega do software. Após a entrega do software são feitas modificações com o objetivo de corrigir falhas, melhorar seu desempenho ou adapta-lo a um ambiente modificado. Antes da entrega do software são feitas atividades de planejamento (SWEBOK, 2014);
• gerência de configuração de software: em concordância com (SWEBOK, 2014) a gerência de configuração de software trata de identificar a configuração do software em pontos distintos do tempo, com o propósito de controlar modificações na configuração e manter a integridade durante o ciclo de vida do sistema;
• gerência de engenharia de software: trata dos aspectos da Engenharia de software, apontando mensuração e gerenciamento (SWEBOK, 2014);
• processo de engenharia de software: Esta etapa trata da implementação, avaliação, mensuração, gerenciamento, alteração e melhora do processo de software. (SWEBOK, 2014);
• ferramentas e métodos de engenharia de software: apresenta as ferramentas e os métodos a serem aplicados na engenharia de software (SWEBOK, 2014); • qualidade de software: De acordo com (SWEBOK, 2014) nessa fase se aborda as considerações relativas à qualidade de software, esta etapa vai além dos processos do ciclo de vida do software.
Mudanças de paradigma e a presença da tecnologia da informação dentro das empresas fizeram surgir a necessidade de maior interação entre a gestão de negócios e a engenharia de software. Surgiu, então, o conceito de gerenciamento do ciclo de vida dos aplicativos, ou do inglês, ALM (Application Lifecycle Management). No entendimento de (CARLOS, 2014 ), “ALM é todo processo que guia a vida útil de uma aplicação desde sua concepção, passando pela construção, operação e evolução”.
Luciano Condé (2009) esclarece que 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”. O autor também afirma que um destaque importante é a diferença entre ALM e o ciclo de vida do desenvolvimento de software ou
Software Development Lifecycle (SDLC). Segundo ele o SDLC pode ser definido como um processo focado no desenho, criação e manutenção de aplicações. Já o ALM é um guia que acompanha toda a vida da aplicação, sendo que o ciclo de vida do desenvolvimento do software (SDLC) é uma das fases do ALM.
Esta prática envolve diferentes papéis, chamados de “Pilares da ALM”. A união destes pilares fornece os recursos necessários para que as empresas possam gerenciar os ciclos de vida de suas aplicações (CONDÉ, 2009).
Ainda, no entendimento de Condé (2009), para identificar as entradas, resultados esperados e os envolvidos em cada etapa, a ALM é dividida em disciplinas. Todo ciclo de vida está compreendido e separado em fases. As fases da ALM são: definição, construção e operação, sendo que cada fase possui ainda subdivisões ou subfases.
A implantação de ALM é realizada através da utilização de ferramentas. Essas ferramentas atuam de forma integrada e auxiliam nas seguintes etapas: gerenciamento de requisitos, arquitetura, codificação, testes, controle e gerenciamento de versões. Empresas como: Microsoft, HP, Borland, IBM, Xerox possuem ferramentas para implantação de ALM. (GARTNER, 2012).
1.1 PROBLEMÁTICA
Um dos grandes desafios das empresas de software é como modernizar o processo de desenvolvimento. A estratégia considerada para isso deve estar presente durante todo o ciclo de desenvolvimento. As aplicações modernas estão focadas em um novo perfil de usuário. Esse novo consumidor está conectado diariamente, conhece aplicativos, utiliza serviços on-line, busca mudanças muito mais rapidamente, faz com que os sistemas atuem como serviços, desta forma a qualidade precisa estar presente durante todo o ciclo de vida. Assim, as respostas devem ser geradas mais rapidamente, e isto obriga as empresas a repensarem o modelo de construção de aplicações.
Novos modelos devem permitir a entrega de atualizações constantes e a integração da equipe, seja ela grande ou pequena.
Hoje em dia, muitas organizações têm grandes equipes de desenvolvimento, trabalhando em software para suportar o negócio. Muitas vezes, as equipes estão espalhadas
no mundo. Isto coloca muitos problemas potenciais, tais como as questões de colaboração, manutenção do código fonte, gerenciamento de requisitos e, assim, por diante. Sem processos para suportar o desenvolvimento de software moderno, o negócio provavelmente vai sofrer. (ROSSBERG e OLAUSSON, 2012).
A ALM surge como alternativa para esse novo modelo de desenvolvimento. Diversas ferramentas auxiliam nesse processo, algumas proprietárias e outras de software livre ou código aberto, do inglês (open source). Nesse sentido, software livre consiste em um programa que pode ter seu código fonte alterado por qualquer usuário e não exige licença para distribuição. (ASSOCIAÇÃO DE SOFTWARE LIVRE.ORG, 2014).
Entre as diversas dificuldades das organizações para adotar essas estratégias de ALM, podem ser mencionadas a falta de conhecimento sobre esse modelo e sobre as ferramentas que facilitam a sua aplicação.
Dessa forma, as perguntas de pesquisa deste trabalho se resumem em: como a estratégia de ALM pode auxiliar à organização no gerenciamento do processo de software? Quais ferramentas de software livre/código aberto suportam essa alternativa? Quais as diferenças entre essas diversas ferramentas e quais os objetivos de cada uma delas?
1.2 OBJETIVOS
A seguir, são apresentados os objetivos deste trabalho.
1.2.1 Objetivo geral
• Definir um conjunto (ou pilha) de ferramentas open source, que oferecem auxilio no gerenciamento das diversas etapas do ciclo de vida das aplicações.
1.2.2 Objetivos específicos
Os objetivos específicos são:
• apresentar o conceito de ALM explicitando suas características principais;
• apresentar a importância de ALM no cenário de desenvolvimento de software atual;
• pesquisar e selecionar ferramentas de código aberto usadas no processo de ALM;
• descrever a utilização de ferramentas de código aberto utilizadas no processo de ALM, demonstrando algumas de suas funcionalidades.
1.3 JUSTIFICATIVA
A adoção de ALM é importante para toda a empresa que deseja automatizar seus processos de desenvolvimento e acompanhar sua aplicação durante todo o ciclo de vida. Este conceito permite uma série de possibilidades de integração entre os setores de desenvolvimento, além de se adaptar à empresa de acordo com seu nível de maturidade. ALM deve ser implantada após uma análise de nível de maturidade da organização.
Neste trabalho, serão apresentados os passos de implantação utilizando ferramentas open source, abordagem que é muito apropriada para times pequenos e médios (SOUZA, 2013), assim como pequenas e médias empresas. Além disso, a opção pelo uso de ferramentas de código aberto permite uma independência maior de fornecimento do software, o cliente não fica preso a nenhum fornecedor específico, proporcionando uma maior personalização . Essa prática proporciona maior segurança, visto que o cliente tem acesso ao código e pode saber como é realizado o acesso aos dados. (MENDONÇA, 2012).
A grande quantidade de interessados, em software livre ou de código aberto, compõem a chamada comunidade de usuários e desenvolvedores de software livre. Quando há algum problema, seja invasão por vírus ou qualquer outro bug, esta comunidade se une em busca da solução. Muitas vezes, a solução é encontrada antes mesmo de a maioria dos usuários terem tido o problema. (BERNARDO, 2012). Outro diferencial, no uso de software livre ou de código aberto, é o fato de suas ferramentas estarem sempre sendo melhoradas, tornando muito baixa a probabilidade de erros desconhecidos, o que aumenta a longevidade. Os usuários de software livre/código aberto, esta comunidade é, neste caso, produtora e consumidora do sistema e ela mesma busca assegurar a sua longevidade. (FERREIRA, 2005).
1.4 ESTRUTURA DO TRABALHO
Esta monografia está estruturada da seguinte forma:
• o capítulo 1 apresenta uma introdução a ALM, procurando demonstrar sua aplicação e ideia geral do modelo, assim como os objetivos e justificativa deste trabalho;
• o capítulo 2 evidencia os aspectos da ALM descrevendo cada passo e subdivisões de cada etapa, e, sua relação com a engenharia de software;
• o capítulo 3 apresenta o método;
• no capítulo 4, são descritos os passos para implantação de ALM utilizando pilha de ferramentas open source. Também há um detalhamento das ferramentas;
• O capítulo 5 apresenta as conclusões indicando a motivação para implantação de ALM nas empresas.
2 REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta a revisão bibliográfica. Para Silva e Menezes (2005 p.37), a revisão bibliográfica refere-se a fundamentação teórica adotada para tratar o tema e o problema de pesquisa por meio da literatura publicada, criando assim a estrutura conceitual que dará sustentação ao desenvolvimento da pesquisa. Desta forma será descrito neste capítulo a teoria que fundamenta alguns dos aspectos da Engenharia de Software e suas ferramentas. Em seguida é apresentada a fundamentação teórica relativa ao gerenciamento do ciclo de vida das aplicações.
2.1 ENGENHARIA DE SOFTWARE
A engenharia de software é um ramo da engenharia focada no desenvolvimento dentro de custos adequados, de sistemas de software. Esta é a disciplina que esta associada a todos os aspectos envolvidos na produção de software, desde a etapa de especificação do sistema até a sua fase de manutenção. O conceito de engenharia de software surgiu em 1968 em uma conferência para discutir a então chamada ‘crise de software’. Esta crise era resultado direto da introdução de um novo hardware baseado em circuitos integrados. As aplicações de computador, até então consideradas não realizáveis, passaram a ser vistas como propostas viáveis. (SOMMERVILLE, 2007).
Na visão de (BAUER, 1969 apud KECHI, 2012, p. 7) “A engenharia de software é o estabelecimento e uso de sólidos princípios de engenharia a fim de obter um software que seja confiável e que funcione de forma econômica e eficiente em maquinas reais”. O autor ainda afirma que os sistemas deveriam ser construídos em módulos, e em níveis.
Para Pressman (2011, p. 39), a engenharia de software é uma tecnologia em camadas, como pode ser visto na figura 1. O autor afirma que: qualquer abordagem de engenharia deve estar fundamentada em um comprometimento organizacional com a qualidade.
Figura 1 – Fases da engenharia de software
Fonte: Pressman (2011, p. 39)
A camada “foco na qualidade” está presente em qualquer engenharia e, dá ênfase a preocupação com a qualidade. Qualidade em engenharia de software está baseada nos conceitos de gerenciamento da qualidade total para melhoria dos processos. Esta é uma abordagem de gerenciamento organizacional para obter sucesso em longo prazo através da satisfação dos clientes (BAUER, 1969 apud KECHI, 2012, p. 8).
2.1.1 Processo
Para a engenharia de software a camada de processos é a base. Nas palavras de Pressman (2011, p. 39), o processo de engenharia de software é a liga que mantém as camadas de tecnologia coesas e possibilita o desenvolvimento de software de forma racional e dentro do prazo. Nesta camada se define a metodologia que deve ser estabelecida para a entrega efetiva de tecnologia de engenharia de software. Sob o ponto de vista de Kechi (2012, p. 8): “A camada de processos permite integrar as camadas de métodos e de ferramentas para que se possa desenvolver um software nos prazos acordados e de maneira adequada. Um processo permite que se planeje e se controle projetos de software”.
No entender de Pressman (2011, p. 40), uma metodologia de processo para a engenharia de software compreende cinco atividades:
• comunicação: antes de qualquer trabalho é de vital importância a comunicação entre o cliente e todos os interessados, visando compreender a intenção e levantar as necessidades que ajudarão a definir as funções e características do software;
• planejamento: esta atividade cria um mapa, que guiará a jornada da equipe. O mapa é chamado de ‘plano de projeto de software’ e define o trabalho descrevendo as tarefas técnicas a serem conduzidas, os riscos, recursos necessários, produtos resultantes e um cronograma de trabalho;
• modelagem: criação de modelos para melhor entender as necessidades do software e o projeto que irá atender essas necessidades;
• construção: combinação de geração de código (manual ou automatizada) e testes necessários para revelar erros na codificação;
• emprego: software como unidade completa ou como um incremento parcialmente efetivado entregue ao cliente, que avalia o produto e fornece feedback baseado na avaliação.
Essas cinco atividades podem ser utilizadas para desenvolvimento de programas simples, bem como para grandes e complexos projetos. Os detalhes serão diferentes para cada um dos casos, mas as atividades metodológicas serão as mesmas (PRESSMAN, 2011, p. 40).
2.1.2 Métodos
Esta camada, no entender de Pressman (2011, p. 40): fornece as informações técnicas para o desenvolvimento de software, envolve ampla gama de tarefas, que incluem: comunicação, análise de requisitos, modelagem de projeto, construção de programa, testes e suporte. Para Kechi (2012, p. 12), métodos são importantes pois definem, por meio de suas notações, um canal de comunicação uniforme entre os membros da equipe.
2.1.3 Ferramentas
As ferramentas de engenharia de software fornecem o suporte automatizado ou semi-automatizado para o processo e para os métodos. Quando uma ferramenta usa as informações geradas por outra, é estabelecido um sistema de suporte ao desenvolvimento de
software, denominado: engenharia de software com o auxilio de computador ou, do inglês, Computer Aided Software Engineering, abreviado como CASE (PRESSMAN, 2011, p. 40).
2.2 FERRAMENTAS CASE
Como visto no fim da seção anterior, as ferramentas CASE, ou engenharia de software com o auxilio de computador, é o nome que se dá ao sistema utilizado para apoiar atividades de processo de software, entre as quais ferramentas para: engenharia de requisitos, projeto, dicionário de dados, compiladores, depuradores, ferramentas de construção de sistemas entre outros (SOMMERVILLE, 2004 p. 33).
Ainda no entendimento de Sommerville (2004, p. 53), o auxilio de computador na engenharia de software apoia o processo, automatizando algumas atividades e fornecendo informações sobre o software que está sendo desenvolvido.
A seguir algumas atividades que podem ser automatizadas utilizando CASE (SOMMERVILLE, 2004, P.56):
• desenvolvimento de modelos gráficos de sistemas, como parte das especificações de requisitos ou de projeto de software;
• dicionário de dados contendo informações sobre suas entidades e sua relação em um projeto;
• geração de interface de usuário a partir de descrição gráfica da interface, que é criada interativamente junto com o usuário;
• depuração de programas, pelo fornecimento de informações sobre um programa em execução;
• tradução automatizada de programas a partir de uma antiga linguagem de programação, como cobol, para uma versão mais recente.
No guia de engenharia de software (Software Engineering Body of Knowledge - Swebok), as ferramentas são definidas de acordo com cada área de conhecimento:
a) ferramentas de requisitos de software são as ferramentas para lidar com os requisitos de software e podem dividir-se em duas categorias: ferramentas para modelagem e ferramentas para gerenciamento de requisitos. Ferramentas para gerenciamento de requisitos suportam normalmente atividades como: documentação, rastreamento e gerenciamento de mudanças (SWEBOK, 2014); b) ferramentas de design de software de acordo com o Swebok (2014), são criadas para apoiar a criação dos artefatos de projetos de software durante o processo de desenvolvimento. Podem suportar as seguintes atividades: tradução do modelo de requisitos em uma representação de design, fornecer apoio para a representação de componentes funcionais e sua interface, fornecer diretrizes para avaliação de qualidade;
c) ferramentas de teste de software apoiam o projeto de testes gerando casos de testes e os tornando mais eficazes. São categorizadas de acordo com a suas funcionalidades (SWEBOK, 2004);
d) ferramentas de construção de software são as que oferecem auxilio no processo de construção de software. Como os exemplos a seguir, de acordo com o Swebok (2004):
• ambiente de desenvolvimento, do inglês, Integrated Development Environment (IDE), oferece auxilio na construção de software integrando um conjunto de ferramentas de desenvolvimento. A escolha destes ambientes pode afetar a eficiência na qualidade da construção do software. As IDEs modernas apresentam recursos para: compilação, detecção de erros, controle de código fonte, teste, depuração e suporte para refatoração;1
• construtor de Interface gráfica: essa ferramenta fornece auxilio na criação de interfaces de usuário, chamada em inglês de Graphical User Interface (GUI). Ela inclui normalmente um editor visual com o qual é possível criar formulários, janelas e gerenciadores de layout, clicando e arrastando (drag and drop). Alguns destes construtores geram automaticamente o
1 De acordo com Fowler (1999), por refatoração entende-se o processo de mudança do código sem alteração do comportamento do sistema, melhorando seu comportamento para minimizar a ocorrência de erros.
código fonte correspondente ao projeto GUI visual. Estas ferramentas podem ser integradas a IDEs através de plug-ins.2
e) ferramentas de manutenção de software são as importantes para a manutenção de software, como por exemplo, analisadores estáticos, que apresentam resumos de conteúdo do programa, analisadores dinâmicos, permitem traçar o caminho de execução de um programa, analisadores de dependência, permitem analisar e compreender as inter-relações entre os componentes de um programa, ferramentas de engenharia reversa, gerando artefatos como descrições e especificações de projetos. Fundamenta o Swebok (2004);
f) ferramentas de gerenciamento de configuração de software. Contempla o Swebok (2004) a este respeito que, essas ferramentas podem ser divididas em três classes de acordo com seu escopo, sendo que podem oferecer, suporte individual, de apoio relacionado com o projeto, e de apoio ao processo. As ferramentas de apoio individual são suficientes para pequenas organizações ou grupos de desenvolvimento, oferecem o suporte ao controle de versão, manipulação e controle de mudanças. As de apoio relacionado com o projeto auxiliam na gestão do espaço de trabalho para as equipes de desenvolvimento, são adequadas para pequenas e médias organizações. As que fornecem o apoio ao processo podem automatizar partes de um processo da empresa, criando suporte para o fluxo de trabalho e gerenciando papeis e responsabilidades;
g) ferramentas de gerenciamento de engenharia de software: conforme o Swebok (2004), essas ferramentas são muitas vezes utilizadas para dar visibilidade e controle aos processos de gestão de engenharia de software. Podem ser automatizadas ou manualmente implementadas. Ainda segundo o guia elas podem ser divididas em categorias:
• ferramentas de planejamento e acompanhamento de projetos: podem ser usadas para estimar esforço e custo do projeto, bem como preparar
2 Segundo Prada (2008), plug-in é todo o programa, ferramenta ou extensão que se encaixa a outro programa principal para adicionar mais recursos ou funções a ele. Normalmente são leves, de fácil instalação e não comprometem o funcionamento do programa principal.
cronogramas de projetos. Podem ser automatizadas, recebendo o tamanho estimado e outras características de um produto de software, produzindo uma estimativa de esforço, cronograma e custo. Ferramentas de planejamento incluem também ferramentas automatizadas de agendamento que verificam as tarefas, durações estimadas, relação de precedência gerando gráfico de Gantt, ressalta o Swebok (2004);
• ferramentas de controle: utilizadas para rastrear os marcos do projeto, reuniões de status do projeto, ciclos de iteração, demonstração de produtos e itens de ação (SWEBOK, 2004);
• ferramentas de gestão de risco: Segundo o Swebok (2004), são as ferramentas de controle e identificação de riscos, estimativa e monitoramento. Incluem abordagens como árvores de decisão ou simulação, para analisar o custo de acordo com os riscos;
• ferramentas de comunicação: podem incluir notificação de e-mail, reuniões diárias de stand-up, gráficos mostrando progresso, entre outros (SWEBOK, 2004);
• ferramentas de medição: citando o Swebok (2004): são as ferramentas relacionadas com a medição do software, podendo ser automatizadas, usadas para coletar, analisar e relatar os dados de medição do projeto. Pode ser baseado em planilhas desenvolvidas por membros da equipe do projeto ou empregados da organização.
h) ferramentas de processo de engenharia de software: segundo o guia Swebok (2004), as ferramentas de processo são as que apoiam muitas das notações usadas para: definir, implementar e gerenciar processos de software individuais, e modelos de ciclo de vida do software. Incluem editores para anotações como: diagrama de fluxo de dados, gráfico de estado, notação de modelagem de processo de negócio, ou do inglês Business Process Modeling Notation (BPMN), redes de Petri, e diagramas de atividades UML. As ferramentas de processo podem apoiar projetos com equipes distribuídas geograficamente;
i) ferramentas de qualidade de software: essas ferramentas incluem ferramentas de análise estática e dinâmica. Na estática é realizada uma análise sintática e
semântica sem executar o código fonte. As ferramentas de análise dinâmica são as descritas nas outras áreas (SWEBOK, 2014).
As ferramentas CASE estão disponíveis para grande parte das atividades de rotina no processo de software, o que melhora a qualidade e produtividade de software. Estas ferramentas podem ser classificadas de acordo com o papel de apoio a cada atividade do processo de software, mas existem diversas formas de classificar as ferramentas CASE. Cada modo de categorização oferece uma perspectiva diferente.
Abaixo três perspectivas, segundo Sommerville, (2004, p. 54.):
• perspectiva funcional: as ferramentas são classificadas de acordo com sua função especifica;
• perspectiva de processo: as ferramentas são classificadas de acordo com a atividade de processo que elas apoiam;
• perspectiva de integração: as ferramentas CASE são classificadas de acordo com a maneira como são organizadas em unidades integradas que fornecem apoio a uma ou mais atividades de processo.
A figura 2 apresenta a classificação das ferramentas de acordo com sua função. Nessa categorização não foram incluídas ferramentas especializadas, como as ferramentas de apoio ao reuso.
Figura 2 – Classificação funcional das ferramentas CASE.
Fonte: SOMMERVILLE (2004, p. 55).
O apoio ao processo de software, proporcionado pela tecnologia CASE é outra possível dimensão de classificação. Para Fuggetta (1993, apud SOMMERVILLE, 2004 p. 54) os sistemas CASE devem ser classificados em três categorias:
1. ferramentas oferecem apoio as tarefas de processo individuais, verificação da consistência de um projeto, a compilação de um programa, comparação de resultados de testes entre outras. Ferramentas podem ser de uso geral, uso restrito (processador de texto) ou agrupadas em workbenches;
2. workbenches apoiam fases ou atividades de processo, como a especificação e o projeto, consiste em conjunto de ferramentas com menor ou maior grau de integração;
3. ambientes oferecem apoio à todo, ou parte substancial do processo de software. Incluem normalmente vários workbenches diferentes.
A seguir é apresentado, na figura 3, uma classificação das ferramentas de acordo com as fases de processo. Por exemplo as ferramentas para planejamento e estimativa, edição de textos, preparação de documentos e gerenciamento de configuração podem ser utilizadas ao longo do processo de software, enquanto que ferramentas de reengenharia são usadas somente na fase de implementação.
Figura 3 – Classificação de ferramentas CASE com base em atividades.
Fonte: SOMMERVILLE (2004, p. 55).
2.3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
As etapas envolvidas no desenvolvimento de software são muitas e envolvem uma série de atividades. Não existe um método de desenvolvimento qualificado como ideal para qualquer projeto. As organizações utilizam abordagens diferentes umas das outras, as vezes dentro de uma mesma organização é adotado diferentes procedimentos para cada projeto (SOMMERVILLE, 2004).
Na visão de Pressman (2010, p. 14), um processo de desenvolvimento software é uma abordagem adaptável que tem como premissa a entrega de software em tempo e com qualidade que satisfaça a necessidade. A estrutura de um processo identifica um grupo de atividades fundamentais, presentes em todo o projeto de desenvolvimento de software. Esse grupo de atividades é descrito a seguir.
2.3.1 Especificação de software
Aqui são estabelecidas quais funções são requeridas pelo sistema, bem como as restrições desse sistema. Esta etapa é de grande importância pois os erros ocorridos aqui podem ocasionar problemas nas fases seguintes. Esta atividade tem sido comumente chamada de engenharia de requisitos (SOMMERVILLE, 2004, p. 46). Em concordância com Pressman (2010 p. 120), a engenharia de requisitos é uma importante atividade da engenharia de software, que começa durante a atividade de comunicação e se estende até a atividade de modelagem.
O processo de engenharia de requisitos resulta em um documento de requisitos, que é a documentação do sistema. Este documento possui dois níveis de detalhamento, um para os clientes e usuários finais, com um detalhamento de mais alto nível, e outro com uma especificação mais detalhada do sistema, para os desenvolvedores. Explica Sommerville (2004, p. 46) .
Ainda de acordo com Sommerville (2004, p. 46) esta etapa de especificação de software possui quatro fases principais, que são:
a) estudo de viabilidade: é verificado se as necessidades dos usuários podem ser satisfeitas com a tecnologia atual. Bem como se é viável comercialmente e se é possível ser desenvolvido com o orçamento disponível. Este estudo deve ser rápido, barato e informar se a decisão é prosseguir com uma análise mais detalhada;
b) levantamento e análise de requisitos: consiste na obtenção dos requisitos de acordo com os sistemas existentes, conversa com usuários e possíveis compradores (SOMMERVILLE, 2004, p. 46). Os interessados trabalham em conjunto para identificar o problema, propor elementos para solução, negociar abordagens diferentes e especificar o conjunto de requisitos da solução (PRESSMAN, 2010, p. 128);
c) especificação de requisitos: é a formalização das informações coletadas durante a fase de análise em um documento definindo um conjunto de requisitos. Aqui
podem ser gerados os dois tipos de documentos, um para o usuário final e outro com as informações do sistema detalhadas (SOMMERVILLE, 2004, p. 46); d) validação de requisitos: de acordo com Sommerville (2004, p. 46) esta atividade verifica a pertinência, consistência e integridade dos requisitos. Nesta etapa são encontrados erros na documentação, que devem ser corrigidos. Na visão de Pressman (2010, p. 144) esta fase deve abordar questões como:
• O requisito é realmente necessário? • Cada requisito está bem limitado?
• Não há ambiguidade? o requisito pode ser testado se implementado?
Essas e outras perguntas devem ser respondidas para garantir que o modelo de requisitos é um reflexo preciso das necessidades das partes interessadas e que fornece uma base sólida para o projeto.
Conforme Sommerville (2004, p. 47) essa atividade continua durante a definição e especificação, novos requisitos vão surgindo ao longo do processo.
2.3.2 Projeto e implementação de software
Esse estágio consiste na conversão de uma especificação de sistema em um sistema executável. Essa etapa envolve processos de projeto e programação de software (SOMMERVILLE, 2004, p. 46). O processo pode envolver o desenvolvimento de vários modelos do sistema em diferentes níveis de abstração.
Muitos projetos de software são desenvolvidos informalmente, e vão sendo modificados a medida que a implementação ocorre, quando este estágio se completa o projeto foi tão modificado que o documento original do projeto é uma descrição incoerente e incompleta do sistema (SOMMERVILLE, 2004, p. 46). Uma abordagem mais metódica é proposta por métodos estruturados, esses métodos envolvem a produção de modelos gráficos resultando em grande quantidade de documentação de projeto, a criação de modelos deste tipo
recebem apoio de ferramentas CASE. Na compreensão de Sommerville (2004, p. 49) os métodos estruturados podem suportar os seguintes modelos de um sistema:
• Modelo de fluxo de dados, onde o sistema é modelado utilizando transformação de dados a medida que são processados;
• Modelo de relacionamento de entidades descrevendo as entidades básicas do projeto e as relações entre elas. Essa é a técnica normal utilizada para descrever estruturas de base de dados;
• Um modelo estrutural onde são documentados os componentes do sistema e suas interações;
• Métodos orientados a objetos, que incluem um modelo de herança dos sistemas, modelos de relacionamento estáticos e dinâmicos entre objetos e um modelo de como os objetos interagem.
Os métodos são notações padronizadas e incorporações de boas praticas (SOMMERVILLE, 2004, p. 49).
A partir dos métodos é realizado a implementação do sistema. A programação de sistemas é uma atividade pessoal e normalmente os programadores tem liberdade de escolher os componentes que desenvolverão primeiro. Alguns começam desenvolvendo os componentes conhecidos primeiro, e então prosseguem com os componentes menos compreendidos. Alguns programadores realizam testes de seus códigos, esses testes podem revelar defeitos do programa, que devem ser removidos. Esse processo é chamado de depuração, e consiste na identificação e correção de defeitos. Apos a realização do processo de depuração os testes são executados novamente para garantir que as correções foram realizadas corretamente (SOMMERVILLE, 2004, p. 49). A etapa de depuração pode ser realizada com o auxilio de ferramentas, que mostram os valores intermediários das variáveis do programa, ressalta Sommerville (2004, p.49).
2.3.3 Validação de software
De acordo com Sommerville (2004, p. 50), a validação de software destina-se a mostrar que o sistema esta de acordo com as suas especificações e atende as expectativas do cliente. Em cada estágio do processo é realizado inspeções, desde a definição de requisitos até o desenvolvimento do programa. Os testes são realizados incrementalmente, em conjunto com a implementação do sistema.
O processo de testes é composto por cinco estágios, no qual são testados os componentes do sistema, o sistema integrado e o sistema com os dados do cliente.
A figura 4 apresenta esses cinco estágios. Figura 4 – Os cinco estágios do processo de testes.
Fonte: SOMMERVILLE (2004, p. 51).
Os estágios do processo de teste são descritos a seguir, na compreensão de Sommerville (2004, p. 51):
1) teste de unidade: os componentes são testados individualmente, para garantir que eles operam corretamente;
2) teste de módulo: módulo é definido como um conjunto de componentes dependentes, desta forma pode ser testado sem outros módulos do sistema;
3) teste de subsistema: teste de um conjunto de módulos integrados em um subsistema;
4) teste de sistema: aqui é realizada a integração dos subsistemas para verificar a ocorrência de erros ocasionados pela interação desses subsistemas, nesta etapa também é verificado se o sistema cumpre os requisitos do sistema;
5) teste de aceitação: nesta fase é realizado o teste final do sistema, com dados fornecidos pelo cliente. Aqui pode ser revelado erros e omissões na definição dos requisitos do sistema, bem como, recursos que não atendem a necessidade do usuário e desempenho inaceitável do sistema.
Os testes de unidade, também chamados de testes unitários, são realizados normalmente pelo programador responsável pelo componente, já os estágios posteriores, são realizados por um conjunto de programadores, com testes previamente elaborados.
Segundo Sommerville (2004, p. 52), os testes de aceitação podem ser denominados:
• alpha: quando desenvolvido para um cliente, essa fase de teste acaba quando a equipe de desenvolvimento e cliente concordam que o sistema é uma implementação aceitável dos requisitos do sistema;
• beta: quando é desenvolvido para uma série de clientes. Esse tipo de teste envolve a entrega do sistema a uma série de possíveis clientes, que reportam o problema quando encontrado, expondo dessa forma o sistema ao uso real.
2.3.4 Evolução de software
Cada vez mais o software está sendo incorporado a sistema grandes e complexos, e as modificações podem ser onerosas mas, ainda assim menos do que as modificações correspondentes no sistema de hardware. O desenvolvimento de software é a atividade criativa na qual um sistema de software é desenvolvido a partir de um conceito inicial até chegar ao sistema em operação. A manutenção é o processo de modificação desse sistema.
Poucos sistemas atualmente são completamente novos, assim tem muito mais sentido considerar desenvolvimento e manutenção como estágios integrados e contínuos. Por esse motivo é mais realista pensar o processo de software como evolucionário, em que o software é continuamente modificado, em resposta a requisitos em constante modificação (SOMMERVILLE, 2004, p. 52).
2.4 GERENCIAMENTO DO CICLO DE VIDA DAS APLICAÇÕES
Organizações modernas necessitam de sistemas de software de várias formas, até mesmo pequenas empresas dependem de software para auxiliar seus processos. O mundo mudou rapidamente e as empresas agora precisam lidar com um ambiente global, que apresenta oportunidades e desafios, precisam se readaptar constantemente. Para as industrias de desenvolvimento de software não foi diferente. Muitas vezes as equipes de desenvolvimento estão espalhadas pelo mundo, fazendo surgir problemas como: as questões de colaboração, manutenção de código fonte, gerenciamento de requisitos entre outros. Desta forma sem processos que auxiliem, que forneçam apoio ao desenvolvimento de software moderno, as empresas tendem a sofrer.
O gerenciamento do ciclo de vida das aplicações, ou do inglês, ALM (Application Lifecycle Management), é o processo que uma organização usa para cuidar de um aplicativo ou sistema de software desde a sua concepção até a sua aposentadoria. ALM une os processos de desenvolvimento e define os esforços necessários para coordenar o processo (ROSSBERG e OLAUSSON, 2012, p. 3).
Para Carlos (2014) ALM é o processo que guia toda a vida útil de uma aplicação desde a sua concepção, passando pela construção, operação e evolução. Na concepção de Birmelle (2007), o gerenciamento do ciclo de vida acompanha tudo aquilo que faz parte do ciclo de vida dos aplicativos, destacando seu início a partir de uma ideia, uma necessidade, um desafio ou um risco. O fim deste ciclo de vida segundo o autor não se dá ao fim da fase de desenvolvimento, e sim no momento em que a empresa abandona o uso desse aplicativo.
Ainda no entendimento de Birmelle (2007) ALM não deve ser confundido com ciclo de desenvolvimento de software, do inglês, Software Development Lifecycle (SDLC), que abrange aquilo que esta relacionando com o desenvolvimento de um aplicativo de
software, como: requisitos, arquitetura, codificação, testes, gerenciamento de projetos e gerenciamento de configuração. Etapas estas descritas na seção anterior. Após o desenvolvimento de software ser finalizado e de estar em operação, o aplicativo continua sendo monitorado, segundo o processo de ALM.
2.4.1 Pilares da ALM
No entender de Condé (2009) ALM está estruturado em cima de pilares, que se complementam, sendo que um deles são as pessoas. Em um processo de desenvolvimento de software varias etapas são desenvolvidas por pessoas, executando funções especificas (ROSSBERG e OLAUSSON, 2012 p. 21).
De acordo com Rossberg e Olausson (2012 p. 22) as funções da ALM são as seguintes:
• gerente de negócios: faz a análise das necessidades do negócio, decide o inicio de um projeto de desenvolvimento de um aplicativo ou sistema. O gerente de negócios esta diretamente envolvido no processo de aprovação de um novo projeto;
• gerente de projetos: é o responsável pelo produto;
• escritório de projetos: esta é a função ocupada pelos tomadores de decisão, estão envolvidos também no planejamento. De acordo com Condé (2009) é o escritório de projetos que gerencia o portfólio dos projetos da empresa, além de divulgar padrões e guias de suporte;
• analista de negócios: é o responsável por analisar as necessidades e requisitos do negócio. Ajuda a identificar problemas de negócio e propõe solução (ROSSBERG e OLAUSSON, 2012 p. 22);
• arquiteto: para Rossberg e Olausson (2012 p. 22) o arquiteto é quem desenha a imagem inicial da solução, o projeto do sistema. As questões atribuídas a esta função podem ser: escalabilidade, substituição de hardware, novas interfaces de usuário, entre outras;
• experiência do usuário, ou do inglês User eXperience (UX), equipe de projeto: de acordo com Rossberg e Olausson (2012 p. 22) esta função deve ser de colaboração com a equipe de desenvolvimento durante todo o projeto. Pode ser ocupada por apenas uma pessoa. De acordo com Unger e Chandler (2009 p. 3) UX trata da criação e sincronização dos elementos que afetam a experiência dos usuários, com a intenção de influenciar seu comportamento e percepção;
• administradores de banco de dados (DBAs): praticamente todos os sistemas de negócio ou aplicativos utilizam algum tipo de banco de dados. É essencial os conhecimentos de um DBA para um performático e correto funcionamento do banco de dados (ROSSBERG e OLAUSSON, 2012 p. 22). Sob o ponto de vista de Condé (2009) a função do DBA é dar suporte para a equipe na montagem do banco de dados;
• desenvolvedores: citando Rossberg e Olausson (2012 p. 23) são as pessoas que desenvolvem o sistema a partir do modelo e desenho da arquitetura. São eles também que alteram o código quando mudanças são solicitadas;
• testador: na compreensão de Condé (2009) o objetivo do testador é verificar a existência de problemas na aplicação e reporta-los para que seja feita a correção. Este profissional deve realizar testes pré-definidos coletando amostras dos resultados e comparando com a saída esperada. O teste deve ser realizado a partir da codificação dos primeiros requisitos e continuar sendo feito durante todo o processo, argumentam Rossberg e Olausson (2012 p. 23);
• operações e manutenção: quando um sistema ou aplicativo está concluído ele é entregue para a equipe de operação e manutenção. Essa equipe cuida do sistema até que deixe de ser usado. Este papel é um passo importante de ALM (ROSSBERG e OLAUSSON, 2012, p. 23).
Os processos são descritos por Condé (2009) como outro pilar e caracterizam-se pelo conjunto das boas práticas, artefatos, guias e manuais relacionados com a construção e manutenção de uma aplicação. Os processos abrangem todos aspectos desde o levantamento das necessidades, passando pelo desenvolvimento (SDLC), e o monitoramento das aplicações já em ambiente operacional.
O ultimo pilar no entendimento de Condé (2009) são as ferramentas, que automatizam e facilitam a condução dos processos. Para Rossberg e Olausson (2012 p. 28) as ferramentas podem automatizar grande parte do processo de ALM.
2.4.2 Disciplinas ALM
As disciplinas permitem identificar as entradas e os resultados esperados em cada fase da ALM, assim como os envolvidos em cada fase Condé (2009).
2.4.2.1 Gerenciamento de Requisitos (Requeriments Management)
Os requisitos representam as funcionalidades que o sistema deve executar. Dentro dessa etapa existem as seguintes fases (CONDÉ, 2009):
• documentar requisitos funcionais e não funcionais;
• identificar se os requisitos estão de acordo com as necessidades do negócio;
• priorizar os requisitos;
• selecionar os requisitos que serão implementados de acordo com cada fase;
• identificar a dependência entre os requisitos; • verificar se os requisitos foram atendidos.
Esta etapa é crucial para o sucesso do projeto, ressalta Condé (2009).
2.4.2.2 Gerenciamento de configuração de software (Software configuration Management)
Esta etapa, segundo Conde (2009), envolve a geração de diversos artefatos, como: código-fonte, documentos, planilhas e apresentações. A disciplina é responsável por gerenciar, gerar a rastreabilidade e versionamento dos artefatos.
De acordo com Condé (2009), algumas ações dessa disciplina são as seguintes: • controlar acesso aos artefatos;
• armazenar as versões de cada artefato; • rastrear modificações de cada versão; • comparar versões;
• restaurar versões específicas dos artefatos de acordo com uma versão especifica da aplicação.
Esta é, segundo Condé (2009), possivelmente a disciplina mais utilizada nas organizações, pois possui apoio de diversas ferramentas disponíveis no mercado.
2.4.2.3 Montagem e integração (build and integration)
Os projetos atuais são compostos de vários módulos. A disciplina de montagem e integração é a responsável por integrar todos os componentes em um único pacote (CONDÉ, 2009).
A seguir estão relacionadas algumas ações da disciplina de montagem e integração, segundo Condé (2009):
• 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;
• criar pacote de instalação para ser testado;
• organizar código compilado conforme layout definido.
O processo de montagem e integração é a tarefa que integra diversas partes garantindo que todas elas estejam estáveis.
2.4.2.4 Gerenciamento de Defeitos (Defect Management)
Na concepção de Condé (2009), essa disciplina é a responsável por coletar os defeitos e tratar como eles serão corrigidos, bem como, identificar de onde o erro surgiu para tentar evitar uma nova ocorrência.
Algumas ações da disciplina de gerenciamento de defeitos podem ser observadas abaixo, no entender de Condé (2009):
• descrever o comportamento esperado; • descrever o comportamento ocorrido;
• descrever os passos necessário 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.
2.4.2.5 Teste unitário, Integrado e de Regressão (Unit test, Integrated and Regression)
O teste unitário é aquele realizado sobre apenas um componente, pode ser uma classe ou um método. Esse teste é caracterizado por um programa que testa se a saída gerada está de acordo com o esperado a partir de um conjunto de valores de entrada. Os testes integrados são normalmente realizados sobre módulos e essa é uma tarefa realizada normalmente pelos programadores. Nos testes de regressão são verificados se as alterações introduzidas a cada build não geraram novos defeitos, fundamenta Condé (2009). Ainda segundo o autor a vantagem de se aplicar esse teste é a garantia de que o software esta em conformidade com os requisitos definidos.
Sob o ponto de vista de Luciano Condé (2009), são descritos a seguir algumas ações:
• criação de teste unitário para cada componente;
• criação de testes integrados, em nível de módulos lógicos e casos de uso; • armazenagem dos testes em repositório, pois também são considerados
• utilização de ferramentas para automatizar a geração de logs de erros.
Os testes unitários têm sido muito utilizados nos últimos tempos devido a sua eficiência.
2.4.2.6 Análise de Código (code analysis)
Esta disciplina de ALM, é a responsável por analisar se o código esta de acordo com os padrões da empresa (CONDÉ 2009).
Algumas das ações realizadas por essa disciplina, de acordo com Condé (2009): • validar formato e estilo da codificação;
• garantir o uso de padrões de projeto; • detectar problemas de desempenho;
• detectar vulnerabilidades conforme as politicas de segurança;
• identificar a compatibilidade da aplicação em conformidade com normas de mercado.
2.4.2.7 Teste de Sistema (System test)
Essa disciplina envolve o teste da aplicação quando ela estiver pronta. Os testes funcionais “caixa preta”, são executados por essa disciplina. Aqui verifica-se se a aplicação esta de acordo com os requisitos. Esses testes são facilitados quando as etapas anteriores são executadas corretamente, defende Condé (2009).
Para essa disciplina são descritas algumas ações: • detectar problemas de desempenho;
2.4.2.8 Relatórios de Acompanhamento (Status Report)
É nessa disciplina que se gera os diversos relatórios referentes ao ciclo de vida da aplicação. Como exemplo: relatório de bugs, uso de recursos de infra estrutura de TI, retorno sobre investimento, relatórios referentes a qualidade de software entre outros.
3 MÉTODO DE PESQUISA
Neste capítulo será abordado o método de pesquisa utilizado neste trabalho. Para Jung (2011) o método consiste no conjunto de etapas, que quando executadas de forma sistemática, facilitam a obtenção de conhecimentos sobre fenômenos físicos, químicos ou biológicos, ou o desenvolvimento de novos produtos ou processos.
O capítulo destaca aspectos como a caracterização do tipo da pesquisa, etapas metodológicas, e as delimitações. De acordo com Silva e Menezes (2005 p.32) nesta etapa se define onde e como será realizada a pesquisa, definindo: tipo de pesquisa, população (universo da pesquisa), amostragem, instrumentos de coleta de dados e a forma de analisar os dados.
3.1 CARACTERIZAÇÃO DO TIPO DA PESQUISA
Conforme Silva e Menezes (2005 p.20), uma pesquisa consiste no conjunto de ações realizadas para encontrar a solução para um problema, seguindo procedimentos racionais e sistemáticos. Ainda de acordo com os autores uma pesquisa é realizada quando se tem um problema e não se tem informações para solucioná-lo.
As pesquisas podem ser classificadas de diversas formas. Abaixo são apresentadas as formas clássicas de classificação segundo Silva e Menezes (2005 p.20):
Pela natureza a pesquisa pode ser básica, quando tem por objetivo gerar novos conhecimentos sem aplicação prevista, envolve verdades e interesses universais. Ou aplicada, quando o conhecimento gerado dirige-se a solução de problemas específicos, envolvendo verdades e interesses locais.
Da forma de abordagem do problema a pesquisa pode ser classificada como quantitativa quando considera tudo que pode ser quantificável, traduzindo em números opiniões e informações para classifica-las, envolve o uso de técnicas e recursos estatísticos. Ou qualitativa, sem uso de métodos e técnicas estatísticas. Aqui o ambiente natural é a fonte de coleta de dados, e os pesquisadores analisam os dados indutivamente, atribuindo significado.
A classificação do ponto de vista de seus objetivos pode ser classificada de três formas (GIL 1991, apud SILVA e MENEZES 2005 p.21):
• pesquisa exploratória: envolve levantamento bibliográfico, entrevistas com pessoas que tiveram experiências práticas com o problema pesquisado, e análise de exemplos que estimulem a compreensão. Em geral, pesquisas bibliográficas e estudos de caso;
• pesquisa descritiva: descreve as características de determinada população ou fenômeno ou o estabelecimento de relações entre as variáveis. Utiliza técnicas de coletas de dados, como questionário e observação sistemática, assumindo em geral a forma de levantamento;
• pesquisa explicativa: visa identificar os fatores que determinam ou contribuem para a ocorrência dos fenômenos. Utiliza, quando realizada nas ciências naturais, o método experimental e nas ciências sociais o método observacional.
Dos procedimentos técnicos podem ter as seguintes classificações segundo (GIL 1991, apud SILVA e MENEZES 2005 p.21):
• pesquisa bibliográfica: quando sua elaboração é realizada a partir de livros, artigos ou periódicos encontrados na internet;
• pesquisa documental: realizada a partir de materiais que não sofreram tratamento analítico;
• pesquisa experimental: aqui é determinado um objeto de estudo, seleciona-se as variáveis capazes de influencia-lo e define-se a forma de controle e observação dos efeitos que a variável produz no objeto;
• levantamento: quando envolve a interrogação direta das pessoas cujo comportamento deseja-se conhecer;
• estudo de caso: envolve o profundo estudo de um ou mais objetos de modo que se permita o seu amplo conhecimento;
• pesquisa expost-facto: o experimento se realiza depois dos fatos;
• pesquisa-ação: concebida e realizada com uma ação ou com a resolução de um problema coletivo. Os pesquisadores e participantes da situação ou problema estão envolvidos de modo cooperativo ou participativo;
• pesquisa participante: desenvolvida a partir da interação entre pesquisadores e membros das situações investigadas.
No que se refere ao presente trabalho, ele se qualifica como uma pesquisa, pois busca respostas para os problemas existentes no processo e gerenciamento do desenvolvimento de software, bem como todo o ciclo de vida da aplicação.
A pesquisa esta classificada, pela natureza, como uma pesquisa aplicada, pois seu conhecimento pretende solucionar um problema específico. Do ponto de vista da abordagem do problema, ela se classifica como qualitativa, visto que não utiliza métodos estatísticos e seus dados são analisados indutivamente. Na observação dos objetivos ela está classificada como uma pesquisa exploratória, envolvendo levantamento bibliográfico. Quanto aos procedimentos técnicos classifica-se como bibliográfica, já que sua elaboração é realizada a partir de livros, artigos e periódicos encontrados na internet. A classificação da pesquisa realizada neste trabalho é apresentada resumidamente no quadro a seguir.
Quadro 1 – Resumo da classificação da pesquisa.
Classificação da Pesquisa Categoria
Do ponto de vista da natureza Pesquisa aplicada
Da abordagem do problema Qualitativa
Dos objetivos Exploratória
Dos procedimentos técnicos Bibliográfica
Fonte: Elaboração do autor, 2014.
3.2 ETAPAS METODOLÓGICAS
A figura 5 apresenta o fluxograma das etapas metodológicas do presente trabalho, que visam solucionar o problema proposto:
Figura 5 – Etapas metodológicas.
Fonte: Elaboração do autor, 2014.
A seguir são descritas cada uma das etapas:
a) revisão bibliográfica: é apresentado inicialmente o conceito de engenharia de software, sua definição, e fases que a compõem. Após é realizado
através da literatura existente, a fundamentação teórica relativa às ferramentas de apoio à engenharia de software, bem como a descrição das etapas do processo de desenvolvimento de software. Por fim é apresentado o conceito de gerenciamento do ciclo de vida de aplicações, os papéis e as disciplinas envolvidas;
b) pesquisa das ferramentas que auxiliam as diferentes etapas do gerenciamento do ciclo de vida;
c) selecionar, a partir da experiência e revisão bibliográfica, as atividades do ciclo de desenvolvimento das aplicações que possuem ferramentas para auxiliar o processo de ALM;
d) no “desenvolvimento da solução” é selecionado uma série de ferramentas open source que auxiliam o processo de gerenciamento do ciclo de vida do desenvolvimento de sistemas, realizando o detalhamento de cada ferramenta, apontando os benefícios do seu uso e descrevendo a possível integração dessas ferramentas conformando uma plataforma tecnológica; e) validação: nesta etapa será pesquisada a possível eficácia da plataforma
proposta, através de entrevista com profissional da área. Caso seja necessário se voltará a algumas das etapas anteriores;
f) nas conclusões é explicitado os resultados alcançados com a adoção do gerenciamento de ciclo de vida das aplicações, demonstrando as vantagens obtidas, bem como a motivação para utilização.
3.3 DELIMITAÇÕES
Nesta seção são definidas as delimitações do trabalho:
a) não será incluído no trabalho a análise, nem especificação, de ferramentas de auxilio ao gerenciamento do ciclo de vida das aplicações de uso proprietário. Somente serão consideradas ferramentas open source;
b) modelos de desenvolvimento ágil, por vezes presentes no gerenciamento do ciclo de vida das aplicações, não serão descritos;
c) não será realizado o desenvolvimento de nenhum sistema, somente a descrição das ferramentas, com imagem das interfaces da ferramenta.
4 FERRAMENTAS PARA O GERENCIAMENTO DO CICLO DE VIDA DAS APLICAÇÕES
Este capítulo apresenta as atividades presentes no processo de ALM, bem como os passos e ferramentas para sua utilização.
O gerenciamento do ciclo de vida das aplicações é realizado com o auxilio de ferramentas sendo que cada ferramenta atua em uma ou mais áreas de ALM.
4.1 PESQUISA DAS FERRAMENTAS DE ALM
O processo de desenvolvimento de sistemas é uma atividade bastante complexa. Grande parte dos projetos conta com uma equipe grande e diversificada de pessoas, que pode incluir: desenvolvedores, designers gráficos, analistas de negócios, especialistas em qualidade, entre outros. Estes profissionais devem trabalhar de forma harmoniosa em conjunto. A utilização de diferentes ferramentas pode aumentar a complexidade, embora elas sejam geralmente idealizadas para apoiar o processo e aumentar a qualidade e produtividade. Desenvolvedores usam vários ambientes de desenvolvimento integrado (IDEs), os designers escolhem suas ferramentas gráficas favoritas, e os analistas de negócios geralmente sentem-se mais a vontade com planilhas. Projetos diferentes adotam comumente soluções diferentes para controle de versão, gerenciamento de testes, entre outros. A diversidade nas ferramentas é inevitável na maioria das organizações. Esta diversidade faz sentido. Pessoas em diferentes papéis certamente precisam de diferentes ferramentas, não faria sentido um analista de negócios utilizar uma IDE para realizar sua tarefa. Mesmo pessoas na mesma função podem fazer escolhas diferentes. Para um desenvolvedor construindo um aplicativo Java provavelmente não seria interessante utilizar o Visual Studio IDE (plataforma da Microsoft para .Net), bem como, a escolha de uma IDE como Eclipse não seria apropriada para um aplicativo .NET (CHAPPELL, 2011). As soluções open source em ALM são constituídas de uma série de produtos de diversas comunidades ou empresas, sendo que, cada uma das ferramentas atende uma necessidade específica no processo de ALM. (GILBERTO JUNIOR, 2012).
