Levantamento de requisitos no desenvolvimento ágil de software
|
|
- Manuella Rios Castro
- 8 Há anos
- Visualizações:
Transcrição
1 Levantamento de requisitos no desenvolvimento ágil de software Ricardo Augusto Ribeiro de Mendonça Coordenação de Pós-Graduação Lato Sensu Pontifícia Universidade Católica de Goiás (PUC Goiás) Goiânia GO Brasil Abstract. This paper presents a study of techniques for requirements gathering and demonstrates how to use them in agile software development methodologies. First, some techniques will be presented to raise requirements, then the key will be known agile methodologies and how the requirements are raised in each. Resumo. Este artigo apresenta um estudo de técnicas de levantamento de requisitos e demonstra como utilizá-las em metodologias de desenvolvimento ágil de software. Primeiro, será apresentado algumas técnicas para levantar requisitos, em seguida, será conhecido as principais metodologias ágeis e a forma como os requisitos são levantados em cada uma delas. 1. Levantamento de requisitos O levantamento de requisitos desempenha um papel importante na construção de um sistema de informação, pois é o início para toda a atividade de desenvolvimento de software. É onde o analista faz as primeiras reuniões com os clientes e/ou usuários para conhecer as funcionalidades do sistema que será desenvolvido. Algumas das razões para o baixo grau de satisfação dos usuários estão na fase de levantamento de requisitos do projeto, onde não é utilizada uma técnica adequada para extrair os requisitos do sistema, além disso, a falha do analista em não descrever os requisitos de modo claro, sem ambiguidades, conciso e consistente com todos os aspectos significativos do sistema proposto [Pompilho 1995]. As técnicas de levantamento de requisitos possuem um conceito próprio e podem ser utilizadas em conjunto pelo analista. A seguir serão apresentadas de forma resumida algumas dessas técnicas Entrevistas A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados. Existem dois tipos de entrevistas:
2 Entrevista fechada, onde o engenheiro de requisitos tem um conjunto prédefinido de perguntas e está à procura de respostas. Entrevista aberta, sem perguntas pré-definidas do engenheiro de requisitos, onde há uma discussão de forma aberta com os interessados sobre o que eles esperam do sistema. Na verdade, muitas vezes não há limite claro entre os dois tipos de entrevistas. Você começa com algumas questões que são discutidas e isso leva a novas questões [Sommerville 1997]. A vantagem de entrevistas é que elas ajudam o desenvolvedor a obter uma rica coleção de informações. Sua desvantagem é que esta quantidade de dados qualitativos pode ser difícil de analisar e poderá haver informações conflitantes das diferentes partes interessadas Questionários Os questionários são indicados, por exemplo, quando há diversos grupos de usuários que podem estar em diversos locais diferentes. Neste caso, elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, pois não seria prático entrevistar todas as pessoas em todos os locais. Existem vários tipos de questionários que podem ser utilizados. Entre estes podemos listar: múltipla escolha, lista de verificação e questões com espaços em branco. O questionário deve ser desenvolvido de forma a minimizar o tempo gasto em sua resposta. Na fase de preparação do questionário deve ser indicado o tipo de informação que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionário com questões de forma simples, clara e concisa, deixar espaço suficiente para as repostas que forem descritivas e agrupar as questões de tópicos específicos em um conjunto com um título especial. O questionário deve ser acompanhado por uma carta explicativa, redigida por um alto executivo, para enfatizar a importância dessa pesquisa para a organização. Deve ser desenvolvido um controle que identifique todas as pessoas que receberão os questionários. A distribuição deve ocorrer junto com instruções detalhadas sobre como preenchê-lo e ser indicado claramente o prazo para devolução do questionário. Ao analisar as respostas dos participantes é feito uma consolidação das informações fornecidas no questionário, documentando as principais descobertas e enviando uma cópia com estas informações para o participante como forma de consideração pelo tempo dedicado a pesquisa Brainstorming Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou várias reuniões que permitem que as pessoas sugiram e explorem ideias. Brainstorming contém duas fases - a fase de geração, onde as ideias são coletadas, e a fase de avaliação, onde as ideias coletadas são discutidas. Na fase de geração, as ideias não devem ser criticadas nem avaliadas. Cada ideia pode levar a novas ideias. A técnica de brainstorming leva a uma melhor compreensão do problema para todos e um sentimento de que todos cooperaram para atingir o objetivo.
3 1.4. Joint Application Design (JAD) A metodologia JAD foi desenvolvida pela IBM para acelerar o desenvolvimento de sistemas de informação e está embasada em dinâmicas de grupo acompanhadas de planejamento, estruturação e sistematização de reuniões. O JAD facilita a criação de uma visão compartilhada do que o produto de software deve ser. Através da sua utilização os desenvolvedores ajudam os usuários a formular problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso do produto. A técnica JAD tem quatro princípios básicos: Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema; Uso de técnicas visuais: para aumentar a comunicação e o entendimento; Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas. Possibilita assim, a garantia de uma análise completa reduzindo as chances de falhas ou lacunas no projeto e cada nível de detalhe recebe a devida atenção; Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes. A técnica JAD é composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificar os requisitos; e projeto, em que se lida com o projeto de software. Cada etapa consiste em três fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construído e preparar o material. Na fase de sessão é realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde os requisitos são desenvolvidos e documentados. A fase de finalização tem por objetivo converter a informação da fase de sessão em sua forma final (um documento de especificação de requisitos). Há seis tipos de participantes, embora nem todos participem de todas as fases: Líder da sessão: é responsável pelo sucesso do esforço, sendo o facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança; Engenheiro de requisitos: é o participante diretamente responsável pela produção dos documentos de saída das sessões JAD. Deve ser um desenvolvedor experiente para entender as questões técnicas e detalhes que são discutidos durante as sessões e ter habilidade de organizar ideias e expressá-las com clareza; Executor: é o responsável pelo produto sendo construído. Tem que fornecer aos participantes uma visão geral dos pontos estratégicos do produto de software a
4 ser construído e tomar as decisões executivas, tais como alocação de recursos, que podem afetar os requisitos e o projeto do novo produto; Representantes dos usuários: são as pessoas na empresa que irão utilizar o produto de software. Durante a extração de requisitos, os representantes são frequentemente gerentes ou pessoas chave dentro da empresa que tem uma visão melhor do todo e de como ele será usado; Representantes de produtos de software: são pessoas que estão bastante familiarizadas com as capacidades dos produtos de software. Seu papel é ajudar os usuários a entender o que é razoável ou possível que o novo produto faça; Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico. Figura 1. Sessão JAD O conceito do JAD de abordagem e dinâmica de grupo poderá ser utilizado para diversas finalidades, como: planejamento de atividades técnicas para um grande projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade de horas necessárias para desenvolver sistemas grandes e complexos. A maioria das técnicas JAD funciona melhor em projetos pequenos ou médios. Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para acelerar a definição dos requisitos do sistema.
5 1.5. Prototipagem Um protótipo de um sistema é uma versão inicial do sistema que está disponível no início do processo de desenvolvimento. Protótipos de sistemas de software são frequentemente utilizados para ajudar a obter e validar requisitos do sistema. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras. Alguns dos benefícios do protótipo são as reduções dos riscos na construção do sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de todos os interessados no projeto, a focalização em áreas menos compreendidas e a rapidez na construção. 2. Desenvolvimento Ágil O Desenvolvimento Ágil é um conjunto de metodologias de desenvolvimento de software. É uma filosofia onde muitas metodologias se encaixam. As metodologias ágeis aplicam uma coleção de práticas guiadas por princípios e valores que podem ser aplicados por profissionais de software no decorrer do trabalho. Métodos ágeis são adaptativos ao invés de preditivos. Com os métodos tradicionais, o processo de software é planejado em detalhes por um longo período de tempo. Isso funciona bem se não houver grandes mudanças, o domínio da aplicação e as tecnologias de software sejam bem compreendidos pela equipe de desenvolvimento. Os métodos ágeis foram desenvolvidos para se adaptar as mudanças [Fowler 2000]. Métodos ágeis são orientados às pessoas ao invés de processos. Eles confiam na experiência das pessoas, na competência e na colaboração direta, do que em rigor dos processos centrados em documentos, para produzir software de alta qualidade [Fowler 2000]. A seguir, os métodos ágeis mais comuns serão brevemente discutidos Extreme Programming (XP) A metodologia Extreme Programming (XP) enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente, além de favorecer o cumprimento das estimativas. As regras, práticas e valores da XP proporcionam um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e coragem. A finalidade do princípio de comunicação é manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação. A comunicação entre os desenvolvedores e o gerente do projeto também é encorajada. A forma de comunicação é um fator chave na XP: procura-se o máximo possível comunicar-se pessoalmente, evitando se o uso de telefone e o envio de mensagens por correio eletrônico.
6 A simplicidade visa permitir a criação de código simples que não deve possuir funções desnecessárias. Por código simples entende-se implementar o software com o menor número possível de classes e métodos. Outra ideia importante da simplicidade é procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis [Soares 2004]. Figura 2. Práticas XP Durante o planejamento, são usadas as técnicas de elicitação de requisitos, como entrevistas, brainstorming e priorização. A principal ferramenta utilizada para elicitação são os cartões de história em que os usuários escrevem suas histórias de usuário, que é uma descrição de um recurso que fornece o valor de negócio para o cliente [Carvalho Costa 2011]. Antes que as histórias possam ser escritas em cartões, os clientes têm que pensar sobre o que eles esperam do sistema e fazer com que a funcionalidade seja necessária. Este processo é uma espécie de brainstorming. Desenvolvedores pedem mais detalhes para determinar o que os clientes realmente querem que o sistema faça e estimam o esforço necessário para desenvolvê-la. Com base nestas estimativas e do tempo disponível na próxima iteração, os clientes estão, por sua vez, capazes para escolher as histórias a serem desenvolvidos.
7 2.1. Scrum O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Scrum não propõe qualquer técnica de desenvolvimento de software específico para a implementação. Ele se concentra em como uma equipe deve trabalhar em conjunto para produzir um trabalho de qualidade em um ambiente em mudança [Abrahamsson 2002]. As fases do Processo de Scrum são: pré-planejamento, desenvolvimento e pósplanejamento. Na fase de pré-planejamento (pre-game phase), os requisitos são descritos em um documento chamado backlog. A seguir os requisitos são classificados por prioridade, onde é estimado o esforço para o seu desenvolvimento. Nesta fase inclui a definição dos integrantes da equipe, identificação da necessidade de treinamento, as ferramentas que serão utilizadas, como também uma lista com os prováveis riscos de projeto. A fase é concluída com uma proposta de arquitetura de software. As alterações futuras devem ser descritas no backlog. Na fase de desenvolvimento (game phase), os riscos previamente identificados devem ser mapeados e acompanhados ao longo do projeto para avaliar o seu impacto. Nesta fase, o software é desenvolvido em ciclos interativos (sprints), onde são adicionadas novas funcionalidades. Cada um desses sprints com duração de 2 a 4 semanas são desenvolvidos de forma tradicional (análise, projeto, implementação e testes). Já na fase de pós-planejamento (post-game phase) é onde acontece a integração do software, os testes finais e a documentação do usuário. A equipe se reúne para analisar o estado do projeto e o software atual é apresentado ao cliente. As principais técnicas são o scrum product backlog, sprints e scrums. No que diz respeito à engenharia de requisitos, o product backlog desempenha um papel especial no scrum. Todos os requisitos considerados necessários ou úteis para o produto estão listados no product backlog. Ele contém uma lista ordenada de todas as funcionalidades, melhorias e bugs. O product backlog pode ser comparado com um documento de requisitos incompleto e em constante mudança, contendo os requisitos necessários para o desenvolvimento. Cada sprint, iteração com 30 dias de desenvolvimento, está prevista com base nas informações incluídas no product backlog. Tarefas selecionadas a partir do product backlog são movidas para o sprint backlog. Nenhuma alteração será feita para o sprint backlog durante o sprint. Ou seja, não há flexibilidade nos requisitos durante um sprint, mas há total flexibilidade para o cliente escolher os requisitos do próximo sprint.
8 Figura 3. Sprint Durante uma sprint a equipe de desenvolvimento passa por várias fases (reunião de planejamento da sprint, sprint, revisão da sprint). O objetivo da reunião de revisão da sprint é de que os participantes (clientes e desenvolvedores) tenham entendimento do sistema, sua arquitetura técnica e design, bem como as funcionalidades entregues. O conhecimento adquirido na reunião de revisão de sprint e o product backlog atual é a base para a próxima reunião de planejamento do sprint. Uma parte da reunião de revisão de sprint, onde os participantes adquirem conhecimentos sobre o sistema, pode ser comparado à revisão de requisitos e a uma apresentação do protótipo evolutivo para o cliente Feature Driven Development (FDD) O Desenvolvimento Orientado a Funcionalidades (FDD) é um processo de curta iteração para desenvolvimento de software com foco no projeto e na fase de desenvolvimento. FDD é composto por cinco processos sequenciais. Os três primeiros são executados no início do projeto e os dois últimos durante cada iteração [Fowler 2000]. Desenvolvimento de um modelo geral; Construção de uma lista de funcionalidades; Planejamento por funcionalidade; Projeto por funcionalidade; Desenvolvimento por funcionalidade. Os dois papéis mais importantes na FDD são o programador-chefe, um desenvolvedor experiente capaz de liderar equipes pequenas de desenvolvimento e de participar da análise de requisitos e da modelagem do projeto, e o proprietário da classe,
9 que trabalhará com a classe que é atribuída a ele. Na primeira fase, um modelo geral é desenvolvido por membros do domínio e pelos desenvolvedores. A lista de funcionalidades é construída na segunda fase com base no modelo global. O modelo global é composto de diagramas de classe com classes, links, métodos e atributos. As classes e links estabelecem a forma do modelo. Os métodos expressam o comportamento e é a base para a construção da lista de funcionalidades. Uma funcionalidade em FDD é uma função que agrega valor para o cliente. As funcionalidades da lista de funcionalidades são priorizadas pela própria equipe. A lista de funcionalidades é revisada pelos membros do domínio [Lefebvre 1999]. Figura 4. Processos da FDD Os requisitos em FDD são listados, definidos e documentados através de casos de uso, produzindo diagramas de classe e sequência. Em seguida, os requisitos são agrupados e priorizados conforme importância e dependência. FDD propõe um encontro semanal de 30 minutos para que a situação das funcionalidades seja discutida e um relatório sobre a reunião seja escrito [Lefebvre 1999]. Esses relatórios podem ser comparados com o monitoramento/gestão dos requisitos Adaptive Software Development (ASD) Os princípios do Desenvolvimento Adaptável de Software (ASD) são provenientes de pesquisas sobre o desenvolvimento iterativo. ASD fornece uma estrutura para o desenvolvimento de sistemas grandes e complexos com orientação suficiente para impedir os projetos de cair no caos. O método estimula o desenvolvimento iterativo e incremental com prototipagem constante. O processo ASD contém três fases que se sobrepõem: especulação, colaboração e aprendizagem.
10 Figura 5. Processo ASD Os nomes das fases enfatizam a diferença do desenvolvimento de software tradicional. Especulação em vez de planejamento, porque o planejamento sempre indica que não há incertezas. A importância do trabalho em equipe é destacada pela colaboração. Em um ambiente imprevisível, pessoas têm a necessidade de se comunicar para serem capazes de lidar com as incertezas [Highsmith 1996]. Aprendizagem salienta que os requisitos mudam durante o desenvolvimento e existe a necessidade de um conhecimento sobre isso. Na ASD os desvios não são uma falha do sistema, mas levarão para uma solução correta. Cada projeto começa com a definição da missão do projeto, uma breve declaração indicando o curso do projeto. Durante a fase de iniciação do projeto, o cronograma geral bem como os prazos e os objetivos para os ciclos de desenvolvimento são definidos. Um ciclo em ASD dura entre quatro e oito semanas. Como ASD é orientada a componentes em vez de orientado a tarefas, ela foca nos resultados e sua qualidade. A próxima fase é o planejamento do ciclo adaptativo que contém a fase de colaboração onde o ASD aborda a visão orientada a componentes. Ciclos do planejamento são repetidos quando ocorrem novas exigências e os componentes têm de ser refinados. Revisões com a presença do cliente demonstram a funcionalidade do software durante o ciclo. A fase de release é a última fase de um projeto ASD. Não há recomendações de como esta fase deve ser realizada, mas a ênfase está na importância de capturar as lições aprendidas. Os requisitos em ASD são definidos através de sessões de JAD com a presença de representantes do cliente. Como em outros processos ágeis, ASD é baseada em ciclos de desenvolvimento iterativo. ASD destaca que um método cascata só funciona em um ambiente bem compreendido e bem definido. Mas as mudanças são frequentes no desenvolvimento de software e é importante ser capaz de reagir às mudanças e utilizar um método de tolerância às mudanças.
11 3. Conclusão As metodologias de desenvolvimento ágil podem ser consideradas novas, porém vêm acompanhando as necessidades de desenvolver softwares com qualidade, no menor tempo possível e que atendam as necessidades dos clientes. Profissionais da tecnologia da informação vêm aprimorando as concepções destas metodologias para atender as necessidades do mercado e principalmente das pessoas. Os métodos ágeis são baseados em um forte envolvimento do cliente durante todo o processo de desenvolvimento. Porém, os métodos pedem vários clientes com diferentes experiências, mas às vezes apenas um cliente está disponível. Isso significa que nem todas as questões levantadas podem ser respondidas com detalhes suficientes. Isso pode resultar em atrasos no desenvolvimento ou em tomada de decisões potencialmente incorretas. Além disso, algumas áreas de negócio não podem ser suficientemente compreendidas pelo cliente, de modo que ele não pode dizer a equipe de desenvolvimento sobre os requisitos relacionados. Mesmo que os requisitos sejam levantados em sessões de grupo não é garantido que os usuários ou clientes com a base necessária estejam presentes. Contudo, o desenvolvimento ágil de software leva a uma melhor compreensão dos requisitos e do processo de desenvolvimento, pois envolve os clientes, que são capazes de tomar as decisões corretas e ter sua própria visão a respeito do sistema a ser desenvolvido. Uma empresa ao utilizar estes métodos, estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança.
12 Referências ABRAHAMSSON, Pekka, SALO, Outi, RONKAINEN, Jussi e WARSTA, Juhani. Agile software developlment methods. Review and analysis. Espoo VTT Publications p. CARVALHO COSTA, Gustavo Henrique de. Engenharia de Requisitos no Desenvolvimento de Software Ágil. Universidade Federal de Pernambuco, Centro de Informática, FOWLER, Martin. The new methodology. articles/newmethodology.html, HIGHSMITH, James A. Adaptive Software Development. Dorset House Publishing, LEFEBVRE, Eric, COAD, Peter e DE LUCA, Jeff. Java Modeling in Color with UML. Prentice Hall PTR, POMPILHO, S. Análise Essencial Guia Prático de Análise de Sistemas. Rio de Janeiro: Ed. Ciência Moderna Ltda, PRESSMAN, Roger S. Engenharia de Software. São Paulo: Ed. Markon Books, SOMMERVILLE, Ian e KONTONYA, Gerald. Requirements Engineering. John Wiley & Sons, SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiet, 2004.
Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br
Comparativo entre Processos Ágeis Daniel Ferreira dfs3@cin.ufpe.br O que discutiremos: Histórico Os Princípios Ágeis Comparação Do ponto de vista incremental Do ponto de vista funcional Vantagens e Desvantagens
Leia maisRequisitos 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 maisUNIVERSIDADE 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 maisProcessos de gerenciamento de projetos em um projeto
Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.
Leia maisLevantamento, 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 maisCom metodologias de desenvolvimento
Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente
Leia maisDesenvolvimento Á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 maisEngenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org
Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming
Leia maisAula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW
Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisENGENHARIA 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 maisO Processo Unificado
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas
Leia maisManifesto Ágil - Princípios
Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o
Leia maisCapítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1
Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de
Leia maisIdeal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?
Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado
Leia maisPlanejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP
Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica
Leia maisModelagem de Processos de Negócio Aula 5 Levantamento de Processos. Andréa Magalhães Magdaleno andrea@ic.uff.br
Modelagem de Processos de Negócio Aula 5 Levantamento de Processos Andréa Magalhães Magdaleno andrea@ic.uff.br Agenda Técnicas de levantamento de processos Análise de documentação Observação Story boarding
Leia maisRoteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos
SENAC Pós-Graduação em Segurança da Informação: Análise de Riscos Parte 2 Leandro Loss, Dr. Eng. loss@gsigma.ufsc.br http://www.gsigma.ufsc.br/~loss Roteiro Introdução Conceitos básicos Riscos Tipos de
Leia maisGerenciamento de Projetos Modulo VIII Riscos
Gerenciamento de Projetos Modulo VIII Riscos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento
Leia maisCurso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP
Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela
Leia maisEngenharia de Software II
Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1 Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap.
Leia maisA SEGUIR ALGUMAS DICAS PARA O DESENVOLVIMENTO DE UM PROJETO CIENTÍFICO
A SEGUIR ALGUMAS DICAS PARA O DESENVOLVIMENTO DE UM PROJETO CIENTÍFICO DESENVOLVENDO UM PROJETO 1. Pense em um tema de seu interesse ou um problema que você gostaria de resolver. 2. Obtenha um caderno
Leia maisScrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE
Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.
Leia maisADMINISTRAÇÃO I. Família Pai, mãe, filhos. Criar condições para a perpetuação da espécie
1 INTRODUÇÃO 1.1 ORGANIZAÇÃO E PROCESSOS A administração está diretamente ligada às organizações e aos processos existentes nas mesmas. Portanto, para a melhor compreensão da Administração e sua importância
Leia maisPráticas de. Engenharia de Software. Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.
"Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software Práticas de Engenharia de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha
Leia maisTópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.
Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico
Leia maisCurso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan
Faculdade INED Curso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan Ago-2008 1 Gestão de requisitos 2 Bibliografia: PAULA
Leia maisDISCIPLINA 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 mais3 Qualidade de Software
3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo
Leia maisATIVIDADES PRÁTICAS SUPERVISIONADAS
ATIVIDADES PRÁTICAS SUPERVISIONADAS 1ª. Série Análise Estruturada de Sistemas Sistemas de Informação A atividade prática supervisionada (ATPS) é um procedimento metodológico de ensino-aprendizagem desenvolvido
Leia maisProf. 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Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.
Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer
Leia maisGerenciamento da Integração (PMBoK 5ª ed.)
Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar
Leia maisTópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.
Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo
Leia maisAlexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes
Instituto Federal do Rio Grande do Norte IFRN Graduação Tecnologia em Analise e Desenvolvimento de Sistema Disciplina: Processo de Desenvolvimento de Software Scrum Alexandre Lima Guilherme Melo Joeldson
Leia maisProjetos Ágeis aplicados a TI. Júlio Cesar da Silva Msc.
Projetos Ágeis aplicados a TI Júlio Cesar da Silva Msc. Apresentação Graduação em Matemática e TI MBA em Gestão em TI Mestre em Administração Certificado ITIL, Cobit e ScrumMaster Professor Graduação Professor
Leia maisUnidade II MODELAGEM DE PROCESSOS
Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que
Leia maisQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE - 02 Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software.
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia maisLEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA
LEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA Kleber Lopes Petry Éder Moretto Garcia Rodrigo Clemente Thom de Souza Proposta de processo para levantamento de requisitos para desenvolvimento de produtos de
Leia maisEAD 615 Gerenciamento de Projetos
EAD 615 Gerenciamento de Projetos O Papel e As Habilidades do Gerente de Projetos Professores: Prof. Dr. Antonio C. Amaru Maximiano Prof. Dr. Roberto Sbragia Colaboradores: Benedito Décio da S. Camargo
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisUnidade I Conceitos BásicosB. Conceitos BásicosB
à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 1961 a 1963 Surgimento de novos Hardwares 1963-1968 Crise do Software! Incapacidade de se utilizar
Leia maisIntrodução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004
Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a
Leia maisOBJETIVO DO PROGRAMA ORGANIZAÇÃO DO PROGRAMA E CARGA HORÁRIA PREMISSAS DOS PROGRAMA INVESTIMENTO E PRÓXIMA TURMA I NSTRUTORES
PROGRAMA DE CERTIFICAÇÃO EM GESTÃO DE PROCESSOS DE OBJETIVO DO PROGRAMA O programa visa capacitar seus participantes em técnicas práticas e conceitos necessários para trabalhar em iniciativas de modelagem,
Leia maisMERCER 360 PRINCIPAIS CARACTERÍSTICAS
MERCER 360 PRINCIPAIS CARACTERÍSTICAS Ponto de Vista da Mercer A avaliação 360 é um elemento vital para o desenvolvimento da liderança e planejamento de talentos Identifica pontos fortes e áreas de desenvolvimento
Leia maisIntrodução. Gerência de Projetos de Software. Sumário. Sistemas de Informação para Processos Produtivos
Sumário Sistemas de Informação para Processos Produtivos 1. Gerência de 2. Agentes principais e seus papéis 3. Ciclo de vida do gerenciamento de projetos M. Sc. Luiz Alberto lasf.bel@gmail.com Módulo 6
Leia maisMetodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697
Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento
Leia maisGERÊNCIA DE PROJETOS DE SOFTWARE. Introdução
GERÊNCIA DE PROJETOS DE SOFTWARE Introdução GERÊNCIA DE PROJETOS DE SOFTWARE - INTRODUÇÃO Um projeto é como uma viagem em uma rodovia. Alguns projetos são simples e rotineiros, como dirigir até uma loja
Leia maisResumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0
O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok
Leia maisMÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que
Leia maisPLANEJAMENTO ESTRATÉGICO
PLANEJAMENTO ESTRATÉGICO Este material resulta da reunião de fragmentos do módulo I do Curso Gestão Estratégica com uso do Balanced Scorecard (BSC) realizado pelo CNJ. 1. Conceitos de Planejamento Estratégico
Leia maisRisco de projeto é um evento ou condição incerta que, se ocorrer, tem um efeito positivo ou um negativo no objetivo de um projeto.
Risco de projeto é um evento ou condição incerta que, se ocorrer, tem um efeito positivo ou um negativo no objetivo de um projeto. Um risco tem uma causa e, se ocorre, uma conseqüência. Se um ou outro
Leia maisGerenciamento de Projeto: Planejando os Riscos. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br
Gerenciamento de Projeto: Planejando os Riscos Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Introdução Planejar o Gerenciamento dos Riscos. Identificar os Riscos Realizar a Análise Qualitativa
Leia maisTREINAMENTO SOBRE PRODUTOS PARA VENDEDORES DO VAREJO COMO ESTRATÉGIA PARA MAXIMIZAR AS VENDAS 1. Liane Beatriz Rotili 2, Adriane Fabrício 3.
TREINAMENTO SOBRE PRODUTOS PARA VENDEDORES DO VAREJO COMO ESTRATÉGIA PARA MAXIMIZAR AS VENDAS 1 Liane Beatriz Rotili 2, Adriane Fabrício 3. 1 Pesquisa realizada no curso de Administração da Unijuí 2 Aluna
Leia maisCasos de uso Objetivo:
Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de
Leia maisExtração de Requisitos
Extração de Requisitos Extração de requisitos é o processo de transformação das idéias que estão na mente dos usuários (a entrada) em um documento formal (saída). Pode se entender também como o processo
Leia maisQuestionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP
DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP Versão 2.2.0 Julho 2014 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 3ª Edição (a publicar)
Leia mais4 Metodologia e estratégia de abordagem
50 4 Metodologia e estratégia de abordagem O problema de diagnóstico para melhoria da qualidade percebida pelos clientes é abordado a partir da identificação de diferenças (gaps) significativas entre o
Leia maisGestão e estratégia de TI Conhecimento do negócio aliado à excelência em serviços de tecnologia
Gestão e estratégia de TI Conhecimento do negócio aliado à excelência em serviços de tecnologia Desafios a serem superados Nos últimos anos, executivos de Tecnologia de Informação (TI) esforçaram-se em
Leia maisAutoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maisProjeto da Disciplina Parte1: Estudo de Viabilidade. Um Estudo de Viabilidade
Projeto da Disciplina Parte1: Estudo de Viabilidade ENTREGA: 09/04/09 Professor: Carlos José Maria Olguin Um Estudo de Viabilidade Você deve fazer um estudo de viabilidade para um projeto de sistema de
Leia maisDESENVOLVENDO O SISTEMA
DESENVOLVENDO O SISTEMA Declaração da Necessidade O primeiro passo do processo de análise de sistema envolve a identificação da necessidade [Pressman-95]. Normalmente o analista reúne-se com o usuário
Leia maisARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.
ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página
Leia maisProcessos de Software
Processos de Software Prof. Márcio Lopes Cornélio Slides originais elaborados por Ian Sommerville O autor permite o uso e a modificação dos slides para fins didáticos O processo de Um conjunto estruturado
Leia maisnatureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues
Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas
Leia maisRoteiro SENAC. Análise de Riscos. Análise Quantitativa de Riscos. Análise Quantitativa de Riscos. Análise Quantitativa de Riscos
SENAC Pós-Graduação em Segurança da Informação: Análise de Riscos Parte 5 Leandro Loss, Dr. Eng. loss@gsigma.ufsc.br http://www.gsigma.ufsc.br/~loss Roteiro Análise de Qualitativa Quantitativa Medidas
Leia maisCampus 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 maisQUANDO este projeto deve ser realizado e QUANTO este projeto deverá custar?
O PROJECT MODEL CANVAS (www.pmcanvas.com.br) é uma ferramenta que permite que um projeto seja entendido no contexto dos aspectos Fundamentals da teoria de gerenciamento de projetos. A metodologia facilita
Leia maisRequisitos do usuário, do sistema e do software [Sommerville, 2004]
Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que
Leia maisPMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto
PMBOK 4ª Edição III O padrão de gerenciamento de projetos de um projeto 1 PMBOK 4ª Edição III Processos de gerenciamento de projetos de um projeto 2 Processos de gerenciamento de projetos de um projeto
Leia maisO Processo de Engenharia de Requisitos
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo de Engenharia de Requisitos Engenharia de Software 2o.
Leia maisIntrodução à. Engenharia de Software. Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.
"Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software Introdução à Engenharia de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha
Leia maisSimulado "Simulado PMP 13-02-2012 25 questoes"
Pá gina 1 de 12 Simulado "Simulado PMP 13-02-2012 25 questoes" Simulado do PMI por Juarez Vanderlei Guimarães Junior 13 de March de 2012 Pá gina 2 de 12 Disciplinas e temas deste simulado Introdução ao
Leia maisProcedimentos de Gestão da Qualidade. NOME FUNÇÃO ASSINATURA DATA ELABORADO POR Dr. Ivo Fernandes Gerente da Qualidade 13/10/2009
Versão: 2 Pág: 1/5 NOME FUNÇÃO ASSINATURA DATA ELABORADO POR Dr. Ivo Fernandes Gerente da Qualidade 13/10/2009 DE ACORDO Dr. Renato de Lacerda Diretor Técnico 13/10/2009 APROVADO POR Dr. Jose Carlos dos
Leia maisGerenciamento de Projetos Modulo III Grupo de Processos
Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento
Leia maisSistemas de Informação I
+ Sistemas de Informação I Extreme Programming I Ricardo de Sousa Britto rbritto@ufpi.edu.br Você gostaria de trabalhar assim? Análise de Requisitos Longe de acordo Requerimentos Complexo Anarquia Perto
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
CI 221 DISCIPLINA: Engenharia de Software AULA NÚMERO: 5 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO Nesta aula serão apresentados e discutidos os conceitos de Gestão de projetos de software, riscos de software,
Leia maisISO 9001: SISTEMAS DE GESTÃO DA QUALIDADE
ISO 9001: SISTEMAS DE GESTÃO DA QUALIDADE Prof. MARCELO COSTELLA FRANCIELI DALCANTON ISO 9001- INTRODUÇÃO Conjunto de normas e diretrizes internacionais para sistemas de gestão da qualidade; Desenvolve
Leia maisClassificação de Sistemas: Sistemas Empresariais
Universidade do Contestado Campus Concórdia Curso de Ciências Contábeis Prof.: Maico Petry Classificação de Sistemas: Sistemas Empresariais DISCIPLINA: Sistemas de Informação Gerencial O QI da empresa
Leia maisLISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE
Questionamento a alta direção: 1. Quais os objetivos e metas da organização? 2. quais os principais Produtos e/ou serviços da organização? 3. Qual o escopo da certificação? 4. qual é a Visão e Missão?
Leia maisAdministração de Pessoas
Administração de Pessoas MÓDULO 5: ADMINISTRAÇÃO DE RECURSOS HUMANOS 5.1 Conceito de ARH Sem as pessoas e sem as organizações não haveria ARH (Administração de Recursos Humanos). A administração de pessoas
Leia maisRegulamento Projeto interdisciplinar
Regulamento Projeto interdisciplinar 1 Apresentação O presente manual tem como objetivo orientar as atividades relativas à elaboração do Projeto Interdisciplinar (PI). O PI é o estudo sobre um tema específico
Leia maisXP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br
XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso
Leia maisProf. Fernando Lopes. Unidade II. Administração de Cargos e
Prof. Fernando Lopes Unidade II Administração de Cargos e Salários Conforme Chiavenato (2004, p. 267), a avaliação de cargos visa a obtenção de dados que permitirão uma conclusão acerca do valor interno
Leia maisMETODOLOGIAS Á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 maisIntroduçã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 maisProcesso de Software - Revisão
Processo de Software - Revisão Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Pressman, R. S. Engenharia de Software, McGraw-Hill, 6ª. Edição,
Leia maisIntrodução. Toda organização executa basicamente dois tipos de atividade: Projeto; e. Operação (execução).
Gestão de Projetos Introdução Toda organização executa basicamente dois tipos de atividade: Projeto; e Operação (execução). O projeto é uma atividade muito particular, cuja finalidade principal é dar origem
Leia mais4.1. UML Diagramas de casos de uso
Engenharia de Software 4.1. UML Diagramas de casos de uso Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Utilizados para ajudar na análise de requisitos Através da forma como o utilizador usa o sistema
Leia maisPromoção especial para o III Congresso Cearense de Gerenciamento Certified ScrumMaster, Certified Scrum Product Owner e Management 3.
Promoção especial para o III Congresso Cearense de Gerenciamento Certified ScrumMaster, Certified Scrum Product Owner e Management 3.0 Sobre a GoToAgile! A GoToAgile é uma empresa Brasileira que tem seu
Leia maisUNIVERSIDADE FEDERAL DE OURO PRETO PROJETO BÁSICO CURSO DE APERFEIÇOAMENTO EM PRODUÇÃO E ORGANIZAÇÃO DE CONTEÚDO NA EAD CURSO PARA DOCENTES DA UFOP
UNIVERSIDADE FEDERAL DE OURO PRETO CENTRO DE EDUCAÇÃO ABERTA E A DISTANCIA PROJETO BÁSICO CURSO DE APERFEIÇOAMENTO EM PRODUÇÃO E ORGANIZAÇÃO DE CONTEÚDO NA EAD CURSO PARA DOCENTES DA UFOP 2007 IDENTIFICAÇÃO
Leia maisIntrodução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização
Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisComo identificar, vender e comercializar com os prospectos de pequenas empresas Parte 3/3
Como identificar, vender e comercializar com os prospectos de pequenas empresas Parte 3/3 A pequena empresa é um mercado massivo em importante crescimento, que alcançou uma maturidade em termos de oportunidade
Leia maisEngenharia de Software
Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br
Leia maisOuvir o cliente e reconhecer o problema: ingredientes essenciais à gestão de projetos
Ouvir o cliente e reconhecer o problema: ingredientes essenciais à gestão de projetos Antonio Mendes da Silva Filho * The most important thing in communication is to hear what isn't being said. Peter Drucker
Leia maisCopyright Proibida Reprodução. Prof. Éder Clementino dos Santos
NOÇÕES DE OHSAS 18001:2007 CONCEITOS ELEMENTARES SISTEMA DE GESTÃO DE SSO OHSAS 18001:2007? FERRAMENTA ELEMENTAR CICLO DE PDCA (OHSAS 18001:2007) 4.6 ANÁLISE CRÍTICA 4.3 PLANEJAMENTO A P C D 4.5 VERIFICAÇÃO
Leia mais