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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leia mais

Metodologias Á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

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 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

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

Introdução ao OpenUP (Open Unified Process)

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

Leia mais

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

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

Leia mais

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

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

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

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

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

Tipos de teste de software

Tipos de teste de software Tipos de teste de software Volnys Borges Bernal volnys@lsi.usp.br Adilson Hira ayhira@lsi.usp.br Laboratório de Sistemas Integráveis Departamento de Sistemas Eletrônicos Escola Politécnica da USP Sumário

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. 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

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

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

Levantamento, Análise e Gestão Requisitos. Aula 06

Levantamento, Análise e Gestão Requisitos. Aula 06 Levantamento, Análise e Gestão Requisitos Aula 06 Agenda Técnicas de Levantamento de Requisitos: Entrevista Workshop, Brainstorming, Storyboarding e Roleplaying Prototipação JAD Joint Application Design

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

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

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

Engenharia de Sistemas de Computador

Engenharia de Sistemas de Computador Engenharia de Sistemas de Computador Sistema é um conjunto ou disposição de elementos que é organizado para executar certo método, procedimento ou controle ao processar informações. Assim, o que é um Sistema????????

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

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

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

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

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

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

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

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT Disciplina: Modelagem a Programação Orientada a Objetos

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

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

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

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

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

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

Leia mais

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello Unidade II GERENCIAMENTO DE SISTEMAS DE INFORMAÇÃO Prof. Roberto Marcello SI Sistemas de gestão A Gestão dos Sistemas Integrados é uma forma organizada e sistemática de buscar a melhoria de resultados.

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

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 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

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

O que é um processo de software?

O que é um processo de software? O que é um processo de software? Um conjunto de atividades realizadas por pessoas cujo objetivo é desenvolvimento ou evolução de software e sua documentação. Atividades genéricas em todos os processos:

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Engenharia de requisitos

Engenharia de requisitos Engenharia de requisitos Um Requisito é uma característica que um sistema precisa ter ou uma restrição que ele precisa satisfazer para ser aceito pelo cliente. A Engenharia de requisitos tem por objetivo

Leia mais

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti

Leia mais

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br A importância da aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: estudo de caso do sistema de controle de veículos AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br

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

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

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

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

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantação

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