TESTANDO REQUISITOS NO MOMENTO DA SUA DEFINIÇÃO, COM ADERÊNCIA À TERCEIRA ÁREA CHAVE DO TPI

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

Download "TESTANDO REQUISITOS NO MOMENTO DA SUA DEFINIÇÃO, COM ADERÊNCIA À TERCEIRA ÁREA CHAVE DO TPI"

Transcrição

1 UNIVERSIDADE FEDERAL DE PERNAMBUCO PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA TESTANDO REQUISITOS NO MOMENTO DA SUA DEFINIÇÃO, COM ADERÊNCIA À TERCEIRA ÁREA CHAVE DO TPI Autoras Audrey Bezerra de Vasconcelos Virgínia Carvalho Chalegre Orientador Prof. Jaelson Freire Brelaz de Castro RECIFE 2009

2 AUDREY BEZERRA DE VASCONCELOS VIRGÍNIA CARVALHO CHALEGRE TESTANDO REQUISITOS NO MOMENTO DA SUA DEFINIÇÃO, COM ADERÊNCIA À TERCEIRA ÁREA CHAVE DO TPI Monografia apresentada ao Curso de pósgraduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Orientação: Prof. Jaelson Freire Brelaz de Castro RECIFE 2009 ii

3 SUMÁRIO 1 INTRODUÇÃO PROBLEMAS DE REQUISITOS INTELIGIBILIDADE REDUNDÂNCIA INCOMPLETUDE AMBIGUIDADE INCONSISTÊNCIA DESORGANIZAÇÃO INCONFORMIDADE COM PADRÕES FALTA DE TRACEABILIDADE PROCESSO DE MELHORIA DE TESTES - TPI REQUISITOS DO TPI ESCOPO DO TPI PASSOS PARA IMPLANTAR A MELHORIA RELAÇÃO DE REQUISITOS COM O TPI TESTES NA ENGENHARIA DE REQUISITOS TESTES NO CICLO DE VIDA DO SOFTWARE VALIDAÇÃO DOS REQUISITOS TRABALHOS RELACIONADOS CONSIDERAÇÕES FINAIS REFERÊNCIAS iii

4 Resumo Este trabalho está relacionado com os problemas encontrados na elicitação de requisitos que impactam todo o desenvolvimento do software. A idéia principal é fazer com que a qualidade dos requisitos aumente através da aplicação do TPI (Test Process Improvement), com a melhoria do processo de testes e as técnicas de teste de requisitos, explicando como a metodologia do TPI pode servir de base para o procedimento de melhoria do documento de requisitos. Palavras-chave Teste. Requisitos. TPI. Processo. Melhoria. Qualidade. Cliente. Usuário. iv

5 Abstract This work is related to the problems found in the elicitation of requirements that impact the whole development of the software. The main idea is to make quality requirements increase through the application of TPI (Test Process Improvement), with a improvement of test process and the techniques of test requirements, explaining how the TPI methodology can serve as a basis for the procedure to improve of document requirements. Key-words Testing. Requirements. TPI. Process. Improvement. Quality. Customer. User v

6 Lista de ilustrações Figura 1. Processo Total de Desenvolvimento Figura 2. Estrutura do TPI Figura 3. Modelo para Implantar Melhorias Figura 4. Rational Unified Process RUP Figura 5. Modelo V Verificação e Validação Figura 6. Processos de Desenvolvimento e Testes Figura 7. Validação dos Requisitos entradas e saídas Figura 8. Processo de Revisão dos Requisitos Lista de tabelas Tabela 1. Fatores Prejudiciais aos Projetos Tabela 2. Checklist para Revisão dos Requisitos vi

7 7 1 INTRODUÇÃO Diante do cenário em que o cliente não sabe expressar com clareza as suas necessidades e que os engenheiros de requisitos nem sempre as interpretam como deveriam, é preciso ter requisitos bem definidos e passar por constantes processos de validação e aprovação, para evitar que o produto seja construído com erros e que não represente um espelho do que o cliente realmente deseja. A melhor forma de fazer com que esta validação seja possível é realizando testes na fase de requisitos, para que se possa encontrar com antecedência os erros comuns que ocorrem na elicitação e escrita dos documentos relacionados (Kotonia & Sommerville, 1997). Neste contexto, sentiu-se a necessidade de usar uma metodologia para que os testes de requisitos fossem realmente efetivos. A metodologia é o TPI Test Process Improvement (Melhoria de Processo de Testes) que é um conjunto de melhores práticas do processo de testes divididas em vinte áreas-chave. A terceira área, objeto de estudo desta monografia, indica o momento em que os testes devem ser envolvidos. O TPI defende o teste de requisitos, como forma de antecipar os problemas, diminuindo o custo do re-trabalho e até mesmo, a insatisfação do cliente. Este trabalho está organizado da seguinte maneira: a seção 2 apresenta quais são os problemas enfrentados na fase de requisitos, informando os impactos gerados nas outras fases do desenvolvimento; a seção 3 explica o que é o TPI e como ele pode ajudar nesse processo de testes de requisitos, seguindo as melhores práticas; a seção 4 apresenta algumas metodologias de desenvolvimento e que técnicas são usadas para fazer os testes de requisitos; na seção 5, são apresentados os trabalhos relacionados, fazendo uma contextualização com o mercado atual; e a seção 6 apresenta as considerações finais, como conclusão de todo o trabalho.

8 8 2 PROBLEMAS DE REQUISITOS A demanda por qualidade tem estimulado a comunidade de software para o desenvolvimento de modelos que conduzam a validação constante dos sistemas. Existe uma forte ligação entre requisitos e qualidade. O foco está em prevenir a insatisfação do cliente por meio de um melhor entendimento dos requisitos estabelecidos e, então, utilizá-los no projeto do software (Carvalho & Tavares, 2002). Não obstante, com o objetivo de obter uma solução, observada nas próximas seções, que consiga contrapor, pelo menos, os problemas mais comuns encontrados nos artefatos gerados durante a fase de requisitos, detalhou-se alguns destes problemas a seguir: 2.1 INTELIGIBILIDADE O termo inteligibilidade tem sido usado de três formas: para indicar legibilidade de escritos manuais ou tipográficos; para indicar facilidade de leitura conforme o valor, interesse de leitura; e para indicar o fácil entendimento ou compreensão devido ao estilo de escrever (Barboza & Nunes, 2007). Esta última abordagem, defendida por Klare (Klare, 2000), é específica para a natureza bidimensional da escrita, por se concentrar no estilo de escrever, nada dizendo a respeito de sua utilidade para o usuário. Inteligibilidade por si só não garante a compreensão por uma audiência específica. Ela está relacionada com o problema do encontro do leitor com o texto. Caso um membro da equipe do projeto que tenha um nível mais avançado porventura precisar ler os requisitos especificados, provavelmente ficará entediado com textos simples e repetitivos. No entanto, se for de um nível mais iniciante, poderá ficar desencorajado com textos nos quais encontra demasiada dificuldade para ler fluentemente. Essa situação provavelmente acontece quando o texto contém sentenças com estruturas complexas ou traz excessivo material com idéias inteiramente novas.

9 9 O termo inteligibilidade, portanto, refere-se a todos os fatores que afetam o sucesso na leitura e entendimento de um texto. Contudo, na elaboração de um documento de Especificação de Requisitos de Software (ERS), o autor deve convergir seus pensamentos para o seguinte questionamento: os leitores do documento entenderão o que os requisitos significam?. Este é, provavelmente, o atributo mais importante do documento de requisitos, pois, se ele não pode ser entendido, os requisitos não podem ser validados. 2.2 REDUNDÂNCIA Na Teoria da Comunicação, redundância diz respeito ao excesso ou desperdício de sinais ou de signos na transmissão da mensagem. Em geral, redundância refere-se a uma informação que foi repetida desnecessariamente. Porém, em algumas situações, repetir informação pode melhorar a compreensão. Logo, deve haver uma balança entre remover toda redundância e fazer um documento difícil de entender. Ou seja, a redundância em si mesma não é um erro, mas leva à ocorrência de erros. A redundância pode ocasionalmente ajudar a tornar um documento de ERS mais legível, contudo o problema surge quando o documento é atualizado. Por exemplo, uma sentença pode ser alterada em apenas um dos locais onde aparece. Neste caso, o documento fica inconsistente. Então, quando a redundância for mesmo necessária, referências cruzadas devem ser utilizadas para tornar o documento modificável (Gonçalves & et al, 2004). 2.3 INCOMPLETUDE Este problema está relacionado tanto com a incompletude do próprio documento ERS, caso não estejam especificados todos os requisitos do software necessários, como com a escrita destes, nos casos em que falta alguma informação nas descrições individuais dos requisitos de software. Tal dificuldade não é recente. Já em 1997, no artigo Classification of research efforts in requirements engineering (Zave, 1997), a autora se referia à incompletude e inconsistência de requisitos, além das barreiras da comunicação, como problemas que precisavam ser resolvidos.

10 10 Neste sentido, segundo (Gonçalves & et al, 2004), um documento de requisitos é considerado completo, se, e só se, inclui os seguintes elementos: Todos os requisisitos significantes, quer se prendam com a funcionalidade, o desempenho, restrições de desenho, atributos, ou interfaces externas (em particular, quaisquer requisitos externos impostos por especificações de sistemas) estão reconhecidos e tratados. Respostas do software a todas as classes realizáveis de entradas de dados em todas as situações. Legendas e referências completas para todas as figuras, tabelas e diagramas do documento, bem como a definição de todos os termos e unidades de medida. 2.4 AMBIGUIDADE Defini-se ambiguidade como sendo a duplicidade de sentido em uma construção sintática, ou seja, quando se permite mais de uma interpretação para uma determinada frase. No padrão IEEE Std 830 (Gonçalves & et al, 2004), temos que: Um documento de EES1 é uma parte importante do processo de exigências do ciclo de vida do software, sendo também utilizado nas fases de desenho, implementação, monitorização do projeto, verificação e validação, e na fase de treino tal como descrito no standard IEEE-std O documento de EES não pode conter ambiguidades, quer para quem o cria quer para quem o utiliza. No entanto, frequentemente estes dois grupos de pessoas não possuem o mesmo background e por essa razão tendem a não descrever as exigências de software da mesma forma. Representações que melhorem a especificação de exigências para a equipe de desenvolvimento tendem a ser contra-produtivos porque diminuem a compreensão do documento pelos utilizadores e vice-versa. 1 No referido documento, "Software Requirements Specification" foi traduzido por "Especificações de Exigências de Software", e, consequentemente, a sigla "SRS" foi traduzida por "EES".

11 11 Logo, nas situações em que um termo, ao ser utilizado em determinado contexto, possa adquirir múltiplos significados, esse termo deve ser incluído em um glossário onde o seu significado se torna mais específico. Este mesmo documento ainda sugere algumas recomendações para evitar a ambiguidade: como os requisitos são escritos em linguagem natural, estes devem ser revistos por uma pessoa que não fez parte do levantamento para identificar o uso de ambiguidades da linguagem, que devem ser corrigidas; outra solução seria transpor a linguagem numa linguagem especial, orientada para especificação de requisitos, pois, o processador desta linguagem tem a capacidade de detectar automaticamente muitos erros lexicais, sintáticos e semânticos; além disso, sugerese a aproximação da realidade através dos métodos e linguagens de requisitos, bem como ferramentas de apresentação, que são agrupados em objetos, processos e aproximações comportamentais que descrevem o comportamento externo do sistema em termos de noções abstratas. 2.5 INCONSISTÊNCIA Um requisito não deve estar em conflito ou contradição com outros requisitos; isso configuraria um problema quanto à consistência do documento de Especificação de Requisitos de Software. De acordo com o padrão IEEE Std 830 (Gonçalves & et al, 2004), existem três tipos de conflitos possíveis num documento de ERS: conflitos com relação às características dos objetos do mundo real; conflitos entre duas ações especificadas; e conflitos entre dois requisitos que descrevem o mesmo objeto, porém usando diferentes termos para este objeto. Portanto, cada requisito deve ser consistente com todos os demais requisitos na especificação; a consistência também deve existir entre os vários níveis de abstração, se é utilizada a decomposição de requisitos em níveis (Sayão, Staa, & Leite, 2003). Infelizmente, corrigir uma incoerência não é tão simples. Inconsistências geralmente resultam em erros de lógica, e para corrigir tais requisitos, certamente

12 12 seria necessária uma remodelação do documento. E, como é do conhecimento de todos, se essa inconsistência só for identificada no final do ciclo de vida do desenvolvimento de software, seu custo será incomensurável. 2.6 DESORGANIZAÇÃO O documento de requisitos deve ser descrito de modo que a informação desejada seja localizada facilmente. Para isto, este documento deverá ser elaborado seguindo alguns critérios mínimos de organização. Sugere-se que os requisitos sejam agrupados, seguindo uma classificação, possibilitando assim uma melhor manipulação do documento. Quanto à sua estrutura, o documento ERS poderá utilizar a atribuição de identificadores, como por exemplo, números sequenciais (1, 2, 3,...), números hierárquicos (1, 1.1, 1.2, 2,...), ou números sequenciais dentro de uma categoria (A1, A2,..., B1, B2,...); e a hierarquização, definindo os requisitos em vários níveis de abstração (requisitos e sub-requisitos). 2.7 INCONFORMIDADE COM PADRÕES Atualmente existem várias entidades nacionais e internacionais que definem padronização de software, inclusive para os seus artefatos a serem produzidos. São exemplos dessas entidades: IEEE Institute of Electrical and Electronic Engineers, ISO International Standardization Organization, IEC International Electrotechnical Commission, ABNT - Associação Brasileira de Normas Técnicas, etc. Neste sentido, seguir uma ou várias dessas padronizações no momento da elaboração do documento de ERS é altamente recomendável. Inclusive, um desses padrões IEEE Std 830 (Gonçalves & et al, 2004) já foi referenciado algumas vezes neste trabalho, justamente por ser um padrão que descreve as abordagens recomendadas para a especificação de requisitos de software. Portanto, se um documento de ERS for escrito de acordo com as diretrizes propostas por este padrão, estará seguindo as especificações de software; logo, estará mais propício a evitar erros na fase de definição dos requisitos, além de produzir um artefato bem mais consolidado e com qualidade.

13 FALTA DE TRACEABILIDADE Uma definição clara para traceabilidade (ou rastreabilidade), do inglês traceability, envolve a capacidade de identificar a versão do documento, permitindo recuperar informações de uma versão específica (Sinfic, 2009). Todavia, um documento de ERS diz-se rastreável se cada um dos seus requisitos é claro e há uma certa facilidade de identificação do mesmo requisito em versões futuras do desenvolvimento ou da documentação. Portanto, podem existir dois tipos de rastreabilidade: para estágios anteriores ao desenvolvimento (depende do fato de cada requisito se referir explicitamente à sua fonte em outros documentos que o originam) ou para todos os documentos que emanam do documento de ERS, sejam eles código ou documentação propriamente dita (depende do fato de cada requisito ter um nome ou um número de referência únicos). Portanto, traceabilidade de requisitos aumenta a habilidade do usuário para localizar a correspondência das entidades e ações dentro da base de conhecimento gerada para o documento de ERS (Cordes & Carver, 1988).

14 14 3 PROCESSO DE MELHORIA DE TESTES - TPI O modelo TPI foca na melhoria do processo de testes e ajuda a definir gradualmente os passos para sua evolução, levando em consideração o tempo, o custo e a qualidade. Foi desenvolvido porque a Intelligent & Quick Information Processing- IQUIP e seus clientes necessitavam de um modelo que suportasse as constantes mudanças do processo de testes. Analisando os prós e contras de várias metodologias, criaram o TPI, com o objetivo de identificar os problemas do processo e propor melhorias. O processo de teste é parte do processo total de desenvolvimento, demonstrado na Figura 1. Por isso, é de extrema importância analisar os problemas relacionados às atividades de teste e que impactos eles causam no processo geral (JACOBS, Moll, & Sotokes, 2000). Figura 1. Processo Total de Desenvolvimento

15 REQUISITOS DO TPI O TPI se baseia em um conjunto de requisitos, descritos a seguir, para que as práticas de melhoria sejam utilizadas gradualmente e que, aos poucos, o processo de testes seja modificado. Passos de melhoria específicos e controlados são possíveis: Esse é o requisito mais importante. Passos controláveis de melhoria podem ser possíveis, se implementados gradualmente. Objetividade: O modelo deve ser suficientemente controlável e objetivo, de modo que, se duas pessoas o analisarem, interpretem da mesma forma. Ações e Prioridades: Há diversos tipos de metodologias sendo usadas pelas empresas. Por esta razão, a melhoria do processo de testes deve priorizar as ações, fazer tomadas de decisão, para que o processo seja adaptável facilmente. Interdependência: O modelo precisa ser independente de qualquer metodologia de testes, ambiente de programação ou arquitetura de sistemas. 3.2 ESCOPO DO TPI O TPI possui vinte áreas chave dentro do processo de testes, onde cada área tem níveis que representam a maturidade do processo de testes utilizado na empresa. Cada nível possui checkpoints e sugestões de melhoria que respectivamente são os pontos de verificação que definem onde o processo se encaixa e os passos a seguir para se alcançar o nível desejado. A estrutura do TPI pode ser observada na Figura 2.

16 16 Key Areas Test Maturity Matrix Levels Checkpoints Improvement Figura 2. Estrutura do TPI Áreas Chave 1 Estratégia de teste: É focada na detecção de defeitos importantes o mais cedo possível. A estratégia define que requisitos e riscos serão cobertos por quais testes. 2 Modelo de ciclo de vida: Definição das fases, como planejamento, preparação, especificação, execução e finalização. Em cada fase, várias atividades são requeridas. Para cada atividade, os seguintes aspectos precisam ser definidos: proposta, entradas, processo, saídas, dependências, técnicas e ferramentas aplicadas, documentação etc. 3 Quando se envolver? O envolvimento tardio dos testes é um risco para o projeto, porque os defeitos são mais caros e mais difíceis de serem consertados. Por esta razão, os engenheiros de teste devem se envolver no início do projeto. 4 Estimativa e planejamento: Indica quais atividades serão executadas e que recursos serão necessários para os diversos tipos de projetos.

17 17 5 Técnicas de especificação de testes: Padronização do caminho para especificar casos de testes da fonte de informação. Aplicando estas técnicas, obtémse uma melhor qualidade e reusabilidade dos casos de testes. 6 Técnicas de teste estático: Nem tudo pode ser testado dinamicamente, ou seja, rodando programas. Inspeção de produtos, avaliação de medidas ou checklists são exemplos de técnicas de teste estático. 7 Métricas: Para o processo de testes, as métricas de progresso e de qualidade do sistema testado são muito importantes. Especificamente, para melhoria do processo de testes, as métricas devem avaliar as consequências de certas ações de melhoria. 8 Automação de testes: Quando possível, a automação serve para diminuir as horas de execução e ter um status dos resultados, o mais cedo possível. 9 Ambiente de Testes: Hardware, software, conexão com o banco de dados etc. O ambiente de testes tem uma grande influência na qualidade do software. 10 Ambiente de trabalho: Um desorganizado ambiente de trabalho pode desmotivar as pessoas e, consequentemente, impactar o resultado dos testes. 11 Comprometimento e motivação: A área de testes deve ter suficiente tempo e recursos (quantidade e qualidade) para que os profissionais trabalhem motivados e realizem bons testes. 12 Funções de testes e treinamento: Para a área de testes, uma mistura de diferentes conhecimentos, funções e perfis é requerida. É necessário ter experiência em testes, boa comunicação, conhecimento sobre o projeto e sobre a organização em geral. 13 Escopo da metodologia: A empresa deve usar uma metodologia suficientemente genérica para ser aplicada em diversas situações e não tenha a necessidade de ser remodelada a cada novo projeto.

18 18 14 Comunicação: No processo de teste, a comunicação é feita em diversos níveis, dependendo das pessoas envolvidas (desenvolvedor, usuário, cliente, gerente, etc). 15 Reportagem: Teste não é só detecção de defeitos, mas sim a principal maneira de melhorar a qualidade de software. O relatório de resultados deve, não só conter as causas dos defeitos, como também o melhor caminho para consertá-lo. 16 Gerenciamento dos defeitos: Deve ser capaz de acompanhar o ciclo de vida do defeito, além de dar suporte à análise e a resolução dos mesmos. 17 Gerenciamento dos documentos de testes: Os produtos (plano de testes, especificações e arquivos) de teste devem ser mantidos, reusáveis e gerenciáveis. 18 Gerenciamento do processo de testes: Para gerenciar as atividades de teste, é essencial seguir esses quatro passos: planejar, executar, checar e ajustar. O gerenciamento é vital para a realização dos testes. 19 Avaliação: Se inicia na inspeção de produtos intermediários de acordo com requisitos. Os defeitos são encontrados em estágios iniciais e o re-trabalho tem um custo baixo. 20 Testes de baixo nível: Testes unitários e de integração. Erros encontrados na fase de desenvolvimento.

19 PASSOS PARA IMPLANTAR A MELHORIA Figura 3. Modelo para Implantar Melhorias Como pode ser observado na Figura 3,, há uma série de passos, detalhados abaixo, para se implantar a melhoria do processo de testes. É preciso fazer uma análise de como está o processo atual, para verificar qual é o objetivo e estruturar a empresa para alcançá-lolo (Koomen & Pol, 1999). Obter conscientização: Saber que o processo precisa melhorar e ter compromisso, não só no início das mudanças, mas sim ao longo de todo o projeto. Determinar o alvo e a abordagem: Que áreas serão atacadas e quais as metas de melhoria? Primeira avaliação: Conhecimento da situação atual, a partir da matriz, são verificados os pontos fortes e fracos do processo de teste. Com base em entrevistas e documentação, os níveis das áreas-chave do TPI são definidos. Definir ações de melhoria: Baseadas nas metas e no resultado da avaliação. Os níveis das áreas-chave e a Matriz de Maturidade dão várias possibilidades para se definir a melhoria gradual do processo.

20 20 Formular plano: O plano aborda as atividades necessárias para orientar o processo de mudança em uma determinada direção. Implementar ações de melhoria: Execução do plano. São analisadas e executadas as ações para melhorar o processo de testes. Avaliação final: Qual foi o rendimento das ações implementadas? Nesta fase, o objetivo é mensurar as ações que foram executadas com sucesso, bem como avaliar se as metas iniciais foram cumpridas. Com base nestas observações, a decisão sobre a continuação do processo de mudança será tomada. 3.4 RELAÇÃO DE REQUISITOS COM O TPI Embora seja comum a execução dos testes só começar após implementado o software, o processo de testes pode e deve ser iniciado com mais antecedência. Se os responsáveis por testes se envolvem o quanto antes, os erros do sistema são detectados previamente, consequentemente são mais fáceis de serem resolvidos e seu conserto tem um custo bem menor. A área três do TPI defende que o envolvimento dos testes no momento da definição dos requisitos provê maior segurança ao cliente em relação à qualidade do software. A grande vantagem é que os requisitos, quando testados, se tornam mais completos, mensuráveis, com o critério de aceitação definido. Há uma discussão prévia sobre o que foi definido incorretamente, evitando muitos dos problemas descritos na seção anterior e fazendo com que o sistema seja implementado com mais clareza e eficiência. A sugestão de melhoria proposta para que o processo proveja a execução dos testes no levantamento de requisitos é treinar os engenheiros de testes de forma que eles tenham conhecimento suficiente para, na elicitação dos requisitos, revisá-los, sugerir mudanças e extrair casos de testes.

21 21 4 TESTES NA ENGENHARIA DE REQUISITOS A parte mais difícil do desenvolvimento de um sistema de software é decidir o que é necessário para construí-lo. Nenhuma outra parte do trabalho conceitual é tão difícil quanto definir os requisitos técnicos detalhados, inclusive todas as interfaces com as pessoas, com as máquinas, e com outros softwares. Nenhuma outra parte do trabalho é tão crítica para o resultado final do sistema, se for realizada de forma errônea. Nenhuma outra parte é mais difícil de corrigir tardiamente (Brooks). Segundo o The Standish Group (The Standish Group, 1995), de acordo com as opiniões relativas aos fatores mais prejudiciais aos projetos, Requisitos Incompletos foi classificado como o principal fator, liderando o ranking. Além desse, foram abordados ainda: Falta de Envolvimento do Usuário, Falta de Recursos, Expectativas Irreais, Falta de Suporte Executivo, Mudanças de Requisitos e Especificações, Falta de Planejamento, Funcionalidades desnecessárias, Falta de Gerenciamento de TI, Falta de conhecimento da Tecnologia e Outros, conforme a Tabela 1 abaixo. Fatores Prejudiciais aos Projetos % de Respostas Requisitos Incompletos 13.1% Falta de Envolvimento do Usuário 12.4% Falta de Recursos 10.6% Expectativas Irreais 9.9% Falta de Suporte Executivo 9.3% Mudanças de Requisitos & Especificações 8.7% Falta de Planejamento 8.1% Funcionalidades desnecessárias 7.5% Falta de Gerenciamento de TI 6.2% Ignorância da Tecnologia 4.3% Outros 9.9% Tabela 1. Fatores Prejudiciais aos Projetos

22 22 Considerando ainda um Processo de Engenharia de Software tradicional, como por exemplo o Rational Unified Process RUP 2 (Rational Software Corporation, ), verifica-se que (Figura 4) a disciplina de Requisitos possui uma ênfase maior durante as primeiras iterações do projeto. Por isso, torna-se imprescindível uma maior atenção para a fase de Especificação dos Requisitos de Software, pois se estima que o custo de descobrir e corrigir um defeito nas iterações posteriores seja bem maior. Figura 4. Rational Unified Process RUP No processo da Engenharia de Requisitos tradicional, existem quatro atividades a serem seguidas (Kotonia & Sommerville, 1997): 1. Elicitação dos Requisitos os requisitos do sistema são descobertos através de consultas aos stakeholders, de documentos do sistema, padrões, conhecimento organizacional e pesquisas de mercado; 2 O RUP é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis. (Rational Software Corporation, )

23 23 2. Análise e Negociação dos Requisitos os requisitos são analisados detalhadamente, verificando alguns fatores (necessidade, consistência, completude), e os stakeholders negociam para decidir quais requisitos serão aprovados; 3. Documentação dos Requisitos os requisitos aprovados são documentados em um nível de detalhe apropriado, de forma que facilite a comunicação (entendimento dos requisitos) entre os desenvolvedores e todos os stakeholders do sistema; 4. Validação dos Requisitos certifica que os requisitos estão consistentes e completos, descritos de forma que possibilite o desenvolvimento do sistema. Seguindo a terceira área chave do TPI (descrita no capítulo anterior), a qual indica que os engenheiros de teste devem se envolver no início do projeto, concluise que se torna cada vez mais importante a realização de Testes de Requisitos, não só na atividade de Validação dos Requisitos, mas sim em todo processo Engenharia de Requisitos. Desta forma, poderão ser minimizados não somente os riscos de ocorrer algum daqueles problemas de requisitos que foram descritos no capítulo 2 deste trabalho, mas também os re-trabalhos nas fases finais do ciclo de desenvolvimento de software. 4.1 TESTES NO CICLO DE VIDA DO SOFTWARE A estrutura do Modelo V é uma aproximação estruturada de testes que pode ser usada durante o ciclo de vida do software. Focaliza se em testar durante todo o ciclo de desenvolvimento para conseguir uma detecção adiantada dos erros (Martins, 2009). Este modelo está representado na Figura 5 a seguir (Qualiti, 2002):

24 24 Figura 5. Modelo V Verificação e Validação A letra V simboliza a igualdade entre as tarefas de desenvolvimento e testes: o lado esquerdo representa o processo de desenvolvimento e o lado direito o processo de integração e testes. No processo de desenvolvimento, temos: 1. Especificação de Requisitos as necessidades dos clientes são coletadas, especificadas e aprovadas, definindo os propósitos do sistema e suas características; 2. Projeto Funcional do Sistema os requisitos são mapeados em funções; 3. Projeto Técnico do Sistema a implementação do sistema é projetada, as interfaces são definidas e o sistema é decomposto em subsistemas; 4. Especificação de componentes são definidas as tarefas, comportamentos, estruturas internas e interfaces de cada subsistema (cada subsistema é independente e pode ser codificado e testado sem interferências externas);

25 25 5. Programação codificação de cada componente específica na linguagem de programação escolhida. No processo de integração e testes, temos: 1. Teste de Componente verifica se cada componente do software está de acordo com sua especificação; 2. Teste de Integração verifica se grupos de componentes colaboram para o andamento especificado pelo projeto técnico do sistema; 3. Teste de Sistema verifica se o sistema como um todo está de acordo com os requisitos especificados; 4. Teste de Aceitação verifica se o sistema está de acordo com o que foi especificado no contrato, do ponto de vista do cliente. Em cada nível de teste o resultado do desenvolvimento precisa ser comparado aos requisitos especificados; trata-se do processo de validação. A verificação se refere apenas a uma fase no processo de desenvolvimento, ou seja, deve assegurar que o resultado de uma fase em particular do desenvolvimento tenha sido construída corretamente e com completude de acordo com sua especificação. Em algum momento pode parecer que os testes começam tarde, apenas após a codificação. Porem, os testes realizados no processo de integração e testes do Modelo V (lado direito), devem ser interpretados como níveis de execução dos testes. Porém, a preparação (planejamento, análise, execução etc) dos testes começa antes e são feitos em paralelo com as fases de desenvolvimento (Figura 6).

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

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

MODELO CMM MATURIDADE DE SOFTWARE

MODELO CMM MATURIDADE DE SOFTWARE MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo

Leia mais

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

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 QUALIDADE DE SOFTWARE Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 Objetivos Apresentar o processo de gerenciamento de qualidade e as atividades centrais da garantia de

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

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

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

Implantação de um Processo de Medições de Software

Implantação de um Processo de Medições de Software Departamento de Informática BFPUG Brazilian Function Point Users Group Implantação de um Processo de Medições de Software Claudia Hazan, MSc., CFPS claudinhah@yahoo.com Agenda Introdução Processo de Medições

Leia mais

Gerenciamento de Níveis de Serviço

Gerenciamento de Níveis de Serviço Gerenciamento de Níveis de Serviço O processo de Gerenciamento de Níveis de Serviço fornece o contato entre a organização de TI e o cliente, para garantir que a organização de TI conhece os serviços que

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

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

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

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

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

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

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

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 3 Planejamento e Aula 8 do Projeto Aula 08 do Projeto SUMÁRIO INTRODUÇÃO... 3 ACOMPANHAMENTO DO PROJETO... 3 1. do Progresso...

Leia mais

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010

1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010 Engenharia de Software Aula 5 (Versão 2010-02) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br

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

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

Melhorias de Processos de Engenharia de Software

Melhorias de Processos de Engenharia de Software Melhorias de Processos de Engenharia de Software CMMI 1 Profa. Reane Franco Goulart O que é CMMI? O Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processos que fornece às

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Gerenciamento de Problemas

Gerenciamento de Problemas Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar

Leia mais

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

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

Leia mais

Processos de gerenciamento de projetos em um projeto

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

Gerência de Projetos

Gerência de Projetos Gerência de Projetos Escopo Custo Qualidade Tempo CONCEITO PROJETOS: são empreendimentos com objetivo específico e ciclo de vida definido Precedem produtos, serviços e processos. São utilizados as funções

Leia mais

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

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

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

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

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

Levantamento, Análise e Gestão Requisitos. Aula 12 Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

Metodologia de Gerenciamento de Projetos da Justiça Federal Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

Professor: Curso: Disciplina:

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

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Qualidade de Software. Anderson Belgamo

Qualidade de Software. Anderson Belgamo Qualidade de Software Anderson Belgamo Qualidade de Software Software Processo Produto Processo de Software Pessoas com habilidades, treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos

Leia mais

Gerenciamento de Incidentes

Gerenciamento de Incidentes Gerenciamento de Incidentes Os usuários do negócio ou os usuários finais solicitam os serviços de Tecnologia da Informação para melhorar a eficiência dos seus próprios processos de negócio, de forma que

Leia mais

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Teste de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Teste de software

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 Renan J. Borges 1, Késsia R. C. Marchi 1 1 Universidade Paranaense (UNIPAR) Paranavaí, PR Brasil renanjborges@gmail.com, kessia@unipar.br

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

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

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

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

Planejamento e Gerenciamento de Software. Tema 3. Gerência de Projetos Profa. Susana M. Iglesias

Planejamento e Gerenciamento de Software. Tema 3. Gerência de Projetos Profa. Susana M. Iglesias Planejamento e Gerenciamento de Software Tema 3. Gerência de Projetos Profa. Susana M. Iglesias Planejamento A primeira atividade do gerenciamento de projeto é Planejamento Depende de estimativas (Grado

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico

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

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Processo de Implementação de um Sistema de Gestão da Qualidade

Processo de Implementação de um Sistema de Gestão da Qualidade 3 Processo de Implementação de um Sistema de Gestão da Qualidade Não existe um jeito único de se implementar um sistema da qualidade ISO 9001: 2000. No entanto, independentemente da maneira escolhida,

Leia mais

Verificação é um processo para se determinar se os produtos, (executáveis ou

Verificação é um processo para se determinar se os produtos, (executáveis ou ATIVIDADES VV&T E A NORMA IEEE 1012 A qualidade do software está diretamente relacionada à satisfação do cliente, sendo assim, as empresas estão percebendo a importância em produzir software com qualidade.

Leia mais

Gerenciamento de Projetos Modulo VIII Riscos

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

MUDANÇAS NA ISO 9001: A VERSÃO 2015

MUDANÇAS NA ISO 9001: A VERSÃO 2015 MUDANÇAS NA ISO 9001: A VERSÃO 2015 Está em andamento o processo de revisão da Norma ISO 9001: 2015, que ao ser concluído resultará na mudança mais significativa já efetuada. A chamada família ISO 9000

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

A importância da comunicação em projetos de

A importância da comunicação em projetos de A importância da comunicação em projetos de Tecnologia da Informação (TI) Autor: Ivan Luizio R. G. Magalhães Um perigo previsto está metade evitado. Thomas Fuller Introdução Há muitos anos atrás, um bom

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2 .:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento

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

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

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

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos

Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Gerenciamento de Serviços de TI ITIL v2 Módulo 1 Conceitos básicos Referência: An Introductory Overview of ITIL v2 Livros ITIL v2 Cenário de TI nas organizações Aumento da dependência da TI para alcance

Leia mais

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

GERÊNCIA DE INTEGRAÇÃO DO PROJETO GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Roteiro Inspeção Defeitos dos Software Classificação dos Erros Técnica de Leitura Ad-hoc Checklist Exercício Inspeção Inspeção de Software Definição É um método de análise estática

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capí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 mais

Sistemas de Gerenciamento de Banco de Dados

Sistemas de Gerenciamento de Banco de Dados Sistemas de Gerenciamento de Banco de Dados A U L A : C R I A Ç Ã O D E B A N C O D E D A D O S - R E Q U I S I T O S F U N C I O N A I S E O P E R A C I O N A I S P R O F. : A N D R É L U I Z M O N T

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Gerenciamento de Requisitos

Gerenciamento de Requisitos Gerenciamento de Requisitos Jaelson Castro 2013 1 Gerenciamento de requisitos Relaciona-se ao processo de gerenciar a mudança dos requisitos de um sistema As principais preocupações do gerenciamento de

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

Engenharia de Requisitos- como Previnir e Reduzir Riscos Engenharia de Requisitos- como Previnir e Reduzir Riscos Natasha de Souza Arruda natasha.arruda@ig.com.br FGS Resumo:Engenharia de Requisitos é um dos processos fundamentais para o desenvolvimento de software.

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

Atividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software

Atividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software Módulo 1 SCE186-ENGENHARIA DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br CONSTRUÇÃO Planejamento do Codificação Teste MANUTENÇÃO Modificação 2003 2 Planejamento do Gerenciamento CONSTRUÇÃO de Codificação

Leia mais

1 2009 CBG Centro Brasileiro de Gestão

1 2009 CBG Centro Brasileiro de Gestão 1 2009 CBG Centro Brasileiro de Gestão ISO 9001:2015 Histórico da série 2 2009 CBG Centro Brasileiro de Gestão Histórico da série REVISÕES DA SÉRIE ISO 9000 2000 2008 2015 1994 1987 3 2009 CBG Centro Brasileiro

Leia mais

Extração de Requisitos

Extraçã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 mais

Pontos de Função. André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos. Engenharia de Software Mestrado Ciência da Computação - UFMS

Pontos de Função. André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos. Engenharia de Software Mestrado Ciência da Computação - UFMS Pontos de Função André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos Engenharia de Software Mestrado Ciência da Computação - UFMS Roteiro Introdução Métricas de Projeto Análise de Pontos de Função

Leia mais

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista )

Requisitos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Qualidade de Software Aula 8 (Versão 2012-01) 01) Requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Revisando... 1. Qual o

Leia mais

Desafio Profissional PÓS-GRADUAÇÃO 2012. Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira

Desafio Profissional PÓS-GRADUAÇÃO 2012. Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira Desafio Profissional PÓS-GRADUAÇÃO 12 Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira 1 DESAFIO PROFISSIONAL Disciplinas: Ferramentas de Software para Gestão de Projetos. Gestão de

Leia mais

Modelos de Qualidade de Produto de Software

Modelos de Qualidade de Produto de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Modelos de Qualidade de Produto de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

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

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

Leia mais

Planejamento de Projetos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista )

Planejamento de Projetos. Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Qualidade de Software Aula 9 (Versão 2012-01) 01) Planejamento de Projetos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( http://sites.google.com/site/professorgabrielbaptista ) Revisando...

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.

SETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014. A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor

Leia mais

Gerenciamento de Riscos do Projeto Eventos Adversos

Gerenciamento de Riscos do Projeto Eventos Adversos Gerenciamento de Riscos do Projeto Eventos Adversos 11. Gerenciamento de riscos do projeto PMBOK 2000 PMBOK 2004 11.1 Planejamento de gerenciamento de riscos 11.1 Planejamento de gerenciamento de riscos

Leia mais

Processos de Software

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

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web

Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Resumo. Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Autor: Danilo Humberto Dias Santos Orientador: Walteno Martins Parreira Júnior Bacharelado em Engenharia da Computação

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

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software Prof. Dr. Juliano Lopes de Oliveira (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

Leia mais