DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI

Tamanho: px
Começar a partir da página:

Download "DESENVOLVIMENTO DE UMA FERRAMENTA DE GERENCIAMENTO DE PROJETOS ADRIANO HENRIQUE DE SOUZA DA SILVA DANILO FRANÇOSO TEDESCHI"

Transcrição

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.

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2

ENGENHARIA DE SOFTWARE II. Modelos de Ciclo de Vida e Processos de Software AULA 2 ENGENHARIA DE SOFTWARE II Modelos de Ciclo de Vida e Processos de Software AULA 2 Sumário Motivação Conceitos de Processo de Desenvolvimento de Software Atividades que compõem os processos de desenvolvimento

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Introdução ao Processo Unificado (PU)

Introdução ao Processo Unificado (PU) Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Introdução ao Processo Unificado (PU) Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin

Leia mais

O Processo Unificado

O Processo Unificado UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE VI: Como desenvolver Sistemas de Informação e Gerenciar Projetos. Novos sistemas de informação são construídos como soluções para os problemas

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

Leia mais

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS Rosiane da Silva Biscaia Discente do curso Tecnologia em Análise e Desenvolvimento de Sistemas Faculdades

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

Introdução aos computadores, à Internet e à World Wide Web. 2005 by Pearson Education do Brasil

Introdução aos computadores, à Internet e à World Wide Web. 2005 by Pearson Education do Brasil 1 Introdução aos computadores, à Internet e à World Wide Web OBJETIVOS Neste capítulo, você aprenderá: Conceitos básicos de hardware e software. Conceitos básicos de tecnologia de objeto, como classes,

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Tecnologia Java Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Origem da Tecnologia Java Projeto inicial: Oak (liderado por James Gosling) Lançada em 1995 (Java) Tecnologia

Leia mais

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF 1. Identificação de um problema a ser implementado 2. Análise

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Sumário. Uma visão mais clara da UML

Sumário. Uma visão mais clara da UML Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da

Leia mais

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO

SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO SISTEMATIZAÇÂO DOS TIPOS DE INFORMAÇÂO DO PLANEJAMENTO ESTRATÉGICO EMPRESARIAL E DE TECNOLOGIA DA INFORMAÇÂO E COMUNICAÇÂO Danilo Freitas Silvas Sistemas de informação CEATEC danilofs.ti@gmail.com Resumo:

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

A história de UML e seus diagramas

A história de UML e seus diagramas A história de UML e seus diagramas Thânia Clair de Souza Vargas Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Florianópolis, SC Brazil thania@inf.ufsc.br Abstract.

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS

TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS TECNOLOGIAS E FRAMEWORKS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS GERENCIAIS Janderson Fernandes Barros ¹, Igor dos Passos Granado¹, Jaime William Dias ¹, ² ¹ Universidade Paranaense (UNIPAR) Paranavaí

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Análise e Projeto Orientados a Objeto

Análise e Projeto Orientados a Objeto Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo Baseado em Craig Larman 1 Aplicando UML, Padrões e APOO Objetivo Desenvolver habilidades práticas na utilização

Leia mais

Busca Certa Combustíveis

Busca Certa Combustíveis UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Busca Certa Combustíveis por Luma Melo Borges Documento de conclusão da disciplina de Trabalho

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita Unified Process Sueleni Mendez Batista Orientadora: Dra. Elisa Hatsue Moriya Huzita Processo de Desenvolvimento de Software 8O processo de desenvolvimento de software é um conjunto de atividades e resultados

Leia mais

Lógica e Programação Java

Lógica e Programação Java Lógica e Programação Java Agenda Orientação a Objetos Parte 2 UML (software astah) Diagramas Estruturais Diagramas Comportamentais Diagramas de Interação astah Diagrama de Classes Antigo Jude Versão Community

Leia mais

UNIVERSIDADE ESTADUAL DE PONTA GROSSA

UNIVERSIDADE ESTADUAL DE PONTA GROSSA UNIVERSIDADE ESTADUAL DE PONTA GROSSA SECRETARIA MUNICIPAL DE GESTÃO DE RECURSOS HUMANOS CONCURSO PÚBLICO PARA ANALISTA DE SUPORTE 08 DE NOVEMBRO DE 2009... (NOME COMPLETO EM LETRA DE FORMA) INSTRUÇÕES

Leia mais

O Ciclo de Vida do Desenvolvimento de Sistemas i

O Ciclo de Vida do Desenvolvimento de Sistemas i O Ciclo de Vida do de Sistemas i O Ciclo de Vida do de Sistemas ( SDLC Systems Development Life Cycle), conhecido também com o ciclo de vida do software refere-se aos estágios de concepção, projeto, criação

Leia mais

Felipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet)

Felipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet) UML Felipe Denis M. de Oliveira Fonte: Alice e Carlos Rodrigo (Internet) 1 Programação O que é UML? Por quê UML? Benefícios Diagramas Use Case Class State Interaction Sequence Collaboration Activity Physical

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Micro Mídia Informática Fevereiro/2009

Micro Mídia Informática Fevereiro/2009 Micro Mídia Informática Fevereiro/2009 1 UML Introdução Fases de Desenvolvimento Notação Visões Análise de Requisitos Casos de Uso StarUML Criando Casos de Uso Orientação a Objetos Diagrama de Classes

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br

Engenharia de Software: Metodologias e Contextualização. Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Engenharia de Software: Metodologias e Contextualização Prof. José Eduardo A. de O. Teixeira vqv.com.br / j.edu@vqv.com.br Conceitos iniciais Informática: Ciência que tem como objetivo o tratamento da

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC Felipe Moreira Decol Claro 1, Késsia Rita da Costa Marchi 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil felipe4258@hotmail.com, kessia@unipar.br

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Desenvolvimento de Software requer Processo e Gestão

Desenvolvimento de Software requer Processo e Gestão Desenvolvimento de Software requer Processo e Gestão Antonio Mendes da Silva Filho * If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Programação WEB Introdução

Programação WEB Introdução Programação WEB Introdução Rafael Vieira Coelho IFRS Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul Campus Farroupilha rafael.coelho@farroupilha.ifrs.edu.br Roteiro 1) Conceitos

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm.

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm. Autor José Jesse Gonçalves Graduado em Licenciatura em Matemática pela Universidade Estadual de São Paulo - UNESP, de Presidente Prudente (1995), com especialização em Análise de Sistemas (1999) e mestrado

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais