ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS GUSTAVO KATAOKA

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS GUSTAVO KATAOKA"

Transcrição

1 ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE SISTEMAS GUSTAVO KATAOKA USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL CAMPO GRANDE MS 2012

2 GUSTAVO KATAOKA USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL Monografia apresentada ao Curso de Pós- Graduação em Engenharia de Software da Escola Superior Aberta do Brasil como requisito para obtenção do título de Especialista em Engenharia de Sistemas, sob orientação Profa. Ma. Rachel Cristina Mello Guimarães. CAMPO GRANDE MS 2012

3 GUSTAVO KATAOKA USO DE TESTES DE SOFTWARE NA METODOLOGIA ÁGIL Monografia aprovada em... de... de Banca Examinadora CAMPO GRANDE MS 2012

4 RESUMO Com a popularização do desenvolvimento ágil, surgem dúvidas em como se deve proceder com os testes em um software, pois alguns dos seus princípios podem ser confundidos com a falta de metodologia. O estudo objetiva descobrir como o desenvolvimento ágil aborda os testes de software, sendo o teste totalmente dependente da documentação produzida para este software. Dessa forma, utiliza a pesquisa caracterizada como indutiva do tipo qualitativa de caráter exploratório utilizando estudos realizados anteriormente, disponíveis em publicações como livros, teses, dissertações e artigos científicos. Conclui que o principal princípio do desenvolvimento ágil é a entrega contínua de funcionalidades de um software ao cliente. Palavras-chave: Desenvolvimento ágil. Teste de software. Qualidade de software.

5 SUMÁRIO CAPITULO 1 - INTRODUÇÃO JUSTIFICATIVA OBJETIVOS Objetivo geral Objetivos específicos DELIMITAÇÃO DO TRABALHO METODOLOGIA ORGANIZAÇÃO DO TRABALHO... 9 CAPITULO 2 - TESTE DE SOFTWARE VALIDAÇÃO DE REQUISITOS QUALIDADE DE SOFTWARE ATRAVÉS DE TESTES DEFINIÇÕES DO QUE OS TESTES PODEM IDENTIFICAR Falha Falta Erro Defeito VALIDAÇÃO E VERIFICAÇÃO VISÃO GERAL DAS TÉCNICAS DE TESTE DE SOFTWARE Testes de caixa branca Testes de caixa preta Testes de caixa cinza FASES DE TESTE DE SOFTWARE Teste Unitário Teste de Integração Teste de Sistema Teste de Aceitação CONSIDERAÇÕES SOBRE O CAPÍTULO CAPITULO 3 - DESENVOLVIMENTO ÁGIL PLANEJAMENTO NO DESENVOLVIMENTO ÁGIL ESTIMANDO AS HISTÓRIAS DE USUÁRIO Planning Poker... 36

6 3.3. EXECUÇÃO DO PLANEJAMENTO MÉTODOS ÁGEIS Feature Driven Development Extreme Programming Scrum CAPITULO 4 - TEST DRIVEN DEVELOPMENT O QUE É O TDD? CICLO DE VIDA DO TDD TIPOS DE TESTES UTILIZADOS NO TDD Teste Unitário Teste de Integração Teste de Aceitação EXEMPLO SIMPLES DE UTILIZAÇÃO DO TDD CAPITULO 5 - CONCLUSÃO REFERÊNCIAS... 57

7 6 CAPITULO 1 - INTRODUÇÃO O desenvolvimento de software vem, ao longo do tempo, sofrendo diversas mudanças. Partindo de um processo caótico ou inexistente, passando por metodologias burocráticas e pesadas, até chegar a estratégias que visem a melhoria da qualidade e redução de custos. O teste de software é uma das principais atividades realizadas no processo de desenvolvimento de um produto de software, sendo responsável, segundo Sommerville (2011), por cerca de 40% do esforço realizado pela equipe de desenvolvimento. No passado, o teste não era tratado com a devida importância, agora é cada vez mais visto como atividade essencial no desenvolvimento e entrega de um software. Entretanto, testes pobres ou ineficazes podem ser tão ruins quanto nenhum teste realizado e pode custar tempo, esforço e custo significativo, pois além de não contribuir para melhorar a qualidade do software, tem como resultado que seus clientes são os que irão encontrar e relatar os defeitos em seu software (WATKINS, 2009). A experiência adquirida com o tempo mostra que o gasto com esforço em desenvolvimento e confecção de testes de software é melhor do que ter a credibilidade da organização afetada por causar prejuízos a clientes devido a funcionalidades que não foram testadas devidamente. Atualmente está se passando uma evolução no se diz respeito ao desenvolvimento de software, com o Desenvolvimento Ágil (também referenciado como Método Ágil) em ascensão. Esse método trás consigo um conjunto de princípios que chamam muito a atenção de quem os vê pela primeira vez. Um desses princípios que mais se destaca na visão deste autor é o que diz: Priorize o software funcionando do que a produção de documentação extensa. Um dos principais objetivos do teste de software, segundo Sommerville (2011), é demonstrar que o software atende aos requisitos para o qual fora proposto. Logo,

8 7 para produzir os testes do software é necessária a documentação de requisitos desse software. Como o desenvolvimento ágil, ao propor que se priorize o software funcionando acima de sua documentação, trata a confecção das várias formas de testes na produção de um software e de que forma isso contribui para a garantia de qualidade no software produzido? Este trabalho está focado em encontrar e organizar as idéias de vários autores dessa área de maneira a responder esse questionamento JUSTIFICATIVA Com o crescimento da adoção de metodologias ágeis de desenvolvimento de software, surge a preocupação em como os testes de um produto de software será tratado durante o processo de produção do mesmo. Essa preocupação se deve ao fato de que um dos princípios do desenvolvimento ágil de software diz que se deve priorizar o software em funcionamento do que a documentação do mesmo (RÜPING, 2003). As metodologias de desenvolvimento tradicionais baseiam a confecção dos testes em cima da documentação produzida. E como produzir os testes para um software que pode ter documentação escassa? A justificativa para esse estudo é esclarecer que, apesar de ser flexível e adaptativa à equipe e aos projetos, o desenvolvimento ágil também objetiva a melhoria da qualidade do software. E uma das formas para atingir esse objetivo é através dos testes de software OBJETIVOS Os objetivos estabelecidos para esse estudo foram definidos conforme apresentado a seguir.

9 Objetivo geral Descobrir de que maneiras as metodologias ágeis de desenvolvimento de software confeccionam os testes de um sistema a ser produzido e como isso pode contribuir para a garantia de qualidade desse sistema Objetivos específicos 1. Estudar as principais formas de testes aplicáveis ao desenvolvimento de software; 2. Conceitualizar as principais metodologias de desenvolvimento ágil; 3. Identificar as formas como cada metodologia ágil estudada trata o planejamento e execução de testes durante o desenvolvimento de um produto de software DELIMITAÇÃO DO TRABALHO A proposta deste trabalho é desvendar quais as principais formas de teste de caixa branca, caixa preta e caixa cinza e suas estratégias para a confecção, bem como suas fases de execução. Este trabalho também foca em estudar o desenvolvimento ágil, mostrando alguns de seus métodos. Os métodos apresentados serão Scrum, Programação Extrema e Feature Driven Development (FDD). Também é apresentado o Test Driven Development (TDD), sendo dedicado um capítulo inteiro a ele METODOLOGIA A pesquisa deste trabalho caracteriza-se como indutiva do tipo qualitativa de caráter exploratório. Utiliza estudos realizados anteriormente, disponíveis em publicações como livros, teses, dissertações e artigos científicos sobre o tema proposto. Para a avaliação do material pesquisado é aplicada uma análise e descrição de conteúdo, buscando obter indicadores que permitam compreender melhor o tema.

10 ORGANIZAÇÃO DO TRABALHO Este trabalho está organizado da forma como apresentado a seguir: Capítulo 2 - Este capítulo apresenta uma revisão bibliográfica sobre teste de software. Mostrando a sua importância para a garantia de qualidade de um produto, quais os principais tipos de testes existentes e em que fases são aplicados. Capítulo 3 - Conceitualiza o desenvolvimento ágil de software. Apresenta os princípios defendidos pelo chamado Manifesto Ágil, diferença dos modelos tradicionais e teóricos de desenvolvimento, quais os principais métodos e de que forma cada um dos métodos apresentados contribui para melhorar o processo de teste de software. Capítulo 4 - Apresenta a metodologia de desenvolvimento ágil orientado a testes (Test Driven Development TDD). O TDD trata-se de um método ágil. O motivo pelo qual fora dedicado um capítulo exclusivamente para isso deve-se ao fato de o TDD representar a união dos dois objetos de estudo deste trabalho, no caso o Teste de Software e Desenvolvimento Ágil.

11 10 CAPITULO 2 - TESTE DE SOFTWARE Para Pressman (2010), o teste de software é um dos elementos que compõe a gestão de qualidade e seve para descobrir erros cometidos inadvertidamente ao projetar e construir um software. Um dos aspectos mais críticos para a qualidade de um produto de software customizado que deve ser levado em consideração é que o software deve atender aos requisitos desejados pelo cliente (NAIK; TRIPATHY, 2008). Isso pode ser facilmente observado quando nos deparamos com alguns requisitos impostos por clientes que, muitas vezes, para o desenvolvedor não faz o menor sentido, mas que deve ser atendido para que satisfaça o seu desejo. Segundo Sommerville (2011), o processo de teste de software possui dois objetivos distintos, sendo eles descritos como segue: 1. Demonstrar ao desenvolvedor e ao cliente de que o software atende aos requisitos no qual fora proposto. Para um software customizado, isso significa que deve haver pelo menos um teste para cada requisito listado no documento de requisitos de usuário e de sistema. Para um produto de software genérico, significa que deve existir testes para todas as funcionalidades do sistema que irão incorporar o produto a ser lançado; 2. Descobrir falhas e defeitos no software onde o seu comportamento está incorreto, indesejado ou fora das conformidades de suas especificações. Isso engloba comportamento indesejável do sistema, tais como: falhas, cálculos incorretos e corrupção de dados. Já Lewis (2009) diz que teste não é apenas uma atividade para encontrar bugs 1, é também utilizado com o objetivo de assegurar a qualidade de software medindo seus atributos e capacidades seguindo de encontro às expectativas e normas aplicáveis, fornecendo informações valiosas sobre o esforço de desenvolvimento de software. 1 Termo utilizado para acusar um erro, falha, engano, fracasso em software de computador que produz um resultado incorreto ou inesperado.

12 11 Ao testamos um software, estamos atribuindo-lhe um valor que aumenta sua qualidade e confiabilidade, além de reduzir drasticamente eventuais erros. Não apenas testar para mostrar que ele funciona, mas começar com a suposição de que contém erros e tentar encontrar o maior número de erros possível (MYERS, 2004) VALIDAÇÃO DE REQUISITOS O objetivo da validação de requisitos é assegurar que os requisitos definidos para um sistema refletem o que o cliente deseja. Essa validação é importante, pois erros em um documento de requisitos podem conduzir a um extenso custo de retrabalho quando descobertos durante o desenvolvimento ou, principalmente, depois de o sistema ter sido implantado. O custo para consertar o problema de requisito, fazendo mudanças no sistema, é muito maior do que reparar o design ou erros de codificação. A razão disso é que uma mudança no requisito significa que o design e implementação do sistema também requerem mudança, além de ser necessário testar novamente (SOMMERVILLE, 2011). Uma afirmação um tanto quanto contraditória ao desenvolvimento ágil. Pois Shore e Warden (2008) afirmam que um dos princípios do manifesto ágil diz que as mudanças de requisitos são sempre bem vindas, mesmo tarde no desenvolvimento, pois, com as mudanças sendo implementadas o quanto antes, o cliente pode conseguir uma vantagem competitiva em seu negócio. Embora o custo seja o mesmo, a mudança é mais bem vista no desenvolvimento ágil. Sommerville (2011) afirma ainda que durante o processo de validação de requisitos, verificações devem ser realizadas sobre os requisitos na documentação de requisitos. Sendo: Verificações de validade - Um usuário pode pensar que um sistema é necessário para executar determinadas funções. No entanto, uma reflexão e análise podem identificar as funções adicionais ou diferentes que são necessárias. Sistemas possuem diversos stakeholders 2 com necessidades distintas, e qualquer conjunto de requisitos é inevitavelmente um compromisso com toda a comunidade de stakeholders. 2 Qualquer grupo, indivíduo, ou organização que seja afetado, ou possa afetar o produto, projeto, ou organização (KANDT, 2006).

13 12 Verificações de consistência - Os requisitos em documento não podem ter conflitos uns com os outros. Ou seja, não deve haver regras ou descrições contraditórias de uma mesma funcionalidade do sistema. Verificações de integridade - Todas as funcionalidades e restrições definidas pelo usuário do sistema devem estar incluídas no documento de requisitos. Verificações da realidade - Todo o conhecimento em tecnologia existente deve ser utilizado na verificação dos requisitos para garantir que possam realmente ser implementados, levando em conta o orçamento e cronograma para o desenvolvimento do sistema. Verificabilidade - para reduzir um conflito em potencial entre o cliente e o contratante, os requisitos do sistema devem sempre ser escritos de modo que sejam verificáveis. Deve ser possível escrever um conjunto de testes que possam demonstrar que o sistema entregue atende cada requisito especificado QUALIDADE DE SOFTWARE ATRAVÉS DE TESTES Em seu trabalho, Kandt (2006) diz que, ao desenvolver um software, devemos nos preocupar tanto com a qualidade do produto de software quanto a qualidade do processo utilizado para a produção desse software. A qualidade do produto reflete o caráter essencial, funcionalidades e propriedades dos artefatos, e é um reflexo do quão bem atenderão as necessidades dos stakeholders. Já a qualidade do processo, por outro lado, reflete em como o produto de software é produzido. Ao atingir essas qualidades beneficiará os usuários de três modos apresentados abaixo. 1. Qualidade convencional: representa a satisfação das partes interessadas; 2. Qualidade essencial: refere-se a atributos de um artefato necessários para alcançar um nível mínimo de satisfação do cliente; 3. Qualidade atrativa: representa uma característica inesperada, porém bem vinda, pelo produto. Pressman (2010) descreve cinco pontos de vista nos quais a qualidade de software pode ser embasada, sendo estes apresentados abaixo:

14 13 1. Visão transcendental: qualidade é algo que é reconhecido imediatamente, porém não pode ser definido; 2. Visão do usuário: o usuário vê a qualidade em termos de objetivos específicos do usuário final. Se o produto atende aos objetivos, então esse apresenta qualidade; 3. Visão do fabricante: define a qualidade em termos de especificação original do produto. Se o produto está em conformidade com a sua especificação, então esse produto apresenta qualidade; 4. Visão do produto: sugere que a qualidade pode ser vinculada a características inerentes de um produto; 5. Visão baseada em valor: baseia-se em quanto um cliente está disposto a pagar pelo produto. A qualidade de software pode definida como sendo a conformidade desse software com os requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento documentados e características esperadas pelo software desenvolvido. Além disso, a qualidade é medida com base nos requisitos do software, sendo que a falta de conformidade com esses requisitos significa falta de qualidade no software produzido. Tian (2005) afirma que existem dois grupos com visões e expectativas diferentes sobre garantia de qualidade de software: o grupo dos consumidores de produtos de software composto basicamente por clientes e usuários, e o grupo dos produtores de software formado pelos envolvidos com desenvolvimento, gestão, manutenção, publicidade e serviços de produtos de software. A expectativa dos consumidores é que o software execute funções úteis tal qual fora especificado. Além disso, é esperado que o software realize essas funções especificadas corretamente sobre uso repetitivo, por longos períodos de tempo e de forma confiável.

15 14 Para os produtores de software a qualidade fundamental desejada é o cumprimento das obrigações contratuais na produção de produtos de software que estejam de acordo suas especificações pretendidas. A garantia de qualidade foca no processo prevenindo contra defeitos, enquanto o teste de software foca na detecção de erros e defeitos, relatando problemas com a execução, tempo, tráfico, transações e interações do sistema (FUTRELL; SHAFER; SAFER, 2002). Em busca de um processo de fabricação relativamente livre de defeitos, devem-se concentrar esforços em testes no processo de desenvolvimento de um software. Sendo assim, os testes devem ser projetados e implementados para sistemas e componentes para demonstrar que eles funcionam como esperado (TIAN, 2005). Portanto, a demonstração de bom comportamento é o objetivo principal do teste, que também pode ser interpretada como fornecendo evidências de qualidade no contexto de qualidade de software, ou como atingir as metas de qualidade determinadas. Para Kandt (2006) a qualidade de um produto de software geralmente está associada com a ausência de defeitos nesse software. Entretanto, qualidade também pode estar associada a outras propriedades valorizadas por consumidores e produtores de software, as quais são: eficiência, disponibilidade, manutenabilidade, confiabilidade, portabilidade, reusabilidade e usabilidade. Dentro manutenabilidade encontra-se a definição de testabilidade sendo definida como a extensão na qual o software facilita a verificação do seu funcionamento. O propósito primário para o teste de software pode ser considerado como a demonstração de qualidade desse software. Tian (2005) demonstra pensar da mesma forma quando afirma que os testes vão muito mais além de detectar e consertar defeitos no software. Afirma ainda que com os testes podemos nos beneficiar com a detecção de problemas com o processo de desenvolvimento e entregas de produtos de software. O teste pode ainda ser utilizado na detecção de problemas no sistema como um todo quando um determinado sub-módulo sofre alguma alteração. Kand (2006) afirma que dois terços dos defeitos encontrados no código do sistema são

16 15 introduzidos dessa forma. Ter uma boa estratégia de teste de software por ajudar quando todo o processo de teste deve ser repetido, garantindo a qualidade mesmo que mudanças aconteçam DEFINIÇÕES DO QUE OS TESTES PODEM IDENTIFICAR Quando muitas pessoas associam qualidade a um sistema de software, é uma indicação que poucos, caso haja, problemas são esperados acontecer durante sua operação. E ainda, quando algum problema ocorrer, é esperado que cause o mínimo de impacto possível (TIAN, 2005). A literatura estudada apresenta diferentes visões a respeito dos elementos identificados durante o processo de teste de software, sendo apresentados a seguir Falha A incapacidade de um sistema ou componente para executar suas funções requeridas dentro de requisitos de desempenho especificados (TIAN, 2005) Falta Uma característica de um sistema de software que pode levar a um erro do sistema. Por exemplo, a falta ao inicializar uma variável poderia levar a um resultado errado quando ela for utilizada (SOMMERVILLE, 2011) Erro É definido por Tian (2005) como sendo uma ação humana que produz um resultado incorreto. O erro é um estado do sistema. Na ausência de qualquer ação corretiva por parte do sistema, um estado de erro pode levar a uma falha que não seria atribuído a qualquer evento subseqüente ao erro (NAIK; TRIPATHY, 2008).

17 Defeito Segundo Kandt (2006), um defeito é uma anomalia do produto que causa um efeito inesperado. Uma organização deve utilizar uma abordagem eficiente e eficaz para detecção de defeitos, tendo um benefício significativo, pois a detecção de defeitos e as atividades de correção praticadas de forma ineficiente e ineficaz consomem cerca de cinqüenta por cento da força de trabalho para criar o software, além de setenta e cinco por cento do custo total do ciclo de vida do software. Figura 1: Relações referentes a defeitos. Fonte: Tian (2005). Nota: Adaptado pelo autor. O defeito se refere a um desvio de comportamento de um requisito de usuário ou da especificação do produto de software (TIAN, 2005). Este autor afirma também que o defeito pode ser visto como diferentes aspectos de erros, faltas e falhas, ou um relacionamento entre os três. Um ou vários erros podendo gerar uma ou várias faltas, e/ou uma ou várias faltas podendo gerar uma ou várias falhas, como ilustra a Figura 1.

18 VALIDAÇÃO E VERIFICAÇÃO Sommerville (2011) define a Validação e Verificação (V&V) como sendo o processo de checagem e analise de um software, realizado durante e depois do processo de implementação, para assegurar o cumprimento de suas especificações, garantindo assim, a entrega das funcionalidades esperadas pelo cliente. Atividades de verificação acontecem em todos os estágios do processo de desenvolvimento. A V&V começa na revisão de requisitos e continua da revisão do design e inspeção de código até a produção de testes de software. A verificação avalia um sistema ou componente para determinar se o produto, em uma determinada fase do ciclo de vida, satisfaz as condições impostas no início dessa fase. Isso tipicamente envolve reuniões de revisão para avaliar documentos, planos, código, requisitos e especificações, usando listas de verificação, questionários, normas e convenções organizacionais. Verificação (Estamos construindo certo o sistema?) ocorre durante cada fase do ciclo de vida do desenvolvimento do software. Validação tipicamente envolve teste real e coloca-se depois de completas as verificações. Validação (Estamos construindo o sistema certo?) ocorre no final com os testes de aceitação do usuário. Também pode ser considerado em ocorrer durante todo o ciclo de vida, pois as matrizes de rastreabilidade de requisitos permitirão a avaliação contínua (FUTRELL; SHAFER; SAFER, 2002).

19 18 Figura 2: Atividades exigidas para alcançar a qualidade de software. Fonte: Pressman (2010). Nota: Adaptado pelo autor. A Figura 2 apresenta as atividades, como um conjunto de componentes, necessárias para alcançar a qualidade de software. A atividade de testes constitui o último baluarte 3 a partir do qual a qualidade pode ser avaliada. Não se pode testar a qualidade. Se ela não estiver lá antes de começar a testar, também não estará lá quando terminar de testar (PRESSMAN, 2005, p.451). Pressman (2005) afirma também que a V&V abrange um conjunto de atividades de garantia de qualidade, tais como revisões técnicas formais, auditoria de configuração e qualidade, monitoração do desempenho, simulação, estudo de viabilidade, revisão da documentação, revisão do banco de dados, analise de algorítimos, teste de desenvolvimento, teste de qualificação, teste de instalação e teste de desempenho. A verificação serve para provar que um produto de software atende aos requisitos especificados durante as atividades anteriores realizadas corretamente durante o ciclo de vida de desenvolvimento. Já a validação confirma que o sistema atende aos requisitos do cliente no final do ciclo de vida. A criação de testes está mais 3 Fortaleza, refúgio, construção segura.

20 19 relacionada com a validação do que a verificação. O teste de software é considerado um processo de validação, ou uma fase do ciclo de vida (LEWIS, 2009). A Figura 3 representa uma variação do modelo cascata com as fases de desenvolvimento dispostas em forma de V (Modelo V), onde Tian (2005) relaciona a verificação ou validação com seu requisito ou especificação correspondente. Os requisitos do cliente são validados por uso operacional, enquanto a especificação do produto, o projeto de alto-nível e o projeto de baixo-nível são verificados pelo teste de sistema, teste de integração e teste de componente, respectivamente. O teste de sistema também faz validação do produto, concentrando-se na forma como as operações do sistema atendem as especificações do produto. Por fim, a atividade de codificação e o teste unitário são agrupados em uma única fase, onde o próprio código especifica o comportamento esperado através de testes unitários. Figura 3: Atividades de V&V associadas com o modelo V. Fonte: Tian (2005). Nota: Adaptado pelo autor.

21 20 O teste passa a acontecer em todas as fases do ciclo de vida quando a verificação é incorporada ao teste. Melhores resultados são atingidos ao combinar a verificação e validação no processo de teste do produto. A verificação inclui procedimentos sistemáticos de revisão, analise e teste durante o ciclo de vida de desenvolvimento, começando com a fase de requisitos e continuando até a fase de codificação, assegurando a qualidade da produção e manutenção do software. Além de impor uma prática de desenvolvimento sistemática e organizada resultando em um produto que pode ser facilmente compreendido e avaliado por uma entidade independente (LEWIS, 2009) VISÃO GERAL DAS TÉCNICAS DE TESTE DE SOFTWARE A atividade de teste, segundo Pressman (2010), possui como objetivo primário a descoberta de erros em um software. Como objetivo secundário, a atividade de teste demonstra que as funções do software estão trabalhando de acordo com as especificações do cliente. Um teste bem sucedido é aquele que revela um erro, defeito ou desconformidade com a especificação ainda não descoberta. Pressman (2005) salienta ainda que o intuito do teste não seja apenas demonstrar a ausência de erros, mas evidenciar a presença de erros ao se testar um software. A maior parte da literatura estudada referentes a testes de software apontam a existência de três técnicas principais. Sendo elas apresentadas abaixo: Teste de caixa branca; Teste de caixa preta; Teste de caixa cinza. A seguir é abordada cada uma dessas técnicas de teste de software Testes de caixa branca Segundo Sommerville (2011) o teste de caixa branca, também conhecido como teste estrutural, é uma abordagem para projetar casos de teste, onde os testes são derivados de estruturas e implementações de software conhecidas. O entendimento

22 21 do algorítimo usado em um determinado componente é utilizado para fazer as projeções de casos de teste. Para Pressman (2010), usando o teste de caixa branca, o engenheiro de software pode confeccionar casos de teste com os propósitos listados abaixo: 1. Garantir que caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez; 2. Exercitar todas as decisões lógicas com os valores falso ou verdadeiro; 3. Executar todos os laços em suas fronteiras e dentro de seus limites operacionais; 4. Exercitar todas as estruturas de dados internas para garantir sua validade. Tian (2005) diz o teste de caixa branca serve para verificar a correta implementação das unidades internas do software tal como declarações, estruturas de dados, blocos, etc. Isso é feito através da execução de tais unidades e observando seus comportamentos. Esse teste possui essa denominação devido a visualização das partes internar do software, como se o software fosse uma caixa transparente. Uma desvantagem do teste de caixa branca é que ele não verifica se as especificações estão corretas, isto é, concentra-se apenas na lógica interna e não verificar a conformidade da lógica com a especificação. Outra desvantagem é que não há maneira de detectar os caminhos desaparecidos e dados sensíveis a erros. Por exemplo, se a declaração em um programa deve ser codificada "se a-b < 10", mas é codificada "se (a-b) < 1", isso não seria detectável sem a consulta da especificação do produto. Uma desvantagem final é que o teste de caixa branca não pode executar todos os caminhos possíveis da lógica de um programa, porque isso implicaria um número astronomicamente grande de testes (LEWIS, 2009). Segundo Tian (2005), várias ferramentas de software são utilizadas no auxílio da execução do teste de caixa branca, tais como as ferramentas de depuração de software (debuggers), ajudando na rastreabilidade de quais caminhos são exercitados durante a execução.

23 22 O teste de caixa branca examina o código fonte com foco no fluxo de controle e no fluxo de dados. O fluxo de controle refere-se ao fluxo de uma instrução para outra. O controle passa de uma instrução para outra através de uma série de maneiras, como uma instrução que é seguida de outra, chamada a funções, passagem de mensagem e interrupções. Instruções condicionais o fluxo de controle normal em um programa. O fluxo de dados refere-se à propagação de valores de uma variável ou constante para outra variável. Definições e usos de variáveis determinam o aspecto do fluxo de dados em um programa (NAIK; TRIPATHY, 2008) Testes de caixa preta Tian (2005) define o teste de caixa preta, também denominado na literatura como teste funcional, verifica a correta manipulação das funções externas providas por um software. Esse teste é conhecido como caixa preta porque toma-se o software como uma caixa, a qual não é possível visualizar o seu interior, mas sim seu comportamento exterior através da entrada e saída de dados e outras características observáveis. Simplificando, o teste de caixa preta consiste rodar o software e observar na esperança de ser fácil distinguir um comportamento esperado de um inesperado. No teste de caixa preta, o engenheiro de teste preocupa-se apenas com a parte externa acessível do software, geralmente a mesma visão que um simples usuário do software teria, isto é, basta inserir os valores de entrada e observar o que ocorre na saída dos resultados. Ao aplicar uma entrada para o software e observar o resultado, o engenheiro de teste deve ser capaz de determinar se esse resultado era ou não esperado. As possíveis entradas e a avaliação dos resultados devem ser interpretados a partir da especificação de requisitos do software (NAIK; TRIPATHY, 2008). Para Pressman (2010), os testes de caixa preta não são uma alternativa aos testes de caixa branca. Trata-se de uma abordagem complementar que tem a finalidade de descobrir uma classe de erros diferentes dos erros descobertos pelos testes de caixa branca. Os testes de caixa preta procuram descobrir as seguintes categorias de erros: 1. Funcionalidades incorretas ou ausentes;

24 23 2. Erros de interface; 3. Erros nas estruturas de dados; 4. Erro no acesso a bancos de dados externos; 5. Erros de desempenho; 6. Erros de inicialização e término. Segundo Myers (2004), na abordagem de teste de caixa preta, os testes devem ser derivados da especificação do produto, sem se preocupar como ele funciona por dentro. Neste caso o teste de caixa preta assemelha-se a fazer um test-drive em um automóvel. Grande parte das pessoas sequer imagina como os automóveis funcionam por dentro, mas a maioria delas sabe como operar um veículo e possuem especificações e preferências ao realizarem o teste. Myers (2004) afirma ainda que, ao usar a abordagem de teste de caixa preta para encontrar erros em um software, o critério deve ser exaustivo, fazendo uso de várias possibilidades de condições de entradas nos casos de teste Testes de caixa cinza De acordo com Patton (2005) o teste de caixa cinza é uma mistura do teste de caixa branca com o teste de caixa preta. Com esse teste, o testador equilibra a linha que divide o teste de caixa branca do teste de caixa preta. Porém, o teste é feito como o teste de caixa preta, mas o trabalho é complementado com observações (não tão minuciosas como no teste de caixa branca) no funcionamento interno do software. Para Lewis (2009), o teste de caixa preta representa a combinação entre o teste de caixa branca e o teste de caixa preta. O testador deve estudar a especificação de requisitos do software e conversar com a equipe de desenvolvimento para entender a estrutura interna do sistema. A motivação para esse tipo de teste é esclarecer especificações ambíguas para projetar testes. Um exemplo do uso de teste de caixacinza é quando aparece para o testador uma determinada funcionalidade que parece ser reutilizada em vários momentos da aplicação. Se o testador se comunica com o

25 24 desenvolvedor e entende o design interno e arquitetura, muitos testes serão eliminados, pois a funcionalidade será testada apenas uma única vez FASES DE TESTE DE SOFTWARE Essa seção apresenta as diferentes estratégias e fases teste de software, bem como quais as técnicas que são utilizadas em cada uma dessas fases Teste Unitário Segundo Pressman (2010), o teste unitário é usado para verificar a menor unidade de projeto de software, ou seja, o módulo. Caminhos de controle são testados para descobrirem erros dentro do módulo, utilizando para isso a descrição detalhada do projeto. A complexidade dos testes e os erros detectados são limitados pelo campo de ação restrito estabelecido para o teste unitário, sendo este baseado sempre no teste de caixa branca. Para Sommerville (2011), teste unitário é chamado de teste de componente e referese ao processo de testar componentes individuais em um sistema. Esse teste tem o objetivo de expor as falhas que um sistema venha a possuir. Há diferentes componentes que podem ser testados nesse estágio, dentre os quais: 1. Funções individuais ou métodos de um objeto; 2. Classes de objeto que possuem diversos atributos e métodos; 3. Componentes compostos formado por vários objetos ou funções diferentes. Estes componentes compostos têm uma interface definida que é usada para acessar sua funcionalidade. O teste unitário pode feito isoladamente do resto do sistema dependendo do ciclo de vida de desenvolvimento e do sistema. O teste de componente pode incluir o teste de funcionalidades e características não-funcionais especificas como o comportamento dos recursos utilizados, performance ou robustez, bem como testes estruturais. Os casos de teste são derivados de produtos de trabalho, tais como o design de software ou o modelo de dados (GRAHAM et al., 2006).

26 Teste de Integração Segundo Pressman (2010), o teste de integração é uma técnica sistemática para a construção da arquitetura de software e que, ao mesmo tempo, realiza testes para descobrir erros associados à interface. O objetivo é coletar unidades de componentes testados e construir uma estrutura de programa ditada pelo design. O teste de integração são testes de caixa preta também. Porém as caixas são geralmente maiores do que uma unidade. Muitas vezes, as unidades são agrupadas em componentes, ou programas com várias sub-rotinas, ou mesmo sub-sistemas. Em um paradigma orientado a objetos, vários objetos pertencentes a um subsistema são agrupados e submetidos a teste de caixa preta, depois o agrupamento é combinado com outros agrupamentos para formar o sistema como um todo, como mostra a Figura 4, que é então submetido ao teste de integração (FUTRELL; SHAFER; SAFER, 2002). Figura 4: Teste de integração. Fonte: Futrell; Shafer; Safer (2002). O grande problema do teste de integração, segundo Sommerville (2011), é localizar os erros. Há interações complexas entre os componentes do sistema e, quando uma saída anômala é descoberta, pode ser difícil identificar onde ocorreu o erro. Para facilitar a localização de erros, deve-se sempre usar uma abordagem incremental

27 26 para integração de sistemas e testes. Inicialmente, deve-se integrar uma configuração mínima do sistema e testar. Depois deve-se adicionar componentes a esta configuração mínima e teste novamente após cada incremento e assim, sucessivamente, até que todos os componentes tenham sido integrados Teste de Sistema Após o teste de integração ser completado, o próximo passo é o teste de sistema. O teste de sistema checa se o produto integrado atende a especificação de requisitos (SPILLNER; LINZ; SCHAEFER, 2007). Isso é necessário após o teste de integração devido: Os testes abaixo do teste de sistema, de acordo com o Modelo V, testa o sistema segundo suas especificações técnicas, ou seja, na perspetiva técnica do desenvolvedor de software. O teste de sistema olha para o software com a perspectiva do usuário, sendo que os testadores validam se os requisitos estão completos e atendidos apropriadamente; Muitas funções e características do sistema resultam da interação de todos os componentes, sendo estas visíveis apenas no nível de operação do sistema. Para Graham et al. (2006), o teste de sistema está concentrado no comportamento de todo o software como fora definido no escopo do projeto de desenvolvimento. Podem-se incluir testes baseados em riscos e/ou na especificação de requisitos, processos de negócio, casos de uso ou outra descrição de alto nível do comportamento do sistema, interações com o sistema operacional e recursos do sistema. O teste de sistema, geralmente, é o último teste diretamente relacionado com desenvolvimento que verifica se o produto a ser entregue atende as especificações de requisitos, sendo seu propósito encontrar o maior número de defeitos possível. Na maioria das vezes, esse teste é realizado por testadores especializados que formam uma equipe de teste dedicada, e às vezes independente, no âmbito do desenvolvimento, reportando os erros e defeitos encontrados ao gerente de desenvolvimento ou gerente de projeto. Em algumas organizações, o teste de sistema é realizado por uma equipe de terceiros ou por analistas de negócios. O nível de independência é baseado no nível de risco

28 27 aplicável e isso terá uma influência alta sobre a forma como o teste do sistema é organizado. Graham et al. (2006) afirma ainda que o teste de sistema deve abordar tanto os requisitos funcionais como os não-funcionais. Os testes não-funcionais incluem desempenho e confiabilidade. Os testadores podem precisar para lidar com requisitos incompletos ou em situação irregular. O teste de requisitos funcionais começa usando técnicas de caixa preta apropriadas para o aspecto do sistema a ser testado. Por exemplo, uma tabela de decisão pode ser criada para combinações de efeitos descritos nas regras de negócio. Técnicas de caixa branca também podem ser usadas para avaliar a meticulosidade dos elementos de testes. O teste de sistema para um software grande e complexo pode levar muitos meses e envolver uma quantidade elevada de pessoas do time de desenvolvimento. Também é possível que seja necessário todos os programadores do time de desenvolvimento para corrigir os erros e defeitos encontrados durante essa fase de teste. O termo teste de sistema se originou dos testes de grandes aplicações. Hoje, o termo é aplicado para a fase final de testes de aplicações de qualquer tamanho. O teste de sistema é, também, um termo abrangente que inclui testes especializados, tais como desempenho ou segurança (JONES; BONSIGNOUR, 2011). Teste de sistema pode exigir controles de configuração formais e também merece apoio de monitoramento de defeitos. Teste de sistema é normalmente baseado em princípios de caixa preta, embora às vezes a forma de teste caixa branca seja usada também. Teste de sistema pode ser realizado pelos desenvolvedores, o pessoal de teste profissional, ou por pessoal de garantia da qualidade (JONES; BONSIGNOUR, 2011) Teste de Aceitação De acordo com Watkinst (2009), o teste de aceitação é usado para garantir que o software atende aos requisitos de negócios, fornecendo confiança de que o sistema funciona corretamente. Sendo utilizado antes de o software ser formalmente entregue ao usuário, o teste de aceitação é conduzido por representantes indicados pelos usuários e por um representante da equipe de desenvolvimento.

29 28 Segundo Graham et al. (2006), a organização de desenvolvimento, ao realizar os testes de sistema e todas as correções de defeitos necessárias, deve entregar o software ao usuário ou cliente mediante teste de aceitação. O teste de aceitação deve responder a perguntar como: O sistema pode ser liberado? Quais são os riscos em potencial? O sistema cumpre suas obrigações? Graham et al. (2006) firma ainda que o teste de aceitação requer mais atenção dos usuários ou clientes do que dos outros stakeholders envolvidos. Sua execução deve ser feita em um ambiente o mais parecido possível com o ambiente de produção onde o software será implantado. Para Lewis (2009), o teste de aceitação verifica se o sistema satisfaz aos critérios de aceite do usuário. Esse teste deve ser planejado com base nas especificações de requisitos e requer um ambiente de teste formal. O teste de aceitação usa a técnica de teste de caixa preta para testar o sistema segundo suas especificações e é, geralmente, executado pelo usuário final. Durante o teste de aceitação, é importe que o time do projeto coordene o processo de teste e atualize os critérios de aceite, conforme necessário. O objetivo do teste de aceitação é estabelecer uma relação de confiança entre o sistema e seus interessados. O teste de aceitação é mais focado no tipo de teste de validação, nesse caso, a tentativa de determinar se o sistema é adequado para a finalidade. Encontrar defeitos não deve ser o foco principal do teste de aceitação e sim avaliar a disponibilidade do sistema para a implantação e uso (GRAHAM et al., 2006) CONSIDERAÇÕES SOBRE O CAPÍTULO Obviamente a literatura traz muito mais sobre teste de software, podendo ser dedicados livros inteiros sobre o assunto, que é tão antigo quanto a própria engenharia de software. Porém, a principal informação sobre o teste de software foi

30 29 adquirida, sendo esta: os testes são totalmente dependentes das informações contidas nos documentos de requisitos para sua produção. Este capítulo mostrou também como se relacionam o teste de software e a qualidade de software, apresentando os testes como forma de verificação dos requisitos e validação do processo de desenvolvimento e do produto de software.

31 30 CAPITULO 3 - DESENVOLVIMENTO ÁGIL Pressman (2010) define o desenvolvimento ágil como sendo a combinação de filosofias e de um conjunto de diretrizes de desenvolvimento. Essa filosofia encoraja a satisfação do cliente através da entrega rápida e incremental do software, e motiva a equipe com métodos informais e processos simplificados. Segundo Sommerville (2011), a filosofia por traz do desenvolvimento ágil está refletida no chamado "Manifesto Ágil", o qual foi concebido pelos principais desenvolvedores desses métodos. O manifesto é apresentado na Figura 5, sendo exatamente o mesmo apresentado por Pressman (2010) e Sommerville (2011). Essa figura mostra também os nomes dos desenvolvedores fundadores do Manifesto Ágil. Figura 5: Maniesto Ágil. Fonte: Manifesto ( 2001). O Manifesto Ágil de Desenvolvimento de Software foi assinado por Kent Beck e outros dezesseis notáveis desenvolvedores, escritores e consultores de software

32 31 (Figura 5), sendo que este grupo ficou conhecido como a "Aliança Ágil" (PRESSMAN, 2010). A Aliança Ágil segue os seguintes princípios: 1. A maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. 2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. 3. Entregar freqüentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. 4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 5. Construir projetos em torno de indivíduos motivados. Dar a eles o ambiente e o suporte necessário e confiar neles para fazer o trabalho. 6. O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento é através de conversa face a face. 7. Software funcionando é a medida primária de progresso. 8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. 9. Contínua atenção a excelência técnica e bom design aumentam a agilidade. 10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial. 11. As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis. 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

33 32 Os princípios apresentados estão em ordem de prioridade, portanto a maior prioridade do desenvolvimento ágil é: Satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. É muito difícil fazer entrega contínua em curtos períodos de tempo. Por causa desse princípio, o método ágil, segundo Rasmusson (2010), preocupa-se em quebrar um grande problema em problemas menores. A quebra do problema em partes menores pode ser uma tarefa complicada do ponto de vista do desenvolvedor. Para amenizar esse problema, o método ágil procura manter o cliente quase como um membro da equipe, consultando-o sempre, de maneira organizada, e focando em seu ponto de vista, afinal é a ele que o produto de software deve atender. Rasmusson (2010) afirma ainda que deve-se assegurar que o que será entregue deve funcionar. Com isso, cada um dos pequenos problemas deve passar por testes. A cada nova funcionalidade implementada no software pode e deve passar pelos mesmos testes vistos no Capítulo 2. Para isso a documentação do software deve existir como forma de suporte a essas etapas. As mudanças em como o software deve se comportar sempre fazia as equipes de desenvolvimento da velha guarda ficar apreensivas com o fato. Mas as equipes de desenvolvimento ágil devem ser capazes de responder bem a essas mudanças, quase que as desejando. Pressman (2010) diz que a agilidade é muito mais do que resposta eficaz às mudanças. Também engloba a filosofia, adotada no manifesto, que incentiva a organização e atitude do time, fazendo com que a comunicação entre membros do time melhore. A adoção do cliente como parte da equipe elimina eventuais disputas entre eles e a equipe de desenvolvimento PLANEJAMENTO NO DESENVOLVIMENTO ÁGIL Todo projeto, geralmente, começa com o planejamento e no desenvolvimento ágil isso não é diferente. A grande questão é como deve ser o planejamento no desenvolvimento ágil de modo a dar suporte ao seu primeiro princípio, sendo entregar o software continuamente, em curtos períodos de tempo, através de iterações.

34 33 Rasmusson (2010) compara o planejamento no desenvolvimento ágil com um planejamento de afazeres de um fim de semana agitado, utilizando para isso uma lista de tarefas. Essa lista de tarefas é conhecida no desenvolvimento ágil como master story list (lista de histórias mestre), e cada elemento contido nessa lista, ou seja, cada tarefa, é denominada user story (história de usuário). A história de usuário é definida por Cohn (2004) como sendo uma funcionalidade que será útil ao usuário ou cliente interessado no software. As histórias de usuário são compostas de três aspectos: Uma descrição usada para planejamento e para lembrete; Conversas para concretizar os detalhes; Testes que transmitem e documentam os detalhes, sendo usado para determinar quando a funcionalidade é concluída. A lista de histórias mestre contém uma descrição em alto nível de cada funcionalidade que o cliente deseja ver no sistema, sendo a base para a especificação de requisitos (RASMUSSON, 2010). Essa lista deve ter as histórias de usuário ordenadas segundo a prioridade definida pelo cliente. Após terem sido priorizadas, cada uma das histórias deve ser estimada, quanto ao tempo de sua conclusão, pela equipe de desenvolvimento. Esse trabalho inicial, apresentado na Figura 6, forma a base para o planejamento do projeto.

35 34 Figura 6: Criação da Master story list para planejamento do projeto. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor. Uma iteração refere-se a um grupo de histórias de usuário, ordenadas segundo prioridade do cliente, a ser desenvolvido em um determinado intervalor de tempo. Geralmente um período de uma ou duas semanas é definido para cada entrega. A cada iteração um grupo de histórias é transformado em software testado e pronto para execução em ambiente de produção do cliente. Conforme as histórias vão sendo implementadas, é possível medir a velocidade do time, ou seja, quanto do software é feito por iteração, para saber o quanto do software será feito no futuro (RASMUSSON, 2010). Uma maneira eficiente para registrar as histórias de usuário, segundo Leffingwell (2011), é apresentada abaixo: Como <papel>, eu gostaria <atividade> com isso <benefício>. Dessa forma, as histórias de usuário podem ser vistas de modo a incorporar elementos do problema como o benefício desejado, a função ou papel do usuário diante do problema, e a atividade em si que o usuário deseja no sistema. Abaixo segue um exemplo:

36 35 Como vendedor, eu gostaria de paginar meus contatos, com isso posso selecionar facilmente um grande números de clientes em potencial. Leffingwell (2011) afirma também que as histórias de usuário são consideradas como sendo a substituição ágil para o que tem sido tradicionalmente expresso como declarações de requisitos de software (ou casos de uso no RUP e UML), sendo elas a locomotiva do desenvolvimento ágil. Desenvolvidas inicialmente dentro de construções do XP, são agora utilizadas também para desenvolvimento ágil em geral, e são ensinadas na maioria das classes de Scrum ESTIMANDO AS HISTÓRIAS DE USUÁRIO Ao estimar história de usuário, logo vem a cabeça que o que se deseja com a estimativa é descobrir quanto tempo uma determinada história gastará para ser concluída. Porém, raramente as estimativas serão corretas devido ao fato de não ser possível saber se os membros da equipe de desenvolvimento terão interrupções ao longo dos dias de desenvolvimento. Um dia sem interrupções ou preocupações de um time de desenvolvimento é definido por Cohn (2004) como sendo um dia ideal. Também é possível pensar em outras unidades de tempo pra medir a estimativa, por exemplo, uma semana ideal. Um dia ideal dificilmente acontecerá a um dos membros do time, sendo praticamente impossível que aconteça para todos os membros do time. Segundo Shore e Warden (2008), parte do segredo para fazer boas estimativas é de prever o esforço e não o tempo que um projeto irá tomar. As estimativas devem der feitas em termos de dias ideais, muitas vezes chamado de store points (pontos de história). Pontos de história é o número de dias ideais que uma tarefa levaria se realizada inteiramente. Conforme McConnell (2006 apud MCCONNELL; RASMUSSON, 2010), o principal objetivo da estimativa de software não é prever o resultado de um projeto, é para determinar se as metas do projeto são realistas o suficiente para permitir que o projeto seja controlado para conhecê-las.

37 Planning Poker O Planning Poker (Poker do Planejamento) consiste em um baralho de cartas contendo valores de pontos de história. Sendo que cada membro da equipe de desenvolvimento possui um baralho completo (PICHLER, 2010). A Figura 7 ilustra procedimento do poker do planejamento. Para cada história, o cliente lê a descrição, fazendo com que o time realize um debate para conhecer os detalhes da história. A estimativa é feita através do baralho, sendo que cada membro do time de desenvolvimento seleciona a carta que representa sua estimativa (LEFFINGWELL, 2011). As cartas devem ser colocadas na mesa com a face para baixo, ou seja, sem revelar a estimativa no primeiro momento. As estimativas devem ser reveladas ao mesmo tempo depois que todos os membros do time fizerem a escolha. Figura 7: Aplicação do Poker de Planejamento para estimar uma história. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor.

38 37 Revelar a estimativa ao mesmo tempo é útil para evitar que uma estimativa revelada prematuramente influencie a escolha dos outros membros. Segundo Rasmusson (2010), o poker do planejamento pode ser usado também para prover a comunicação entre os membros do time. Depois de reveladas as estimativas, o time discute, caso haja alguma divergência, para revelar detalhes da história não vistos por alguns membros e pra descobrir os membros que já tiveram algum tipo de experiência com histórias parecidas. Após a discussão, todas as cartas são recolhidas e o processo é repetido até que se faça um consenso na estimativa de todos os membros da equipe de desenvolvimento (RASMUSSON, 2010) EXECUÇÃO DO PLANEJAMENTO Como foi dito anteriormente, o software é produzido continuamente através de iterações. As iterações são constituídas de histórias de usuário, sendo que o agrupamento das histórias deve ser feito de modo que uma iteração seja possível de ser realizada, segundo a estimativa obtida, no período de uma a duas semanas, respeitando a ordem de prioridade definida pelo cliente. De acordo com Rasmusson (2010), ao desenvolver uma iteração, há basicamente três etapas que cada história de usuário contida nessa iteração deve passar para se convertida em funcionalidade útil ao cliente. Essas etapas são listadas abaixo: Análise e projeto; Desenvolvimento; Teste. Essas etapas são observadas também na Figura 8. Após fazer tudo o que se julgar necessário para a história é que se pode considerá-la como uma funcionalidade desenvolvida.

39 38 Figura 8: Processo aplicado a cada tarefa da Master story list. Fonte: Rasmusson (2010). Nota: Adaptado pelo autor. Quando a funcionalidade é desenvolvida, passa-se à outra história, até que todas as histórias da iteração sejam desenvolvidas, podendo assim realizar a entrega do incremento de software ao cliente. Para Leffingwell (2011), cada história opera no mesmo padrão, ou seja, a definição da história, escrita do código e do teste, e execução dos testes em função do código. Tudo é feito em paralelo e desenvolvimento da história só é completo quando tudo isso é feito. Essa seqüência é conhecida como Definição/Construção/Teste, e é definida a seguir: Definição: essa função refere-se a combinação da especificação de requisitos e projeto. Essa etapa é elaborada através de interações entre o cliente e a equipe de desenvolvimento; Construção: refere-se basicamente a etapa de codificação da história de usuário. Durante esse processo não só é admitida como também é encorajada conversações entre desenvolvedores e cliente;

40 39 Teste: a história não pode ser dada como completa sem antes passar por um teste de aceitação, o que assegura que o código produzido atende a intenção definida para essa história. A produção de testes de aceitação (além de testes unitários) depois, ou em paralelo com a codificação, ajuda a compreensão da história pela equipe de desenvolvimento. Portanto, na primeira etapa do desenvolvimento de uma história, ou seja, na etapa de analise e projeto, é que é feito o detalhamento da especificação de requisitos. Isso significa que a cada inicio do desenvolvimento de uma história, deve-se fazer a especificação dessa história. Para que isso seja possível, a comunicação constante com o cliente é necessária. Dessa forma consegue-se atingir os objetivos do manifesto ágil, ou seja, valorizando mais os indivíduos envolvidos através de interações, colaboração com o cliente e resposta às mudanças. Mas até que ponto se pode considerar a documentação do software de modo que dê suporte necessário para as etapas seguintes como o teste, por exemplo? Rüping (2003) descreve a experiência de dois colegas quando esses se juntaram a ele em um projeto, um após o outro. O primeiro deles foi submetido a uma grande e complexa documentação desenvolvida antes de sua chegada. Algum tempo depois, ao ver como o colega estava se saindo com a documentação, encontrou descontentamento e frustração, pois o colega estava afogado na especificação, mas era impossível manter todos os detalhes em sua mente. O trabalho do novo colega começou a melhorar quando começou a interagir com os outros membros do time, fazendo discussões e depois tomando a documentação como apoio. Quando o segundo colega se juntou à equipe, seu tratamento foi diferente do primeiro. Ele recebeu apenas uma breve explicação sobre o projeto e um pequeno documento introdutório que incluía todas as coisas úteis para saber sobre o projeto, além de uma lista de contatos para esclarecimento de várias questões. Seu amadurecimento no projeto foi mais rápido do que o primeiro. Rüping (2003) conclui estas histórias evocando a questão de por que alguns documentos acabam por ser úteis, enquanto outros não. Aparentemente, algumas

41 40 coisas podem ser melhor comunicadas através de documentos, mas outras não podem. Ao voltar para o manifesto ágil, o qual diz "software em funcionamento mais do que documentação abrangente", podemos concluir que a documentação é mais valiosa se contribuir para os outros objetivos globais. Neste sentido, a documentação é um meio e não um fim. Quanto mais ela ajudar os indivíduos interagirem em equipe, mais a documentação se torna útil, e mais fácil se torna para a equipe desenvolver software em funcionamento MÉTODOS ÁGEIS Segundo Shore e Warden (2008), um método, ou processo, é uma maneira de trabalhar. Para fazer algo, deve-se seguir um processo. Alguns processos são escritos, como se fossem roteiros a serem seguidos; outros são informais, como limpar uma casa. Métodos Ágeis são processos de desenvolvimento de software que dão suporte à filosofia ágil e consistem em conjuntos de elementos individuais chamados práticas. Dentre essas práticas encontram-se o uso de controle de versão, definição de padrões de código e demonstrações semanais aos stakeholders. Essas práticas, muitas das quais já existem há anos, são combinadas pelo método ágil em uma maneira única que acentua as partes que dão apoio a filosofia ágil, descarta o que for considerado desnecessário, e agrega algumas novas idéias. O resultado é visto por muitos como leve, porém um poderoso método de desenvolvimento. A seguir são apresentados alguns métodos ágeis, sendo eles o Feature Driven Development (FDD), o Extreme Programing (XP) e o Scrum. Dentre os assuntos tratados, será apresentado o ciclo de vida de cada um e maneiras como cada um trata os testes durante o desenvolvimento do produto de software Feature Driven Development O Feature Driven Development (FDD), conhecido também em nosso idioma como "Desenvolvimento Orientado à Funcionalidade", é um modelo de processo de

42 41 desenvolvimento de software orientado a objetos. Foi introduzido por Peter Coad e colegas, e vem sendo ampliado e melhorado por Stephen Palmer e John Felsing, sendo aprimorado para um processo de adaptação ágil que pode ser aplicado a projetos de tamanho razoavelmente grande. De acordo com Pressman (2010), o FDD adota uma filosofia que enfatiza a colaboração entre pessoas em uma equipe FDD, gerencia problemas e complexidades do projeto utilizando um recurso baseado em decomposição seguido de integração de incrementos de software, e a comunicação de detalhes técnicos utiliza meios verbais, gráficos e baseados em texto. Além disso, o FDD enfatiza atividades de garantia de qualidade, incentivando uma estratégia de desenvolvimento incremental com o uso de inspeções de projeto e de código, aplicação de auditorias, coleta de métricas e uso de padrões de projeto. No contexto do FDD, uma funcionalidade representa uma função do software valorizada pelo cliente que pode ser implementada em duas semanas ou menos. O FDD define cinco atividades em seu processo como mostra a Figura 9. Figura 9: Processo de Desenvolvimento Orientado à Funcionalidade. Fonte: Palmer e Felsing (2002). Nota: Adaptado pelo autor. Palmer e Felsing (2002) afirmam que o FDD utiliza os testes de software da mesma forma como a atividade de teste é definida em processos tradicionais como o modelo em cascata por exemplo. A diferença é dada pelo fato de, no processo incremental e iterativo, a atividade de teste ser realizada após cada incremento ou após certo número de iterações. O FDD pode usufruir dos seguintes tipos de teste, vistos no capítulo anterior:

43 42 Teste Unitário; Teste de Integração; Teste de Sistema; Teste de Aceitação Extreme Programming Segundo Sommervile (2011), a Programação Extrema (XP), traduzido do inglês, é um dos mais conhecidos e usados dos métodos ágeis. Esse nome, dado por Kent Beck em 2000, foi definido dessa forma devido à abordagem empregar boas práticas reconhecidas, tais como o desenvolvimento iterativo, ao nível "extremo". De acordo com Pressman (2010), existem cinco valores que estabelecem a fundação para todo o trabalho realizado como parte do XP. Cada um desses valores é utilizado como guia para especificar atividades, ações e tarefas do XP. Os valores são apresentados abaixo: Comunicação: Para alcançar uma comunicação eficaz, o XP enfatiza a colaboração informal entre clientes e desenvolvedores, com estabelecimento de metáforas para comunicação de conceitos importantes, feedback contínuo e evitar a documentação volumosa como um meio de comunicação. Simplicidade: O XP restringe os desenvolvedores a projetar apenas para necessidades imediatas, ao invés de considerar as necessidades futuras. A intenção é criar um projeto simples que pode ser facilmente implementado em código. Feedback: O feedback é obtido basicamente de três formas: o Através da concepção e implementação de uma estratégia de teste eficaz, o software fornece resultados à equipe ágil. O XP faz uso do teste unitário como a sua tática de teste primária. Com o desenvolvimento de cada classe, a equipe escreve um teste unitário para cada operação de acordo com a funcionalidade especificada.

44 43 o o Com a entrega de um incremento do software ao cliente, as histórias de usuário implementadas são utilizadas como base para testes de aceitação. Ao grau em que o software implementa uma saída, o comportamento da história é considerado uma forma de feedback. Ao derivar requisitos como parte do planejamento iterativo, a equipe oferece ao cliente um feedback rápido em relação ao custo e impacto sobre o cronograma. Coragem: A adesão rigorosa a certas práticas XP exige coragem. Por exemplo, existe muita pressão para projetar necessidades futuras. A maioria das equipes de desenvolvimento sucumbe, argumentando que projetar para o "futuro" vai economizar tempo e esforço a longo prazo. Uma equipe ágil de XP deve ter a coragem para projetar para "hoje", reconhecendo que as necessidades futuras podem mudar drasticamente, exigindo assim retrabalho substancial de projeto e código implementado. Respeito: Ao alcançar a entrega bem sucedida de incrementos de software, a equipe desenvolve crescente respeito entre eles e os outros stakeholders. Figura 10: Processo de desenvolvimento em Programação Extrema. Fonte: Pressman (2010). Nota: Adaptado pelo autor.

45 44 Shore e Warden (2008) afirmam que as equipes XP executam todas as atividades de desenvolvimento de software simultaneamente. Análise, projeto, codificação, testes e até mesmo a implantação pode ocorrer com certa freqüência. A Figura 10 ilustra essas atividades de desenvolvimento. O XP faz isso através do trabalho em iterações, sendo que cada iteração representa um incremento realizado em uma semana de trabalho. Toda semana, a equipe faz um pouco de planejamento, um pouco de design, um pouco de codificação, um pouco de testes, e assim por diante. O trabalho é realizado sobre histórias de usuário, ou seja, durante a semana, a equipe trabalha em todas as fases de desenvolvimento para cada história. No final de uma semana, um incremento do software é lançado para análise interna, ou diretamente em ambiente de produção. Para a atividade de teste, Shore e Warden (2008) afirmam que cada membro do time XP faz sua própria contribuição para garantir a qualidade do software. Os programadores providenciam a primeira linha de defesa através de testes unitários e testes de integração. Os Testes de aceitação são especificados pelo cliente e baseados em características e funcionalidades do sistema que são visíveis pelo cliente (caixa preta). Os testes de aceitação são derivados das histórias de usuários implementadas como parte de um determinado lançamento do software (PRESSMAN, 2010). Por fim, os testadores ajudam a equipe de desenvolvimento a descobrir se os seus esforços estão sendo de fato voltados à produção de código de alta qualidade. Isso é realizado através de testes exploratórios que buscam surpresas e falhas no software. Quando os testadores encontram e reportam falhas, a equipe realiza análise da causa do defeito e considera como melhorar o seu processo para evitar que erros similares ocorram no futuro (SHORE; WARDEN, 2008).

46 45 Os testadores também exploram características não-funcionais do software, tais como o desempenho e estabilidade. Os clientes, em seguida, podem usar essas informações para decidir criação ou modificação de histórias Scrum De acordo com Pressman (2010), o Scrum, cujo nome é derivado de uma atividade que ocorre durante uma partida de rugby, é um método de desenvolvimento ágil de software que foi concebido por Jeff Sutherland e sua equipe de desenvolvimento no início de Nos últimos anos, o andamento do desenvolvimento dos métodos Scrum tem sido realizado por Ken Schwaber e Mike Beedle. Segundo Sommerville (2011), o Scrum é um método de desenvolvimento ágil que foca na gestão de desenvolvimento iterativo ao invés de abordagens técnicas específicas para engenharia de software ágil. A Figura 11 apresenta o processo de desenvolvimento Scrum. O Scrum não prescreve a utilização de práticas de programação, como programação em pares e testes durante desenvolvimento. Ele pode ser usado em conjunto com outras abordagens ágeis, como XP, fornecendo uma estrutura de gerenciamento para o projeto. Figura 11: Processo Scrum. Fonte: Pressman (2010). Nota: Adaptado pelo autor.

47 46 O time Scrum é composto pelo scrum master (mestre Scrum), o product owner (proprietário do produto) e o time de desenvolvimento, sendo referido simplesmente como "o time". O time deve possuir todas as habilidades necessárias para a construção de um produto de software, tais como a coleta de requisitos, análise, projeto, codificação e teste (PHAM; PHAM, 2011). O scrum master é caracterizado por Pichler (2010) como o membro do time Scrum que dá suporte ao product owner e ao time, protege o time e o processo, e intervém de forma adequada quando necessário para garantir que o ritmo de trabalho seja sustentável, que a equipe se mantenha saudável e motivada, e que nenhum débito técnico ocorra. O product owner é responsável por tomar nota de entradas para o software dos diferentes stakeholders, ou dos usuários que os representam, para elaborar uma lista de requisitos que resultará no product backlog (PHAM; PHAM, 2011). O product backlog é uma lista priorizada de requisitos, que pode incluir tudo, desde características do negócio até questões técnicas para correções de defeitos. Os sprints consistem em unidades de trabalho que são necessárias para alcançar um ou mais requisitos definidos no product backlog. Um sprint deve se encaixar em um período de tempo pré-definido, sendo usualmente utilizado o valor de trinta dias (PRESSMAN, 2010). Alterações em itens do product backlog não são introduzidas durante o Sprint. Isso permite que os membros da equipe possam trabalhar em um ambiente de curto prazo, porém de forma estável. No início de cada sprint, o time Scrum se reúne para fazer seu planejamento. Durante a primeira metade do encontro, o time discute os itens de alta prioridade do product backlog. Comunicação eficaz é essencial para o time entender o product owner e as expectativas dos stakeholders para esses itens. A discussão pode incluir esboços de alto nível para ajudar o time a entender a visão do product owner. Na segunda metade do encontro, o time Scrum foca no product backlog para identificar as histórias de usuário da lista às quais se comprometerá a completar durante o sprint. Para cada história de usuário, o time irá detalhar todas as tarefas, incluindo a

48 47 revisão de arquitetura, desenvolvimento, teste, documentação do usuário final, e outras (WOODWARD; SURDEK; GANIS, 2010). No início de cada dia do sprint, o time se reúne para uma "Daily Scrum" (reunião diária Scrum), onde cada membro do time responde a basicamente três perguntas: O que você fez ontem? O que você vai fazer hoje? Você tem algum impedimento? No final do sprint, o time demonstra código em funcionamento para cada história de usuário completada durante o sprint para o product owner e para os stakeholders. O time não mostra histórias do sprint que não foram concluídas, em vez disso, eles as movem de volta para o product backlog. O product owner definirá nova prioridade para essas histórias, e o time terá a chance de terminar o trabalho no sprint seguinte. Após a demonstração, o time se reúne para refletir sobre o sprint e identificar caminhos que podem ser melhorados. Nessa reunião é feita uma reflexão sobre o que correu de bom e de ruim. Além disso, a reunião de reflexão do sprint pode contribuir na troca de experiências entre os membros do time.

49 48 CAPITULO 4 - TEST DRIVEN DEVELOPMENT O Test Driven Development (TDD), do inglês Desenvolvimento Orientado à Teste, é apontado por Pressman (2010) como uma tendência emergente em Engenharia de Software. O método foi criado por Kent Beck (mesmo criador do XP) em 2002, e abordado por ele em sua obra "Test-Driven Development By Example" publicada pela Addison Wesley em O TDD ganhou a atenção recente em ambientes profissionais e tem feito incursões iniciais no ensino de engenharia de software. Uma ampla gama de estudos empíricos sobre o impacto do TDD em prática industrial e ambientes acadêmicos dando provas convincentes de sua popularidade (MADEYSKI, 2010) O QUE É O TDD? Segundo Madeyski (2010), a característica chave do TDD é que os programadores escrevem os testes antes de produzir o código que implementará as funcionalidades do software, ou seja, antes que eles mudem o comportamento do código, eles devem ter testes falhando para esse código. De acordo com Sommerville (2011), o TDD foi introduzido como parte de outro método ágil, o XP. Pressman (2010) afirma que os requisitos para um componente de software servem de base para a criação de uma série de casos de teste que exercitarão a interface e tentarão encontrar erros nas estruturas de dados e funcionalidades entregues pelo componente. Nesse caso o TDD pode ser visto como uma tendência que enfatiza a produção dos casos de teste antes da criação do código fonte do software. O feedback dos desenvolvedores é que TDD é uma abordagem muito valiosa, segundo Watkins (2009). A necessidade de entender os requisitos em detalhes para ser capaz de projetar testes e mostrar que o código atende aos requisitos antes de

50 49 implementar o código ajuda os desenvolvedores a ganharem uma compreensão completa dos requisitos. Alguns desenvolvedores, ainda segundo Watkins (2009), expressam a visão de que TDD pode atrasá-los e reduzir a sua produtividade. Na prática, houve redução na produtividade do desenvolvedor, mas não se mostrou muito significativa. Em contrapartida houve uma melhoria mensurável na qualidade do código produzido, em termos de requisitos de adequação, bem como na entrega de código com menos defeitos CICLO DE VIDA DO TDD A Figura 12 apresenta o ciclo de vida de desenvolvimento utilizando o TDD. Figura 12: Ciclo de vida do TDD. Fonte: Pressman (2010). Nota: Adaptado pelo autor. Sommerville (2011) descreve os passos no processo de desenvolvimento TDD como segue:

Organização para Realização de Teste de Software

Organização para Realização de Teste de Software Organização para Realização de Teste de Software Quando o teste se inicia há um conflito de interesses: Desenvolvedores: interesse em demonstrar que o programa é isento de erros. Responsáveis pelos testes:

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 4 http://www.ic.uff.br/~bianca/engsoft2/ Aula 4-03/05/2006 1 Modelos Prescritivos de Processo Modelo em cascata Modelos incrementais Modelo incremental Modelo RAD Modelos

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 6 http://www.ic.uff.br/~bianca/engsoft2/ Aula 6-10/05/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software (Caps. 13 e 14 do

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Fases do Processo. Ciclo de vida do processo. Processo Unificado Orientado por Casos de Uso, surgiu para realizar o

Leia mais

Luiz Fernando Maurício de Souza Sidemar Fidelis Cezario. FDD Desenvolvimento dirigido a funcionalidades

Luiz Fernando Maurício de Souza Sidemar Fidelis Cezario. FDD Desenvolvimento dirigido a funcionalidades Luiz Fernando Maurício de Souza Sidemar Fidelis Cezario FDD Desenvolvimento dirigido a funcionalidades 2 Agenda FDD; Melhores práticas do FDD; Principais papéis; Processos. FDD Metodologia interativa e

Leia mais

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PROF. MSC. EMILIANO MONTEIRO CONTEÚDO Conceitos básicos Caracterização de um processo Estágios básicos Linha do tempo Cascata Espiral Prototipação Modelo-V Orientado

Leia mais

Introdução a Teste de Software

Introdução a Teste de Software Universidade Católica de Pelotas Tecnólogo em Análise e Desenvolvimento de Sistemas Disciplina de Qualidade de Software Introdução a Teste de Software Prof. Luthiano Venecian 1 Conceitos Teste de software

Leia mais

TS02. Teste de Software INTRODUÇÃO AO PROCESSO DE TESTE DE SOFTWARE. COTI Informática Escola de Nerds

TS02. Teste de Software INTRODUÇÃO AO PROCESSO DE TESTE DE SOFTWARE. COTI Informática Escola de Nerds TS02 Teste de Software INTRODUÇÃO AO PROCESSO DE TESTE DE SOFTWARE COTI Informática Escola de Nerds 1. ENTENDENDO O PROCESSO DE TESTE. 1. ENTENDENDO O PROCESSO DE TESTE. Adequação de perfil profissional

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ - UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE FEDERAL DO PARANÁ - UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CI 221 DISCIPLINA: Engenharia de Software AULA NÚMERO: 3 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos básicos como processo, projeto, produto, por que

Leia mais

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS 1. Com relação à engenharia de software, julgue os itens seguintes. Engenharia de software não está relacionada

Leia mais

TS03. Teste de Software ESTÁGIOS DO TESTE DE SOFTWARE. COTI Informática Escola de Nerds

TS03. Teste de Software ESTÁGIOS DO TESTE DE SOFTWARE. COTI Informática Escola de Nerds TS03 Teste de Software ESTÁGIOS DO TESTE DE SOFTWARE COTI Informática Escola de Nerds Teste do Desenvolvedor O Teste do Desenvolvedor denota os aspectos de design e implementação de teste mais apropriados

Leia mais

Modelos de Processo de Software

Modelos de Processo de Software Modelos de Processo de Software Seiji Isotani, Rafaela V. Rocha sisotani@icmc.usp.br rafaela.vilela@gmail.com PAE: Armando M. Toda armando.toda@gmail.com (material produzido e atualizado pelos professores

Leia mais

Processos de Software

Processos de Software Riscos Processos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Muitos problemas no desenvolvimento de software provêm de riscos Seriam problemas potenciais que poderão ocorrer em um futuro próximo

Leia mais

SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos

SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos Jonas Analista de Negócios e Gerente de Projetos Fone:5184298411 Jonas.dc.cardoso@gmail.com 1 PROJETO Esforço temporário* para criar um produto,

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 7 http://www.ic.uff.br/~bianca/engsoft2/ Aula 7-12/05/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software (Caps. 13 e 14 do

Leia mais

Qualidade de Software II Testes e Documentação

Qualidade de Software II Testes e Documentação Qualidade de Software II Testes e Documentação Garantir a qualidade de uma aplicação é sempre um desafio, pois há muitas etapas envolvidas na sua construção, desde o levantamento dos requisitos, passando

Leia mais

Verificação e Validação

Verificação e Validação Verificação e Validação Sistemas possuem restrições de qualidade e confiabilidade Qualidade de sw: satisfação dos requisitos funcionais, de desempenho e normas explicitamente declarados. Redução de custos

Leia mais

Engenharia de Software Processo de Desenvolvimento de Software

Engenharia de Software Processo de Desenvolvimento de Software Engenharia de Software Processo de Desenvolvimento de Software Prof. Elias Ferreira Elaborador por: Prof. Edison A. M. Morais Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar

Leia mais

Princípios da Engenharia de Software aula 03

Princípios da Engenharia de Software aula 03 Princípios da Engenharia de Software aula 03 Prof.: José Honorato Ferreira Nunes Material cedido por: Prof.: Franklin M. Correia Na aula anterior... Modelos de processos de software: Evolucionário Tipos

Leia mais

Prof. Dr. Thiago Jabur Bittar

Prof. Dr. Thiago Jabur Bittar Prof. Dr. Thiago Jabur Bittar Uma representação abstrata e simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de

Leia mais

Prof. Luiz A. Nascimento

Prof. Luiz A. Nascimento Prof. Luiz A. Nascimento Qual a importância da Engenharia de Software? O desenvolvimento de um software envolve processos muitos complexos. A engenharia de software estabelece um modelo para se construir

Leia mais

TESTES DE SOFTWARE Unidade 1 Importância do Teste de Software. Luiz Leão

TESTES DE SOFTWARE Unidade 1 Importância do Teste de Software. Luiz Leão Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático 1.1 - O teste nas fases de vida e de desenvolvimento de um software. 1.2 - O teste na engenharia de sistemas e na engenharia de

Leia mais

Desenvolvimento Ágil de Software. Prof. Edjandir Corrêa Costa

Desenvolvimento Ágil de Software. Prof. Edjandir Corrêa Costa Desenvolvimento Ágil de Software Prof. Edjandir Corrêa Costa edjandir.costa@ifsc.edu.br Métodos Ágeis História Na início da década de 90 havia uma visão de que a melhor maneira para se criar software era

Leia mais

Gerência e Planejamento de Projeto. Engenharia de Software I Profa. Elisa Yumi Nakagawa 1 o semestre de 2015

Gerência e Planejamento de Projeto. Engenharia de Software I Profa. Elisa Yumi Nakagawa 1 o semestre de 2015 Gerência e Planejamento de Projeto Engenharia de Software I Profa. Elisa Yumi Nakagawa 1 o semestre de 2015 Conteúdo: Parte 1: Gerenciamento & Qualidade Plano de Projeto - aspectos gerais Parte 2: Plano

Leia mais

RUP RATIONAL UNIFIED PROCESS

RUP RATIONAL UNIFIED PROCESS O que é RUP? É um metodologia para gerenciar projetos de desenvolvimento de software que usa a UML como ferramenta para especificação de sistemas. Ele é um modelo de processo híbrido Mistura elementos

Leia mais

Desenvolvimento Ágil no Governo. Produtos de Software. Luís Dosso. Outubro/2011. Sistemas e aplicações sob medida para as necessidades do seu negócio.

Desenvolvimento Ágil no Governo. Produtos de Software. Luís Dosso. Outubro/2011. Sistemas e aplicações sob medida para as necessidades do seu negócio. Desenvolvimento Ágil no Governo Luís Dosso Outubro/2011 Produtos de Software Sistemas e aplicações sob medida para as necessidades do seu negócio. A Dextra Soluções de Software Projetos de software complexos

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 UML Linguagem Unificada de Modelagem Projeto de Software Introdução O que é projeto em software? O termo projeto é um tanto

Leia mais

Paradigmas da Engenharia de Software AULA PROF. ABRAHAO LOPES

Paradigmas da Engenharia de Software AULA PROF. ABRAHAO LOPES Paradigmas da Engenharia de Software AULA 03-04 PROF. ABRAHAO LOPES Introdução O processo de software é visto por uma sequência de atividades que produzem uma variedade de documentos, resultando em um

Leia mais

Disciplina - Requisitos. Grupo Yuni Luiz Eduardo Káthia

Disciplina - Requisitos. Grupo Yuni Luiz Eduardo Káthia Disciplina - Requisitos Grupo Yuni Luiz Eduardo Káthia RUP(Rational Unified Process) 1. Introdução. 2. Introdução a disciplinas no RUP. 3. Requisitos. 4. Gerenciamento de Requisitos. 5. Relação com outras

Leia mais

Verificação e Validação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1

Verificação e Validação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1 Verificação e Validação Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1 Objetivos Apresentar a verificação e validação de software e discutir a distinção entre elas Descrever

Leia mais

Unidade II MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

Unidade II MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini Unidade II MODELAGEM DE PROCESSOS Profa. Gislaine Stachissini Modelagem de sistemas A fase do desenvolvimento do sistema exige: esforço; dedicação; envolvimento; um único objetivo. Estilo de desenvolvimento

Leia mais

Requisitos de Sistemas

Requisitos de Sistemas Requisitos de Sistemas Unidade I - Engenharia de Requisitos Definição de Requisitos (Continuação) Processos de Engenharia de Requisitos (Cont.) - Análise - Registro - Validação - Gerência 1 Processo de

Leia mais

27) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema:

27) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema: Modelos de Ciclo de Vida e Metodologias de Software 33) No SCRUM, uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto é denominada: A) Backlog. B) Sprint. C) Daily scrum. D)

Leia mais

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN

RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS. Prof. Fabiano Papaiz IFRN RUP RATIONAL UNIFIED PROCESS PRÁTICAS RECOMENDADAS Prof. Fabiano Papaiz IFRN O RUP recomenda as seguintes práticas que devem ser utilizadas no desenvolvimento de um software: 1. Desenvolver de forma iterativa

Leia mais

Gerência de Projetos e Qualidade de Software. Prof. Walter Gima

Gerência de Projetos e Qualidade de Software. Prof. Walter Gima Gerência de Projetos e Qualidade de Software Prof. Walter Gima 1 Plano de Ensino e Aprendizagem 2 3 Objetivos CONTEÚDO Se preparar para o inicio de um projeto Acompanhamento projeto Controles Métricas

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 Verificação e Validação (V&V) S.L.Pfleeger (Cap.8 & 9) R.Pressman (Cap.13 & 14) I.Sommerville (Cap.22 & 23) Introdução Verificação

Leia mais

Estágio II. Aula 04 Testes Ágeis. Prof. MSc. Fred Viana

Estágio II. Aula 04 Testes Ágeis. Prof. MSc. Fred Viana Estágio II Aula 04 Testes Ágeis Prof. MSc. Fred Viana Agenda Manifesto dos Testes Ágeis Testes Ágeis x Testes Tradicionais Sinais de que os Testes Não São Ágeis Testador Ágil Testador Ágil em Equipe Independente

Leia mais

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) A Rational é bem conhecida pelo seu investimento em orientação em objetos. A empresa foi à criadora da Unified Modeling Language (UML), assim como de várias ferramentas que

Leia mais

SIMPLe: uma abordagem simples

SIMPLe: uma abordagem simples SIMPLe: uma abordagem simples orientada a problemas para o desenvolvimento de software Rafael Sabbagh Parte I!! Problemas e Soluções Aceitar Feature Request gera desperdício! Feature Request! Converse

Leia mais

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia

Engenharia de Software. Processos. Desenvolvimento de Software Tradicionais 2014/2. Prof. Luís Fernando Garcia Engenharia de Software Processos Desenvolvimento de Software Tradicionais 2014/2 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR Processos Um conjunto estruturado de atividades necessárias para o desenvolvimento

Leia mais

Aula 2 Processo de Software

Aula 2 Processo de Software Aula 2 Processo de Software Processo de software O que é processo de software? Deve incluir 4 partes fundamentais Não existe um processo ideal Certo ou errado? O tipo de software influencia no tipo de

Leia mais

Processos Ágeis de Desenvolvimento de Software

Processos Ágeis de Desenvolvimento de Software Processos Ágeis de Desenvolvimento de Software -Focono XP - Rodrigo Rebouças de Almeida rodrigor@rodrigor.com Processo Conjunto de atividades ordenadas, restrições e recursos que produzem um resultado

Leia mais

ENGENHARIA DOS REQUISITOS

ENGENHARIA DOS REQUISITOS Apostila Estácio: Engenharia de Software de Roger S. Pressman. 6º Edição/2006 1 2 A engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento

Leia mais

Estágio II. Aula 02 Conceitos de Teste de Software. Prof. MSc. Fred Viana

Estágio II. Aula 02 Conceitos de Teste de Software. Prof. MSc. Fred Viana Estágio II Aula 02 Conceitos de Teste de Software Prof. MSc. Fred Viana Agenda Teste de Software Defeito, Erro ou Falha? Dimensões do Teste Níveis de Teste Tipos de Teste Técnicas de Teste Teste de Software

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE FEDERAL DO PARANÁ UFPR BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CI 221 DISCIPLINA: Engenharia de Software AULA NÚMERO: 2 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO Nesta aula serão apresentados e discutidos os conceitos de Processo de desenvolvimento de software e ciclo

Leia mais

Análise e Projeto de Sistemas

Análise e Projeto de Sistemas Análise e Projeto de Sistemas Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2012 Paradigmas e Processo de Software Engenharia de Software: Abrangência Engenharia de Software possui

Leia mais

Introdução a Testes de Software. Ricardo Argenton Ramos

Introdução a Testes de Software. Ricardo Argenton Ramos Introdução a Testes de Software Ricardo Argenton Ramos ricargentonramos@gmail.com Agenda da Aula Introdução sobre Testes; Testes Funcionais de software; Testes Estruturais de Software; Teste de Software

Leia mais

Análise de Requisitos, Estimativas e Métricas

Análise de Requisitos, Estimativas e Métricas Análise de Requisitos, Estimativas e Métricas Marcos Dorça Gerente de Serviços Borland Latin America 1 Visão de Mercado 2 Estatísticas 82% do re-trabalho em aplicações é causado por erros em requisitos

Leia mais

Processo Unificado (PU) Unified Process

Processo Unificado (PU) Unified Process Processo Unificado (PU) Unified Process 10 de junho de 2011 Adonai Canêz One comment Introdução O Processo Unificado (PU) surgiu para realizar o desenvolvimento de software visando a construção de sistemas

Leia mais

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

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

Leia mais

Processos de software

Processos de software Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos de

Leia mais

Programação Orientada a Objetos

Programação Orientada a Objetos Ciência da Computação Prof. Elias Ferreira Elaborador por: Ana Claudia Bastos Loureiro Monção JUNIT Teste de Software Processo de Software Um processo de software pode ser visto como o conjunto de atividades,

Leia mais

SCRUM na prática com TANGRAN

SCRUM na prática com TANGRAN SCRUM na prática com TANGRAN Prof. Msc. Bruno Andrade da Silva ALTAMIRA/PA 04 de novembro de 2016 Reflexão A ciência, como um todo, não é nada mais do que um refinamento do pensar Albert Einstein SCRUM

Leia mais

Documentação de Software. Simone Vasconcelos

Documentação de Software. Simone Vasconcelos Documentação de Software Simone Vasconcelos 1 Contexto Qualquer software deve ter uma quantidade razoável de documentação.! Documentos de trabalho.! Manuais de usuário produzidos profissionalmente. Em

Leia mais

14/11/2014. Engenharia de Software. Modelos de software. Modelo Clássico - Cascata

14/11/2014. Engenharia de Software. Modelos de software. Modelo Clássico - Cascata 4//204 Engenharia de Software Luiz A. Nascimento Modelos de software Cascata (especificação/desenvolvimento/ validação e evolução) Na teoria:desenvolvimento linear Na prática: São necessárias várias iterações

Leia mais

Engenharia de Confiança. Helena Macedo Reis Luis Fernando de Souza Moro

Engenharia de Confiança. Helena Macedo Reis Luis Fernando de Souza Moro Engenharia de Confiança Helena Macedo Reis Luis Fernando de Souza Moro 1 Engenharia de Confiança Preocupada com técnicas que aumentam a confiança e diminui os riscos de falhas Falha pode causar perda de

Leia mais

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

Levantamento, Análise e Gestão Requisitos. Aula 02 Levantamento, Análise e Gestão Requisitos Aula 02 Agenda RUP Visão Geral Qualidade de software Estrutura Fases Disciplinas Principais papéis Atualização dos Requisitos Visão Geral Conjunto Subjacente de

Leia mais

VERSÃO RESPOSTAS PROVA DE MÉTODOS QUANTITATIVOS

VERSÃO RESPOSTAS PROVA DE MÉTODOS QUANTITATIVOS UNIVERSIDADE DE SÃO PAULO FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E CONTABILIDADE DE RIBEIRÃO PRETO PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO DE ORGANIZAÇÕES PROCESSO SELETIVO DOUTORADO - TURMA 20 VERSÃO

Leia mais

CICLO DE VIDA DO SOFTWARE. Nas empresas também é difícil adotar apenas um ciclo de vida, na maioria das vezes possui mais de um.

CICLO DE VIDA DO SOFTWARE. Nas empresas também é difícil adotar apenas um ciclo de vida, na maioria das vezes possui mais de um. Aula 02 CICLO DE VIDA DO SOFTWARE O ciclo de vida de um software é uma estrutura contendo todos os processos e tarefas envolvendo o desenvolvimento e finalização, ou seja, as etapas de operação e manutenção

Leia mais

Engenharia de Software. Teste de Software. Introdução. Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff

Engenharia de Software. Teste de Software. Introdução. Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff Engenharia de Software Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff Teste de Software Introdução Estratégias de teste Testes de módulo Testes de integração Teste de aceitação

Leia mais

Gerência e Planejamento de Projeto. Engenharia de Software Profa. Elisa Yumi Nakagawa 1 o semestre de 2016

Gerência e Planejamento de Projeto. Engenharia de Software Profa. Elisa Yumi Nakagawa 1 o semestre de 2016 Gerência e Planejamento de Projeto Engenharia de Software Profa. Elisa Yumi Nakagawa 1 o semestre de 2016 Conteúdo: Parte 1: Gerenciamento & Qualidade Plano de Projeto Aspectos Gerais Parte 2: Plano de

Leia mais

XP EXTREME PROGRAMMING. AGO106 - Gestão

XP EXTREME PROGRAMMING. AGO106 - Gestão XP EXTREME PROGRAMMING AGO106 - Gestão de Processos de Desenvolvimento de Software DESENVOLVIMENTO TRADICIONAL Sequencial: Análise, Design, Implementação, Teste, Implantação e Manutenção Características:

Leia mais

MODELOS DE PROCESSOS (PARTE 2)

MODELOS DE PROCESSOS (PARTE 2) MODELOS DE PROCESSOS (PARTE 2) Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Recordando nossas Datas Provas (novas datas): 3ª Prova (1ª chamada): 03/07 2ª Prova (2ª chamada):

Leia mais

Introdução à Análise e Projeto de Sistemas

Introdução à Análise e Projeto de Sistemas Introdução à I. O Que vamos fazer na Disciplina? Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO Tem que saber Análise e Projeto OO (APOO) Isto é, Análise

Leia mais

CONTPATRI Plano de Garantia de Qualidade. Versão 1.1

CONTPATRI Plano de Garantia de Qualidade. Versão 1.1 CONTPATRI Plano de Garantia de Qualidade Versão 1.1 Histórico da Revisão Data Versão Descrição Autor 04/05/2013 1.0 Verificação do documento Emerson José Porfírio 21/04/2013 1.0 Elaboração do documento

Leia mais

Entenda as idéias do movimento que está revolucionando a indústria de desenvolvimento de software mundial. Alisson Vale

Entenda as idéias do movimento que está revolucionando a indústria de desenvolvimento de software mundial. Alisson Vale Entenda as idéias do movimento que está revolucionando a indústria de desenvolvimento de software mundial Alisson Vale Revoluções Científicas 1900 William Tomson (Lord Kelvin) Não há nada novo na física

Leia mais

Desenvolvimento dirigido por Funcionalidades(FDD), Desenvolvimento de Software Enxuto(LSD) e Processo Unificado Agil (AUP)

Desenvolvimento dirigido por Funcionalidades(FDD), Desenvolvimento de Software Enxuto(LSD) e Processo Unificado Agil (AUP) Desenvolvimento dirigido por Funcionalidades(FDD), Desenvolvimento de Software Enxuto(LSD) e Processo Unificado Agil (AUP) José Cláudio Moretti Junior - GRR20093177 Será apresentado os conceitos de desenvolvimento

Leia mais

Controle - 3. Realizar o Controle da Qualidade Relatório de Desempenho. Mauricio Lyra, PMP

Controle - 3. Realizar o Controle da Qualidade Relatório de Desempenho. Mauricio Lyra, PMP Controle - 3 Realizar o Controle da Qualidade Relatório de Desempenho 1 Realizar o Controle da Qualidade Preocupa-se com o monitoramento dos resultados do trabalho, a fim de verificar se estão sendo cumpridos

Leia mais

Engenharia de Software. Tema da Aula. A Crise do Software. Principais problemas da área de Informática

Engenharia de Software. Tema da Aula. A Crise do Software. Principais problemas da área de Informática Tema da Aula A Crise do Prof. Cristiano R R Portella portella@widesoft.com.br Principais problemas da área de Informática Questionário aplicado à alta direção de 200 empresas de porte médio/grande, sobre

Leia mais

Processos de software RUP

Processos de software RUP Processos de software RUP Revisão Conceitos Básicos - Processo Um conjunto de tarefas ordenadas constitui um processo, uma séria de etapas que envolvem atividades, restrições e recursos para alcançar a

Leia mais

Regras do jogo equipe de evolução de software /6/2006 versão 2.1

Regras do jogo equipe de evolução de software /6/2006 versão 2.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Regras do Jogo Objetivo do jogo: Os jogadores competem para terminar um projeto

Leia mais

Desvios Condicionais. Curso: Técnico em Informática Disciplina: Algoritmos Prof. Abrahão Lopes

Desvios Condicionais. Curso: Técnico em Informática Disciplina: Algoritmos Prof. Abrahão Lopes 1 Desvios Condicionais Curso: Técnico em Informática Disciplina: Algoritmos Prof. Abrahão Lopes abrahao.lopes@ifrn.edu.br Conteúdo Desvio simples (SE) Desvio composto (SE/ SENÃO) Desvios encadeados Operadores

Leia mais

Fábricas de Software. Processos de Software. Fábricas de Software. Fábricas de Software 17/08/2010. Jorge Dias

Fábricas de Software. Processos de Software. Fábricas de Software. Fábricas de Software 17/08/2010. Jorge Dias Fábricas de Software Processos de Software Jorge Dias Um processo estruturado, controladoe melhoradode forma contínua, considerando abordagens de engenharia industrial, orientado para o atendimento a múltiplas

Leia mais

Estratégias de Testes Parte I

Estratégias de Testes Parte I Engenharia de Software III 5º. Semestre ADS Capítulo 9 Estratégias de Testes Parte I Profa. Dra. Ana Paula Gonçalves Serra Prof. Ms. Edson Saraiva de Almeida Agenda Exercício Profa. Dra. Ana Paula G. Serra

Leia mais

O Fluxo de Requisitos

O Fluxo de Requisitos O Fluxo de 1 Finalidade do fluxo de requisitos A finalidade deste fluxo é: Chegar a um acordo com o cliente e o usuário sobre o que o sistema deve fazer. Oferecer ao desenvolvedor um melhor entendimento

Leia mais

Guia do Processo de Teste Metodologia Celepar

Guia do Processo de Teste Metodologia Celepar Guia do Processo de Teste Metodologia Celepar Agosto de 2009 Sumário de Informações do Documento Documento: guiaprocessoteste.odt Número de páginas: 11 Versão Data Mudanças Autor 1.0 26/12/07 Criação.

Leia mais

Modelos de Software. Tema 2. Processo de Software. Modelos Profa. Susana M. Iglesias

Modelos de Software. Tema 2. Processo de Software. Modelos Profa. Susana M. Iglesias Modelos de Software Tema 2. Processo de Software. Modelos Profa. Susana M. Iglesias Processo de software Processo de software: Ferramentas Métodos Processo Foco: A qualidade Um conjunto de atividades realizadas

Leia mais

Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam:

Ainda que muitos modelos sejam semelhantes entre os modelos de ciclo de vida, existem alguns aspectos que os diferenciam: Prof. Edson dos Santos Cordeiro 1 Tópico: Objetivo: Introdução a Ciclo de Vida do Software Conhecer os principais conceitos relacionados a ciclo de vida do software. Bibliog. Base: McCONNEL, Steve. Rapid

Leia mais

Sistemas Distribuídos Aula 03

Sistemas Distribuídos Aula 03 Sistemas Distribuídos Aula 03 Prof. Bruno Crestani Calegaro Curso de Ciência da Computação ELC1018 - Sistemas Distribuídos 1 Estilos Arquitetônicos Os mais importantes estilos de arquitetura para sistemas

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Raul Vidal, João Pascoal Faria, Ademar Aguiar, Gil Gonçalves FEUP/LEIC/LGP 2003-04 Processos de Desenvolvimento Software 1 Controlo de Projectos Quatro variáveis

Leia mais

Sistemas Especialistas e Representação do Conhecimento. Sistemas Especialistas e Representação do Conhecimento. Sistema Especialista

Sistemas Especialistas e Representação do Conhecimento. Sistemas Especialistas e Representação do Conhecimento. Sistema Especialista Sistemas Especialistas e Representação do Conhecimento Sistemas Especialistas e Representação do Conhecimento -programa que comporta-se como um expert em algum domínio restrito de aplicação. -capaz de

Leia mais

2. Processos em Engenharia de Software

2. Processos em Engenharia de Software Renato Cardoso Mesquita Departamento de Eng. Elétrica da UFMG renato@cpdee.ufmg.br Engenharia de Software 2. Processos em Engenharia de Software.......... 2.1. Visão Geral Conceito de processo conjunto

Leia mais

Testes Ágeis com BDD. Por que o BDD pode salvar o agile? Paloma Costa

Testes Ágeis com BDD. Por que o BDD pode salvar o agile? Paloma Costa Testes Ágeis com BDD Por que o BDD pode salvar o agile? Paloma Costa paloma.costa@gmail.com Agenda Sobre a Palestrante Introdução Entender o Comportamento O que é BDD? O que Cucumber? Testes Orientados

Leia mais

UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO CURSO: CIÊNCIA DA COMPUTAÇÃO. Prof.ª Danielle Casillo

UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO CURSO: CIÊNCIA DA COMPUTAÇÃO. Prof.ª Danielle Casillo UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO CURSO: CIÊNCIA DA COMPUTAÇÃO TEORIA DA COMPUTAÇÃO Aula 03 Programas (Monolítico e Iterativo) Prof.ª Danielle Casillo Programas, Máquinas e Computações Diferentes

Leia mais

Requisitos de Software e UML Básico. Janaína Horácio

Requisitos de Software e UML Básico. Janaína Horácio Requisitos de Software e UML Básico Janaína Horácio janaina@les.inf.puc-rio.br Agenda Requisitos O que é? Objetivos? Atividades?... UML O que é? Modelos... Casos de Uso O que é? Componentes 2 Requisitos

Leia mais

Auditoria Contínua Uma visão do IIA Global. Oswaldo Basile, CIA, CCSA, QAR. CEO Trusty Consultores Presidente IIA Brasil

Auditoria Contínua Uma visão do IIA Global. Oswaldo Basile, CIA, CCSA, QAR. CEO Trusty Consultores Presidente IIA Brasil Auditoria Contínua Uma visão do IIA Global Oswaldo Basile, CIA, CCSA, QAR. CEO Trusty Consultores Presidente IIA Brasil Normas Internacionais para a Prática Profissional - NIPP Elementos - NIPP Definição

Leia mais

VERSÃO RESPOSTAS PROVA DE MÉTODOS QUANTITATIVOS

VERSÃO RESPOSTAS PROVA DE MÉTODOS QUANTITATIVOS UNIVERSIDADE DE SÃO PAULO FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E CONTABILIDADE DE RIBEIRÃO PRETO PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO DE ORGANIZAÇÕES PROCESSO SELETIVO MESTRADO - TURMA 2012 PROVA

Leia mais

Abordagens e dimensões da qualidade

Abordagens e dimensões da qualidade Abordagens e dimensões da qualidade PPGEP / UFRGS ENGENHARIA DE PRODUÇÃO Abordagens da Qualidade Garvin, (1992) mostrou que a qualidade sofre modificações Em função da sua organização e abrangência, sistematizou

Leia mais

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

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

PROJETO DE PROGRAMAS. Projeto de Programas PPR0001

PROJETO DE PROGRAMAS. Projeto de Programas PPR0001 PROJETO DE PROGRAMAS Projeto de Programas PPR0001 Desenvolvimento de Software 2 3 Desenvolvimento de Software Análise de Requisitos Distinguir e dividir o sistema em componentes: Analisar os componentes

Leia mais

Engenharia de Software I - Aula 04

Engenharia de Software I - Aula 04 Engenharia de Software I - Aula 04 Prof. Denis Carvalho Instituto Federal de Educação, Ciência e Tecnologia de Minas Gerais Campus São João Evangelista Conteúdo 1 Introdução 2 Paradigmas 3 Referências

Leia mais

Prof. Adriano Maranhão

Prof. Adriano Maranhão Prof. Adriano Maranhão Memória Considerações: Recurso caro e escasso; Programas só executam se estiverem na memória principal; Quanto mais processos residentes na memória principal, melhor será o compartilhamento

Leia mais

O Processo Unificado (PU) SSC 121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

O Processo Unificado (PU) SSC 121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012 O Processo Unificado (PU) SSC 121 Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012 Modelos de Processo de Software Desenvolver software é geralmente uma tarefa complexa e sujeita

Leia mais

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software ENGENHARIA DE SOFTWARE Aula 03 Processos de Software AGENDA Modelos de processo de software Atividades do processo Lidando com mudanças Rational Unified Process (RUP) 14/03/2017 IFPR QUEDAS DO IGUAÇU -

Leia mais

Análise e Projeto de Software

Análise e Projeto de Software Análise e Projeto de Software Proj. Desenvolvimento de Software Prof. Cleverton Hentz cleverton.hentz@ifrn.edu.br 8 de junho de 2017 Material Apresentado Sumário de Aula 1 Introdução 2 Estruturação do

Leia mais

TESTES DE SOFTWARE 1. Fundamentos sobre testes de software

TESTES DE SOFTWARE 1. Fundamentos sobre testes de software ENG SOFT - TESTES TESTES DE SOFTWARE 1. Fundamentos sobre testes de software A atividade de teste de software sempre foi considerada como um gasto de tempo desnecessário, uma atividade de segunda classe,

Leia mais

Manual de Instruções do Cadastrador de Mesa Prox 125KHz USB

Manual de Instruções do Cadastrador de Mesa Prox 125KHz USB Manual de Instruções do Cadastrador de Mesa Prox 125KHz USB Sumário 1. Apresentação... 3 2. Especificações Técnicas... 3 3. Configuração do Sistema... 3 4. Cadastrar Cartões na NetControl... 4 5. Termo

Leia mais

7ª Conferência da Qualidade de Software e Serviços

7ª Conferência da Qualidade de Software e Serviços 7ª Conferência da Qualidade de Software e Serviços Case de Sucesso Utilização de métodos ágeis em projeto de software Na Prática Apresentação Fundada em 2003, a Enter5 é uma empresa cuja proposta de trabalho

Leia mais

Administração das Operações Produtivas

Administração das Operações Produtivas Administração das Operações Produtivas MÓDULO 14: A VISÃO DA QUALIDADE, DOS SISTEMAS E DOS MELHORAMENTOS Mesmo tendo sido acabado todo o projeto do produto e do processo, resta a atividade contínua do

Leia mais

Ref.: Consulta pública relativa a fixação de valores dos honorários a serem pagos aos peritos no âmbito da justiça gratuita

Ref.: Consulta pública relativa a fixação de valores dos honorários a serem pagos aos peritos no âmbito da justiça gratuita Ao Egrégio CONSELHO NACIONAL DE JUSTIÇA SEPN Quadra 514 norte, lote 7, Bloco B Brasília DF. CEP 70.760-542. Ref.: Consulta pública relativa a fixação de valores dos honorários a serem pagos aos peritos

Leia mais