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

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

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

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

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

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

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

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

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

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

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

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

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

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

METODOLOGIAS ÁGEIS - SCRUM -

METODOLOGIAS ÁGEIS - SCRUM - METODOLOGIAS ÁGEIS - SCRUM - André Roberto Ortoncelli ar_ortoncelli@hotmail.com 2010 Organização da Apresentação Introdução as Metodologias Ágeis Scrum Conceitos Básicos Artefatos Papeis Cerimônias Estórias

Leia mais

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

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

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

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

Professor: Curso: Disciplina:

Professor: Curso: Disciplina: Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos

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

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

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 03 Profissões de TI Prof. MSc. Edilberto Silva edilms@yahoo.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos respectivos

Leia mais

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

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

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

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

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução aos Processos de Software: modelos e ciclo de vida de software Prof. MSc. Hugo Vieira L. Souza Este documento está sujeito a copyright. Todos os direitos estão reservados

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

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

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

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

Prof. Me. Marcos Echevarria

Prof. Me. Marcos Echevarria Prof. Me. Marcos Echevarria Nas décadas de 80 e 90 a visão geral sobre a melhor maneira de desenvolver software era seguir um cuidadoso planejamento para garantir uma boa qualidade; Esse cenário era aplicável

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

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

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

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

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

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

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

Sistema de Acompanhamento ao Desempenho do Aluno

Sistema de Acompanhamento ao Desempenho do Aluno Sistema de Acompanhamento ao Desempenho do Aluno Manoel Cardoso da Silveira Neto 1, Luciana Vescia Lourega 1 1 Instituto Federal Farroupilha Campus Júlio de Castilhos RS - Brasil Caixa Postal 38 98.130-000

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com

Introdução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML UML (Unified Modeling Language Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de

Leia mais

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta

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

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

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

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

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

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

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

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

Nome da Empresa Sistema digitalizado no almoxarifado do EMI

Nome da Empresa Sistema digitalizado no almoxarifado do EMI Nome da Empresa Documento Visão Histórico de Revisões Data Versão Descrição Autor 23/02/2015 1.0 Início do projeto Anderson, Eduardo, Jessica, Sabrina, Samuel 25/02/2015 1.1 Correções Anderson e Eduardo

Leia mais

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software São Paulo 2007 JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação

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

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti. TI Aplicada Aula 02 Áreas e Profissionais de TI Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http:// Papéis... Um papel é uma definição abstrata de um conjunto de atividades executadas e dos

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

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

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

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

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

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert: BRAlarmExpert Software para Gerenciamento de Alarmes A TriSolutions conta com um produto diferenciado para gerenciamento de alarmes que é totalmente flexível e amigável. O software BRAlarmExpert é uma

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

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

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

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

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe: Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael

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

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

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

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20 Guia de utilização Índice Introdução... 3 O que é o sistema BlueTalk... 3 Quem vai utilizar?... 3 A utilização do BlueTalk pelo estagiário do Programa Acessa Escola... 5 A arquitetura do sistema BlueTalk...

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

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

PROVA DE NÍVEL SUPERIOR. CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO

PROVA DE NÍVEL SUPERIOR. CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO PROVA DE NÍVEL SUPERIOR CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO 1. O ambiente Delphi suporta o desenvolvimento de aplicações orientadas a objetos por meio da linguagem Object

Leia mais

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital. APÊNDICES A seguir são exibidos os documentos, formulários e questionários que contribuíram para a elaboração da tese, denominada: XDTv: um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

Leia mais

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

Leia mais

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE Modelo de Otimização de SAM Controle, otimize, cresça Em um mercado internacional em constante mudança, as empresas buscam oportunidades de ganhar vantagem competitiva

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

Como Criar uma Aula? Na página inicial do Portal do Professor, acesse ESPAÇO DA AULA: Ao entrar no ESPAÇO DA AULA, clique no ícone Criar Aula :

Como Criar uma Aula? Na página inicial do Portal do Professor, acesse ESPAÇO DA AULA: Ao entrar no ESPAÇO DA AULA, clique no ícone Criar Aula : Como Criar uma Aula? Para criar uma sugestão de aula é necessário que você já tenha se cadastrado no Portal do Professor. Para se cadastrar clique em Inscreva-se, localizado na primeira página do Portal.

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

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais