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

Engenharia de Software

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

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

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

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

ENGENHARIA DE REQUISITOS

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

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) Universidade Federal de Santa Catarina Departamento de Informática e Estatística INE Curso: Sistemas de Informação Disciplina: Projetos I Professor: Renato Cislaghi Aluno: Fausto Vetter Orientadora: Maria

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

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

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

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

Uma Experiência de Engenharia de Requisitos em Empresas de Software

Uma Experiência de Engenharia de Requisitos em Empresas de Software Uma Experiência de Engenharia de Requisitos em Empresas de Software Carina Frota Alves Centro de Informática, Universidade Federal de Pernambuco, Brasil cfa@cin.ufpe.br Resumo. Este artigo apresenta uma

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

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

Modelos de processos de desenvolvimento de software

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

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering.

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering. Parte I Requirement Engineering Gestão de Projectos Informáticos Gestão do Âmbito (Scope Management) Requirement Engineering Introduzir as noções requisitos de sistema e processo de engª de requisitos

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

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

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

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

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

Leia mais

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

Engenharia de Requisitos de Software. Visão Geral

Engenharia de Requisitos de Software. Visão Geral de Software Visão Geral João Sousa Apoio: Desenvolvimento de Sw - Como estamos? Segundo o Standish Group (CHAOS Report 2004): 34% dos projetos com sucesso. 15% dos projetos cancelados antes de completados.

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

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

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Software Gerenciamento de Requisitos Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Requisitos (ER) Engenharia de O termo Engenharia implica em dizer que um processo sistemático

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

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

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 Capítulo 8 Gerenciamento da Qualidade do Projeto O Gerenciamento da Qualidade do Projeto inclui os processos necessários para garantir que o projeto irá satisfazer as necessidades para as quais ele foi

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Engenharia de Requisitos. Aécio Costa

Engenharia de Requisitos. Aécio Costa Aécio Costa Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004) Um requisito é algo que o sistema é capaz

Leia mais

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

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

Leia mais

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

Engenharia de Software Software Requirements

Engenharia de Software Software Requirements Requisitos Engenharia de Software Software Requirements SWEBOK, Capítulo 2 Primeira Classificação de Requisito 1. Requisito do usuário: declarações sobre as funções que o sistema deve oferecer 2. Requisito

Leia mais

A Importância do Controle da Qualidade na Melhoria de Processos de Software

A Importância do Controle da Qualidade na Melhoria de Processos de Software A Importância do Controle da Qualidade na Melhoria de Processos de Software Ana Liddy Cenni de Castro Magalhães 1 1 SWQuality Consultoria e Sistemas analiddy@swquality.com.br Resumo. Este trabalho visa

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

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

Introdução ao OpenUP (Open Unified Process)

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

Leia mais

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

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

Leia mais

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

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

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa

Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Aplicação da ISO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de Software de uma Pequena Empresa Odair Jacinto da Silva 1, Carlos Alberto Borges 1, Clênio Sampaio Salviano 2, Adalberto N. Crespo

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

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

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

Leia mais

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

Requisitos de Software

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

Leia mais

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE O GERENCIAMENTO DE REQUISITOS E A SUA IMPORTÂNCIA EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE Leonardo Manoel Mendes¹, Rogério Homem da Costa², Reinaldo Lorenso³ 1. Especializando do Curso de Pós-Graduação

Leia mais

Documento de Requisitos

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

Leia mais

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

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

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

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

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

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

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Tiago Domenici Griffo 1, Gothardo Francisco de Magalhães Santos 1, Rodrigo Becke Cabral 1 1

Leia mais

Introdução à Engenharia de Requisitos

Introdução à Engenharia de Requisitos Introdução à Engenharia de Requisitos Ana Luiza Ávila analuizaavila@yahoo.com.br É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) e Mestre em Ciências da Computação pela PUC-Rio

Leia mais

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA?

A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? A PROBLEMÁTICA DO DESENVOLVIMENTO DE SOFTWARE: CRISE OU CALAMIDADE CRÔNICA? ADEMILSON ANGELO CABRAL Discente da AEMS Faculdades Integradas de Três Lagoas DIEGO BEZERRA DA SILVA Discente da AEMS Faculdades

Leia mais

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

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

Leia mais

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

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

Leia mais

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

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo

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

Verificação e Validação de Requisitos

Verificação e Validação de Requisitos Verificação e Validação de Requisitos Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência

Leia mais

Eduardo Alves de Oliveira. eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio

Eduardo Alves de Oliveira. eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio Eduardo Alves de Oliveira eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio Processo de Desenvolvimento de Software; Produtividade:

Leia mais

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

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

Leia mais

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

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

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento Ciência da Computação ENGENHARIA DE SOFTWARE Planejamento e Gerenciamento Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Pessoas, Produto, Processo e Projeto; 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

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

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

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

24/04/2011 GERÊNCIA DO ESCOPO PMBOK GESTÃO DE PROJETOS NA PRÁTICA

24/04/2011 GERÊNCIA DO ESCOPO PMBOK GESTÃO DE PROJETOS NA PRÁTICA GESTÃO DE PROJETOS NA PRÁTICA Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol 1 No contexto do projeto, 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

Definição do Framework

Definição do Framework Definição do Framework 1. Introdução 1.1. Finalidade Este documento tem por finalidade apresentar o mapeamento dos processos de Definição de Processo Organizacional e Avaliação e Melhoria do Processo dos

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

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

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

Leia mais

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas?

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Fábio Martinho. obtido [on-line] na URL http://www.testexpert.com.br/?q=node/669, em 11/03/2008. Segundo a NBR

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

Elicitação e Análise de Requisitos. Slide 1

Elicitação e Análise de Requisitos. Slide 1 Elicitação e Análise de Requisitos Slide 1 Objetivos Descrever o processo da elicitação e análise requisitos. Introduzir um número de técnicas elicitação de requisitos e análise de requisitos. Discutir

Leia mais

Práticas de IHC versus Processos de Engenharia de Software: Uma Análise para Adoção

Práticas de IHC versus Processos de Engenharia de Software: Uma Análise para Adoção Práticas de IHC versus Processos de Engenharia de Software: Uma Análise para Adoção Joyce Cristina Souza Bastos 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação - Instituto de Ciências Exatas

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Extração de Requisitos

Extração de Requisitos Extração de Requisitos Criação: Março 2001 Atualização: Setembro 2005 Referências I.Sommerville. Sw Engineering, 6ª ed, 2001, cap6 P.Jalote. An Integrated Approach to Sw Engineering, 2ª ed., 1997, cap3

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 (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications) A boa organização lógica do documento

Leia mais

Fatores humanos de qualidade CMM E CMMI

Fatores humanos de qualidade CMM E CMMI Fatores humanos de qualidade CMM E CMMI Eneida Rios¹ ¹http://www.ifbaiano.edu.br eneidarios@eafcatu.gov.br Campus Catu 1 Curso de Análise e Desenvolvimento de Sistemas Conteúdos Fatores humanos de qualidade

Leia mais

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Micaelly P. Soares e Silva, Carla I. M. Bezerra, Camilo C. Almendra, Enyo José T. Gonçalves Universidade

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

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Processo de Eng. Requisitos p Composto por quatro (ou cinco) atividades de alto nível (Soares, 2005): p Viabilidade p Identificação. p Análise e negociação. p Especificação e documentação.

Leia mais

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

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

Leia mais

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process Capítulo 6: PSP Personal Software Process Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6: PSP

Leia mais