Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação

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

Download "Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação"

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Relato de Experiência Usando SCRUM e Protótipo Marcelo da Rocha Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Orientador Prof. Dr. Rodrigo Bonifácio de Almeida Brasília 2011

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Computação Licenciatura Coordenador: Prof. Dr. Homero Luiz Picolo Banca examinadora composta por: Prof. Dr. Rodrigo Bonifácio de Almeida (Orientador) CIC/UnB Prof. Dr. Genaina Nunes Rodrigues CIC/UnB Prof. Me. Hilmer Rodrigues Neri FGA/UnB CIP Catalogação Internacional na Publicação Santos, Marcelo da Rocha. Relato de Experiência Usando SCRUM e Protótipo / Marcelo da Rocha Santos. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Scrum, 2. Metodologia Ágil, 3. Gerência de Projetos, 4. Protótipo CDU Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Relato de Experiência Usando SCRUM e Protótipo Marcelo da Rocha Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Prof. Dr. Rodrigo Bonifácio de Almeida (Orientador) CIC/UnB Prof. Dr. Genaina Nunes Rodrigues CIC/UnB Prof. Me. Hilmer Rodrigues Neri FGA/UnB Prof. Dr. Homero Luiz Picolo Coordenador do Curso de Computação Licenciatura Brasília, 05 de junho de 2011

4 Dedicatória Ao meu avô Pedro da Rocha Machado (in memorian). i

5 Agradecimentos Agradeço a todos os que me ajudaram durante essa jornada. Aos meus pais, que sempre me apoiaram, mesmo quando escolhi um área de estudos que me levaria para longe deles. Ao meu bem, Taís de Sant Anna Machado por todo o apoio e incentivo ao longo do curso e especialmente durante este último semestre. Agradeço também aos amigos do Inep, local onde trabalho há 7 anos e onde elaborei o estudo de caso que deu origem a esse trabalho monográfico. E ao meu orientador, Rodrigo, pelo acompanhamento e apoio ao trabalho aqui apresentado. ii

6 Resumo Esta monografia consiste em um estudo de caso sobre a utilização de metodologias ágeis, aliado à adoção de protótipos como parte importante no levantamento de requisitos. Este estudo se deu entre os anos de 2008 a 2010, no Inep - Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira. A pesquisa bibliográfica foi feita sobre os três temas envolvidos nesse estudo de caso: a engenharia de requisitos, os protótipos e a metodologia ágil. Por fim temos a elaboração do estudo sobre a forma como se iniciou a utilização da metodologia ágil e dos protótipos dentro do órgão e quais foram os principais benefícios alcançados, bem como as customizações que foram necessárias para adaptar as metodologias à realidade do desenvolvimento de software numa instituição pública. Palavras-chave: Scrum, Metodologia Ágil, Gerência de Projetos, Protótipo iii

7 Abstract This monograph consists on a case study on the use of agile methodologies, with the adoption of prototypes as part s important in requirements gathering. This study took place between the years 2008 to 2010, at the INEP - National Institute of Educational Studies Anísio Teixeira. The theoretical research was done on the three issues involved in this case of study: requirements engineering, prototypes and agile. Finally, we have the survey about the way the institution started using the agile methodology and prototyping and what were the main bene?ts achieved, and the customizations that were necessary to adapt the methodology to the reality of the development of software in a public institution. Keywords: Scrum, Agile Methodology, Project Management, Prototype iv

8 Sumário 1 Introdução 1 2 Engenharia de requisitos Tipos de requisitos O levantamento de requisitos Prototipagem no processo de desenvolvimento de softwares Prototipação e objetivos Uso dos protótipos em testes Tipos de protótipos Quanto à reutilização e funcionalidades implementadas Quanto à fidelidade Quanto à abrangência de funcionalidades Protótipos Globais e locais Protótipo Storyboarding Protótipo em papel Mágico de Oz (Wizard of Oz) Benefícios e riscos Metodologia Ágil e Prototipagem Extreme Programming Scrum Características do Scrum Protótipos e Metodologias Ágeis Metodologia Ágil e Protótipos no Inep Situação anterior Implantação da Metodologia Ágil Resultados da implantação Referências 36 v

9 Lista de Figuras 2.1 Tipos de requisitos não funcionais (Sommerville (2007)) O processo de requisitos (Pfleeger (2004)) Curva de falhas para o software (Pressman (2006)) Caso de uso Processo de desenvolvimento de protótipos.(sommerville (2007)) Teste back-to-back (Sommerville (2007)) Exemplo de campos em um protótipo descartável Protótipo vertical x Protótipo Horizontal (Nielsen (1993)) Protótipo de cenário Protótipo em papel (Snyder (2003)) Processo de desenvolvimento iterativo Cartão CRC O processo Extreme Porgramming (Pressman (2006)) Formação Scrum no esporte Rugby Fluxo de processo do Scrum Pressman (2006) Gráfico de Burndown ( Kniberg (2007)) Protótipo não funcional Gráfido de BurnDown do Enem em Quadro do Scrum utilizado no Enem em Ocorrências em 2009, por nível de gravidade Ocorrências em 2011, por nível de gravidade vi

10 Lista de Tabelas 2.1 Métricas para especificar requisitos não funcionais (Sommerville (2007)) Princípios dos métodos ágeis vii

11 Capítulo 1 Introdução Uma falha no levantamento dos requisitos de um sistema pode ter grande impacto no software produzido. Temos à disposição várias formas distintas de levantar requisitos, desenvolver softwares e gerenciar projetos. Uma combinação adequada dessas formas pode garantir o sucesso de um projeto de desenvolvimento de software e a satisfação dos clientes e demais usuários. Nessa monografia apresentaremos o empenho do Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira - Inep - para implementar uma metodologia ágil de desenvolvimento, visando melhorias nos prazos de entrega e na qualidade dos softwares produzidos por sua Diretoria de Tecnologia e Disseminação de Informações Educacionais - DTDIE. Os softwares em questão utilizam a plataforma Web para coletar os dados de inscrições, divulgar locais de prova e resultados de exames como o ENEM (Exame Nacional do Ensino Médio), ENCCEJA (Exame Nacional para Certificação de Jovens e Adultos) e Prova Brasil. O total de usuários externos ao órgão atendidos por esses sistemas supera o número de 10 milhões de pessoas. O Inep é uma autarquia federal ligada ao Ministério da Educação, criada em 1937, que tem como missão promover pesquisas, estudos e avaliações do Sistema Educacional Brasileiro, visando dar subsídios à formulação e implantação de políticas públicas Inep (2011). O estudo de caso apresentado nessa monografia se deu entre os anos de 2008 e Durante esse período participamos da equipe que implantou o modelo de desenvolvimento aqui apresentado, de forma pioneira. No início do ano de 2008, o Inep desenvolvia seus sistemas utilizando o modelo Cascata. Esse modelo vinha atendendo até então, e, juntamente com a contratação externa de soluções de softwares, atendiam suficientemente a necessidade de sistemas de informação do órgão. No entanto, no referido ano, outras necessidades de desenvolvimento de softwares surgiram. Uma parte dessas necessidades ocorreu devido à difícil manutenção dos sistemas existentes. Esses sistemas utilizavam a estrutura cliente-servidor e precisavam se adaptar à nova realidade: a plataforma web. Outro motivo para o crescimento da quantidade de sistemas a serem desenvolvidos foi a ampliação do número de participantes dos exames administrados pelo instituto. Em 2009, as inscrições do Enem, por exemplo, passaram a ser efetuadas apenas via Internet. Dessa forma, o número de pessoas que utilizava o sistema de inscrição passou de 1,5 milhões para 4,8 milhões. Com todo esse acréscimo de necessidade de atendimento a DTDIE percebeu que precisava alterar o seu modelo de gestão de projetos e de desenvolvimento dos softwares. A metodologia ágil, então, foi escolhida como uma possível solução para 1

12 garantir que o desenvolvimento dos sistemas ocorresse dentro do prazo e com a qualidade necessária. O principal objetivo dessa monografia é apresentarmos a implantação da metodologia ágil dentro do Inep e demonstrarmos algumas alterações feitas na metodologia para melhor adaptação a características do órgão. Será apresentada a utilização dos protótipos como parte da documentação utilizada para levantamento de requisitos, sua utilização na fase de testes e na homologação dos sistemas. Desta forma demonstramos, através de um caso real, é que a utilização de protótipos no levantamento de requisitos para projetos que são administrados e desenvolvidos utilizando metodologia ágil tende a melhorar a qualidade do software produzido e reduzir a incidência de ocorrências de maior gravidade durante os testes, garantindo assim a satisfação dos envolvidos no projeto e dos usuários finais do sistema. Para tanto, o trabalho foi organizado em quatro partes: 1. No capítulo dois serão apresentados conceitos sobre a Engenharia de requisitos, apontando os tipos de requisitos e as formas de levantamento dos mesmos. 2. No terceiro capítulo apresentamos uma revisão bibliográfica sobre protótipos, suas classificações e usos, além dos objetivos de se utilizar. 3. O quarto capítulo é formado por duas partes: as metodologias ágeis de desenvolvimento de sistema e gerência de projetos e como os protótipos estão inseridos nesse contexto. 4. Por fim, apresentaremos o estudo de caso sobre a adoção da metodologia ágil no Inep e como a utilização dos protótipos foi importante para melhoria na qualidade dos softwares produzidos. 2

13 Capítulo 2 Engenharia de requisitos O desenvolvimento de softwares se inicia a partir do levantamento dos requisitos. Através deles podemos entender melhor qual o problema que deve ser resolvido através de um sistema ou mesmo quais os fatores que levam à necessidade de substituição de um já existente. Os clientes, que são os principais Stakeholders, têm em mente uma ideia do que desejam do sistema, e cabe ao analista transformar essa necessidade em requisitos. De maneira detalhada, Stakeholder é o termo usado para denominar a pessoa ou grupo de pessoas que são afetadas pelo sistema (Sommerville (2007)), e entende-se por requisito as características do sistema ou descrições de suas finalidades, incluindo tudo que ele é capaz de realizar para atender os anseios daquele que o idealizou Pfleeger (2004). 2.1 Tipos de requisitos O termo requisito é utilizado de maneira muito livre pela indústria de software. Para alguns é aceitável que ele possua um nível abstrato de definição. Para outros é necessário que seja uma definição formal e detalhada de cada uma das funções do sistema. Existe ainda a possibilidade de utilizar-se de ambos os tipos de requisitos, como por exemplo para a contratação do desenvolvimento de um software. Num primeiro momento, para possibilitar uma maior concorrência pode-se estabelecer apenas as diretrizes gerais do sistema. Após a escolha da empresa que desenvolverá o sistema os requisitos podem ser melhor detalhados. Os requisitos, segundo Sommerville (2007), podem ser classificados em: Requisitos de usuário: declarações em linguagem natural das necessidades que deverão ser supridas pelo sistema. Esses requisitos devem especificar, preferencialmente, apenas o comportamento externo do sistema, desta forma evitando interferir no projeto do software. Para escrever requisitos de usuário não é indicada a utilização de termos muito técnicos. Eles devem ser escritos da forma mais simples e intuitiva possível, tomando o máximo cuidado para que o documento seja claro, os requisitos bem diferenciados e destacados. Sommerville (2007) indica que se crie e/ou adote um padrão para levantamento desses requisitos. A padronização facilita a redução na quantidade de erros. 3

14 Requisitos de sistema: definem mais detalhadamente as funções, serviços e até mesmo as restrições. Deve ser um documento preciso e definir exatamente o que deverá ser implementado. A rigor tratam-se de uma versão expandida dos requisitos de usuário, que serão usados para projetar o sistema. Possui termos mais técnicos e maiores informações sobre o fluxo do sistema. Essa especificação pode ser utilizada para contratação do desenvolvimento do sistema, o que leva geralmente a ser feita antes do início do projeto. A existência de documentos com diferentes níveis de detalhamento das funcionalidades pode ser útil para a comunicação com diferentes tipos de leitores. Por exemplo, um documento pode ser apresentado ao contratante e outro ao stakeholder que utilizará mais diretamente o sistema. Requisitos funcionais são serviços ou funcionalidades que o sistema deverá oferecer. Em alguns casos esse tipo de requisito pode também ser utilizado para explicar o que não será atendido pelo sistema. Como exemplo podemos citar um sistema que faça o trâmite de documentos dentro de um escritório, mas que não será responsável pelo processo de digitalização dos mesmos. Esse tipo de requisito depende do tipo de sistema, dos Stakeholders e principalmente da orientação geral do desenvolvimento do sistema. Os requisitos funcionais podem expressar os do usuário, no entanto de maneira mais detalhada. As entradas, saídas e os processos internos do software devem fazer parte desse tipo de requisito. Requisitos não funcionais são restrições gerais sobre o sistema. Geralmente se aplicam ao sistema como um todo e podem estar relacionadas a propriedades necessárias, como por exemplo, sua segurança, disponibilidade e tempo de resposta. Podem também expressar restrições dos sistemas que não dizem respeito à sua implementação em si. É o caso da capacidade de processamento do hardware utilizado para suporte ao sistema, ou mesmo da velocidade de rede do ambiente onde o sistema estará disponível. Esses requisitos podem ter grande influência sobre o custo final do sistema. A produção de um sistema crítico, com alta disponibilidade e velocidade de processamento extrema, que é uma necessidade crescente do mundo atual, podem tornar o desenvolvimento do sistema mais complexo e interferir na escolha da linguagem e das ferramentas que serão utilizadas durante seu desenvolvimento. Desta forma os requisitos não funcionais podem estar ligados às restrições orçamentárias, ou até mesmo às necessidades de interoperação entre sistemas. Sommerville (2007) classifica os requisitos não funcionais em tipos. Esses tipos são apresentados na figura 2.1. Mais detalhadamente os grandes grupos de requisitos não-funcionais são: 1. De produto: dizem respeito ao comportamento do produto, como por exemplo, sua velocidade e a memória que será utilizada. Além disso, devem orientar o desenvolvimento do sistema quanto às necessidades de usabilidade, eficiência, confiabilidade e portabilidade, quando necessário. 4

15 Figura 2.1: Tipos de requisitos não funcionais (Sommerville (2007)). 2. Organizacionais: são produtos das políticas e procedimentos das organizações. Esses procedimentos são referentes, principalmente, aos padrões de desenvolvimento, procedimentos de implantação e/ou entrega de sistemas. 3. Externos: são as restrições referentes à interoperabilidade, às questões referentes à ética ou mesmo referentes ao aspecto legal do sistema. Os requisitos não funcionais, geralmente, são de difícil verificação, pois são definidos de maneira genérica em alguns casos. Por exemplo é difícil medir a usabilidade de um sistema. Uma forma de tentar resolver esse problema é se criando metas conforme representado na tabela 2.1 (Sommerville (2007)). 2.2 O levantamento de requisitos Pfleeger (2004) divide o processo de levantamento de requisitos em quatro etapas, conforme figura 2.2. Desta maneira, no primeiro momento, tem-se a análise do problema, iniciada com o trabalho de questionar os Stakeholders quanto às suas necessidades. Quando possível é importante mostrar as soluções já existentes, sistemas que atendem a necessidades similares produzidos anteriormente. Este trabalho de compreensão das necessidades possibilita uma visão mais acurada do problema que deverá ser resolvido. Posteriormente, é necessário descrever o entendimento do analista sobre o problema exposto. Este momento é importante para evitarmos descompassos no entendimento da questão a ser solucionada. De modo análogo, vale também analisar se estamos observando 5

16 Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade Medida Transações processadas por segundo Tempo de resposta de usuário para cada evento do sistema Tempo de demora para atualização de tela Medidas de armazenagem Número de chips de RAM Tempo necessário para treinamento de novos usuários Quantidade de opções de ajuda existentes no sistema Tempo médio das falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade do sistema Tempo para voltar à disponibilidade após uma falha. Probabilidade de corrupção de dados por falha Percentual de eventos que causam falhas O quanto o software depende do sistema operacional Quantidade de sistemas operacionais em que funciona. Tabela 2.1: Métricas para especificar requisitos não funcionais (Sommerville (2007)). o problema do ponto de vista correto. Caso sejam muitos os Stakeholders envolvidos no projeto, provavelmente será necessária a realização de uma reunião conjunta para uma melhor compreensão das várias necessidades e equalização dos diversos pontos de vista. Por mais preparada que seja a equipe que desenvolverá o sistema, caso os requisitos não sejam bem levantados ou os mesmos sejam ambíguos, ou ainda existam falhas no entendimento das necessidades, o projeto de software poderá passar por sérios problemas, muitas vezes podendo inclusive ser abandonado. Pressman (2006) indica que modificações nos requisitos dos sistemas trazem consigo um grande aumento na incidência de falhas na implementação do software. Para ilustrar tal fato, elaborou o gráfico presente na figura 2.3. Na tentativa de diminuir a incidência de modificações de requisitos, tem-se a terceira etapa do processo de requisitos, a prototipação. Para Pressman (2006) a prototipação ou prototipagem é: [...] um processo que capacita o desenvolvedor a criar um modelo do software que será implementado. Este modelo pode assumir uma das seguintes formas: 1. Um protótipo em papel ou um modelo baseado em PC que retrata a interação homem-máquina de uma forma que capacita o usuário a entender quanta interação ocorrerá; 2. Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado; ou 3. Um programa existente que executa parte ou toda a função desejada, mas que tem características que serão melhoradas num novo esforço de desenvolvimento. 6

17 Figura 2.2: O processo de requisitos (Pfleeger (2004)). Figura 2.3: Curva de falhas para o software (Pressman (2006)). Outro conceito é aquele proposto por Bahn e Nauman (Bahn e Nauman, 1997, apud Lopez (2003)), que entendem protótipo como um processo de construção e avaliação do modelo de funcionamento de um sistema. Esse processo tem como finalidade auxiliar na aprendizagem de alguns aspectos dos requisitos do sistema e/ou suas potenciais soluções. Os benefícios da prototipação foram descritos por Gordon e Bieman e citados por Sommerville, em seu livro Engenharia de Software (Gordon e Bieman, 1995, apud Sommerville (2007)): 1. Usabilidade aprimorada do sistema 2. Adequação maior do sistema às necessidades do usuário 3. Qualidade do projeto final aprimorada 4. Facilidade de manutenção aprimorada 7

18 5. Esboço de desenvolvimento reduzido Como o trabalho se refere ao uso de protótipos na Engenharia de Requisitos, este assunto será abordado com maior profundidade no próximo capítulo. A quarta e última etapa se ocupa da definição e especificação dos requisitos, a partir da documentação e validação. Para facilitar o entendimento dos requisitos do sistema podemos gerar a documentação de diversas formas. Algumas incluem documentos extensos que descrevem cenários de utilização para todas as etapas e possibilidades de uso do sistema. São os denominados Casos de Uso, que são característica fundamental da UML (Unified Modeling Language).(Booch et al. (2000)) Em alguns ambientes de trabalho os Casos de Uso têm também a função de estabelecer um compromisso entre o Stakeholder e a equipe responsável pelo desenvolvimento. No entanto, algumas vezes o documento pode ser de difícil leitura por pessoas que não estão familiarizadas com seu formato e suas características, caso da maioria dos Stakeholders. Um caso de uso bem estruturado tem de conter pelo menos os seguintes fluxos (Larman (2007)): 1. Fluxo de eventos principal: contém o caminho comum a todos usuários do sistema. 2. Fluxo de eventos alternativos: contém os caminhos alternativos do sistema, que podem ou não ser apresentados para os usuários. 3. Fluxo de exceção: contém, principalmente o comportamento do sistema quando ocorre alguma exceção no fluxo de utilização do sistema. É o fluxo responsável pelo tratamento dos erros. A UML prevê o Diagrama de Casos de Uso como um agrupador das funções que os atores têm dentro do sistema. A categoria ator é utilizada para representar os papéis que os usuários desempenham quando interagem com os casos de uso. (Booch et al. (2000)) Os atores e casos de uso são representados conforme figura 2.4. Figura 2.4: Caso de uso Outros documentos utilizados no desenvolvimento do sistema, como o Modelo de Dados ou a Estrutura Analítica do Projeto também geram muitas dúvidas se forem apresentados aos Stakeholders. A dificuldade força, na maioria das vezes, a explicação detalhada 8

19 do documento em si pelos Analistas de Requisitos. Isto prejudica o verdadeiro foco dos encontros: o levantamento dos requisitos para construção do sistema. Um documento de especificação de requisitos bem elaborado evita problemas na etapa da validação do sistema, uma vez que tem de ser aceito ou não pelo usuário. Nos próximos capítulos, serão descritos o processo de prototipagem e os tipos de protótipo, para entender de que modo a utilização destes modelos pode auxiliar no levantamento de requisitos e na produção de documentos na Metodologia Ágil. 9

20 Capítulo 3 Prototipagem no processo de desenvolvimento de softwares Quando se pretende construir um imóvel, ou mesmo efetuar uma reforma em algum já pronto, é certo não se iniciar sem antes se ter uma idéia de como ficará a construção. Para permitir que o cliente saiba aproximadamente como ficará a sua obra, os engenheiros e arquitetos utilizam plantas e maquetes. Com base nessas plantas e maquetes, o cliente então passa a conhecer e poder solicitar mudanças no planejamento da obra, na posição dos quartos ou no tamanho da sala, por exemplo. De maneira análoga o uso de protótipos no desenvolvimento de softwares permite aos stakeholders visualizar desde o antes do início do desenvolvimento como o sistema ficará quando completamente desenvolvido. O uso da prototipagem no desenvolvimento de softwares pode ir mais além. Engenheiros e arquitetos provavelmente não poderão, sem um gasto elevado, ou a utilização de outras tecnologias, propiciar aos seus clientes a sensação de estarem em sua sala de estar no segundo andar, antes mesmo do primeiro andar estar pronto. O uso dos protótipos no desenvolvimento de softwares permite que os stakeholders possam, por exemplo, verificar como ficarão os seus relatórios antes mesmo da interface de captação dos dados estar pronta. A prototipagem pode ser vista como uma técnica que permite a validação, avaliação e demonstração da interface de um software que será desenvolvido, dando suporte às iterações rápidas e ao esclarecimento de dúvidas restantes do levantamento de requisitos. Podemos utilizar diversas ferramentas diferentes para desenvolver os protótipos. Muitas vezes a tecnologia utilizada no seu desenvolvimento difere da utilizada no desenvolvimento do sistema em si. Exemplos de tecnologias que podem ser utilizadas na prototipagem (Frank et al. (1995)): HTML - Hyper Text Markup Language Papel e caneta JSP - Java Server Pages ASP.NET CSS - Cascading Style Sheets Editores de imagem 10

21 Como exemplo prático da utilização de diferentes tecnologias nas etapas de desenvolvimento e prototipagem podemos citar a utilização de papel e caneta para o desenvolvimento do protótipo, e de qualquer linguagem de programação para desenvolvimento do sistema. Essa liberdade torna o processo de prototipagem de fácil inserção nas diferentes metodologias de desenvolvimento, sendo possível inclusive escolher qual a tecnologia deve ser utilizada em cada fase do desenvolvimento do sistema. Na fase inicial pode ser interessante utilizar um protótipo em linguagem de programação, como forma de adiantar o andamento do projeto, possibilitando uma reutilização do protótipo. Ou, nesta mesma fase pode se optar por tecnologias que tornem a prototipação mais rápida, como a utilização de editores de imagem. 3.1 Prototipação e objetivos Um modelo de processo para o desenvolvimento de protótipos funcionais foi definido por Sommerville (2007) e é apresentado na figura 3.1. Figura 3.1: Processo de desenvolvimento de protótipos.(sommerville (2007)). Os objetivos da prototipação devem ser definidos: a validação da interface com o usuário, um estudo da viabiliade do desenvolvimento da aplicação ou a validação dos requisitos são algumas das possibilidades. É possível ainda abranger todos esses objetivos com um único protótipo. Posteriormente, é necessário definir o que será implementado e o que não será implementado no protótipo. É importante que o desenvolvimento do protótipo não adicione custos muitos altos ao processo de desenvolvimento do sistema. Da mesma maneira, o seu desenvolvimento não deve consumir muito tempo da equipe. Por último, para que a avaliação seja feita adequadamente, é necessário que o usuário tenha tempo para validar o protótipo. Uma validação feita apressadamente pode esconder falhas no levantamento dos requisitos ou na simulação da atividade a qual se destina o software. A utilização dos protótipos possibilita ao Stakeholder, desde o princípio do desenvolvimento do sistema, poder validar as entradas de dados e o posicionamento dos campos nas telas, entre outros detalhes. Estabelece-se, assim, uma relação de cumplicidade entre o stakeholder e a equipe de desenvolvimento, devido à compreensão mais real dos requisitos levantados e do sistema que será produzido a partir destes. Além disso, as reuniões de apresentação dos protótipos servem para dar a sensação de que o projeto está evoluindo, em contraposição ao sentimento de isolamento experimentado quando o projeto só é visto meses após sua especificação inicial. 11

22 Esta utilização de protótipos, aliada à adoção de entregas parciais, contribuem em muito para a redução dos gastos referentes às alterações feitas nos softwares após a sua entrega final. O risco envolvido na entrega de um sistema cuja interface só será conhecida quando o desenvolvimento já estiver concluído é alto, pois além da possibilidade da interface desenvolvida não agradar, os stakeholders podem mudar de opinião com o tempo, e neste caso já não gostarem da solução que foi planejada no começo da jornada de desenvolvimento. Esse descontentamento poderá se tornar irreversível, fazendo o software desenvolvido não ser utilizado. Atualmente, não basta ao sistema executar a função para qual foi desenvolvido. É necessário que ele tenha uma interface amigável e intuitiva. O desenvolvimento das interfaces representa 48% do código do software e 1/3 do esforço de revisão do sistema após sua entrega (Nielsen (1993)). Desta maneira, quanto mais próxima estiver a interface da necessidade do cliente, maior a chance de obtermos uma redução no esforço de revisão. 3.2 Uso dos protótipos em testes A utilização dos protótipos vai além da validação dos requisitos. Eles podem também serem utilizados nas etapas de teste e para realizar experimentos, que possibilitem o estudo da viabilidade do projeto proposto. No caso da utilização para testes, os protótipos auxiliam na resolução de um dos maiores problemas destes: validar os resultados e respostas enviadas pelo sistema. Podemos utilizar os protótipos para realização de testes back-to-back, comparando as respostas do sistema com os protótipos do mesmo e gerando-se relatórios de diferenças. Essa utilização facilita a homologação com o cliente final, visto que a própria equipe envolvida no desenvolvimento do sistema, de posse dos protótipos aprovados pelos stakeholders pode adiantar a homologação do sistema, percebendo diferenças entre os protótipos e o software desenvolvido. Nesse caso, aliada à facilitação dos testes em si, a utilização dos protótipos pode evitar desgastes desnecessários junto aos clientes. Sommerville (2007) ilustra o teste back-to-back conforme descrito na figura Tipos de protótipos Quanto à reutilização e funcionalidades implementadas Quanto à possibilidade de reutilização, Pfleeger (2004) define protótipos de requisitos da seguinte maneira: 1. Protótipos descartáveis (throw-away): tem caráter exploratório e são utilizados para se aprender mais sobre o problema que se pretende resolver ou para explorar a viabilidade das possíveis soluções para o mesmo. Podem ser apresentados em papel ou mesmo em formado digital, mas não permitem a interação do usuário. Pode ser utilizado apenas no início do desenvolvimento dos protótipos, pois é de mais rápido desenvolvimento e de baixo custo, ou como único tipo de protótipo. O protótipo descartável retratado na figura 3.3 foi desenvolvido em um editor de imagens. 12

23 Figura 3.2: Teste back-to-back (Sommerville (2007)). Figura 3.3: Exemplo de campos em um protótipo descartável Uma das vantagens deste tipo de protótipo é a sua rápida criação. Além disso, já que a sua função principal não é demonstrar interface ao usuário, a atenção durante sua criação recai somente sobre as funcionalidades do sistema, deixando em segundo plano a interface do mesmo. Os protótipos não funcionais facilitam o entendimento durante um encontro de levantamento de requisito e devem ser utilizados quando lidamos com stakeholders muito ocupados ou impacientes. Esse protótipo após apresentado é descartado, não sendo utilizado como parte do software final. Pode ser utilizando, por exemplo, quando o ciclo de entregas ou o prazo de desenvolvimento do projeto são curtos. As funcionalidades, navegação e interfaces, serão apresentadas nas entregas parciais sequentes. 2. Protótipos evolutivos: permitem navegação no sistema, dando ao usuário a sensação de estar realmente utilizando um software totalmente implementado. Esse tipo de 13

24 protótipo permite acessar as páginas do sistema e simular a sua interação com o mesmo. Têm como principal vantagem a simulação mais real do que será construído. O cliente pode então opinar na sequência de páginas (quando existirem), no posicionamento dos botões e até nas cores do sistema, validando desta maneira toda a interface humano-computador. Pode ser reutilizado posteriormente no desenvolvimento do sistema. Aplica-se a partes do projeto sobre as quais o cliente apresenta dúvidas, relativas principalmente a interface e o fluxo. Por exemplo, caso o cliente tenha dúvidas sobre a utilização de uma combo-box ou um check-box, protótipos evolutivos podem ser apresentados e o aprovado incorporado no projeto Quanto à fidelidade A fidelidade de um protótipo pode ser avaliada em quatro dimensões: (Mayhew (1999) appud dos Santos (2006)) 1. Detalhamento: a quantidade de detalhes que o modelo suporta. Um protótipo feito com papel e caneta, por exemplo suporta menos detalhes que um desenvolvido em software. 2. Funcionalidades: o quanto o protótipo possui de operações implementadas. 3. Similaridade de interação: o quanto a interação do usuário com o protótipo se assemelha com a do software final. 4. Estética: o quanto a interface gráfica utilizada é parecida com a do software final. Os protótipos podem ser de baixa ou alta fidelidade. Essa separação é criada avaliandose os protótipos conforme citado acima. Protótipos de alta fidelidade São os protótipos que se assemelham em muito ao produto final. Para esse tipo de protótipo recomenda-se a utilização da mesma linguagem que será utilizada no sistema final uma vez que sua reutilização no desenvolvimento do sistema é comum. A utilização da mesma linguagem, no entanto, muitas vezes pode não ser possível, devido a critérios como tempo necessário ou mesmo priorização do desenvolvimento de outros módulos do sistema, que já possuem requisitos levantados e aprovados. Indica-se sua utilização quando o objetivo é a venda de um sistema ou o teste quanto a problemas técnicos (da Cunha (2007)). Essa recomendação se dá por ser o tipo de protótipo que mais se aproxima do sistema que será desenvolvido. Portanto ao apresentálo durante um processo de venda, o cliente terá a sua disposição uma visão próxima do produto final. Como vantagens do uso de protótipos de alta fidelidade temos: 1. Funcionalidades completas. 2. Acesso do usuário ao protótipo diretamente. 14

25 3. Navegação completa no sistema. 4. Exploração e teste do sistema. 5. Utiliazação como ferramenta de venda e marketing. 6. Especificação do sistema de forma interativa. Como desvantagens podemos citar: 1. Elevado investimento de tempo para desenvolvimento. 2. Elevado investimento financeiro para desenvolvimento. 3. Ineficiente para provas de conceito. 4. Ineficaz para aquisição de novos requisitos. 5. Aparência de software pronto, o que pode gerar falsas expectativas nos clientes. Protótipos de baixa fidelidade Sua função principal é elucidar novos requisitos do sistema. Possuem um tempo de vida muito curtos, sendo possível modificá-los muito rapidamente durante seu desenvolvimento.(medeiros et al. (2008)) Como vantagens da sua utilização podemos citar: 1. Custos mais baixos. 2. Vários conceitos de design podem ser implementados. 3. Rápido desenvolvimento. 4. Identificação de requisitos de mercado. 5. Pode ser utilizado como prova de conceito. As seguintes desvantagens podem ser listadas: 1. Especificação de código fraca. 2. Verificação de erros limitada. 3. Pouca utilidade após fase de requisitos. 4. Pouco útil para testes de usabilidade. 5. Limitações de fluxo e navegação Quanto à abrangência de funcionalidades Os protótipos podem ser também classificados de acordo com sua abrangência, conforme figura

26 Figura 3.4: Protótipo vertical x Protótipo Horizontal (Nielsen (1993)). 1. Protótipo vertical: Contém poucas das funcionalidades do sistema, implementadas com maior profundidade. Esse protótipo é, na maioria das vezes, reutilizado no desenvolvimento da solução final. Por conter toda a implementação de uma função do sistema, esse tipo de protótipo deve ser utilizado em pontos críticos, onde existe maior dificuldade no entendimento na especificação dos requisitos ou ainda para avaliar soluções de softwares possíveis. 2. Protótipo horizontal: Contém todas as funções do sistema, implementadas apenas na camada de interface. Esse protótipo é usado para simulação da interface e identificação de possíveis funcionalidades que não tiveram seus requisitos levantados. Geralmente são protótipos descartáveis, visto que podem ser desenvolvidos em outra linguagem, diferente da utilizada no sistema ou mesmo feito em papel. Existe ainda uma terceira abordagem, apontada por Dumas and Redish (1994) que propõe uma área de intersecção, denominada protótipo de cenário (Nielsen and Mack (1994)). Esse tipo de protótipo é orientado à tarefa, sendo implementado apenas em camada de apresentação, em algumas partes, e com maior profundidade, quando se busca solucionar o entendimento de determinada função do sistema ou ainda demonstrar os caminhos possíveis. Dumas e Redish propuseram uma nova representação, aqui apresentada pela figura 3.5, para ilustrar esse tipo de protótipo, modificando a anteriormente publicada por Nielsen (1993) Protótipos Globais e locais Para finalizar a classificação dos protótipos, eles podem também serem classificados em Globais e Locais. Essa classificação se assemelha com a classificação em Horizontal e Vertical. Os protótipos globais abrangem todas as funcionalidades do sistema. A diferença para entre o protótipo global e o horizontal é que no primeiro caso podem haver diferentes níveis de implantação em cada parte do sistema. O protótipo local tem como objetivo tratar de detalhes objetivos do sistema, não necessariamente sendo necessária a implementação em profundidade da solução, como no protótipo vertical. O protótipo 16

27 Figura 3.5: Protótipo de cenário local também costuma ser utilizado por pouco tempo, sendo descartado após a solução do problema Protótipo Storyboarding Trata-se de uma técnica que expressa o comportamento do sistema, projeto ou intenção de implementação baseando-se na perspectiva do usuário através da utilização de imagens. Esta técnica foi utilizada no cinema e em desenhos animados, por poder representar um esboço dos personagens e da história (Gonçalves et al. (2005)). O storyboarding é um tipo de protótipo de baixa fidelidade que pode ser classificado em (Leffingwell and Widrig (2003) appud Gonçalves et al. (2005)): Passivo: São constituídos de quadros, fotos, esboços, etc. Neste caso são apresentadas ao usuário as regras do sistema em sua sequência, com uma explanação do tipo Quando você faz isto, acontece isto ; Ativo: Corresponde a uma sequência de figuras que mostram uma descrição automatizada do modo como o sistema se comporta em um uso típico ou em um cenário operacional, por exemplo, em uma apresentação automática de slides; Interativo: Permite ao usuário interagir sobre o sistema de um modo mais realístico, exigindo sua participação. Pode ser uma simulação dos possíveis cenários (protótipo não-funcional), ou mesmo um protótipo funcional simplificado do sistema. 17

28 3.3.6 Protótipo em papel Segundo Snyder (2003), protótipos em papel é um método amplamente utilizado para desenho de interface, testes e ajustes juntamente aos usuários. No início dos anos 1990 era um método pouco conhecido pela maioria das equipes de desenvolvimento de software. É notavelmente o meio mais simples e rápido de se construir um protótipo visto que utiliza materiais simples, como papel, lápis e régua, para desenhar a interface humanocomputador. Após desenhados os protótipos pode-se demonstrá-los aos stakeholders e efetuar os ajustes e correções necessárias rapidamente. Snyder (2003) considera essa técnica de protótipação como um método de criação, um brainstorming. No entanto para tarefas de prototipagem que envolvam muitas telas esse processo pode se tornar cansativo, tornando latente a necessidade de utilização de ferramentas automatizadas. Figura 3.6: Protótipo em papel (Snyder (2003)) Mágico de Oz (Wizard of Oz ) Essa técnica de prototipagem utiliza um operador humano (o mágico de Oz) para simular o comportamento do software, processando e simulando a resposta do software. É uma prototipagem barata, pois somente a interface do sistema precisa estar desenvolvida. A pessoa que opera o sistema pode ser ou não exibida ao usuário, pois podemos utilizar ferramentas de controle a distância para controlar o computador. Essa técnica é indicada quando se pretende incluir no sistema funcionalidade complexas ou avaliar idéias mais inovadoras de design (de Souza Coutinho (2006)). 18

Engenharia de Software I

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

Leia mais

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

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

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

Leia mais

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

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

Leia mais

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

Desenvolvimento de Interfaces Prototipação

Desenvolvimento de Interfaces Prototipação Autarquia Educacional do Vale do São Francisco AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Centro de Engenharia e Ciências Tecnológicas CECT Curso de Ciência da Computação Desenvolvimento

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

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

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

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

Leia mais

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira LEVANTAMENTO DE REQUISITOS Lílian Simão Oliveira Níveis de erros Fonte: imaster.com um software São as características e funcionalidades que um software tem Engenharia de Requisitos O que é? Quem faz?

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

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

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

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

Leia mais

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

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

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

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

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

Modelos de processos de desenvolvimento de software

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

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA ELABORAÇÃO DE AVALIAÇÕES DE ENSINO UTILIZANDO NOVAS ABORDAGENS DE DESENVOLVIMENTO

DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA ELABORAÇÃO DE AVALIAÇÕES DE ENSINO UTILIZANDO NOVAS ABORDAGENS DE DESENVOLVIMENTO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA ELABORAÇÃO DE AVALIAÇÕES DE ENSINO UTILIZANDO NOVAS ABORDAGENS DE DESENVOLVIMENTO Danilo Damaceno Lima 1 NIPETI 2 - Instituto Federal de Mato Grosso do Sul (IFMS),

Leia mais

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 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

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

Leia mais

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

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

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

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais Objetivos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

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

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

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

DESAFIO ETAPA 1 Passo 1

DESAFIO ETAPA 1 Passo 1 DESAFIO Um dos maiores avanços percebidos pela área de qualidade de software foi comprovar que a qualidade de um produto final (software) é uma consequência do processo pelo qual esse software foi desenvolvido.

Leia mais

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

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

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

EXIN Agile Scrum Fundamentos

EXIN Agile Scrum Fundamentos Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada

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

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

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

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

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

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

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

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

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Roberto Costa Araujo Orientador: Cristiano T. Galina Sistemas de Informação Universidade do Vale do Rio dos Sinos

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

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

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

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

Leia mais

Guia Projectlab para Métodos Agéis

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

Leia mais

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação

ITIL na Prática. Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação ITIL na Prática Quais são os fatores críticos de sucesso para obter valor a partir de um Service Desk? Conhecimento em Tecnologia da Informação 2010 Bridge Consulting

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

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

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA O Impacto da Engenharia de Requisitos no Processo de Métricas Fátima Cesarino CAIXA Apresentação Diferentes Cenários Desenvolvimento Software Importância do SISP Agradecimento Oportunidade Responsabilidade

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

Géssica Talita. Márcia Verônica. Prof.: Edmilson

Géssica Talita. Márcia Verônica. Prof.: Edmilson Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO MP1 DATA 05/03/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

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

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

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

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente

Leia mais

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

Leia mais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais 2 Jogos Educacionais Jogos estão presentes como uma prática habitual, eles tem sido concebidos como uma atividade lúdica que é bastante motivadora no processo de ensinoaprendizado. É assim que jogos educacionais

Leia mais

APOO Análise e Projeto Orientado a Objetos. Requisitos

APOO Análise e Projeto Orientado a Objetos. Requisitos + APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

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

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

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

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

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

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

Leia mais

Pesquisa de perfis de empresas do interior de São Paulo, cidade de Ribeirão Preto, que utilizam a Dívida Técnica do Scrum e de como o fazem uso

Pesquisa de perfis de empresas do interior de São Paulo, cidade de Ribeirão Preto, que utilizam a Dívida Técnica do Scrum e de como o fazem uso 2011 Pesquisa de perfis de empresas do interior de São Paulo, cidade de Ribeirão Preto, que utilizam a Dívida Técnica do Scrum e de como o fazem uso Arthur Gera Orientador Profº Marcos Danilo Chiodi Martins

Leia mais

ENG1000 Introdução à Engenharia

ENG1000 Introdução à Engenharia ENG1000 Introdução à Engenharia Aula 01 Processo de Desenvolvimento de Software Edirlei Soares de Lima Processo de Software O processo de software consiste em um conjunto estruturado

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

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

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

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

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

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

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis

Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Requisitos para Gestão de Requisitos no Desenvolvimento de Software que Utilizam Prática Ágeis Abstract. Resumo. 1. Introdução Vinicius A. C. de Abreu 1 Departamento de Ciência da Computação - DCC Universidade

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

Especialização em Engenharia de Software e Banco de Dados

Especialização em Engenharia de Software e Banco de Dados Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Metodologias Ágeis Prof. Rodolfo Miranda de Barros rodolfo@uel.br O que é agilidade? Agilidade: Rapidez,

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

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

Modelos de Sistemas Casos de Uso

Modelos de Sistemas Casos de Uso Modelos de Sistemas Casos de Uso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2000 Slide 1 Casos de Uso Objetivos Principais dos Casos de Uso: Delimitação do contexto de

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

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

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

Leia mais

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

PROTOTIPAÇÃO DE INTERFACES: REDUZINDO CUSTOS E MELHORANDO O PROJETO

PROTOTIPAÇÃO DE INTERFACES: REDUZINDO CUSTOS E MELHORANDO O PROJETO 1 PROTOTIPAÇÃO DE INTERFACES: REDUZINDO CUSTOS E MELHORANDO O PROJETO BASSO, Thiago 1 SAKAGUTI, Solange Tieko 2 RESUMO: Este artigo tem como motivação destacar a importância da confecção de protótipos

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 3: Gerenciamento da Qualidade, dos Recursos

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

Expresso Livre Módulo de Projetos Ágeis

Expresso Livre Módulo de Projetos Ágeis Expresso Livre Módulo de Projetos Ágeis Desenvolvedor / Orientador Rafael Raymundo da Silva Guilherme Lacerda Out / 2010 1 Sumário 1.Conhecendo a ferramenta...3 2.Gerência de projetos ágeis...3 2.1Product

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

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