DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI - PDF
DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI
Download "DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI"
Gilberto Regueira Mangueira
1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS LINS/SP 2º SEMESTRE/2013
2 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados. Orientador: Prof. Me. Fábio Lúcio Meira LINS/SP 2º SEMESTRE/2013
3 ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados sob a orientação do Prof. Me.Fábio Lúcio Meira. Data de aprovação / / Orientador Fábio Lúcio Meira Examinador Examinador
4 Dedico à toda a minha família, principalmente à minha esposa e meu filho que está à caminho. Agradeço à Deus pela oportunidade de realizar este trabalho. Adriano Henrique de Souza da Silva
5 Dedico este trabalho à Deus e à minha mãe Neusa, que sempre me apoiou em todas as etapas de minha vida e à quem eu devo tudo que tenho. Danilo Françoso Tedeschi
6 AGRADECIMENTOS Com a finalização desta fase, que dá início em nossas carreiras profissionais, sentimos que estamos mais preparados para enfrentar os desafios que virão. Reconhecemos o apoio que nos fora dado durante todo o curso, especialmente na fase final. Todos os professores que dividiram seus conhecimentos durante essa jornada foram importantíssimos, porém alguns deles assumiram um papel fundamental e gostaríamos, de aqui, destacá-los. Nosso orientador Fábio Lúcio Meira. O professor Mario Henrique de Souza Pardo, que nos ajudou aprimorar nossos conhecimentos, além do que a grade curricular exigia. Professora Adriana de Bortoli, especialmente pela ajuda no desenvolvimento deste trabalho. Professor Júlio Lieira, que sempre nos motivou para participação de projetos extracurriculares.
7 RESUMO Gerenciar um projeto durante sua execução não é uma tarefa fácil. O número de envolvidos, bem como o seu grau de complexidade podem fazer com que esta atividade se torne um obstáculo para o sucesso final de um produto. Com uma equipe muito grande, o gerente de software encontra dificuldades em estar ciente de tudo o que está acontecendo. Quando o tamanho do projeto é o que preocupa, fazer com que todos seus subordinados entendam suas responsabilidades é a maior dificuldade. Portanto, o propósito desse trabalho é criar uma ferramenta para ajudar a controlar a execução de projetos de desenvolvimento de software em equipe, focando em projetos que utilizem metodologias de desenvolvimento ágil. A meta é auxiliar tanto a visão do gerente, quanto a dos desenvolvedores, mantendo informações detalhadas de cada etapa do projeto. Ele será desenvolvido para a plataforma de internet para que seja facilitada a sua implantação. Java será a linguagem de programação utilizada e o sistema gerenciador de banco de dados o PostgreSql. Palavras-chave: desenvolvimento de software, gerenciamento de projeto, Java, PostgreSql.
8 ABSTRACT Controling a project during its execution is not an easy task. The number of people involved, as well as its compleity can make this mission become the issue that will push the product success down the hill. A large development team makes software mangers find themselves tangled not being able to retrieve all the information they need from their team. When the project's size is the one which is concerning, making every professional involved understand their roles is the burdensome task. Having that in mind, this final project will deliver an application that helps team software development management, focusing projects that use agile development methods. The target is to help both the manager's and the developers' work, keeping track of detailed information on each stage of the project. It will be developed for the Internet plataform, so the implanting can be easier not depending on the local facilities. Java will be used as the programming language and PostGreSql as the DBMS. Keywords: software development, progrect management, Java, PostgreSql
9 LISTA DE ILUSTRAÇÕES Figura 1.1: Exemplo diagrama de classe...22 Figura Exemplo relacionamentos...24 Figura Exemplo generalização...24 Figura Exemplo diagrama de casos de uso...26 Figura Exemplo diagrama de atividade...26 Figura Exemplo diagrama de sequência...27 Figura 3.1: Design da ferramenta...39 Figura Diagrama de Classe...40 Figura Diagrama de casos de uso...41 Figura Diagrama de atividades. Efetuar login...42 Figura MVC. Efetuar Login...43 Figura Diagrama de sequência. Efetuar login...43 Figura Diagrama de Atividade. Manter projetos...44 Figura MVC. Manter projetos...44 Figura Diagrama de sequência. Manter projetos...45 Figura MVC. Manter processos de desenvolvimento...45 Figura 3.11: Diagrama de atividades. Manter processos de desenvolvimento...46 Figura 3.12: Diagrama de sequência. Manter processos de desenvolvimento...46 Figura Diagrama de atividade. Manter fases...47 Figura MVC. Manter fases...48 Figura Diagrama de sequência. Manter fases...48 Figura Diagrama de atividade. Manter atividades...49 Figura MVC. Manter atividades...49 Figura Diagrama de sequência. Manter atividades...50 Figura 3.19: MVC. Manter tarefas...50 Figura Diagrama de atividades. Manter tarefas...51 Figura Diagrama de sequência. Manter tarefas...51 Figura Diagrama de atividade. Iterações...52 Figura MVC. Manter Iterações...52 Figura Diagrama de sequência. Manter Iterações...53
10 Figura 3.25: MVC. Manter artefatos...53 Figura Diagrama de atividade. Manter artefatos...54 Figura Diagrama de sequência. Manter artefatos...54 Figura MVC. Manter Envolvidos...55 Figura Diagrama de sequência. Manter Envolvidos...55 Figura 3.30: Diagrama de atividades. Manter envolvidos...56 Figura 3.31: Diagrama de sequência. Manter tipos de envolvidos...56 Figura Diagrama de atividades. Manter tipos de envolvidos...57 Figura MVC. Manter tipos de envolvidos...57 Figura Diagrama de atividades. Manter papéis...58 Figura MVC. Manter papéis...58 Figura Diagrama de sequência. Manter papéis...59 Figura MVC. Manter tipos de papéis...59 Figura Diagrama de atividades. Manter tipos de papéis...60 Figura Diagrama de sequência. Manter tipos de papéis...60 Figura Login...61 Figura Cadastro de artefatos...62 Figura Cadastro de tarefas...62 Figura Cadastro de atividades...63 Figura Cadastro de processos de desenvolvimento...63 Figura Cadastro de fases...64 Figura Cadastro de projetos...64 Figura Consulta de projetos...65 Figura Consulta de processos...66 Figura Consulta de fases...66 Figura Consulta de tarefas...66
11 LISTA DE ABREVIAÇÕES E SIGLAS API - Application Programming Interface DSDM - Dynamic Systems Development Method HTML - Hiper-Text Markup Language JCP - Java Community Process JDBC - Java Database Connectivity JSF - JavaServer Faces JSP - Java Server Pages JVM - Java Virtual Machine SGBD - Sistema Gerenciador de Banco de Dados SGML - Standard Generalized Markup Language SQL - Structure Querry Language UML Unified Modeling Language W3C - World Wide Web Consortium XP - Extreme programing
12 SUMÁRIO INTRODUÇÃO TECNOLOGIAS UTILIZADAS NO DESENVOLVIMENTO DA FERRAMENTA A PLATAFORMA DA FERRAMENTA Linguagem de marcação de texto Hiper-Text Markup Language (HTML) LINGUAGEM DE PROGRAMAÇÃO Tecnologia JavaServer Faces (JSF) Restore View Apply Request Values Process Validations Update Model Values Invoke Application Render Response Prime Faces UNIFIED MODELING LANGUAGE (UML) Objetos e Classes Relacionamento de associação Generalização Dependência Os Casos de Uso O diagrama de atividades O diagrama de sequência O SISTEMA GERENCIADOR DE BANCO DE DADOS A ENGENHARIA DE SOFTWARE O PRODUTO DA ENGENHARIA DE SOFTWARE O CICLO DE VIDA DO SOFTWARE CONCEITOS DA ENGENHARIA DE SOFTWARE O PROBLEMA COM ESTIMATIVA DE PRAZOS E CUSTOS GESTÃO DE QUALIDADE PRODUÇÃO DE SOFTWARE METODOLOGIAS ÁGEIS...33
13 2.7.1 Manifesto Ágil Princípios Ágeis A metodologia XP (Extreme programing) Um exemplo de projeto XP DSDM (Dynamic Systems Development Method) Scrum ANÁLISE O DESIGN DA FERRAMENTA DIAGRAMA DE CLASSE DIAGRAMA DE CASO DE USO ESPECIFICAÇÕES DE HISTÓRIAS E DIAGRAMAS Efetuar Login Manter Projetos Manter Processos de Desenvolvimento Manter Fases Manter Atividades Manter Tarefas Manter Iterações Manter Artefatos Manter Envolvidos Manter Tipos de Envolvidos Manter Papéis Manter Tipos de Papéis IMPLEMENTAÇÃO INTERFACE GRÁFICA Login Cadastro de Artefatos Cadastro de Tarefas Cadastro de Atividades Cadastro de Fases Cadastro de Processos de Desenvolvimento Cadastro de Projetos Consulta de Projetos Consulta de Processos de Desenvolvimento...65
14 Consulta de Fases Consulta de Tarefas...66 CONCLUSÃO...67
15 14 INTRODUÇÃO O desenvolvimento de software em equipe, atualmente, é indispensável para o atendimento das demandas que o mercado exige das empresas de tecnologia da informação. O aumento da complexidade e também a diminuição de prazos, fez com que projetos, que anteriormente poderiam ser realizados por um número pequeno de desenvolvedores, agora tenham que ser divididos entre vários profissionais. Com um número maior de envolvidos na produção de software, aumenta-se também a dificuldade na organização da produção. Apenas ter bons profissionais não é o suficiente para se obter um bom nível de desenvolvimento em equipe. Para atingir as metas de qualidade e não quebrar prazos preestabelecidos é necessário que equipes possuam métodos de desenvolvimento e que todos integrantes os sigam. Segundo Boehm (2004), metodologias de desenvolvimento podem ser classificadas em dois tipos, tradicional ou ágil. O método tradicional de desenvolvimento foca na qualidade final do produto, levando em conta aspectos como o gerenciamento de risco, a constante melhora nos processos e o planejamento do projeto como um todo. Mesmo possuindo vertentes positivas, o método tradicional é questionado por deixar em segundo plano a agilidade da produção. Como o cliente valoriza o tempo que ele necessita aguardar para receber um retorno, a utilização do método ágil, se tornou mais atraente para o desenvolvimento de software comercial, pois combina as forças do método tradicional com técnicas específicas que visam um retorno mais veloz e frequente ao cliente. Tendo em vista o desenvolvimento ágil e sua aplicação pratica, este trabalho tem como objetivo criar uma ferramenta capaz de auxiliar o gerenciamento de projetos que utilizem metodologias ágeis. Um controle sobre as etapas de desenvolvimento será proposto, visando o fornecimento de dados à todos envolvidos sobre o progresso atual da produção, bem como o que está planejado para ser produzido em etapas futuras. A metodologia de pesquisa que será utilizada o levantamento bibliográfico de
16 15 livros e artigos publicados. O primeiro capítulo irá analisar algumas metodologias de desenvolvimento ágil e também, resumir os processos que pertencem à engenharia de software. As tecnologias e plataforma utilizadas serão apresentadas no capítulo 2, suas utilizações também serão justificadas neste capítulo. No terceiro capítulo a análise da ferramenta é produzida. No quarto e último capítulo é apresentada a interface gráfica, junto com detalhes de sua implementação.
17 16 1 TECNOLOGIAS UTILIZADAS NO DESENVOLVIMENTO DA FERRAMENTA Neste capítulo, serão explanados detalhadamente o ambiente de execução da aplicação e as tecnologias e técnicas empregadas no desenvolvimento do software. Serão apresentados argumentos que pesaram na a escolha das tecnologias que serão utilizadas. Dentre as capacidades levadas em conta estão: a difusão da tecnologia no mercado, o custo para utilizá-la e o nível de dificuldade em sua utilização. Também foi dada a preferência para tecnologias abordas em aula pelo corpo docente desta instituição. 1.1 A PLATAFORMA DA FERRAMENTA Este software será concebido para a plataforma da internet, com o propósito de qualquer pessoa do mundo, que tenha conhecimento ou que trabalhe na área da informática e que deseja gerenciar seus projetos, acesse o programa e tenha o controle total de seus processos e projetos. Partindo deste ponto, uma aplicação desta natureza deve ser desenvolvida visando o desempenho para que o usuário não necessite possuir uma conexão de internet robusta para utilizar o produto. Mesmo estando instalada em um servidor na rede mundial de computadores, a ferramenta terá como objetivo funcionar com o mesmo desempenho e estilo de uma aplicação local Linguagem de marcação de texto Hiper-Text Markup Language (HTML) O HTML é uma linguagem de marcação, que se consolidou no mundo da produção de software como padrão de criação de hyper-texto2. Ela foi criada em 1989 pelo físico britânico Tim Berners-Lee, que visava fazer o casamento de linguagens como Hytime e Standard Generalized Markup Language (SGML), e assim produzir uma linguagem que fosse padrão e não tivesse os defeitos que seus 1 Aplicação local: programa que não depende de conexão à internet ou de outros computadores, a não ser a máquina onde foi instalado 2 Hyper-Texto: é o resultado da interpretação de HTML feita por um navegador de internet qualquer.
18 17 antecessores tinham. Desde 1996, o desenvolvimento e a padronização do HTML vêm sido feitos pela instituição World Wide Web Consortium (W3C). Eles têm como principal objetivo diminuir as diferenças nas interpretações de código de diferentes navegadores. Em 1999 foi lançado o HTML 4.01, com uma errata emitida em 2001, esta foi a última versão de especificação da linguagem. Em 2006, foi lançado o XHTML, versão de sintaxe mais rigorosa e menos ambígua do que o HTML Em 2008, mais uma inovação foi anunciada, a W3C publicou os conceitos do XHTML5. Atualmente o projeto está em uso e vários navegadores já são capazes de interpretá-lo, no entanto, a W3C ainda define o XHTML5 como se ainda estivesse em processo de desenvolvimento. 1.2 LINGUAGEM DE PROGRAMAÇÃO A linguagem de programação escolhida para ser utilizada no desenvolvimento deste projeto foi o Java. Influenciada por linguagens como: C++, C# e Objective Pascal, foi criada por um projeto interno da empresa Sun Microsystems a partir de Desde maio de 2007, a Sun transformou quase todo o código do Java em código aberto, essa decisão, fez com que uma comunidade surgisse para manter a linguagem voluntariamente. A principal característica inovadora que fez o Java ter o número de usuários que tem atualmente é a portabilidade. Com a utilização da Java Virtual Machine (JVM) o programa feito em Java não necessita de uma versão diferente para cada sistema operacional, pois o programa será executado sobre a JVM e não sobre o sistema operacional. O Java também se qualifica, por ter diversas Application Programming Interface (APIs) nativas. Entre essas APIs não constam apenas estruturas de dados avançadas ou algoritmos usados frequentemente. O Java possui, por exemplo, bibliotecas para criação de interface gráfica, interação com a rede e manipulação de componentes de Hardware. Além disso, é muito fácil adicionar novos componentes para auxiliar o desenvolvimento mais específicos. Alguns exemplos são, o Java Server Pages (JSP), componente que ajuda no desenvolvimento WEB; o Java Database Connectivity (JDBC), conjunto de APIs que envia comandos SQL (Structure Querry Language) do Java para qualquer Sistema Gerenciador de Banco
19 18 de Dados (SGBD), facilitando muito a tarefa do desenvolvedor. Como o Java será utilizado no desenvolvimento WEB, alguns componentes adicionais serão utilizados. Eles são: Java Server Faces (JSF) e Hibernate-JPA Tecnologia JavaServer Faces (JSF) O JSF, segundo GONÇALVES (2008), é uma especificação de framework de componentes para desenvolvimento em ambiente WEB utilizando Java. Foi criado através do Java Community Process (JCP) em Esta organização padronizou a tecnologia através do esforço conjunto de várias empresas: Apache, BEA Systems, EDS, EMC, Fujitsu, Hewlett-Packard, IBM, Macromedia, Novell, Oracle, Siemens e Sun Mycrosystems. Além disso, o JSF possui uma vasta documentação de componentes que serviram para a comunicação entre o usuário e o sistema. O ciclo de processamento de uma requisição feita pelo usuário pode ser dividido da seguinte forma, de acordo com GONÇALVES (2008): Restore View O objetivo desta fase é criar ou restaurar a interface do usuário (view) que foi requisitada. Uma view contém todos os componentes do JSF declarados em uma página, como listeners (ouvintes de eventos que o usuário pode acionar), validadores (responsáveis por validar informações que o usuário informa ao sistema antes mesmo de enviar as informações pela rede) e conversores (convertem as informações do usuário em formatos especificados pelo programador). Após a requisição de um cliente, acionada por um clique em um botão, por exemplo, todo o estado da view é recuperado e armazenado em uma instância da classe FacesContext. Caso esta seja a primeira requisição, uma nova view é criada e mantida no FacesContext. O ciclo também sofre alteração, ele é desviado para a fase Render Response Apply Request Values O objetivo desta fase é recuperar o estado corrente de cada componente da
20 19 interface gráfica do sistema. Esses componentes são identificados pelo atributo id e seus valores são extraídos dos parâmetros de requisição. Os valores são convertidos de acordo com a propriedade associada ao componente, e caso ocorram falhas na conversão, mensagens de erros são adicionadas ao FacesContext. Se os componentes foram recuperados, independente de erros de conversão, o processamento segue para a fase Process Validations. Caso ocorram falhas na recuperação de algum destes, o processamento é redirecionado para a fase Render Response Process Validations Nesta fase o JSF valida as condições para cada componente, caso estejam configuradas. Por exemplo, se o desenvolvedor definiu que um campo de texto só poderá conter endereços válidos de , o JSF, agora, checará se o valor de tal campo é realmente um endereço de . Se não houver erros de validação o ciclo prossegue para a próxima fase, Update Model Values. Caso haja alguma falha na validação, mensagens de erro são adicionadas ao FacesContext e o ciclo de vida é redirecionado para a fase Render Response, onde serão exibidas junto com as mensagens de conversão Update Model Values Assim que o ciclo atinge esta fase, todos os valores submetidos são considerados como válidos. Com isso, o JSF começa a caminhar sobre a árvore de componentes atribuindo valores e modificando atributos bean correspondentes às propriedades de objetos do Java no servidor. Se os valores dos dados não podem ser convertidos nos tipos especificados pelos atributos do backing bean, mensagens de erros são adicionadas ao FacesContext e o fluxo é redirecionado para a fase Render Response, caso contrário o processamento segue para a fase Invoke Application.
21 Invoke Application Nesta fase são executados os métodos de ação do backing bean e aplicadas as regras de navegação. O FacesServlet, programa feito em Java responsável por atender as requisições do usuário, envia um evento para um método listener ou invoca um método controller. Métodos listeners e métodos controllers podem executar um conjunto de operações, como lógica de aplicação, manipular componentes, adicionar mensagens e definir o conteúdo a ser exibido. Finalmente o FacesServlet está pronto para exibir uma resposta ao usuário e redireciona o processamento para a fase Render Response Render Response Nesta fase, a implementação do FacesServlet autoriza o WEB container a mostrar a página de resposta. As seguintes tarefas são executadas: O estado da view é salvo para ser recuperado pela fase Restore View, caso o usuário requisite novamente. Os componentes são traduzidos de acordo com as classes renderer (HTML) e o WEB container exibe a página. Se houve erros durante o processamento do ciclo de vida, estes erros serão exibidos na página. Enfim, a tecnologia JSF pode ser considerada bastante complexa. Ela propicia recursos da linguagem de marcação de textos HTML em sua essência, com a finalidade de tornar mais rápidas e interativas as aplicações WEB. Diversas tecnologias foram criadas para funcionar em parceria com o JSF, uma delas é o PrimeFaces. A seguir uma breve explicação sobre esta tecnologia Prime Faces O Prime Faces foi criado pelo turco Çağatay Civici. Ele é membro da JavaServer Faces Group e projetou esta API, baseada no JSF, incorporando muitos componentes adicionais para o desenvolvedor. O seu intuito é basicamente agilizar o desenvolvimento de interfaces para aplicativos WEB, desenvolvimento da comunicação entre a interface e o servidor. bem como no
22 21 O grande advento desta criação foi o seu modelo de interface de usuário que possui características antes encontradas apenas em aplicativos desenvolvidos para Desktop. Somando com o desenvolvimento acelerado que ela proporciona, o Prime Faces acabou atraindo gigantes do mundo corporativo que necessitavam de soluções WEB, porém ainda estavam muito ligados aos seus sistemas de plataforma Desktop. 1.3 UNIFIED MODELING LANGUAGE (UML) Partindo agora para o assunto que cerca a modelagem do sistema e a estrutura em que ele será projetado, vem à necessidade de projetar um sistema com a técnica da orientação a objetos. Para a exposição deste tipo de técnica, será utilizado na execução deste projeto a UML. A UML é a notação mais usada pela comunidade que desenvolve com a técnica de orientação a objetos. Segundo Pádua Filho (2012), a notação representa a síntese das técnicas de modelagem orientadas a objeto de James Rumbaugh, Ivar Jacobson e Grady Booch, com o aproveitamento de outras metodologias. Posteriormente, em 1997 a versão 1.1 foi adotada pelo Object Management Group, um consórcio que visa à padronização desse tipo de notação. Portanto, a UML será utilizada neste trabalho, por oferecer uma forma de modelar sistemas de objetos de fácil entendimento e também por ser padronizada Objetos e Classes Em um sistema de objetos, as classes são representações de como os objetos funcionarão. Uma classe é o menor componente de um sistema desse tipo e as boas práticas de programação sempre enfatizam que cada objeto tem uma função específica. Em outras palavras, uma classe representa um molde para a construção de um objeto. Como os objetos do mundo real, os objetos do mundo dos computadores têm características e comportamentos semelhantes, porém, na representação da UML, as características recebem o nome de atributos e os comportamentos recebem o nome de métodos. A Figura 2.1 apresenta classes de acordo com as especificações da UML:
23 22 Figura 1.1: Exemplo diagrama de classe Fonte: uml-diagrams.org, Na Figura 2.1 percebe-se que existem símbolos que precedem os atributos e métodos. Estes símbolos representam como os atributos e os métodos são acessados no programa. Por exemplo, a visibilidade pública representada +, significa que o atributo o método é visível, ou seja, poderá ser acessado por outras classes do sistema. Já quando o símbolo é o - o atributo é apenas visível dentro da classe. Outra possibilidade é que o atributo ou método seja protegido, #, sendo visíveis apenas por classes que herdarem suas características, assim como os filhos herdam características de seus Pais. Por último, a visibilidade de pacote representada por ~, a qual representa a visibilidade padrão e todas as classes que estiverem no mesmo pacote poderão acessar os atributos e métodos desta classe.
24 23 Além da representação de Classes, a notação propõe também a de Objetos. Um objeto é representado com seu nome seguido de dois pontos e o nome da Classe que o construiu. Como dito anteriormente, as classes constituem um molde para que os objetos sejam criados. Estes objetos podem resolver problemas de um assunto em particular, definido pelo Engenheiro de Software. Para separá-los e definir um assunto que será resolvido pelos objetos, a UML, define um tipo específico de diagrama, chamado de Diagrama de Pacotes: Além disso, os relacionamentos entre objetos também possuem uma representação na UML, eles podem ser classificados em três grupos básicos: associação, generalização ou dependência Relacionamento de associação A UML permite que as associações das classes ou representações de objetos, sejam n-árias, ou seja, muitas Classes se relacionando entre si. A leitura do diagrama deve ser feita da esquerda para a direta ou de cima para baixo: Essa maneira de entender o relacionamento pode ser expressa na UML, com a notação de multiplicidade. As multiplicidades podem ser: 0..1 (lê-se: zero ou um), 1..1 (lê-se: um e somente um), 1..* (lê-se: um ou muitos), * (lê-se: muitos) e 0..* (lêse zero ou muitos). Estas representações de multiplicidade ajudam os desenvolvedores a criarem as dependências dos objetos no sistema. A Figura 2.2, a seguir, possui alguns dos relacionamentos citados acima: Generalização Segundo, Pádua Filho (2012), o relacionamento de generalização existe entre um elemento de um diagrama, mais genérico e outro elemento mais específico. Este elemento mais específico herda as características do item mais genérico. A Figura 2.3 apresenta um exemplo de generalização. Nela, a entidade Account é uma generalização das entidades Checking account, Savings Account e Credit Account.
25 24 Figura Exemplo relacionamentos Fonte: uml-diagrams.org, Figura Exemplo generalização Fonte: uml-diagrams.org, Dependência Este tipo de relacionamento ocorre quando o objeto dependente do relacionamento é afetado por uma alteração do objeto fornecedor. A Figura 2.2
26 25 apresenta exemplos de relação de dependência, na relação onde a entidade Librarian depende das interfaces Search e Manage Os Casos de Uso Os casos de uso, ao contrário das representações de elementos presentes internamente nos sistemas, representam a parte externa da aplicação, ou seja, a interação do usuário com a aplicação. Os atores são representados por bonecos padrão e os casos de uso representados por balões com o nome da interação. Por exemplo, um ator pode utilizar uma funcionalidade com o nomeada Gerar Pedido de Compra. Nesta interação, uma sequência de passos é seguida pelo usuário de acordo com as respostas do sistema, para que alcance o resultado final que é um pedido de compra gerado no sistema. As especificações de casos de uso demonstram exatamente quais são os passos para que o objetivo final seja alcançado. A figura 2.4 exemplifica o uso de diagramas de casos de uso O diagrama de atividades Justamente, as sequências de passos expressas em textos dos casos de uso, são expressas em gráficos nos diagramas de atividades. Estes diagramas podem representar estruturas de decisão e ações que podem ser executadas em paralelo. Podem representar também ações executadas pelos usuários e ações executadas pelo sistema. A Figura 2.5 apresenta um simples diagrama de atividades O diagrama de sequência Estes diagramas representam a mesma sequência de eventos representada pelo diagrama de atividades, porém, representando as mensagens que os objetos do sistema enviam uns aos outros para completar a tarefa. A figura 2.6 exemplifica um diagrama de sequência.
27 26 Figura Exemplo diagrama de casos de uso Fonte: uml-diagrams.org, Figura Exemplo diagrama de atividade Fonte: uml-diagrams.org, 2013.
28 27 Figura Exemplo diagrama de sequência Fonte: uml-diagrams.org, O SISTEMA GERENCIADOR DE BANCO DE DADOS A ferramenta proposta utilizará um Sistema Gerenciador de Banco de Dados (SGBD), com o intuito de persistir informações fundamentais para o funcionamento dinâmico do sistema. Há diversos SGBDs disponíveis hoje no mercado, muitos deles são software proprietários (Oracle, SQL Server), para utilizá-los é necessário efetuar a compra dos mesmos. Graças ao movimento de software livre, hoje existem vários SGBDs que possuem código fonte aberto sem custo algum para qualquer usuário que deseje utilizá-lo ou realizar mudanças ajudando no desenvolvimento. Alguns exemplos de SGBDs de código aberto são: PostgreeSql, Mysql e SQLite. Levando em conta essas informações, o SGBD escolhido foi o PostgreeSQL. Ele é muito robusto e possui todas as funcionalidades que um SGBD proprietário possui, além de ser muito bem documentado, o que facilita o desenvolvimento utilizando-o.
29 28 2 A ENGENHARIA DE SOFTWARE Este capítulo terá seu foco voltado para alguns dos conceitos que cercam o assunto vasto da Engenharia de Software. O tema será percorrido, passando por subitens sobre a sua natureza, sendo eles: a produção de software, o seu ciclo de vida, os requisitos necessários, os prazos e metas, os custos de produção e a gestão de qualidade. 2.1 O PRODUTO DA ENGENHARIA DE SOFTWARE O produto da engenharia de software é complexo, pois os sistemas de informática são formados por diversos componentes que trabalham em separado, mas que compartilham o mesmo foco. Sistemas de computação podem ser formados por uma ou mais partes produzidas utilizando uma ou mais linguagens de programação3. Essa parte produzida com o uso de uma linguagem de programação é chamada de software. A parte conhecida como Hardware representa a parte física (eletrônica) que processa efetivamente as requisições que a camada de software o solicita. Entre o hardware e o software, na grande maioria das vezes, estará o sistema operacional, que também tem de ser levado em conta pela engenharia de software. O sistema operacional é nada mais do que um software, também criado com uma ou mais linguagens de programação que atua como um mediador entre a parte física e lógica. Sempre que um sistema executa uma operação, ele, em vez de se pronunciar diretamente ao hardware, utilizará a camada intermediária, que por sua vez comunicará com o hardware local, realizando os devidos procedimentos. Apesar da divisão das tarefas entre os componentes dos sistemas, eles ainda acabam apresentando problemas. Segundo Pádua Filho (2012), as pessoas que utilizarão os programas, geralmente visualizam a tecnologia como a criação dos problemas e não como a resolução deles. Infelizmente esta imagem acabou sendo concretizada pelo uso de processos não totalmente consolidados. Outra causa pode estar associada a processos de negócio ineficientes na sua essência. 3 Linguagem de Programação: É um idioma intermediário entre o computador e o ser humano. Com o seu uso, podemos dar ordens à máquina, que são traduzidas e então executadas pelo computador.
30 O CICLO DE VIDA DO SOFTWARE O ciclo de vida de um sistema é feito dentro de um projeto, o qual tem um tempo determinado para sua conclusão e representa a execução de um processo. Os processos podem ser definidos pelos membros da equipe de acordo com sua adaptação e ocorrem subdivisões nos processos com a função de determinar o progresso da equipe. Além desses detalhes, um projeto é guiado por um Gerente, que terá a difícil tarefa de cuidar para que os desejos de todos os interessados no projeto, também chamados de stakeholders, sejam atendidos de alguma forma. As partes mais importantes desse planejamento são os clientes e os usuários, no entanto, os membros da equipe também são afetados pelo sucesso ou insucesso do projeto. Durante o ciclo de vida da produção de um sistema, existem várias fases. Dentre elas está a Análise de Requisitos. Nesta fase, o esforço da equipe de desenvolvimento fica concentrado nas funções que o sistema possuirá. É importante ressaltar que nesta fase não há preocupação em como o produto irá ser produzido, ou quais tecnologias serão utilizadas. Segundo Pádua Filho (2012), há uma distância enorme sobre o que é necessário fazer para resolver o problema do cliente e o que acaba sendo produzido no final do processo, ou seja, conforme as etapas de produção são alcançadas, novos problemas, ou até mesmo soluções mais atraentes podem surgir, tirando o projeto do rumo inicialmente delineado. Depois das fases de definição do software estarem completas, se inicia a etapa chamada desenvolvimento. No desenvolvimento antes de ser feita qualquer implementação será absolutamente necessário ser feito o design de tal. As fases de design incluem: design conceitual, design de interface, design de arquitetura e design de algoritmos4 e estrutura de dados. O design conceitual será uma tentativa de visualizar o que o software será, ou seja, os analistas devem definir uma meta que o projeto deve atingir no final de sua produção. A partir do conceito preparado, será possível realizar o design de interface, onde todas as telas de interação com o usuário serão desenvolvidas. O terceiro estágio será o design de arquitetura e ocupará um papel crucial para a futura implementação, pois é ai que será feito um planejamento minucioso relacionado a módulos, tecnologias que deveram ser utilizadas, processos que serão 4 Sequência de instruções, onde o intuito é realizar alguma tarefa definida.
31 30 executados durante determinadas tarefas e prioridades de implementação. O último design será o de algoritmos e estruturas de dados 5, ele trará detalhadamente descrito, como cada elemento deve ser implementado. As estruturas de dados também serão abordadas, deve-se decidir quais serão utilizadas, considerando um balance no desempenho do sistema e velocidade de desenvolvimento. Em conjunto com o design de arquitetura, o design de algoritmos e estruturas de dados funcionará como um manual para o programador implementar o software adequadamente. Depois que a implementação é finalizada, o sistema passará por um período de teste antes de ser instalado na infraestrutura do cliente. O ideal seria que, sistemas após serem desenvolvidos, fossem intensamente testados, evitando vários problemas no futuro, com o software já fora do estágio de produção. Logo após esta etapa, o sistema será instalado e testado novamente em seu ambiente definitivo. Também será necessário o treinamento das pessoas que utilizaram o software, para que possam usufruir de todas as funcionalidades a eles disponíveis. No final do ciclo, temos o estágio de retirada do software. Este etapa tem a intenção de dar lugar a uma nova versão, que possa trazer melhorias significantes e realmente ajudar a empresa. Esta fase é considerada difícil no ponto de vista empresarial, pois as empresas geralmente não apreciam a ideia de ter que gastar dinheiro com um novo produto, enquanto ainda possuem um software que é capaz de atender às suas necessidades básicas. 2.3 CONCEITOS DA ENGENHARIA DE SOFTWARE Segundo Pádua Filho (2012), o foco da engenharia é a necessidade humana. O autor afirma que o conhecimento científico é uma necessidade do homem, porém o produto da engenharia provém as circunstancias necessárias para que o anseio pelo conhecimento apareça no ser humano. A Engenharia de software, por sua vez, traz valor através do processamento de informação. A ciência da computação possui métodos e procedimentos que são utilizados pela Engenharia de software. Porém, segundo o autor citado acima, boa parte dos métodos desta engenharia reflete a experiência prática das pessoas no dia a dia. Só depois de um tempo a Ciência e a pesquisa intervêm com padronizações, 5 Modos de armazenamento de dados em uma aplicação.
32 31 explicações e generalizações. Além disso, o trabalho dos Engenheiros construtores de software é transformar ideias e necessidades em produtos geradores de valor, no caso desta engenharia os programas de computador são os produtos, que por sua vez agrega uma série de serviços que o engenheiro deve estar preparado para desenvolver, como por exemplo, a comunicação com sistemas externos. Ainda segundo o autor anterior, a Engenharia de software segue processos com ação sistemática, sem nenhum tipo de improvisação. 2.4 O PROBLEMA COM ESTIMATIVA DE PRAZOS E CUSTOS Os sistemas de informática são frequentemente subestimados com relação aos prazos e custos, principalmente quando são feitos sob medida. Os contratos para o desenvolvimento dos programas são irreais e são feitos para satisfazer os anseios dos clientes e gerentes dos projetos e causam todo tipo de transtorno entre os membros de toda a equipe. Os processos da Engenharia de Software enfatizam justamente que não deve haver este tipo de conflito, enfatiza também que as equipes aprendam com os projetos passados para evoluir e não cometer erros nos projetos futuros. Para evitar problemas, o gerente, deve, segundo Pádua Filho (2012), assumir os compromissos de prazos e custos com base em requisitos bem levantados, analisados e documentados. Todo e qualquer plano de projeto deve ser feito com boas técnicas de estimativas e análise de tamanho, esforços, prazos e riscos. Apesar de todo esse planejamento, na execução dos projetos podem ocorrer imprevistos e os membros devem estar preparados utilizando processos que suportem mudanças no plano. Nestes momentos, as mudanças podem ser rigorosas ao ponto de ocorrerem até renegociações de contrato. Estes problemas acabam afastando profissionais da área da informática, por causa das promessas de prazos sem fundamento e planejamento. Muitos profissionais estão preferindo trabalhar como autônomos, a continuarem como assalariados, pois enfrentam graves problemas com projetos malplanejados. 2.5 GESTÃO DE QUALIDADE
33 32 De acordo com Pádua Filho (2010), a qualidade de um produto, de qualquer natureza, se dá a partir da conformidade com seus requisitos. Com o produto da Engenharia de Software não é diferente, pois o foco é atender os requisitos propostos em cada uma das reuniões que são realizadas durante seu ciclo de produção. Porém, algumas dessas necessidades capturadas escondem funções complexas ou então os desafios relacionados com a tecnologia utilizada são subestimadas naquele momento pela equipe e quando o problema começa a ser encarado, não há mais tempo hábil para completar um produto de qualidade. Portanto, cada requisito não atendido é considerado um defeito dos produtos gerados, causando enormes contratempos e pagamento de multas. O trabalho humano de escrever programas acaba também por introduzir erros ocultos, que poderiam ser evidenciados por testes exaustivos, que, caso a equipe de desenvolvimento não possua tais práticas, o produto final estará propenso a falhar repentinamente. Em tais processos uma das ideias principais é remover o maior número de erros associados inconscientemente pelos desenvolvedores. Segundo Pádua Filho (2012), a pior forma de remoção de defeitos é a operação de manutenção, porque os problemas são detectados no momento em que o software está em produção, causando transtornos para os clientes e reforçando a imagem negativa sobre a informática. 2.6 PRODUÇÃO DE SOFTWARE Os esforços de empresas produtoras de software estão na criação rápida de produtos de altíssima qualidade, entretanto, a produção em larga escala de software se mostra um pouco mais complexa e acaba sendo subestimada pelas empresas. As empresas se mantêm no mercado trabalhando com prazos muito apertados que prejudicam os membros da equipe, porém, algumas empresas que se sobressaem, acabam utilizando métodos e técnicas mais eficientes e altamente produtivas, criando softwares com certa complexidade em tempo razoável e alta qualidade. Se o planejamento for priorizado desde o começo, a equipe tem condições de fazer previsões e saber a carga de trabalho, homens por hora, a ser depositada em cada projeto que a empresa tem. O que não deve acontecer é a quantidade de trabalho ser exacerbadamente grande, obrigando os profissionais a pularem etapas
34 33 essenciais da engenharia de software, indo diretamente para a implementação. Esta medida feita com o intuito de reduzir o tempo de desenvolvimento, pode se tornar um câncer no projeto, que muitas vezes não tem cura. 2.7 METODOLOGIAS ÁGEIS As metodologias ágeis prometem o desenvolvimento rápido e eficiente de aplicações, com o melhor aproveitamento possível do contingente humano. Para tanto, adaptação é a palavra-chave em equipes ágeis, ou seja, estas metodologias propõem que os membros da equipe atuem de uma forma flexível com suas tarefas. Outra característica deste tipo de metodologia é a utilização de uma estratégia para a resolução de problemas complexos chamada dividir para conquistar. Essa estratégia consiste em dividir problemas maiores em problemas menores, fazendo com que o resolvedor tenha que lidar com vários problemas menores, ao invés de ter que atacar um problema maior. (KEN, 2004) Apesar de inovar, as metodologias ágeis partiram de uma fundação forte e muitos de seus princípios são originais de metodologias tradicionais de desenvolvimento. Segundo Boehm (2004), o foco nos processos de teste, o gerenciamento dos riscos e a colaboratividade são pontos herdados de metodologias tradicionais e que as metodologias ágeis que surgiram, as utilizam adicionando novos atributos visando a vertente de tempo, que é de suma importância para atender as exigências do mercado atualmente. Neste capítulo, serão explicados os detalhes de algumas das metodologias mais importantes e reconhecidas na engenharia da computação Manifesto Ágil Em 2001, dezessete especialistas reuniram-se para a criação do manifesto ágil. Neste manifesto, a proposta era modificar a ideia anterior que centralizava o valor do desenvolvimento de software nas ferramentas e documentação, para então focar no capital humano disponível. Os conceitos apresentados no Manifesto Ágil são: Indivíduos e a interação entre eles é mais importante que processos e ferramentas, software em funcionamento mais importante que documentação abrangente, colaboração com o cliente mais importante que negociação de
35 34 contratos, responder as mudanças mais importante que seguir um plano Princípios Ágeis Alguns dos objetivos da filosofia do desenvolvimento ágil permeiam o incentivo a inovação tecnológica. Sabbagh (2013) define um processo ágil como aquele capaz de se adaptar a novas ideias, capaz também de entregar produto que atenda as necessidades do cliente hoje, mas que sejam capazes de moldarem-se as inovações tecnológicas de amanhã. Muitas atividades devem ser descartadas para utilizar apenas aquelas que realmente agregam valor ao produto. Segundo Larman (2003), em acordo com manifesto ágil, os princípios são a prioridade em satisfazer o cliente através do cumprimento de prazos e continuo desenvolvimento do software valioso. Isso demonstra a grande qualidade de uma equipe para trabalhar com essa estrutura de produção de software comercial, em outras palavras, o software é um produto complexo que deve atender a uma série de requisitos, ditos básicos, porém de alta dificuldade de produção, para então caracterizar valor para o cliente. Larman (2003) diz que Acolher as mudanças de requisitos, mesmo tarde no desenvolvimento. Aproveitar as mudanças nos processos para trazer a vantagem competitiva do cliente. Toda mudança, quando tardia em qualquer estilo de produção do software, pode causar sérios problemas à equipe de desenvolvimento, porém, ao aplicar os processos ágeis, a forma como a equipe vai lidar com as mudanças pode amenizar os problemas. Larman (2003) também diz que Entregar software funcionando frequentemente, com ciclo de duas semanas até no máximo um mês, com preferência para a escala de tempo mais curto. Neste princípio, a disciplina entre os participantes do time, será o fator primordial para o cumprimento desta meta. Um dos alicerces da filosofia ágil segundo Larman (2003) é o envolvimento entre equipes de áreas diferentes que envolvem o projeto, membros da equipe de negócios e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto. Não há espaço para divergências que paralisam o progresso da equipe. Quanto a comunicação no projeto, o método mais eficiente é a cara a cara, nas comunicações formalizadas os membros da equipe podem omitir a verdade dos fatos, prejudicando o desempenho do grupo como um todo.
36 35 Segundo Larman (2003), o software tem de passar por uma quantidade de testes significante durante e após o termino do desenvolvimento. Não pode ser considerado como desperdício de mão de obra a dedicação de uma boa parcela do tempo aos testes. Um produto bem testado não trará problemas imprevistos ao cliente, e tampouco fará com que equipes sejam redirecionadas a correções de erros cometidos por outros programadores no passado. A participação dos interessados no projeto deve ser incessante e deverão determinar maior qualidade ao software. Eles têm que estar constantemente avaliando a qualidade do software e apontando mudanças necessárias. É de extrema importância que o projeto execute o trabalho exato que foi determinado, que não haja invenções não planejadas ou aprovadas pelo cliente. O que o desenvolvedor pode pensar ser facilitador para o usuário, pode ser, na verdade, um complicador e causador de problemas. Também fundamental para o desenvolvimento ágil é a autocrítica. Não deve haver espaço para o ego pessoal dos envolvidos, o pensamento tem que ser centralizado no produto final. Desenvolvedores tendem a insistir em ideias criadas por eles mesmos, o problema é que às vezes a ideia pode ser inviável, ou, até mesmo ruim. Cabe ao gerente de projeto identificar essas situações e resolvê-las antes que grandes mudanças tenham que ser feitas A metodologia XP (Extreme programing) Criada por Kent Beck em 2000, propondo uma forma de responder rapidamente às mudanças sem deixar de lado a qualidade do produto. Beck reforça que os programadores são o centro de um projeto XP, e que são os responsáveis pela qualidade final do sistema. O projeto é iterativo e incremental com iterações de no máximo um mês e no mínimo duas semanas, porém Kent Beck enfatiza o mínimo. De acordo com Beck (2004), seus princípios básicos são: Feedback rápido: no processo em cascata o feedback é capturado em alguns meses. Este problema pode inviabilizar o desenvolvimento do sistema, pois erros são frequentes na interpretação de requisitos, por mais eficientes que sejam os métodos usados, a imprecisão da língua escrita é grande. Se um requisito for mal compreendido, toda a modelagem do sistema pode ser ineficaz. Por outro lado, em um projeto XP, o foco é aprender rápido com os erros cometidos em cada iteração e realimentar o sistema com código testado.
37 36 Simplicidade presumida: este princípio recomenda que o projeto seja simplificado, dando ênfase em nas funções que realmente tragam valor para o cliente/usuário no momento atual do desenvolvimento. A tendência das pessoas em planejar para o futuro deve ser deixada de lado e os testes, refatorações e comunicação são executadas para os problemas atuais. O reúso deve ser considerado apenas após uma avaliação, não por deduções. Em um capítulo intitulado Aprendendo a Dirigir, Beck (2004) faz uma comparação do gerenciamento de software com a prática de guiar um carro Dirigir não é fazer o carro andar na direção certa. Dirigir é prestar atenção constantemente, fazendo uma pequena correção para um lado, outra pequena correção para o outro. (Beck 2004, p. 43). Assim como nesta passagem, não é recomendado fazer grandes mudanças no software, mas sim pequenas mudanças incrementais. As mudanças no plano podem ser uma arma estratégica para aumentar a competitividade da equipe de desenvolvimento, como uma vantagem competitiva em relação às outras. A alta qualidade não pode ser colocada em segundo plano, tudo o que foi citado acima tem que ser cumprido não abrindo mão da qualidade. É importante realçar, que qualidade de software só é atingida quando se da a devida importância ao processo de testes Um exemplo de projeto XP Em um projeto XP, inicialmente os participantes convocam uma reunião para decidir como será a iteração seguinte, determinam as estórias que serão usadas para o desenvolvimento, fazem uma pequena etapa de análise e começam a programar. O código gerado é responsável por manter a qualidade, que pode ser conseguido com os testes constantes e integração a cada final de iteração DSDM (Dynamic Systems Development Method) Segundo Presman (2006), segue a filosofia de Pareto, onde 80% do sistema podem ser entregue em 20% do tempo necessário para fazer a aplicação por completo. A sequência da metodologia é apresentada abaixo: Primeiramente são feitos estudos da viabilidade do projeto poder ser construído com o uso da metodologia. São levantados também, assim como em
38 37 qualquer metodologia, os requisitos do sistema. Em seguida uma análise mais profunda das funcionalidades de maior valor e requisitos de manutenibilidade do sistema são realizados. Na fase posterior, chamada de iteração de modelo funcional, um conjunto de protótipos de iteração são gerados para provocar feedback rápido pelo uso dos clientes. Estes protótipos, segundo Presman (2006), são destinados a evolução para serem entregues. Iteração de projeto e construção: para garantir que os protótipos sejam consistentes, os mesmos são revisados, para fornecer valor real para o negócio. Implementação: coloca efetivamente o(s) protótipo(s) em produção, porém não em estado completo, podendo ser alterado de forma incremental ainda Scrum Comparado com a metodologia XP, o Scrum se diferencia por focar mais na questão gerencial dos processos. As duas metodologias possuem diversos pontos em comum, pois têm como alicerce o manifesto ágil. No entanto, o Scrum, por ter sido inicialmente elaborado para ser um método de gerenciamento de produção de automóveis, pode ser utilizado não somente com a finalidade de produzir software, mas sim para gerenciar qualquer tipo de produção. (BOEHM, 2004) O Sprint é o principal fundamento do Scrum, definido como um ciclo de desenvolvimento que pode durar de uma semana a um mês. Ele é precedido por uma reunião, que definirá as atividades a serem realizadas a partir dos requisitos feitos pelo cliente. Durante a execução de um sprint, serão realizadas reuniões diárias, visando o acompanhamento do progresso de todos os envolvidos na produção. Após o termino de um sprint, um artefato será gerado, permitindo o cliente ter uma prévia de seu produto final. Também será feita uma revisão dos requisitos, que redefinirá prioridades ou cancelará um requisito quando se conclui que o mesmo é inviável. (KEN, 2004) Por ser uma técnica voltada para auxiliar o gerenciamento de projetos, o Scrum não estabelece práticas de engenharia de software. Segundo Ken (2004), é indicado a integração das práticas do Scrum com práticas de desenvolvimento pertencentes à metodologia XP. Sem práticas de desenvolvimento de software definidas, alguns problemas podem ocorrer, a integração com o XP pode evitar problemas e até otimizar a produção de uma equipe.
39 38 3 ANÁLISE Neste capítulo serão apresentados o design da ferramenta, bem como os diagramas UML desenvolvidos a partir do processo de análise de sistema. Serão apresentados diagramas de casos de uso, classes, atividades, sequência e também o MVC. 3.1 O DESIGN DA FERRAMENTA A ferramenta proposta neste trabalho tem como seu objetivo gerenciar projetos de desenvolvimento de software que utilizem metodologias de desenvolvimento ágil. Como explanado no Capitulo 1, metodologias ágeis se caracterizam pela divisão de problemas maiores em problemas menores. O projeto, como um todo, pode ser definido como o problema maior, nas metodologias analisadas neste trabalho, a divisão do projeto, ou seja, a divisão do problema maior resulta em ciclos de desenvolvimento, que também são chamados de fases de desenvolvimento ou, no caso da metodologia Scrum, sprint. Cada um destes ciclos resultantes, também podem ser divididos. Ao invés de definir apenas um objetivo para ser concretizado durante a execução do ciclo, várias atividades são definidas como o conjunto de requisitos para a finalização do ciclo de desenvolvimento. Essa prática ajuda na especificação do que é necessário ser produzido e, também a atacar os requisitos impostos pelo cliente. As atividades criadas em um ciclo, também podem ser fracionadas. Suas divisões geram tarefas, que são realmente específicas, onde o problema chegou a sua forma mais simples. Ao serem completadas, as tarefas gerarão artefatos para que a atividade, na qual pertencem, possa gerar sua iteração. A Figura 3.1 apresenta de forma simplista o design da ferramenta. Nela fica implícita a entidade Projeto e é mostrada no topo, a entidade Processo, seguida pela Fase, Atividade, Tarefa e Artefato, seguindo o modelo hierárquico da divisão dos problemas proposta acima. Ao lado da Atividade, fica destacada a Iteração, ela demostra, que ao final de cada atividade, após a junção de todos os artefatos gerados pelas tarefas pertencentes à atividade, é efetuada a iteração, que determina
40 39 que aquela atividade já esta finalizada e a equipe designada está pronta para o início da próxima fase, ou auxiliar outra equipe responsável por alguma outra atividade. Processo Fase Iteração Atividade Tarefa Artefato Figura 3.1: Design da ferramenta Como clientes são ativamente envolvidos em projetos que utilizam metodologias ágeis, fica necessário a elaboração de uma entidade para ser possível a diferenciação de clientes de todos os tipos de profissionais envolvidos. A entidade que possuirá esta responsabilidade será a Papel. Ela será ligada diretamente as Tarefas, ou seja, a toda Tarefa será ligada a uma lista de papéis, que representará as pessoas envolvidas na execução daquela Tarefa. 3.2 DIAGRAMA DE CLASSE A Figura 3.2 apresenta o diagrama de classe, efetuado após a analise do design da ferramenta proposta. Nele segue a hierarquia apresentada no design da ferramenta, é possível observá-la começando na entidade Projeto e finalizando na entidade Artefato. No entanto, algumas entidades complementares consideradas necessárias são apresentadas, são elas: Envolvido e TipoEnvolvido, que definem os
41 40 envolvidos no projeto; Papel, que define a função que cada pessoa terá, ou seja, sua responsabilidade em uma atividade; TipoPapél, entidade que contém as funções que cada papél pode assumir; Usuário, que conterá informações dos usuários e também será ligado ao papel, com a função de indicar o usuário que fica responsável pela execução de uma atividade. Figura Diagrama de Classe
42 DIAGRAMA DE CASO DE USO A Figura 3.3 apresenta o diagrama de caso de uso, que fora elaborado após o levantamento dos requisitos considerados necessários para o produto final. Nele é possível observar todos os módulos do sistema. Também é destacado os atores envolvidos, sendo eles o usuário e o administrador do sistema. Figura Diagrama de casos de uso
43 ESPECIFICAÇÕES DE HISTÓRIAS E DIAGRAMAS Aqui serão apresentados os diagramas UML de cada modulo apresentado no diagrama de casos de uso Efetuar Login A página de login pode ser facilmente acessada quando o usuário inicia a ferramenta em seu navegador de internet. Um formulário será apresentado pedindo as informações de nome de usuário e senha de acesso. Se os dados informados estiverem corretos, o usuário ganha acesso ao sistema, se caso a senha ou nome de usuário estiverem incorretos, o usuário poderá tentar entrar seus dados de novo. A Figura 3.4 apresenta o digrama de atividades, a 3.5 o MVC e a 3.6 o diagrama de sequencia referentes ao caso de uso efetuar login. Figura Diagrama de atividades. Efetuar login
44 43 Figura MVC. Efetuar Login Figura Diagrama de sequência. Efetuar login Manter Projetos Cada projeto é vinculado com envolvidos e processo, que serão selecionados pelo formulário apresentado, é possível observar na Figura 3.8 os atributos das entidades relacionadas com a entidade Projetos. Fica também destacado na Figura 3.7 e na Figura 3.9, que os dados são validados antes de serem submetidos para a persistência no servidor, tendência que vem sendo cada vez mais usada em aplicativos para internet.
45 44 Figura Diagrama de Atividade. Manter projetos Figura MVC. Manter projetos
46 45 Figura Diagrama de sequência. Manter projetos Manter Processos de Desenvolvimento Processos de Desenvolvimento são cadastrados sem nenhum vínculo a outra entidade, é possível observar a ausência de atributos de outras entidades no diagrama apresentado na Figura Eles têm de ser adicionados antes dos cadastros de projeto ou fase, que são entidades que interagem com o Processo de Desenvolvimento. Figura MVC. Manter processos de desenvolvimento
47 46 Figura 3.11: Diagrama de atividades. Manter processos de desenvolvimento Figura 3.12: Diagrama de sequência. Manter processos de desenvolvimento
48 Manter Fases Todo Processo estará vinculado a várias fases e toda fase possuirá atividades, na Figura 3.13, o digrama de atividade mostra que na apresentação de formulário é necessário a obtenção dos dados das entidades Fase e Processo. Uma fase pode ser, por exemplo, desenvolvimento do banco de dados, que é abrangente e possuirá atividades específicas como: criação de diagramas de relacionamento, padronização do banco de dados e criação de código SQL. Para uma fase ser dada como completa, todas suas atividades têm que ter sido completadas. A especificação de fase também pode variar com a metodologia de desenvolvimento utilizada pelo cliente, então fica a cargo dele a definição de tempo final e inicial, bem como descrição, que são atributos observados na Figura 3.14 no diagrama MVC. A Figura 3.15 demonstra o processo de cadastro e alteração de fases através do diagrama de sequência. Figura Diagrama de atividade. Manter fases
49 48 Figura MVC. Manter fases Figura Diagrama de sequência. Manter fases Manter Atividades Toda atividade estará vinculada a uma fase, também toda atividade possuirá tarefas, observa-se na Figura 3.16 a entidade Tarefas sendo requisitada pelo Apresentar formulário, isso demonstra que no cadastro de atividades será necessário vincular tarefas com a atividade a ser criada. Para uma atividade ser dada como completa, todas suas tarefas têm que ter sido completadas. A Figura 3.17 apresenta o MVC e a 3.18 o diagrama de sequência.
50 49 Figura Diagrama de atividade. Manter atividades Figura MVC. Manter atividades
51 50 Figura Diagrama de sequência. Manter atividades Manter Tarefas Tarefas são divisões de atividades, que ainda podem ser definições um pouco abrangentes. Além de dividir as atividades, as tarefas serão atribuídas como responsabilidades de seus envolvidos. Também serão definidos prazos, que futuramente serão utilizados para a verificação do cumprimento das metas estabelecidas. Figura 3.19: MVC. Manter tarefas.