AUTONOMAÇÃO NA PRODUÇÃO DE SOFTWARE

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

Download "AUTONOMAÇÃO NA PRODUÇÃO DE SOFTWARE"

Transcrição

1 XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente. São Carlos, SP, Brasil, 12 a15 de outubro de AUTONOMAÇÃO NA PRODUÇÃO DE SOFTWARE FERNANDO LUIZ DE CARVALHO E SILVA (IFF) Gabriel Manhães Monnerat (UCAN) Rogério Atem de Carvalho (IFF) A produção de bens intangíveis tem crescido devido ao maior acesso a Tecnologia da Informação e Comunicação (TIC) (BARRET, 1998). Um dos mais valiosos commodities atualmente é o software pois sua produção requer investimentos relativamente menores e possibilita a geração de valor agregado elevado, sem no entanto ser um objeto físico. Segundo Cusumano (1999) o sofware é estratégico para as empresas podendo ser a base de novos negócios baseados em tecnologia. Grandes vantagens tem sido obtidas pela aplicação de software para apoio a gestão empresarial (ERP). Portanto, a produção de software torna-se uma importante atividade econômica e esta precisa ser tratada à luz das técnicas modernas da gestão de produção. Desta feita, a qualidade de software é talvez uma das maiores preocupações nos dias de hoje nesta área (HAMILTON, 2007). Se por um lado convivemos há algumas décadas com software, que já é considerado uma ferramenta estratégica para empresas (PORTER, 2001), simultaneamente fomos doutrinados a acreditar que anormalidades como travamentos, mal funcionamento, inconsistências são normais, toleráveis e esperáveis nestes produtos, mas não são. O objetivo deste artigo é, sob a ótica da Engenharia de Produção, alertar para a tendência e as vantagens em automatizar Testes de Software, e que desta forma podem cobrir aproximadamente 99% da extensão real do produto, facilitando identificação precoce de anormalidades e diminuindo drasticamente a ocorrência de falhas junto ao cliente. Palavras-chaves: Enxuto Software Testes

2 1. Introdução Tradicionalmente, vários autores da Engenharia de Software (ES) (PRESMAN, 1995; SOMMERVILE, 2003) afirmam que o controle da qualidade deve ser feito por testes e inspeções em uma etapa do processo específica após a produção. Nesta etapa, 100% da produção deve ser testada e inspecionada. Os produtos onde forem detectadas anormalidades devem retornar a produção. Por um outro lado, segundo vários autores da Engenharia de Produção (EP) (OHNO, 1997; SHINGO, 1996; SLACK, 2007), as taxas de anormalidades e retrabalho devem ser minimizadas para obter qualidade e estabilidade na produção. Durante a evolução dos sistemas de produção, no início do século XX, ainda sofrendo influência da produção artesanal, os produtos apresentavam elevadas imprecisões, dificultando a montagem e substituição de peças. Nesta época Frederich Taylor introduz os métodos de inspeção manual de 100% da produção para verificar a qualidade de produtos. Segundo OHNO (1997), apesar de filtrar a chegada de produtos defeituosos às mãos dos clientes, estas inspeções geram grande desperdício na forma das perdas de materiais, salários de inspetores, funcionários para recuperar os produtos e disponibilizá-los para as vendas. A Produção Enxuta (PE) (WOMACK & JONES, 1992) apresenta soluções para a verificação autônoma na linha de produção (SHINGO, 1996) através da autonomação, liberando os operadores dos esforço manual de teste e verificação de anormalidades. De forma muito similar aos conceitos da PE, Kent Beck (2002) propõe a técnica TDD (Test-driven Development) para produção de software, que pretende garantir a detecção de anormalidades em aproximadamente 100% do código produzido. Nesta mesma obra, Beck descreve um processo de desenvolvimento de software que vem obtendo espaço na comunidade de ES, o extreme Programming (XP), que se alinha com vários dos conceitos da PE, porém sem referenciá-la explicitamente, todavia ainda não é completamente aceito pela comunidade de ES. Ocorre que a técnica de testes TDD, proposta pelo autor não é dependente deste novo processo, podendo ser utilizada em outros processos. O objetivo deste trabalho não é discutir os detalhes desta técnica de teste de software, mas sim apresentar um caso prático em que esta técnica foi implementada para aplicações empresariais (Enterprise Information Systems - EIS) baseadas em software livre, nas áreas de ERP e ECM (Enterprise Content Management), em ambiente acadêmico, onde os dados referentes ao controle da produção são descritos para a demonstração gráfica dos resultados obtidos. Espera-se que este artigo fomente o interesse na utilização da autonomação de testes de software que já apresenta resultados satisfatórios na literatura, mostrando que a mesma se aplica na construção de EIS. 2. Revisão da Literatura 2.1. Produção Enxuta (PE) Nesta seção serão revistos alguns conceitos com o objetivo de entender o ponto de vista da Produção Enxuta com relação as perdas, e possibilitar o aproveitamento destes conceitos para a melhoria da qualidade no processo de produção de software. Segundo Womack e colaboradores (1998), a produção artesanal se mostrava um processo lento e dependente do artesão para adaptação das partes até que o produto estivesse completo. O artesanato portanto depende do trabalho minucioso e da experiência do artesão para 2

3 aproveitamento das peças produzidas com anormalidades. Este problema só é sanado pelo esforço da indústria em produzir eliminando as anormalidades, o que ficou conhecido por produção de peças substituíveis ou intercambiáveis. A solução utilizada no início do século XX, foi a inspeção de 100% da produção. A desvantagem deste método são os custos excessivos e, mesmo assim, não solucionando o problema. A evolução deste método foi a inspeção aleatória, dentro de uma visão estatística, que conseguia diminuir a quantidade de anormalidades que chegavam ao consumidor. Porém o problema ainda persistia, pois a correção de anormalidades nas peças exigiria um esforço de engenharia ainda maior. A própria produção em massa só é tida como implantada de fato quando a indústria de Ford consegue padronizar as peças utilizadas na montagem do seu vigésimo modelo (Modelo T), o que possibilitou o salto qualitativo e produtivo que configura a produção em massa (WOMACK et al., 1992). As peças utilizadas para montar o modelo T, com anormalidades desprezíveis para o processo, eram tão facilmente encaixáveis ou substituíveis que tornaram o Modelo T um carro no qual os proprietários podiam operar a substituição de peças pessoalmente. A indústria aprendeu que as anormalidades geram baixa produtividade e podem se traduzir em altos custos relativos a recuperação, aproveitamento ou perda de produtos. Segundo OHNO (1997), todas estas opções configuram desperdícios, porque ao tentar utilizar um produto com anormalidades retrocede-se ao tempo da manufatura artesanal. A raiz do problema está no processo produtivo que produziu erradamente a anormalidade. Esta e outras constatações foram percebidas na origem do Sistema Toyota de Produção (STP). Segundo HOLWEG (2007), em 1918 Sakichi Toyoda já havia inventado o tear automático, que parava sua produção assim que faltasse linha (insumo), por falta ou quebra, evitando assim a necessidade de um operador ficar assistindo a produção de uma máquina, e que o produto fosse perdido no caso de alguma anormalidade. Esta forma de automação é conceituada como uma auto-inspeção (SHINGO, 1996), onde as máquinas são responsáveis pela verificação de anormalidades. Taiichi Ohno (1997) cita que este é um dos pilares do STP, chamado de Autonomação, do original em japonês Jidoka, refletindo a autonomia da máquina em detectar problemas ou anormalidades. A Autonomação representa uma forma de automação com um toque humano, e representa uma transferência do conhecimento acerca de problemas detectados no processo para a máquina (SHINGO, 1996). Uma das características da Produção Enxuta é a preocupação com o processo. Segundo Ohno (1997), um dos desperdícios da produção é se produzir anormalidades. O produto fora de conformidade pode ser perdido, retrabalhado ou vendido abaixo do preço. No melhor dos casos gera prejuízo financeiro, podendo acarretar inclusive em uma visão negativa da empresa. Uma das ferramentas para a autonomação é o Poka-yoke ou Baka-yoke, que envolve também modificar as máquinas para realizar a auto-inspeção da produção e tentar impedir o uso inadequado ou distrações no manuseio das mesmas. No STP as máquinas eram capazes de detectar anormalidades na entrada de insumos, impedindo entradas que pudessem causar problemas para o processamento e detecção de saídas com anormalidades. Dependendo da máquina ou da gravidade do caso, a máquina deveria alertar o operador e parar seu processamento, causando a parada da linha de produção. 3

4 Segundo Shigeo Shingo (1996) o abastecimento de materiais de forma inadequada nas máquinas, por distração ou qualquer outro motivo, deve ser fiscalizado pela própria máquina. Para tanto, Shingo especificava modificações para que sempre que uma anormalidade fosse detectada, as próprias máquinas alertassem ao operador. Anormalidades na saída do processamento também deveria ser alertadas ao operador, que poderia manualmente acender o Andon, que é um dispositivo que sinaliza a parada da produção através de uma lâmpada, alertando aos supervisores sobre um problema a ser estudado. A importância desta parada é a valorização da melhoria não só do produto, mas principalmente do processo. É importante notar que o momento da parada é um feedback que possibilita conhecer o problema, o levantamento de dados e a identificação da causa raiz do problema. Esta é uma visão industrial do problema de diminuição de erros e anormalidades através prevenção e da melhoria contínua do processo. A proposta deste artigo é a utilização destes conceitos para o contexto do desenvolvimento de software, visando a otimização do seu processo que produz bens intangíveis Validação e Verificação de software Além da validade do software quanto a aderência aos objetivos especificados, o software deve estar correto quanto a sua construção, isto é, ser executado para verificar se atinge aos objetivos sem erros. As falhas em software geram custos para concerto que fogem aos orçamentos de sua construção, por isso devem ser evitadas. Entretanto, os maiores prejuízos são advindos da ocorrência de falhas durante seu uso em produção, onde podem trazer prejuízos ainda maiores aos usuários (GORADIA, 1993). Atualmente considera-se que a qualidade de software está associada a inspeções e testes. As inspeções são realizadas sobre os documentos de especificação do projeto, enquanto os testes são realizados sob o código executável ou programa. As inspeções foram definidas originalmente por Fagan (1976), buscando incorreções técnicas ou quanto ao domínio do problema. Este processo é normalmente dividido em preparação, encontro e correção das anomalias encontradas. As inspeções normalmente são feitas em 100% da documentação existente, porém Thelin e colaboradores (2004), argumentam que muitas das anormalidades encontradas são sistêmicas, sendo portanto refletidas em vários outros documentos, sendo portanto bastante eficiente a amostragem de documentos, para posterior busca dos problemas encontrados em outros documentos somente quando necessário. Alguns trabalhos, por exemplo Deeprasertkul e colaboradores (2005), também apontam para a inspeção de código fonte, que verifica certas condições de programação e alerta ao programador sobre o uso inadequado de ponteiros e estruturas de programação Técnicas de Teste de Software Segundo PRESMAN (1995), testes devem ser feitos para garantir a qualidade do software, prevenindo que defeitos possam acontecer quando o software entrar em execução pelo usuário. Para tanto, durante a codificação do software, deve ser idealizado o Plano de Testes do Sistema, a ser executado na fase de Testes. Um problema grave relacionado aos testes é que uma alteração para solução de um determinado problema pode gerar mal funcionamento em outro componente não alterado, através de dependências lógicas internas. Portanto, após cada reparo torna-se necessário testar 4

5 novamente todo o sistema verificando as consequências das mudanças realizadas. Caso o sistema não seja totalmente testado a cada mudança, a demora na detecção dos erros acarreta na perda do contexto de trabalho, o que dificulta a correção dos erros. Entretanto, tais testes são custosos uma vez que demandam de um planejamento prévio, tempo para sua execução, controle do processo buscando garantir sua eficácia. Os testes realizados manualmente também agregam a possibilidade de falhas humanas, distrações ou falhas no entendimento. O teste do código possui duas descrições principais. A primeira foi a proposta de MYERS (1979) que descreve o processo de executar um programa ou sistema com a intenção de encontrar defeitos, sendo portanto um teste negativo, que é melhor quanto mais erros encontra. Na segunda descrição proposta por HETZEL (1988), o autor sugere que é mais importante avaliar o atingimento dos resultados esperados, sendo portanto essencial a definição prévia de quais entradas devem gerar quais resultados. Presman (1995) e Sommerville (2003) destacam que no ciclo de vida estruturado de software existem fases específicas para o levantamento das necessidades do usuário, análise do problema, projeto da solução, codificação do software, testes do software e aceite pelo usuário. Segundo estes autores, na fase de codificação, os requisitos são implementados, e é desenvolvido um plano de testes. Após o término da fase de codificação, pode ser iniciada a fase de testes, onde o plano de testes será executado e os resultados documentados. Cada anormalidade será reconduzida para uma das fases anteriores (análise, projeto ou codificação), visando os ajustes necessários. A fase de testes, tem especial importância pois nela se valida e verifica o software, determinando se efetivamente é atingido o objetivo desejado e com que grau de eficiência. Segundo Sommerville (2003), dentre os recursos investidos em software o montante direcionado para a manutenção de software é em média superior ao investido para seu desenvolvimento. Adicionalmente, vários autores concordam (SOMMERVILLE, 2003; PRESMAN, 1995) que mesmo durante o desenvolvimento do software, mas principalmente depois de sua conclusão, podem ocorrer mudanças na lógica do negócio a ser automatizado, gerando necessidades de manutenção do software, o que justifica o maior gasto em manutenção. É importante observar que cada modificação no software requer que todos os testes sejam refeitos, pois uma alteração pode refletir em outros pontos em função das dependências lógicas e funcionais internas comuns nestes produtos, efeito conhecido como problema de regressão. Os testes são portanto desenhados para cobrir vários pontos do projeto, desde os requisitos até as unidades de programação. Porém todos estes processos, apesar de serem importantes, são executados posteriormente às operações de produção, normalmente por outras pessoas. A programação seguida da detecção de erros ou problemas permanece sujeita ao re-trabalho, o que segundo SHINGO (1996) deveria ser evitado. Segundo CUSUMANO (1995), a empresa Microsoft, uma das maiores empresas de produção de software no mundo, durante a década de 1980 apresentava uma taxa de ocorrência de erros muito elevada, causando uma certa desmoralização da empresa frente à seus clientes e usuários. A sustentação desta empresa deveu-se a sua eficiência como player no mercado de software e à sua carteira de clientes já instalada, que era mantida através de atualizações 5

6 anuais ou bianuais pagas. Relatos do autor descrevem que a quantidade de erros era tão volumosa que diversos projetos foram cancelados porque os concertos dos erros geravam cada vez mais erros, em um ciclo intenso que levava ao cancelamento dos projetos (CUSUMANO, op.cit). Ainda neste trabalho, Cusumano descreve que no início da década de 1990, Chris Mason escreve um relatório interno desta empresa, intitulado Zero-defect code, alertando para o problema da instabilidade do processo, e sugere a mudança do processo produtivo, adotando entregas de produção diárias, busca das causas raízes dos problemas, prevenção de erros ao invés de concertos e foco em funcionalidades ao invés de desenvolvimento concomitante de diversas funcionalidades. Segundo o Middleton (2005) a busca pela simplificação do escopo ao se trabalhar orientado para as funcionalidades pequenas com entregas diárias é similar ao dimensionamento do tamanho do lote de trabalho, e a orientação às funcionalidades atinge também aos objetivos da eliminação de estoque em processo, pois não se desejava que algo ficasse inacabado e não testado. Todo software produzido e não testado, ia se acumulando, até que fosse iniciada a fase de testes, quando então durante a execução dos planos de testes, se descobria grande quantidade de erros que forçavam os desenvolvedores a chavear novamente para um contexto antigo, já abandonado, das funcionalidades já terminadas. A solução de focar em funcionalidades, mantinha o contexto aberto, exigindo que cada produção fosse imediatamente inspecionada, diminuindo o custo de setup para ajuste de anormalidades caso fosse necessário. Neste caso também diminui ou extingue o estoque de concertos a serem resolvidos, simplesmente pela mudança do processo. Ao mesmo tempo não se pode garantir que todo o planejamento e controle do processo tornem o software testado manual ou automaticamente seja isentos de falha. De fato o que se propõem com a técnica TDD é que o planejamento de testes seja feito, e ainda mais intensivo e profundo do que o manual, porém que este planejamento seja executável automaticamente e que evolua dinamicamente junto com o produto Test-Driven Development (TDD) Este artigo não se destina à descrição da técnica de TDD, pois existe suficiente material para o aprendizado disponíveis e fugiria a abordagem industrial desejada. Esta forma de testes automatizados também são conhecido como testar antes (Test-First), enquanto os testes manuais são tratados como testar depois. Os testes antes, vem do fato de se buscar de forma incremental, respostas esperadas para um sistema, módulo ou função a ser construído. Segundo Beck (2002), o teste automático de software é inspirado no processo de construção e manutenção de software, no qual se espera determinados valores que não aparecem, ou se espera por resultados que não são inicialmente atingidos. TDD busca automatizar a busca por resultados especificados antes da construção do produto. Basicamente, cada teste é uma especificação executável que mapeia as expectativas de resultados normais ou esperados para cada parte do produto. Sua execução envolve a invocação da parte do produto a ser testada, e a verificação do seu comportamento e dos resultados obtidos contra os resultados esperados. O produto só é desenvolvido após uma versão de sua especificação de comportamento e resultados esperados estar pronta. A evolução se da passo a passo, primeiro pela a evolução da 6

7 especificação seguida da evolução do produto. Tudo isso ocorre dentro de um ambiente no qual todos os testes já produzidos podem ser facilmente/automaticamente executados, verificando todo o software e gerando um feedback global sobre anormalidades encontradas. A maior vantagem esperada pela aplicação desta técnica é a segurança para o desenvolvedor, para que durante a evolução do produto, seja possível trabalhar e verificar instantaneamente anormalidades causadas pelas mudanças (BECK, 2002). Como os testes estão automatizados, o tempo e custo para sua execução caem drasticamente, e portanto estes podem ser executados mais frequentemente, tantas vezes quando necessário a qualquer momento ao longo da produção. Como consequência do feedback dos testes automatizados e frequentes, os desenvolvedores se tornam cada vez mais confiantes em produzir incrementos e melhorias no produto. Beck (op. cit.), também sugere trazer os testes automatizados para serem executados automaticamente durante a integração do produto. Esta integração pode também a ser realizada automaticamente, assim que as modificações do produto são submetidas durante o processo de produção. Neste caso, os resultados encontrados tornam-se visíveis aos desenvolvedores e aos clientes declarados como interessados, anunciando quando ocorrem problemas e quando ficam disponíveis novas versões do produto a serem testadas pelo cliente. 3.2 Estudos sobre TDD Segundo Larman e Basili (2003), uma técnica semelhante ao TDD foi inicialmente utilizada no projeto Mercury da NASA, realizado na década de 60. De acordo com Gelperin e Hetzel (1987), nesta época já se praticava os testes preventivos, onde todo o planejamento dos testes e do próprio programa se baseava nos resultados esperados, com eficiência muito superior na cobertura de testes e na quase eliminação da procura por erros. Os autores descrevem em seu artigo a técnica STEP que possui ciclo de vida paralelo a programação, e propõe o desenvolvimento simultâneo de testes e produto com a participação do cliente. Crispin (2006), começa seu artigo deixando seu depoimento: "Eu posso afirmar por experiência pessoal que TDD produz código que tem ordens de magnitude menos erros de unidade, muito menos erros funcionais, e uma probabilidade de atendimento das expectativas do cliente exponencialmente mais alta, quando comparado com técnicas de programação convencionais.". Neste artigo a autora descreve suas experiências com três equipes diferentes, quanto à evolução da capacitação destas equipes, nas quais ela atuou como treinadora de testes. As equipes estudadas variaram entre estados em que precisavam de treinamento em três estágios: ajuda com testes de unidade, ajuda com testes funcionais e já experientes. Outro ponto destacado neste trabalho (CRISPIN, op. cit.) é que os testes automáticos, também servem como exemplos e como documentação para futura recuperação do contexto do projeto. Os testes buscam por resultados seguindo exemplos passados pelos clientes, portanto ao ler os testes se consegue recuperar os objetivos de requisitos, módulos e unidades (funções e procedimentos) desenvolvidos, simplificando a recuperação do contexto. Ainda segundo a autora, com um ano e meio de treinamento as equipes estava fazendo bons testes de unidade e testes de requisito. O início do processo, ao levantar os requisitos, passa a ser a documentação dos resultados esperados para os testes, utilizando valores e condições concretas e objetivas que devem ser atingidas, descritas pelo próprio usuário. Os resultados obtidos foram de melhoria na diminuição de 65% de erros encontrados em testes posteriores ao desenvolvimento. Em seu artigo, Williams e colaboradores (2003) descrevem seus experimentos para 7

8 comparação da eficácia do TDD, em projetos industriais, realizados na Microsoft Corporation, onde o autor relata redução de tempo de projeto e incremento da qualidade. Os estudos foram realizados no sistema operacional Windows e no sistema MSN, pois foram considerados projetos grandes e distintos em complexidade e linguagens de programação. Foram escolhidos programadores experientes e produtividade e qualidade similares para comparação entre testes convencionais e TDD. Neste artigo foi considerado para avaliação um critério de densidade de erros por quantidade de linhas de código. No primeiro estudo realizado, foi detectado uma taxa de erros sobre quantidade de linhas de código (densidade de erros) de 2,6 vezes maior, referente ao desenvolvimento sem TDD, gerada por programadores de mesma habilidade e no mesmo projeto. Entretanto, estimativas dos gerentes indicam um acréscimo de 25 a 35% no tempo de produção. Neste estudo o índice de cobertura (quantidade de linhas de teste sobre quantidade de linhas de código) foi de 66% de cobertura. No segundo estudo, com um índice de cobertura de 88%, a densidade de erros em termo foi 4,2 vezes maior no desenvolvimento sem TDD, apesar do aumento de tempo de desenvolvimento pelo uso desta técnica ter representado somente 15% a mais. Entretanto, os autores (op.cit) deixam claro como restrições do trabalho que, apesar de acreditarem nas conclusões, mais experimentos são necessários para comprovação dos resultados obtidos, várias outras equipes já praticavam esta técnica em seus projetos, e que pelos resultados obtidos já havia uma expectativa positiva pelos resultados. Huang e Holcombe (2009) buscaram comprovação estatística em experimento conduzido com estudantes de programação em curso de graduação. Para execução de projetos foram designados grupos para utilização de TDD e testes convencionais, e foram testadas a produtividade, o esforço em programação de testes e a qualidade dos software produzidos pelas equipes. A produtividade foi medida pela quantidade de linhas de código / homem-hora. O esforço em programação dos testes foi obtido pela medição e comparação do tempo gasto em codificação de testes e do programa real. A qualidade foi obtida por um questionário aplicado aos clientes dos programas, contendo variáveis como: boa aparência, inteligibilidade, facilidade de uso, tratamento de erros, manuais, inovação, robustez e satisfação geral. Estes experimentos foram realizados com o agravante de mudanças periódicas nos requisitos estabelecidos inicialmente, com o objetivo de observar a vantagens na adaptabilidade das técnicas. Os resultados foram para o critério produtividade foram testados estatisticamente para verificar sua distribuição e coerência interna. A produtividade ficou comprovada apresentando 12,38 linhas/homem-hora desenvolvidas usando TDD, enquanto somente 7,21 linhas/homehora em não-tdd, demonstrando que esta técnica aumenta em 70% em média a produtividade de equipes. Cabe ressaltar que equipes sem treinamento não atingirão esta performance, entretanto entre os indivíduos testados foram uma mistura onde haviam alunos com habilitações baixas e médias. Os resultados obtidos foram que o tempo médio gasto com testes em TDD foi de 8,56 horas com desvio padrão de 7,41 horas, enquanto que com testes convencionais foi de 4,58 horas com desvio de 3,98 horas. Neste critério os autores relataram que os programadores que não utilizaram TDD, deixaram para fazer testes somente ao terminar os programas, e testaram muito menos. As equipes que 8

9 praticaram TDD, apesar do tempo gasto com execução dos testes ser pequeno, em escala de segundos, o tempo gasto com programação dos testes foi muito superior. Foi notado também, que por não haverem programadores maduros no uso de TDD, algum tempo foi gasto estudando e procurando como desenvolver os testes. Quanto a qualidade obtida, os dados indicaram uma leve superioridade para testes convencionais, obtendo uma pontuação de 39,4 enquanto TDD atingiu 38 pontos. A explicação encontrada pelos autores relaciona os resultados obtidos a experiência prévia em desenvolvimento dos diferentes elementos das equipes e a presença de uma grande maioria de critérios não relacionados com TDD, como manuais, aspecto visual, inteligibilidade, facilidade de uso, inovação, enquanto os objetivos do TDD poderiam ser avaliados somente por tratamento de erros e robustez. Desta forma, não foi encontrada relação entre os critérios qualidade e esforço sobre testes. Também não foi encontrada correlação entre esforço para testes e esforço de codificação, por causa da variação de tempos derivada da diferença entre habilidades dos programadores. Os tempos variaram entre 500 hh até mais de 1000 hh, inviabilizando os tratamentos estatísticos. Entretanto, foram obtidos em outros experimentos anteriores dados que possibilitaram a execução dos testes estatísticos e onde foi comprovada a existência de uma correlação entre o esforço para testes e a diminuição do codificação, conforme proposto por Beck (2002), em que o código torna-se mais simples e mais objetivo. 4. Estudo de caso O NSI (Núcleo de Pesquisa em Sistema de Informação) vem desenvolvendo sistemas ERP e ECM desde 2002, e vem aplicando as técnicas descritas neste artigo em seu ambiente produtivo desde Este estudo de casos focará um módulo específico utilizado junto à uma solução ECM mantida pelo NSI. O OOOD (OpenOffice.org Daemon), módulo monitorado neste estudo de caso, foi inicialmente desenvolvido pela Nexedi, empresa Francesa associada ao NSI, que desenvolveu está ferramenta com o objetivo de extrair e inserir metadados em um documento e converter e exportar documentos para formatos suportados pelo OpenOffice.org. Este projeto foi escolhido por ter utilizado a técnica de TDD desde o início de seu desenvolvimento até o momento atual. Inicialmente os desenvolvedores não possuíam proficiência completa no seu uso, mas durante o processo também ocorreu o aprendizado e foram obtidos os resultados esperados em termos de estabilidade. O outro projeto demonstrado neste trabalho, como grupo controle, não apresentando portanto o uso do TDD, é a Biblioteca Digital (BD). Este projeto foi desenvolvido também pelo NSI, tem o objetivo de manter dados sobre obras literárias, gráficas e vídeos. Foi desenvolvida sem a utilização das técnicas de TDD Metodologia do Estudo de Caso A metodologia utilizada espera demonstrar estabilidade durante o processo de produção e a diminuição progressiva dos erros. Ao longo do processo de produção de software normalmente ocorrem o aumento da complexidade e mudanças nos requisitos do produto, causando instabilidade no ambiente e com isso o aumento na ocorrência de erros. A estabilidade que se deseja demonstrar neste trabalho se refere a diminuição de erros e aumento das melhorias observados ao longo do desenvolvimento, atribuídos ao monitoramento contínuo do funcionamento dos software realizado pelos testes automatizados. 9

10 Estima-se empiricamente que quanto maior o grau de cobertura de testes oferecido pelo TDD, maior seja a segurança do desenvolvedor para operar o incremento, melhorias e concertos necessários, diminuindo portanto a ocorrência de erros e aumentando o número de melhorias que são tradicionalmente evitadas. Nestes projetos foram utilizados um recurso para o monitoramento da evolução do software chamado controle de versões. O Controle de versões é um recurso de monitoramento utilizado no desenvolvimento de software para acompanhar as mudanças submetidas pelos desenvolvedores. Cada incremento, alteração ou concerto é enviado para este sistema e só então é incorporado ao software. Para verificar se o crescimento do software foi realmente estável, buscou-se identificar no controle de versões quais informações poderiam sinalizar a evolução do desenvolvimento do software. Foi recuperada a lista das mudanças submetidas ao controle de versão, para a partir desta lista verificar se nas descrições das atualizações ocorriam palavras que pudessem sugerir a categoria de modificação à que cada alteração no código se referia. Idealmente buscou-se identificar três situações básicas a saber: a criação de novas funcionalidades ou evolução do código; alterações para melhoria do código ; e correção de erros. Espera-se que as modificações para crescimento ou criação de novos módulos sirvam como uma indicação da estabilidade do código. Quanto as operações de alteração para melhoria, espera-se que possam indicar a evolução qualitativa do código, pois teoricamente o software estaria funcional, porém diante de uma oportunidade de melhoria. As operações consideradas como de correção, indicam que a execução atingiu um caminho não coberto pelos testes, indicando portanto uma falha na cobertura do código e portanto instabilidade do produto. Após avaliar as informações recuperadas do sistema de controle de versão e identificar a categoria de cada operação, foi associado um vetor de inclinação para cada registro, onde as operações de crescimento indicam um ambiente estável, recebendo atribuição de valor positiva (1), denotando a evolução do código. Operações de alteração receberam uma valor neutro (0), demonstrando estabilidade do ambiente. Operações para concerto de erros recebem inclinação negativa (-2), demonstrando instabilidade. O valor atribuído aos erros (-2) foi utilizado intensificar o efeito visual (exagerar) dos erros, para facilitar a identificação dos erros no gráfico e favorecer uma avaliação visual da evolução do código. Outros valores foram experimentados (-3, -5, -10), porém não favoreceram a interpretação dos resultados. O objetivo desta atribuição de valores é plotar em um gráfico apresentando a evolução do software para inferir se este desenvolvimento foi estável ou não. Um exemplo dos registros recuperados do sistema de controle de versão pode ser visto na figura 1 e 3. 10

11 Figura 1 Evolução do Projeto O3d Na figura 1, pode-se observar que o desenvolvimento pode ser dividido em três fases. Na primeira fase (A), os desenvolvedores começaram a criar a arquitetura da solução, e os primeiros testes ainda não haviam encontrado erros. Na segunda fase (B), os erros começaram a aparecer, o que representou um aprendizado para a equipe. Esta fase apresentou 18 erros o que representou 45% do total de erros do projeto. Na terceira fase (C), a mais longa, pode-se observar uma certa estabilidade, com poucas declividades (erros). Apresentam-se dois momentos em que ocorreram mais erros no final do projeto (P1 e P2). Estes momentos foram erros críticos, porém a partir da estabilidade do ambiente, foram sanados rapidamente. Dentre os 22 erros detectados durante a terceira etapa do desenvolvimento, pode-se estimar que a dispersão destes erros no tempo foi menos densa do que os erros ocorridos durante a segunda etapa por exemplo. Esta distância entre os erros, também é uma vantagem do uso do TDD, pois existe uma tendência a que ocorram cada vez menos erros diante do aperfeiçoamento do desenvolvedor com o uso da técnica. Na figura 2, pode-se observar que a quantidade de erros foi muito pequena dentro do projeto. Também pode-se observar que as operações de refatoração (melhorias e aprimoramentos) foram muito constantes, o que só poderia ocorrer dentro de um ambiente estável e onde os desenvolvedores sentem-se confiantes. Poderia-se imaginar que em um ambiente não controlado, as melhorias poderia gerar mais erros, difíceis de ser encontrados e concertados. Figura 2 Avaliação das categorias do projeto O3d 11

12 Na figura 3 é apresentado o comportamento do outro projeto estudado, a Biblioteca Digital (BD), onde não se usou a técnica de TDD. A metodologia para plotar os dados foi a mesma já citada do caso anterior. Figura 3 Figura 3 - Evolução do projeto BD Este projeto esteve constantemente sujeito a problemas como propagação de erros, o que tornou o desenvolvimento menos estável, diminuindo as chances de melhorias do projeto. Os percentuais das categorias avaliadas encontram-se na figura 4, onde pode-se observar um número menor de melhorias e maior de erros. Pode-se observar por esta figura dois comportamentos característicos. Na fase A foi o início do desenvolvimento ocorrendo incremento de funcionalidades, porém com muitos erros e concertos. A intensidade de incrementos normalmente acompanhada de erros. Durante a fase B, entretanto, ocorreu evolução, com grande aporte de funcionalidades, também ocorreram muitos erros, no entanto o processo esteve melhor controlado, mas sem atingir a estabilidade do projeto O3d. A fase C, apresentou algum crescimento, porém foi predominante de melhorias e concertos. Pode-se observar que durante as três fases a oscilação de erros é bem distinta do projeto O3d. Figura 4 Categorias avaliadas no projeto BD Ao comparar os gráficos é possível notar que o projeto do O3d, utilizou as práticas de TDD desde o inicio, apresenta uma ocorrência de erros menor e mais distribuída, com maior distância entre erros, o que pode sugerir uma maior estabilidade do processo. A partir da figura 3, pode-se perceber um constante envio de testes após o envio do código produzido. Como foi visto empiricamente, teste depois do código produzido é um grande passo para surgimento de erros e necessidade maior de refatoração. 12

PRODUÇÃO ENXUTA. Eng. Liane Freitas, MsC.

PRODUÇÃO ENXUTA. Eng. Liane Freitas, MsC. PRODUÇÃO ENXUTA Eng. Liane Freitas, MsC. O que será visto neste capítulo? 1 O significado a filosofia JIT 2 O JIT versus a prática tradicional 3 As técnicas JIT de gestão 4 As técnicas JIT de planejamento

Leia mais

CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS E ARQUITETURA SUBÁREA: ENGENHARIAS INSTITUIÇÃO: FACULDADE DE ENGENHARIA DE SOROCABA

CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS E ARQUITETURA SUBÁREA: ENGENHARIAS INSTITUIÇÃO: FACULDADE DE ENGENHARIA DE SOROCABA TÍTULO: UTILIZAÇÃO DE SOFTWARES DEDICADOS PARA O DESENVOLVIMENTO E ELABORAÇÃO DO MAPEAMENTO DO FLUXO DE VALOR (MFV) EM SISTEMAS DE PRODUÇÃO ENXUTA LEAN PRODUCTION CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS

Leia mais

Kanban na Fábrica de Software

Kanban na Fábrica de Software Kanban na Fábrica de Software Casimiro Beleze (UEM) casimirobeleze@hotmail.com Lafaiete H. R. Leme (UEM) lafaiete@din.uem.br Resumo: Este trabalho apresenta um enfoque diferenciado para o gerenciamento

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL Guilherme Vota Pereira guivotap@hotmail.com Prof. Pablo Schoeffel, Engenharia de Software Aplicada RESUMO: Este artigo irá efetuar uma abordagem

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

15/09/2011. Historico / Conceito. Lean Production é um programa corporativo ADMINISTRAÇÃO DA PRODUÇÃO II. Evolucao do Conceito LEAN THINKING

15/09/2011. Historico / Conceito. Lean Production é um programa corporativo ADMINISTRAÇÃO DA PRODUÇÃO II. Evolucao do Conceito LEAN THINKING Historico / Conceito Lean : década de 80 James Womack (MIT) Projeto de pesquisa: fabricantes de motores automotivos; ADMINISTRAÇÃO DA PRODUÇÃO II Lean Production é um programa corporativo composto por

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

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

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

Leia mais

SUCESSO JAPONÊS E GESTÃO DO CONHECIMENTO: COMO AS FORMAS DO CONHECIMENTO EXPLÍCITO SE TRADUZEM ATRAVÉS DAS FERRAMENTAS DO SISTEMA TOYOTA DE PRODUÇÃO

SUCESSO JAPONÊS E GESTÃO DO CONHECIMENTO: COMO AS FORMAS DO CONHECIMENTO EXPLÍCITO SE TRADUZEM ATRAVÉS DAS FERRAMENTAS DO SISTEMA TOYOTA DE PRODUÇÃO SUCESSO JAPONÊS E GESTÃO DO CONHECIMENTO: COMO AS FORMAS DO CONHECIMENTO EXPLÍCITO SE TRADUZEM ATRAVÉS DAS FERRAMENTAS DO SISTEMA TOYOTA DE PRODUÇÃO Liliane Dolores Fagundes (UNIS) engenhariadeproducao@unis.edu.br

Leia mais

Análise da Utilização de Conceitos de Produção Enxuta em uma Pequena Empresa do Setor Metal Mecânico

Análise da Utilização de Conceitos de Produção Enxuta em uma Pequena Empresa do Setor Metal Mecânico Análise da Utilização de Conceitos de Produção Enxuta em uma Pequena Empresa do Setor Metal Mecânico Matheus Castro de Carvalho (matheus_c_carvalho@hotmail.com / CESUPA) Resumo: A aplicação dos conceitos

Leia mais

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE

A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE A IMPORTÂNCIA DA ATIVIDADE DE TESTE NO DESENVOLVIMENTO DE SOFTWARE Karla Pires de Souza (FPM ) karlapsouza@hotmail.com Angelita Moutin Segoria Gasparotto (FPM ) angelita@usp.br A atividade de teste de

Leia mais

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

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

Leia mais

Professor: Disciplina:

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

Leia mais

ANÁLISE DO PRODUTO NX CMM INSPECTION PROGRAMMING

ANÁLISE DO PRODUTO NX CMM INSPECTION PROGRAMMING Análise do Produto Dr. Charles Clarke ANÁLISE DO PRODUTO NX CMM INSPECTION PROGRAMMING Tendências e requisitos do setor...3 Uma nova abordagem de programação de inspeção de CMM...4 O aplicativo na prática...5

Leia mais

CLASSIFICAR EMPRESAS CONSTRUTORAS QUANTO AO GRAU DE APLICAÇÃO DE FERRAMENTAS LEAN

CLASSIFICAR EMPRESAS CONSTRUTORAS QUANTO AO GRAU DE APLICAÇÃO DE FERRAMENTAS LEAN ISSN 1984-9354 CLASSIFICAR EMPRESAS CONSTRUTORAS QUANTO AO GRAU DE APLICAÇÃO DE FERRAMENTAS LEAN HELOIZA PIASSA BENETTI (UTFPR) Ildeivan da Silva Junior (UTFPR) Eduardo Bellei (UTFPR) Resumo Nesta pesquisa,

Leia mais

DEFINIÇÃO DE LEAN MANUFACTURING

DEFINIÇÃO DE LEAN MANUFACTURING MANUFATURA ENXUTA DEFINIÇÃO DE LEAN MANUFACTURING A ORIGEM DA PALAVRA LEAN O termo LEAN foi cunhado originalmente no livro A Máquina que Mudou o Mundo de Womack, Jones e Roos, publicado nos EUA em 1990.

Leia mais

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

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

Leia mais

Lean manufacturing ou Toyotismo

Lean manufacturing ou Toyotismo ou Toyotismo Gestão da Qualidade Resultados impressionantes 1 Trimestre 2007 Toyota supera GM como líder mundial em vendas Vendas Mundiais 1º Trimestre Nº Carros Toyota 2.348.000 GM 2.260.000 2007 termina

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

Comercial. Gestão da Qualidade

Comercial. Gestão da Qualidade Gestão da Qualidade Comercial Ferramentas da Qualidade: Ações preventivas são tomadas em problemas potenciais, aqueles que ainda não ocorreram, mas que podem vir a ocorrer no futuro caso não seja tomada

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães

A Importância do Controle da Qualidade na Melhoria de Processos de Software. Ana Liddy Cenni de Castro Magalhães A Importância do Controle da Qualidade na Melhoria de Processos de Software Ana Liddy Cenni de Castro Magalhães Agenda Contextualização da Qualidade Dificuldades na construção de software Possíveis soluções

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Qualidade de Software

Qualidade de Software Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br A expressão ISO 9000 (International Organization for Standardization) designa um grupo de normas técnicas que estabelecem

Leia mais

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

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

Leia mais

JIDOKA. Gilberto I. Kosaka

JIDOKA. Gilberto I. Kosaka Gilberto I. Kosaka JIDOKA A filosofia lean com os seus cinco princípios: valor, fluxo de valor, fluxo contínuo, puxar e perfeição é inspirada no TPS (Toyota Production System). O TPS constitui um sistema

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Gerenciamento de Projetos de Software

Gerenciamento de Projetos de Software Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc. 2º Encontro Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr (VISTO) Aula 2:

Leia mais

TÍTULO: GESTÃO DA PRODUÇÃO COM FOCO NA MANUFATURA ENXUTA MELHORIA DE PROCESSOS INDUSTRIAIS ATRAVÉS DO SISTEMA TOYOTA DE PRODUÇÃO

TÍTULO: GESTÃO DA PRODUÇÃO COM FOCO NA MANUFATURA ENXUTA MELHORIA DE PROCESSOS INDUSTRIAIS ATRAVÉS DO SISTEMA TOYOTA DE PRODUÇÃO TÍTULO: GESTÃO DA PRODUÇÃO COM FOCO NA MANUFATURA ENXUTA MELHORIA DE PROCESSOS INDUSTRIAIS ATRAVÉS DO SISTEMA TOYOTA DE PRODUÇÃO CATEGORIA: EM ANDAMENTO ÁREA: ENGENHARIAS E ARQUITETURA SUBÁREA: ENGENHARIAS

Leia mais

DESAFIOS OPERACIONAIS E METROLÓGICOS DA MEDIÇÃO POR COORDENADAS NO AMBIENTE DE MANUFATURA DIGITAL

DESAFIOS OPERACIONAIS E METROLÓGICOS DA MEDIÇÃO POR COORDENADAS NO AMBIENTE DE MANUFATURA DIGITAL II CIMMEC 2º CONGRESSO INTERNACIONAL DE METROLOGIA MECÂNICA DE 27 A 30 DE SETEMBRO DE 2011 Natal, Brasil DESAFIOS OPERACIONAIS E METROLÓGICOS DA MEDIÇÃO POR COORDENADAS NO AMBIENTE DE MANUFATURA DIGITAL

Leia mais

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

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

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

Tópicos. Engenharia de Software: Uma Visão Geral

Tópicos. Engenharia de Software: Uma Visão Geral Tópicos 2 3 Engenharia de Software: Uma Visão Geral SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 A importância do Software Software Aplicações

Leia mais

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL

Gerenciamento de Serviços em TI com ITIL. Gerenciamento de Serviços de TI com ITIL Gerenciamento de Serviços de TI com ITIL A Filosofia do Gerenciamento de Serviços em TI Avanços tecnológicos; Negócios totalmente dependentes da TI; Qualidade, quantidade e a disponibilidade (infra-estrutura

Leia mais

17/02/2015 JIT KANBAN. Uma técnica que se utiliza de várias normas e regras para modificar o ambiente produtivo.

17/02/2015 JIT KANBAN. Uma técnica que se utiliza de várias normas e regras para modificar o ambiente produtivo. ADMINISTRAÇÃO DA PRODUÇÃO JIT KANBAN - JIT Uma técnica que se utiliza de várias normas e regras para modificar o ambiente produtivo. Técnica voltada para a otimização da produção. PODE SER APLICADA TANTO

Leia mais

LEAN APLICADO À CADEIA DE SUPRIMENTOS

LEAN APLICADO À CADEIA DE SUPRIMENTOS LEAN APLICADO À CADEIA DE SUPRIMENTOS INTRODUÇÃO AO LEAN MANUFACTURING SUPPLY CHAIN (INCLUI LOGÍSTICA) 2 2 INTRODUÇÃO AO LEAN MANUFACTURING 3 INTRODUÇÃO AO LEAN MANUFACTURING Pensar fora da caixa... Lean

Leia mais

Gerenciamento de Qualidade

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

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo

Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo DOCUMENTAÇÃO TÉCNICA Melhores práticas de gerenciamento de ativos de software JUNHO DE 2013 Por que o gerenciamento de ativos de software é tão difícil e como simplificá-lo John Fulton CA IT Business Management

Leia mais

Teste de Software Apresentação

Teste de Software Apresentação Teste de Software Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Agenda Teste de Software VV&T e Defeitos de Software Inspeção de Software Teste

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

Software de gerenciamento de trabalho

Software de gerenciamento de trabalho Software de gerenciamento de trabalho Software de gerenciamento de trabalho GoalPost O software de gerenciamento de trabalho (LMS) GoalPost da Intelligrated fornece informações sob demanda para medir,

Leia mais

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor.

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor. Módulo 6 Módulo 6 Desenvolvimento do projeto com foco no negócio BPM, Análise e desenvolvimento, Benefícios, Detalhamento da metodologia de modelagem do fluxo de trabalho EPMA. Todos os direitos de cópia

Leia mais

Portfólio de Treinamentos. Exo Excelência Operacional // 2014

Portfólio de Treinamentos. Exo Excelência Operacional // 2014 Portfólio de Treinamentos Exo Excelência Operacional // 2014 Treinamentos Exo Excelência Operacional A Exo Excelência Operacional traz para você e sua empresa treinamentos fundamentais para o desenvolvimento

Leia mais

Lean manufacturing ou Toyotismo. Lean manufacturing

Lean manufacturing ou Toyotismo. Lean manufacturing ou Toyotismo Resultados impressionantes 1 Trimestre 2007 Toyota supera GM como líder mundial em vendas Vendas Mundiais 1º Trimestre Nº Carros Toyota 2.348.000 GM 2.260.000 2007 termina empatado tecnicamente

Leia mais

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

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

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

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

Leia mais

PLM Software. A tecnologia de automação de programação NC mais recente para aumentar a eficiência de manufatura de peças. Respostas para a indústria.

PLM Software. A tecnologia de automação de programação NC mais recente para aumentar a eficiência de manufatura de peças. Respostas para a indústria. Siemens PLM Software A tecnologia de automação de programação NC mais recente para aumentar a eficiência de manufatura de peças www.siemens.com/nx W h i t e p a p e r A eficiência de usinagem e a produtividade

Leia mais

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com

Fundamentos em Teste de Software. Vinicius V. Pessoni viniciuspessoni@gmail.com Fundamentos em Teste de Software Vinicius V. Pessoni viniciuspessoni@gmail.com Objetivos do treinamento 1. Expor os fundamentos de Teste de Software; 2. Conceituar os Níveis de Teste; 3. Detalhar sobre

Leia mais

Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio?

Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio? Como obter resultados em TI com gestão e governança efetivas direcionadas a estratégia do negócio? A Tecnologia da Informação vem evoluindo constantemente, e as empresas seja qual for seu porte estão cada

Leia mais

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantação

Leia mais

Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software

Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software Bolívar Arthur Butzke 1, Karine Baiotto 1, Msc. Adalberto Lovato 1, Msc. Vera Lúcia Lorenset Benedetti 1 1 Sistemas de Informação

Leia mais

Questionário - Proficiência Clínica

Questionário - Proficiência Clínica Tema: Elaborador: ENGENHARIA DE PROCESSOS NO LABORATÓRIO CLÍNICO Fernando de Almeida Berlitz. Farmacêutico-Bioquímico (UFRGS). MBA Gestão Empresarial e Marketing (ESPM). Lean Six Sigma Master Black Belt.

Leia mais

LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação

LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação LEAN-CURSOS E WORKSHOPS Cursos otimizados para as necessidades do Cliente Cursos Padrão Workshops de Capacitação Serviços : Cursos e workshops especialmente criados para capacitar a sua organização no

Leia mais

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

ERP: Pacote Pronto versus Solução in house

ERP: Pacote Pronto versus Solução in house ERP: Pacote Pronto versus Solução in house Introdução Com a disseminação da utilidade e dos ganhos em se informatizar e integrar os diversos departamentos de uma empresa com o uso de um ERP, algumas empresas

Leia mais

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Objetivos da Aula: Os objetivos desta aula visam definir termos e conceitos da qualidade. Para tal, pretende-se discutir a relação que se estabelece

Leia mais

Modelagem e Simulação

Modelagem e Simulação AULA 11 EPR-201 Modelagem e Simulação Modelagem Processo de construção de um modelo; Capacitar o pesquisador para prever o efeito de mudanças no sistema; Deve ser próximo da realidade; Não deve ser complexo.

Leia mais

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI)

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) 1 MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) Teresinha Moreira de Magalhães 1 Lúcia Helena de Magalhães 2 Fernando Machado da Rocha 3 Resumo Este trabalho visa apresentar uma

Leia mais

Modelos de processos de desenvolvimento de software

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

Leia mais

Colaboração nas Empresas SPT SIG Aplicações Empresariais

Colaboração nas Empresas SPT SIG Aplicações Empresariais Capítulo 3: Sistemas de Apoio Gerenciais Colaboração nas Empresas SPT SIG Aplicações Empresariais Objetivos do Capítulo Explicar como os SI empresariais podem apoiar as necessidades de informação de executivos,

Leia mais

Garantia de Processo Leis de Lehman Manutenção de Softwares

Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Leis de Lehman Manutenção de Softwares Garantia de Processo Acidentes são eventos raros em sistemas críticos e pode ser impossível simulá-los durante testes de um sistema. Requisitos

Leia mais

Sistemas Empresariais. Capítulo 3: Sistemas de Negócios. Colaboração SPT SIG

Sistemas Empresariais. Capítulo 3: Sistemas de Negócios. Colaboração SPT SIG Capítulo 3: Sistemas de Negócios Colaboração SPT SIG Objetivos do Capítulo Explicar como os SI empresariais podem apoiar as necessidades de informação de executivos, gerentes e profissionais de empresas.

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

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

Leia mais

Gestão da qualidade do software

Gestão da qualidade do software Gestão da qualidade do software Empenhada em assegurar que o nível de qualidade requerido de um produto de software é atingido Envolve a definição de normas e procedimentos de qualidade apropriados, e

Leia mais

COMO MELHORAR O DESEMPENHO DAS LINHAS DE. Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software

COMO MELHORAR O DESEMPENHO DAS LINHAS DE. Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software COMO MELHORAR O DESEMPENHO DAS LINHAS DE PRODUÇÃO Edson Donisete da Silva, Carlos Roberto Sponteado Aquarius Software Objetivo Apresentar conceitos e ferramentas atuais para melhorar eficiência da produção

Leia mais

Projeto de Arquitetura

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

Leia mais

www.fernando.parreiras.nom.br

www.fernando.parreiras.nom.br Análise comparativa de processos de desenvolvimento de software à luz da gestão do conhecimento: um estudo de caso de empresas mineiras Fernando Silva Parreiras Gilzirene Simone Oliveira Contexto A engenharia

Leia mais

Tecnologias e Sistemas de Informação

Tecnologias e Sistemas de Informação Universidade Federal do Vale do São Francisco Curso de Administração Tecnologia e Sistemas de Informação - 02 Prof. Jorge Cavalcanti jorge.cavalcanti@univasf.edu.br www.univasf.edu.br/~jorge.cavalcanti

Leia mais

Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia

Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia P ORTFÓ FÓLIO Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia versão 1.1 ÍNDICE 1. A EMPRESA... 3 2. BI (BUSINESS INTELLIGENCE)... 5 3. DESENVOLVIMENTO DE SISTEMAS... 6 3.1. PRODUTOS

Leia mais

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Carlos Alberto Rovedder, Gustavo Zanini Kantorski Curso de Sistemas de Informação Universidade Luterana do Brasil (ULBRA) Campus

Leia mais

IBM WebSphere Business Monitor

IBM WebSphere Business Monitor Obtenha visibilidade em tempo real do desempenho dos processos de negócios IBM WebSphere Business Monitor Fornece aos usuários de negócios uma visão abrangente e em tempo real do desempenho dos processos

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Visão Geral dos Sistemas de Informação

Visão Geral dos Sistemas de Informação Visão Geral dos Sistemas de Informação Existem muitos tipos de sistemas de informação no mundo real. Todos eles utilizam recursos de hardware, software, rede e pessoas para transformar os recursos de dados

Leia mais

Alinhamento Estratégico da TI com o Modelo de Negócios da Empresa: um estudo sobre as melhores práticas da biblioteca ITIL

Alinhamento Estratégico da TI com o Modelo de Negócios da Empresa: um estudo sobre as melhores práticas da biblioteca ITIL Alinhamento Estratégico da TI com o Modelo de Negócios da Empresa: um estudo sobre as melhores práticas da biblioteca ITIL Fernando Riquelme i Resumo. A necessidade por criar processos mais eficientes,

Leia mais

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

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

Leia mais

TPM Total Productive Maintenance. ENG 90017 Manutenção e Confiabilidade Flávio Fogliatto

TPM Total Productive Maintenance. ENG 90017 Manutenção e Confiabilidade Flávio Fogliatto TPM Total Productive Maintenance ENG 90017 Manutenção e Confiabilidade Flávio Fogliatto Histórico e panorâmica da sistemática Surgida no Japão, é considerada evolução natural da manutenção corretiva (reativa)

Leia mais

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello

Unidade II GERENCIAMENTO DE SISTEMAS. Prof. Roberto Marcello Unidade II GERENCIAMENTO DE SISTEMAS DE INFORMAÇÃO Prof. Roberto Marcello SI Sistemas de gestão A Gestão dos Sistemas Integrados é uma forma organizada e sistemática de buscar a melhoria de resultados.

Leia mais

GESTÃO DA PRODUÇÃO E OPERAÇÕES

GESTÃO DA PRODUÇÃO E OPERAÇÕES GESTÃO DA PRODUÇÃO E OPERAÇÕES CAPÍTULO 1 Gestão da produção: história, papel estratégico e objetivos Prof. Glauber Santos 1 GESTÃO DA PRODUÇÃO E OPERAÇÕES 1.1 Gestão da produção: apresentação Produção

Leia mais

Evolução dos sistemas ERP nas empresas

Evolução dos sistemas ERP nas empresas Evolução dos sistemas ERP nas empresas Aloísio André dos Santos (ITA) aloisio@mec.ita.br João Murta Alves (ITA) murta@mec.ita.br Resumo Os sistemas ERP são considerados uma evolução dos sistemas de administração

Leia mais

Garantia da Qualidade de Software

Garantia da Qualidade de Software Especialização em Gerência de Projetos de Software Garantia da Qualidade de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto de Ciências Exatas e Naturais

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Aula 15. Tópicos Especiais I Sistemas de Informação. Prof. Dr. Dilermando Piva Jr.

Aula 15. Tópicos Especiais I Sistemas de Informação. Prof. Dr. Dilermando Piva Jr. 15 Aula 15 Tópicos Especiais I Sistemas de Informação Prof. Dr. Dilermando Piva Jr. Site Disciplina: http://fundti.blogspot.com.br/ Conceitos básicos sobre Sistemas de Informação Conceitos sobre Sistemas

Leia mais

Como evitar erros utilizando o Poka-Yoke

Como evitar erros utilizando o Poka-Yoke Seis Sigma Como evitar erros utilizando o Poka-Yoke O Poka-Yoke é uma importante ferramenta na etapa Control do método DMAIC do Lean Seis Sigma. Por Cristina Werkema O Poka-Yoke termo japonês que significa

Leia mais

JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO

JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO JUST IN TIME: UMA DAS FERRAMENTAS DE OTIMIZAÇÃO DA PRODUÇÃO RESUMO O presente artigo, mostra de forma clara e objetiva os processos da ferramenta Just in time, bem como sua importância para a área de produção.

Leia mais

Introdução à Qualidade de Software

Introdução à Qualidade de Software FACULDADE DOS GUARARAPES Introdução à Qualidade de Software www.romulocesar.com.br Prof. Rômulo César (romulodandrade@gmail.com) 1/41 Objetivo do Curso Apresentar os conceitos básicos sobre Qualidade de

Leia mais

O Seis Sigma como apoio a Estratégia Organizacional

O Seis Sigma como apoio a Estratégia Organizacional 1 O Seis Sigma como apoio a Estratégia Organizacional Andre Rodrigues da SILVA 1 Introdução A produção em massa revolucionou a fabricação na metade do século XIX e esta filosofia foi explorada por grandes

Leia mais

PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS

PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS PROGRAMA DE DESENVOLVIMENTO DE CADEIAS PRODUTIVAS 2ª OFICINA MAPEAMENTO DO FLUXO DE VALOR Lean Manufacturing é a busca da perfeição do processo através da eliminação de desperdícios Definir Valor Trabalhar

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

INFORMAÇÕES CONECTADAS

INFORMAÇÕES CONECTADAS INFORMAÇÕES CONECTADAS Soluções de Negócios para o Setor de Serviços Públicos Primavera Project Portfolio Management Solutions ORACLE É A EMPRESA Alcance excelência operacional com fortes soluções de gerenciamento

Leia mais

Introdução à Qualidade. Aécio Costa

Introdução à Qualidade. Aécio Costa Introdução à Qualidade Aécio Costa O que é Qualidade? Percepções Necessidades Resultados O que influencia: Cultura Modelos mentais Tipo de produto ou serviço prestado Necessidades e expectativas Qualidade:

Leia mais

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br A importância da aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: estudo de caso do sistema de controle de veículos AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br

Leia mais

ITIL. Information Technology Infrastructure Library

ITIL. Information Technology Infrastructure Library Information Technology Infrastructure Library 34929 - Daniel Aquere de Oliveira 34771 - Daniel Tornieri 34490 - Edson Gonçalves Rodrigues 34831 - Fernando Túlio 34908 - Luiz Gustavo de Mendonça Janjacomo

Leia mais

Introdução Visão Geral Processos de gerenciamento de qualidade. Entradas Ferramentas e Técnicas Saídas

Introdução Visão Geral Processos de gerenciamento de qualidade. Entradas Ferramentas e Técnicas Saídas Introdução Visão Geral Processos de gerenciamento de qualidade Entradas Ferramentas e Técnicas Saídas O que é qualidade? Qualidade é a adequação ao uso. É a conformidade às exigências. (ISO International

Leia mais

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Leonardo Mota, Jobson Massollar, Guilherme Horta Travassos Federal University of Rio de Janeiro/COPPE/PESC Caixa Postal

Leia mais

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

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

Leia mais