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

13 5. Considerações Finais O objetivo deste artigo foi mostrar, sob a luz das origens do teste automatizado na indústria, como a mesma filosofia possui impacto positivo quando empregada no desenvolvimento de software. Esta contribuição se faz necessária em vistas da importância do software na sociedade atual e portanto, da necessidade de melhor gerenciar sua produção. Desta forma, espera-se aumentar o interesse sobre a técnica TDD para projetos que ainda não o utilizem. A partir do estudo de caso, foram avaliados os dados referentes ao desenvolvimento para avaliar a estabilidade do código. É possível observar os vários momentos de desenvolvimento, como por exemplo o início do uso da técnica, em um momento de pouca estabilidade, a evolução do uso e por fim um momento de maior estabilidade do desenvolvimento. A aplicação das técnicas de teste automatizados, refletem positivamente sob a qualidade do software, identificando rapidamente anormalidades e trazendo controle autônomo para o processo produtivo, conforme descrito pela Produção Enxuta. Este trabalho é parte de um estudo de caso mais extenso, onde o projeto será descrito sob vários outros aspectos. Como estudos futuros sugere-se o tratamento estatístico dos dados, através de técnicas de simulação e avaliação dos resultados para melhoria da qualidade no processo de desenvolvimento de software. Outra contribuição deste artigo refere-se ao fato de que as técnicas aqui apresentadas são relativamente recentes, não se encontrando ainda muito trabalhos empíricos comprovando seu desempenho, não existindo um benchmark no qual se possa basear e escalar as vantagens e adicionalmente, não há referências corretas às suas raízes, que podem ser encontradas no Pensamento Enxuto. As técnicas apresentadas apoiam o objetivo de melhoria da qualidade, geram desempenho pelo menos igual aos testes manuais, e se computados os tempos de realização de vários testes, os tempos de produção caem exponencialmente. A utilização da técnica de TDD requer um treinamento para obter os resultados de desempenho quanto a experiência com codificação de testes unitário e de requisitos, e também para ter uma visão mais próxima a do usuário, pois não se pode testar com um olhar técnico sobre o que se fez, sob pena de deixar falhas para que o usuário as encontre. Em próximos trabalhos deverão ser abordadas as vantagens da utilização de BDD (Behaviour Driven Development) (CHELIMSKI et al., 2009), com o objetivo de a validação de software nas camadas mais próximas ao usuário. Referências BECK, K. Test Driven Development: By Example. Addison Wesley. p CRISPIN, L. Driving Software Quality: How Test-Driven Development Impacts Software Quality. IEEE Software. IEEE. p CUSUMANO, M. Microsoft Secrets: How the Worlds Most Powerful Software Company Creates Tchnology, Shapes Markets and Manages People. New York: Free Press. p DEEPRASERTKUL, P.; BHATTARAKOSOL, P.; O'BRIEN, F. Automatic detection and correction of programming faults for software applications. The Journal of Systems and Software. 78. p FAGAN, M.E. Design and Code Inspection to Reduce Errors in Program Development. IBM Systems Journal, vol. 15, no. 3, pp GELPERIN, D. & HETZEL, W. Software quality engineering. Proceedings on: Fourth International 13

14 Conference on Software Testing, Washington, DC, GORADIA, T. Dynamic Impact Analysis: A Cost-effective Technique to Enforce Error-propagation. Proceedings in: ACM-ISSTA'93, Cambrige, MA, USA. p HETZEL, B. The Complete Guide to Software Testing. John Wiley & Sons, Inc, HOLWEG, M. The genealogy of lean production. Journal of Operations Management. 25 p HUANG, L. & HOLCOMBE, M. Empirical investigation towards the effectiveness of Test First programming. Information and Software Technology, n. 51, p LARMAN, G. & V. R. BASILI. Iterative and Incremental Development: A Brief History. IEEE Computer Society. 36(6): MIDDLETON, P. Lean Software Strategies: Proven Techniques for Managers and Developers. New York. Productivity Press. p MYERS, G. J. The Art of Software Testing. Wiley, New York, OHNO, T. O Sistema Toyota de Produção: Além da Produção em Larga Escala. Bookman. Porto Alegre. p PRESMAN, R. Engenharia de Software, 3a. Edição, Makron Books, São Paulo SHINGO, S. O Sistema Toyota de Produção: do ponto de vista da Engenharia de Produção. Porto Alegre: Artmed. p SLACK, N.; CHAMBERS, S.; HARLAND, C.; HARRISON, A.; JOHNSTON, R. Administração da Produção. São Paulo: Editora Atlas, p SOMMERVILLE, I. Engenharia de Software, 6ª Edição, Addison Wesley THELIN, T.; RUNESON, P.; WOHLIN, C.; OLSSON, T.; ANDERSON, C. Evaluation of Usage-Based Reading-Conclusions after Three Experiments. Empirical Software Engineering, v. 9, n. 1-2, p WILLIAMS, L.; MAXIMILIEN, E. M.; VOUK, M. Test-Driven Development as a Defect-Reduction Practice. Proceedings of IEEE International Symposium on Software Reliability Engineering, Denver, CO, pp WOMACK, J. P.; JONES, D. T.; ROSS, D. A máquina que mudou o mundo. Rio de Janeiro: Campus. p WOMACK, J. e JONES, D. (1998) A Mentalidade Enxuta nas empresas: Elimine o desperdício e crie riqueza. Rio de Janeiro: Campus, CHELIMSKI,D.; ASTELS,D.; HELMKAMP,B.; DENNIS,Z.; NORTH,D.; HELLESOY,A. The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. Pragmatic Bookshelf. p

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leia mais

Engª de Produção Prof.: Jesiel Brito. Sistemas Integrados de Produção ERP. Enterprise Resources Planning

Engª de Produção Prof.: Jesiel Brito. Sistemas Integrados de Produção ERP. Enterprise Resources Planning ERP Enterprise Resources Planning A Era da Informação - TI GRI Information Resource Management -Informação Modo organizado do conhecimento para ser usado na gestão das empresas. - Sistemas de informação

Leia mais

Demais Áreas de Conhecimento do PMBOK

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

Leia mais

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

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

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

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

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

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

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

Pós Graduação Engenharia de Software

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

Leia mais

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

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

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

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

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

Leia mais

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

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

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

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

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE Modelo de Otimização de SAM Controle, otimize, cresça Em um mercado internacional em constante mudança, as empresas buscam oportunidades de ganhar vantagem competitiva

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

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 5 http://www.ic.uff.br/~bianca/engsoft2/ Aula 5-05/05/2006 1 Dúvidas da aula passada RUP (Rational Unified Process) é uma ferramenta ou um processo? Resposta: os dois. O

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

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

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

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

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

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

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

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

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

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

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

Gerenciamento de Qualidade

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

Leia mais

Universidade Federal de Sergipe Centro de Ciências Exatas e Tecnológicas Núcleo de Engenharia de Produção Disciplina Engenharia de Produto

Universidade Federal de Sergipe Centro de Ciências Exatas e Tecnológicas Núcleo de Engenharia de Produção Disciplina Engenharia de Produto Universidade Federal de Sergipe Centro de Ciências Exatas e Tecnológicas Núcleo de Engenharia de Produção Disciplina Engenharia de Produto Prof. Andréa Cristina dos Santos, Dr. Eng. andreaufs@gmail.com

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

Análise da vantagem de adoção e uso de sistemas ERP código aberto em relação aos sistemas ERP código fechado

Análise da vantagem de adoção e uso de sistemas ERP código aberto em relação aos sistemas ERP código fechado Análise da vantagem de adoção e uso de sistemas ERP código aberto em relação aos sistemas ERP código fechado Louis Albert Araujo Springer Luis Augusto de Freitas Macedo Oliveira Atualmente vem crescendo

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

Professor: Curso: Disciplina:

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

Leia mais

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

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

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

Sobre a Prime Control

Sobre a Prime Control Sobre a Prime Control A Prime Control é um Centro de Excelência em Qualidade de Software. Nossa missão é desenvolver, aperfeiçoar e realizar serviços de testes de software inovadores que agregam valor

Leia mais

Introdução ao OpenUP (Open Unified Process)

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

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software São Paulo 2007 JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação

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

UTILIZAÇÃO DA METODOLOGIA SEIS SIGMA NO MONITORAMENTO DO SISTEMA OPERACIONAL ENXUTO NA ÁREA DE DESENVOLVIMENTO DE PRODUTOS

UTILIZAÇÃO DA METODOLOGIA SEIS SIGMA NO MONITORAMENTO DO SISTEMA OPERACIONAL ENXUTO NA ÁREA DE DESENVOLVIMENTO DE PRODUTOS UTILIZAÇÃO DA METODOLOGIA SEIS SIGMA NO MONITORAMENTO DO SISTEMA OPERACIONAL ENXUTO NA ÁREA DE DESENVOLVIMENTO DE PRODUTOS Cristiano Marques de Oliveira Delphi Automotive Systems E-mail: cristiano.m.oliveira@delphi.com

Leia mais

Metodologia de Desenvolvimento de Sistemas

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

Leia mais

ISO 9001 Relatórios. A importância do risco em gestao da qualidade. Abordando a mudança. ISO Revisions. ISO Revisions

ISO 9001 Relatórios. A importância do risco em gestao da qualidade. Abordando a mudança. ISO Revisions. ISO Revisions ISO 9001 Relatórios A importância do risco em gestao da qualidade Abordando a mudança BSI Group BSI/UK/532/SC/1114/en/BLD Contexto e resumo da revisão da ISO 9001:2015 Como uma Norma internacional, a ISO

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

Melhores práticas para gerenciamento de suporte a serviços de TI

Melhores práticas para gerenciamento de suporte a serviços de TI Melhores práticas para gerenciamento de suporte a serviços de TI Adriano Olimpio Tonelli Redes & Cia 1. Introdução A crescente dependência entre os negócios das organizações e a TI e o conseqüente aumento

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

ESTUDO COMPARATIVO NBR ISO 13485:2004 RDC 59:2000 PORTARIA 686:1998 ITENS DE VERIFICAÇÃO PARA AUDITORIA

ESTUDO COMPARATIVO NBR ISO 13485:2004 RDC 59:2000 PORTARIA 686:1998 ITENS DE VERIFICAÇÃO PARA AUDITORIA ESTUDOCOMPARATIVO NBRISO13485:2004 RDC59:2000 PORTARIA686:1998 ITENSDEVERIFICAÇÃOPARAAUDITORIA 1. OBJETIVO 1.2. 1. Há algum requisito da Clausula 7 da NBR ISO 13485:2004 que foi excluída do escopo de aplicação

Leia mais

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

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

Leia mais

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

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

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

SISTEMAS DE INFORMAÇÕES GERENCIAIS

SISTEMAS DE INFORMAÇÕES GERENCIAIS 1 SISTEMAS DE INFORMAÇÕES GERENCIAIS John F. Eichstaedt, Toni Édio Degenhardt Professora: Eliana V. Jaeger RESUMO: Este artigo mostra o que é um SIG (Sistema de Informação gerencial) em uma aplicação prática

Leia mais

Impactos humanos da PE CLIENTE. Impactos humanos da PE. Impactos humanos da PE. Impactos humanos da PE. Impactos humanos da PE

Impactos humanos da PE CLIENTE. Impactos humanos da PE. Impactos humanos da PE. Impactos humanos da PE. Impactos humanos da PE Menor Lead Time Estrutura do STP Just-In-Time Fluxo Contínuo Takt Time Produção Puxada Kanban Custo Mais Baixo CLIENTE Segurança Moral Jidoka Separação Homem/ Máquina Poka-Yoke Inspeção Fonte Ação Imediata

Leia mais

Conceitos ADMINISTRAÇÃO DE SISTEMAS DE INFORMAÇÃO. Comunicação; Formas de escritas; Processo de contagem primitivo;

Conceitos ADMINISTRAÇÃO DE SISTEMAS DE INFORMAÇÃO. Comunicação; Formas de escritas; Processo de contagem primitivo; Conceitos Comunicação; Formas de escritas; Bacharel Rosélio Marcos Santana Processo de contagem primitivo; roseliomarcos@yahoo.com.br Inicio do primitivo processamento de dados do homem. ADMINISTRAÇÃO

Leia mais

Módulo 2/3: Automação nos Sistemas de Produção. Prof. André Pedro Fernandes Neto

Módulo 2/3: Automação nos Sistemas de Produção. Prof. André Pedro Fernandes Neto Módulo 2/3: Automação nos Sistemas de Produção Prof. André Pedro Fernandes Neto Razões para Automatizar Alto custo de mão de obra Investimentos em máquinas que possam automatizar a produção com um custo

Leia mais

ONDE OS PROJETOS FALHAM? Manuel da Rocha Fiúza BRANCO, Jr 1

ONDE OS PROJETOS FALHAM? Manuel da Rocha Fiúza BRANCO, Jr 1 ONDE OS PROJETOS FALHAM? Manuel da Rocha Fiúza BRANCO, Jr 1 RESUMO Diversos profissionais relatam dificuldades em coordenar adequadamente projetos sob sua responsabilidade. Muitos fatores que influenciam

Leia mais

EVOLUÇÃO DE SOFTWARE

EVOLUÇÃO DE SOFTWARE EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1 Mudança de Software 2 Manutenção de software Mudança de software é inevitável

Leia mais

O último capítulo desta dissertação visa tecer conclusões a respeito do trabalho e sugerir algumas recomendações para estudos futuros.

O último capítulo desta dissertação visa tecer conclusões a respeito do trabalho e sugerir algumas recomendações para estudos futuros. 7 Conclusão O último capítulo desta dissertação visa tecer conclusões a respeito do trabalho e sugerir algumas recomendações para estudos futuros. A presente dissertação, conforme exposto no Capítulo 1,

Leia mais

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP Versão 2.0.0 Janeiro 2014 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 3ª Edição (a publicar)

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

NECESSIDADES PARA O DESENVOLVIMENTO DE UMA INTERFACE ADEQUADA PARA RESULTADOS DE ENSINO-APRENDIZAGEM BEM SUCEDIDOS. TCC3047

NECESSIDADES PARA O DESENVOLVIMENTO DE UMA INTERFACE ADEQUADA PARA RESULTADOS DE ENSINO-APRENDIZAGEM BEM SUCEDIDOS. TCC3047 1 NECESSIDADES PARA O DESENVOLVIMENTO DE UMA INTERFACE ADEQUADA PARA RESULTADOS DE ENSINO-APRENDIZAGEM BEM SUCEDIDOS. TCC3047 FEVEREIRO /2006 José Antonio Gameiro Salles UNISUAM / CCET / Desenv. de Softwares

Leia mais

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson

Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua Multiplataforma para Java e.net. Hudson QUALIDADE Simpósio Brasileiro de Qualidade de Software - SBQS Instituto Nokia de Tecnologia Unit Test Sucess Bug INdT Melhoria no Desenvolvimento Ágil com Implantação de Processo de Integração Contínua

Leia mais

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

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

Leia mais

Estudo de Viabilidade

Estudo de Viabilidade Estudo de Viabilidade PGE: Plastic Gestor Empresarial Especificação de Requisitos e Validação de Sistemas Recife, janeiro de 2013 Sumário 1. Motivação... 1 2. Introdução: O Problema Indentificado... 2

Leia mais

OS 14 PONTOS DA FILOSOFIA DE DEMING

OS 14 PONTOS DA FILOSOFIA DE DEMING OS 14 PONTOS DA FILOSOFIA DE DEMING 1. Estabelecer a constância de propósitos para a melhoria dos bens e serviços A alta administração deve demonstrar constantemente seu comprometimento com os objetivos

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

Gestão da Tecnologia da Informação

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

Leia mais

Processo de Software

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

Leia mais

DuPont Engineering University South America

DuPont Engineering University South America Treinamentos Práticas de Melhoria de Valor (VIP Value Improvement Practices) DuPont Engineering University South America # "$ % & "" Abordagem DuPont na Gestão de Projetos Industriais O nível de desempenho

Leia mais

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

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

Leia mais

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia mais

2 Fundamentação. 2.1 Manutenção e Evolução de Sistemas

2 Fundamentação. 2.1 Manutenção e Evolução de Sistemas 2 Fundamentação O objetivo deste trabalho é contribuir com pesquisas relacionadas à detecção de anomalias de modularidade em código orientado a objetos. Esses problemas normalmente trazem impactos negativos

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

Conversa Inicial. Olá! Seja bem-vindo à quarta aula de Fundamentos de Sistemas de Informação.

Conversa Inicial. Olá! Seja bem-vindo à quarta aula de Fundamentos de Sistemas de Informação. Conversa Inicial Olá! Seja bem-vindo à quarta aula de Fundamentos de Sistemas de Informação. Hoje iremos abordar os seguintes assuntos: a origem dos sistemas integrados (ERPs), os módulos e fornecedores

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

Importância do GED. Implantação de um Sistema de GED

Importância do GED. Implantação de um Sistema de GED Implantação de um Sistema de GED Gerenciamento Eletrônico de Documentos Importância do GED O GED tem uma importante contribuição na tarefa da gestão eficiente da informação; É a chave para a melhoria da

Leia mais