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

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

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

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

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

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

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

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

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 na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

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

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

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

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

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

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

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

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

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

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Engenharia de Software 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

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

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

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

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

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

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

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

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1.

Autor(es) BARBARA STEFANI RANIERI. Orientador(es) LUIZ EDUARDO GALVÃO MARTINS, ANDERSON BELGAMO. Apoio Financeiro PIBIC/CNPQ. 1. 19 Congresso de Iniciação Científica ESPECIFICAÇÃO E IMPLEMENTAÇÃO DE UMA FERRAMENTA AUTOMATIZADA DE APOIO AO GERSE: GUIA DE ELICITAÇÃO DE REQUISITOS PARA SISTEMAS EMBARCADOS Autor(es) BARBARA STEFANI

Leia mais

GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE GESTÃO DO CONHECIMENTO EM UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE RESUMO Carlos Eduardo Spolavori Martins 1 Anderson Yanzer Cabral 2 Este artigo tem o objetivo de apresentar o andamento de uma pesquisa

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

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

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

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

Engenharia de Software

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

Leia mais

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

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

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

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Metodologia de Desenvolvimento de Sistemas Aula 1 Ementa Fases do Ciclo de Vida do Desenvolvimento de Software, apresentando como os métodos, ferramentas e procedimentos da engenharia de software, podem

Leia mais

Módulo 3 Procedimento e processo de gerenciamento de riscos, PDCA e MASP

Módulo 3 Procedimento e processo de gerenciamento de riscos, PDCA e MASP Módulo 3 Procedimento e processo de gerenciamento de riscos, PDCA e MASP 6. Procedimento de gerenciamento de risco O fabricante ou prestador de serviço deve estabelecer e manter um processo para identificar

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

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

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

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

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

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

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

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

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos White Paper TenStep 2007 Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos Não há nenhuma duvida

Leia mais

Engenharia de Sistemas de Computador

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

Leia mais

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

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

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

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

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

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

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

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro Metodologia para Planejamento, Execução e Controle de Teste de Software Arilo Claudio Dias Neto - acdn@cos.ufrj.br Gladys Machado P. S. Lima - gladysmp@cos.ufrj.br Guilherme Horta Travassos - ght@cos.ufrj.br

Leia mais

Políticas de Segurança da Informação. Aécio Costa

Políticas de Segurança da Informação. Aécio Costa Aécio Costa A segurança da informação é obtida a partir da implementação de um conjunto de controles adequados, incluindo políticas, processos, procedimentos, estruturas organizacionais e funções de software

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

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

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

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

Estratégias de Pesquisa

Estratégias de Pesquisa Estratégias de Pesquisa Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Agenda Survey Design e Criação Estudo de Caso Pesquisa Ação Experimento

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

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

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

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 I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

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

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

Código de prática para a gestão da segurança da informação

Código de prática para a gestão da segurança da informação Código de prática para a gestão da segurança da informação Edição e Produção: Fabiano Rabaneda Advogado, professor da Universidade Federal do Mato Grosso. Especializando em Direito Eletrônico e Tecnologia

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

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

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

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

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

3. Engenharia de Requisitos

3. Engenharia de Requisitos Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton)

Leia mais

Gerenciamento de Projeto

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

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

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

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

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

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

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

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

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

CobiT 4.1 Plan and Organize Manage Projects PO10

CobiT 4.1 Plan and Organize Manage Projects PO10 CobiT 4.1 Plan and Organize Manage Projects PO10 Planejar e Organizar Gerenciar Projetos Pedro Rocha http://rochapedro.wordpress.com RESUMO Este documento trás a tradução do objetivo de controle PO10 (Gerenciamento

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

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

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

Avaliação de Riscos Aplicada à Qualidade em Desenvolvimento de Software

Avaliação de Riscos Aplicada à Qualidade em Desenvolvimento de Software Rafael Espinha, Msc rafael.espinha@primeup.com.br +55 21 9470-9289 Maiores informações: http://www.primeup.com.br riskmanager@primeup.com.br +55 21 2512-6005 Avaliação de Riscos Aplicada à Qualidade em

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