Prevençao em saude item 11 - HubslideToggle navigationBUSINESSEDUCATIONTECHNOLOGYTRAVELMORE TOPICSSign upSign in Home' PaanPrevençao em saude item 11 of 27Prevençao em saude item 11 ' PaanPublished on: Mar 4, 2016 Transcripts - Prevençao em saude item 11\nPamela Jade Maciel Prevenção em Saúde Item 11\nCondiloma Acuminado Infecção por HPV Agente HPV é o nome de um grupo de vírus que inclui mais de 100 tipos. As verrugas genitais ou condilomas acuminados são apenas uma das manifestações da infecção pelo vírus do grupo HPV e estão relacionadas com os tipos 6,11 e 42, entre outros. Os tipos (2, 4, 29 e 57) causam lesões nas mãos e pés (verrugas comuns). Outros tipos tem um potencial ontogênico (que pode desenvolver câncer) maior do que os outros (HPV tipo 16, 18, 45 e 56) e são os que tem maior importância clínica. O espectro das infecções pelos HPV é muito mais amplo do que se conhecia até poucos anos atrás e inclui também infecções subclínicas (diagnosticadas por meio de peniscopia, colpocitologia, colposcopia e biópsia) e infecções latentes (só podem ser diagnosticada por meio de testes para detecção do vírus). Alguns trabalhos médicos referem-se a possibilidade de que 10-20% da população feminina sexualmente ativa, possa estar infectada pelos HPV. A principal importância epidemiológica destas infecções deriva do fato que do início da década de 80 para cá, foram publicados muitos trabalhos relacionando-as ao câncer genital, principalmente feminino. Complicações/Consequências Câncer do colo do útero e vulva e, mais raramente, câncer do pênis e também do ânus.\nTransmissão Contacto sexual íntimo (vaginal, anal e oral). Mesmo que não ocorra penetração vaginal ou anal o vírus pode ser transmitido. O recém-nascido pode ser infectado pela mãe doente, durante o parto. Pode ocorrer também, embora mais raramente, contaminação por outras vias (fômites) que não a sexual : em banheiros, saunas, instrumental ginecológico, uso comum de roupas íntimas, toalhas etc. Período de Incubação Semanas a anos. (Como não é conhecido o tempo que o vírus pode permanecer no estado latente e quais os fatores que desencadeiam o aparecimento das lesões, não é possível estabelecer o intervalo mínimo entre a contaminação e o desenvolvimento das lesões, que pode ser de algumas semanas até anos ou décadas). Diagnóstico O diagnóstico é essencialmente clínico (anamnese e exame físico). Eventualmente recorre-se a uma biópsia da lesão suspeita.\nTratamento O tratamento visa a remoção das lesões (verrugas, condilomas e lesões do colo uterino). Os tratamentos disponíveis são locais (cirúrgicos, quimioterápicos, cauterizações etc.). As recidivas (retorno da doença) podem ocorrer e são freqüentes, mesmo com o tratamento adequado. Eventualmente, as lesões desaparecem espontaneamente. Não existe ainda um medicamento que erradique o vírus, mas a cura da infecção pode ocorrer por ação dos mecanismos de defesa do organismo. Já existem vacinas para proteção contra alguns tipos específicos do HPV, estando as mesmas indicadas para pessoas não contaminadas. Prevenção Camisinha usada adequadamente, do início ao fim da relação, pode proporcionar alguma proteção. Ter parceiro fixo ou reduzir numero de parceiros. Exame ginecológico anual para rastreio de doenças pré-invasivas do colo do útero. Avaliação do(a) parceiro(a). Abstinência sexual durante o tratamento. Em 2006 foi aprovada pela ANVISA (Agência Nacional de Vigilância Sanitária) a utilização da Vacina Quadrivalente produzida pelo Laboratório Merck Sharp & Dohme contra os tipos 6,11,16 e 18 do HPV, para meninas e mulheres de 9 a 26 anos que não tenham a infecção. Esta vacina confere proteção contra os vírus citados acima, os quais são responsáveis por 70% dos casos de câncer do colo do útero (tipos 16 e 18) e 90% dos casos de verrugas (condilomas) genitais (tipos 6 e 11).\nCondiloma peniano. Condiloma vaginal. Fotos\nHerpes Simples Genital Agente Virus do Herpes Genital ou Herpes Simples Genital ou HSV-2. É um DNA vírus. Observação: Outro tipo de Herpes Simples é o HSV-1, responsável pelo Herpes Labial. Tem ocorrido crescente infecção genital pelo HSV-1 e vice-versa, isto é, infecção labial pelo HSV-2, certamente em decorrência do aumento da prática do sexo oral ou oro-genital. Complicações/Consequências Abôrto espontâneo, natimorto, parto prematuro, baixo peso, endometrite pós-parto. Infecções peri e neonatais. Vulvite. Vaginite. Cervicite. Ulcerações genitais. Proctite. Complicações neurológicas etc. Transmissão Frequentemente pela relação sexual. Da mãe doente para o recém-nascido na hora do parto.\nPeríodo de Incubação 1 a 26 dias. Indeterminado se se levar em conta a existência de portadores em estado de latência (sem manifestações) que podem, a qualquer momento, manifestar a doença. Diagnóstico O diagnóstico é essencialmente clínico (anamnese e exame físico). A cultura e a biópsia são raramente utilizados. Tratamento Não existe ainda tratamento eficaz quanto a cura da doença. O tratamento tem por objetivo diminuir as manifestações da doença ou aumentar o intervalo entre as crises. Prevenção Não está provado que a camisinha diminua a transmissibilidade da doença. Higienização genital antes e após o relacionamento sexual é recomendável. Escolha do(a) parceiro(a).\nFotos Herpes Labial. Lesões no pênis (fase inicial). Lesões no períneo feminino Lesões localizadas no pênis.\nCancro Duro (Sífilis) Sífilis primária: trata-se de uma lesão ulcerada (cancro) não dolorosa (ou pouco dolorosa), em geral única, com a base endurecida, lisa, brilhante, com presença de secreção serosa (líquida, transparente) escassa e que pode ocorrer nos grandes lábios, vagina, clítoris, períneo e colo do útero na mulher e na glande e prepúcio no homem, mas que pode tambem ser encontrada nos dedos, lábios, mamilos e conjuntivas. É frequente também a adenopatia inguinal (íngua na virilha) que, em geral passa desapercebida. O cancro usualmente desaparece em 3 a 4 semanas, sem deixar cicatrizes. Entre a segunda e quarta semanas do aparecimento do cancro, as reações sorológicas (exames realizados no sangue) para sífilis tornam-se positivas. Sífilis Secundária: é caracterizada pela disseminação dos treponemas pelo organismo e ocorre de 4 a 8 semanas do aparecimento do cancro. As manifestações nesta fase são essencialmente dermatológicas e as reações sorológicas continuam positivas. Sífilis Latente: nesta fase não existem manifestações visíveis mas as reações sorológicas continuam positivas.\nSífilis Adquirida Tardia: a sífilis é considerada tardia após o primeiro ano de evolução em pacientes não tratados ou inadequadamente tratados. Apresentam-se após um período variável de latência sob a forma cutânea, óssea, cardiovascular, nervosa etc. As reações sorológicas continuam positivas também nesta fase. Sífilis Congênita: é devida a infecção do feto pelo Treponema por via transplacentária, a partir do quarto mês da gestação. As manifestações da doença, na maioria dos casos, estão presentes já nos primeiros dias de vida e podem assumir formas graves, inclusive podendo levar ao óbito da criança. Sinônimos Cancro duro, cancro sifilítico, Lues. Agente Treponema pallidum Complicações/Consequências Abôrto espontâneo, natimorto, parto prematuro, baixo peso, endometrite pós-parto. Infecções peri e neonatal. Sífilis Congênita. Neurossífilis. Sífilis Cardiovascular.\nTransmissão Relação sexual (vaginal anal e oral), transfusão de sangue contaminado, transplacentária (a partir do quarto mês de gestação). Eventualmente através de fômites. Período de Incubação 1 semana à 3 meses. Em geral de 1 a 3 semanas. Diagnóstico Pesquisa direta do agente nas lesões. Exames sorológicos (VDRL, FTA-ABS etc) Tratamento Medicamentoso. Com cura completa, se tratada precoce e adequadamente. Prevenção Camisinha pode proteger da contaminação genital se a lesão estiver na área recoberta. Evitar contato sexual se detectar lesão genital no(a) parceiro(a).\nFotos Lesão localizada no pênis (glande Lesão localizada na vulva (grandes lábios)\nGonorréia Agente Neisseria gonorrhoeae Complicações/Consequências Abôrto espontâneo, natimorto, parto prematuro, baixo peso, endometrite pós-parto. Doença Inflamatória Pélvica. Infertilidade. Epididimite. Prostatite. Pielonefrite. Meningite. Miocardite. Gravidez ectópica. Septicemia, Infecção ocular (ver foto abaixo) , Pneumonia e Otite média do recém-nascido. Artrite aguda etc. Assim como a infecção por clamídia, é uma das principais causas infecciosas de infertilidade feminina.\nTransmissão Relação sexual. O risco de transmissão é superior a 90%, isto é, ao se ter um relacionamento sexual com um(a) parceiro(a) doente, o risco de contaminar-se é de cerca de 90%. O fato de não haver sintomas (caso da maioria das mulheres contaminadas), não afeta a transmissibilidade da doença. Período de Incubação 2 a 10 dias Diagnóstico Exame das secreções coradas pelo Gram e/ou cultura do mesmo material. Tratamento Antibióticos. Prevenção Camisinha. Higiene pós-coito.\nFotos Uretrite gonocócica (no homem) Vaginite gonocócica. Oftalmia gonocócica.\nLinfogranuloma Venéreo Agente Chlamydia trachomatis. Complicações/Consequências Elefantíase do pênis, escroto, vulva. Proctite (inflamação do reto) crônica. Estreitamento do reto. Transmissão Relação sexual é a via mais frequente de transmissão. O reto de pessoas cronicamente infectada é reservatório de infecção. Período de Incubação 7 a 60 dias.\nDiagnóstico Em geral o diagnóstico é feito com base nas manifestações clínicas (íngua, elefantíase genital, estenose uretral etc) sendo ocasional a necessidade de comprovação laboratorial (teste de fixação de complemento, cultura, biópsia etc). Tratamento Sistêmico, através de antibióticos. Aspiração do bubão inguinal. Tratamento das fístulas Prevenção Camisinha. Higienização após o coito.\nFotos Bubão inguinal. Lesão ulcerada do pênis. Elefantíase da bolsa escrotal (saco).\nCancro Mole Sinônimos Cancróide, cancro venéreo simples, "cavalo" Agente Haemophilus ducreyi Complicações/Consequências Não tem. Tratado adequadamente, tem cura completa. Transmissão Relação sexual Período de Incubação 2 à 5 dias\nDiagnóstico Pesquisa do agente em material colhido das lesões. Tratamento Antibiótico. Prevenção Camisinha. Higienização genital antes e após o relacionamento sexual. Escolha do(a) parceiro(a).\nFotos Lesões localizadas no pênis.\nSinônimos SIDA, Síndrome da Imunodeficiência Adquirida, HIV-doença. Agente HIV (Human Immunodeficiency Virus), com 2 subtipos conhecidos : HIV-1 e HIV-2. Complicações/Consequências Doenças oportunísticas, como a tuberculose miliar e determinadas pneumonias, alguns tipos de tumores, como certos linfomas e o Sarcoma de Kaposi. Distúrbios neurológicos. Transmissão Sangue e líquidos grosseiramente contaminados por sangue, sêmem, secreções vaginais e leite materno. Pode ocorrer transmissão no sexo vaginal, oral e anal. Os beijos sociais (beijo seco, de boca fechada) são seguros (risco zero) quanto a transmissão do vírus, mesmo que uma das pessoas seja portadora do HIV. O mesmo se pode dizer de apertos de mão e abraços. Os beijos de boca aberta são considerados de baixo risco quanto a uma possível transmissão do HIV. AIDS\nPeríodo de Incubação De 3 a 10 (ou mais) anos entre a contaminação e o aparecimento de sintomas sugestivos de AIDS. Diagnóstico Por exames realizados no sangue do(a) paciente. Tratamento Existem drogas que inibem a replicação do HIV, que devem ser usadas associadas, mas ainda não se pode falar em cura da AIDS. As doenças oportunísticas são, em sua maioria tratáveis, mas há necessidade de uso contínuo de medicações para o controle dessas manifestações.\nPrevenção Na transmissão sexual se recomenda sexo seguro: relação monogâmica com parceiro comprovadamente HIV negativo, uso de camisinha. Na transmissão pelo sangue recomenda-se cuidado no manejo de sangue (uso de seringas descartáveis, exigir que todo sangue a ser transfundido seja previamente testado para a presença do HIV, uso de luvas quando estiver manipulando feridas ou líquidos potencialmente contaminados). Não há, no momento, vacina efetiva para a prevenção da infecção pelo HIV. É necessário observar que o uso da camisinha, apesar de proporcionar excelente proteção, não proporciona proteção absoluta (ruptura, perfuração, uso inadequado etc). Repito, a maneira mais segura de se evitar o contágio pelo vírus HIV é fazer sexo monogâmico, com parceiro(a) que fez exames e você saiba que não está infectado(a).\nURETRITE NÃO GONOCÓCICA É uma infecção do canal da urina (uretra), parecida com a gonorréia, porém provocada por outros germes (micro-organismos) como: Ureaplasma urealyticum, Mycoplasma hominis, Trichomonas vaginalis, dentre outros, sendo que o principal causador é o Chlamydia trachomatis. Como se pega? Através de contato sexual com o/a parceiro/a contaminado/a. Quais os sintomas? No homem os sintomas são: pouco corrimento, que às vezes aparece somente quando aperta o órgão genital masculino , e ardor para urinar, principalmente na primeira vez pela manhã. A mulher muitas vezes não apresenta sintomas, quando estes aparecem são semelhantes aos da gonorréia, porém menos intensos.\nSE LIGUE Se não for tratada corretamente ou mal tratada (utilizando remédios sem indicação médica) os sintomas podem se agravar cada vez mais. Quanto tempo demora para aparecer? Varia de 14 a 21 dias. Após l a 3 dias, o homem já se queixa de ardência ao urinar, seguida por corrimento. Em alguns casos pode haver febre e outras manifestações gerais de infecção. SAIBA MAIS A u retrite não gonocócica pode ser evitada. Por isso é importante usar a camisinha masculina ou a camisinha feminina. Tratamento As infecções por Chlamydia e Ureaplasma costumam ser tratadas com tetraciclina ou doxiciclina administradas por via oral durante pelo menos 7 dias, ou então com uma dose única de azitromicina. As mulheres grávidas não devem tomar tetraciclina. Em cerca de 20 % das pessoas, a infecção reaparece depois do tratamento. Este é então repetido por um período mais extenso. As pessoas infectadas que têm relações sexuais antes de completar o tratamento podem infectar os seus parceiros. Como consequência e na medida do possível, os referidos parceiros devem ser tratados simultaneamente.\nFebre e tosse. Pneumonia. Dor e secreção ocular. Conjuntivite. Nos Recém-Nascidos Dor e secreção ocular. Infecção do branco dos olhos (conjuntivite). No Homem e na Mulher Dor na parte superior do abdómen. Infecção do revestimento do fígado e da área que circunda este órgão. Dor, gravidez ectópica e esterilidade. Infecção das trompas de Falópio. Na Mulher Obstrução do fluxo de urina. Estreitamento (estenose) da uretra. Dor nos testículos. Infecção do epidídimo. No Homem Efeito possível Complicação Complicações das infecções por Chlamydia ou UreaplasmaRelated DocumentsKeep on trucking`


Integração de modelos de desenvolvimento de software mais e menos ágeis.pdf | Desenvolvimento Àgil de Software | Qualidade (Negócios)\nSalvarSalvar Integração de modelos de desenvolvimento de softwa... para ler mais tarde\n230 visualizações54 páginas\nImplement Ado MPS.br Nivel F\nQualidade em Construção de Software\nCMMI - Nível 2\nSlides Inf. e Adm 1 GQ (RMX)\ntao Gesto de Tecnologia (Estrategia rial\nConceitos e Como Implantar o CMM\nAula 3 - Qualidade de Software - CMMI\nTads - Eng Sftw - Eduardo Salvador Saly - Resumo Cmmi\nUNIABEU_GPT_Gestão de Qualidade em TI\nExperiências de adoção-Artigo2\nFACULDADE DE E NGENHARIA DA UNIVERSIDADE DO PORTO\nmodelos de desenvolv imento de\nsoftwa re mais e menos ágei s\nPedr o Miguel Ribeiro Veloso Gomes\nRelatório de Dissertação Mestrado Inte grado em Engenharia Informática e Computa ção\nOrient ador: João Carlos Pascoal de Faria (Doutor)\nCo-orientad or: Ademar Manuel Teixeira de Aguiar (Doutor)\nIntegração de modelos de desenvolvimento de software mais e menos ágeis\nPedro Miguel Ribeiro Veloso Gomes\nRelatório de Dissertação Mestrado Integrado em Engenharia Informática e Computação\nAprovado em provas públicas pelo Júri:\nPresidente: Ana Cristina Ramada Paiva Pimenta (Professor Auxiliar)\nArguente: José Carlos Nascimento (Professor Auxiliar) Vogal: João Carlos Pascoal de Faria (Professor Auxiliar)\nA utilização de sistemas de informação continua a ter um crescimento exponencial ao\nlongo dos últimos anos e um impacto cada vez mais acrescido. Estes sistemas são intensivamente baseados em software, pelo que a gestão de projectos de desenvolvimento desta natureza assume uma importância acrescida.\nA gestão de um projecto de desenvolvimento de software implica a utilização de práticas\nprofissionais de gestão que controlem o âmbito, o custo e o prazo. Por outro lado, um projecto\nde desenvolvimento de software requer a utilização de práticas de engenharia eficientes, que garantam soluções de qualidade, sustentáveis e adaptadas à utilização social e humana.\nOs dados de mercado mostram que continuamos a ter uma percentagem elevada de projectos de software cancelados e uma percentagem muito elevada de projectos que não cumprem com os objectivos de âmbito, prazo e custo estabelecidos inicialmente.\nA engenharia de software é recente quando comparada com outras engenharias e tem\nsofrido evoluções constantes ao longo dos últimos anos. Surgiram múltiplos modelos e evoluções de modelos de desenvolvimento de software, que sendo de natureza distinta já demonstraram ter sucesso em contextos diversos.\nMais recentemente emergiram uma série de metodologias de desenvolvimento de software designadas de ágeis, que vêm dar ênfase na capacidade que um processo deve ter para absorver mudanças ao longo de um projecto e na vertente humana, de auto-organização da equipa e de contacto próximo com o cliente e de confiança com o mesmo.\nEsta tese pretende trazer um maior esclarecimento sobre os métodos de desenvolvimento de software mais utilizados actualmente, os mais e menos ágeis, e mostrar como a sua combinação adequada pode trazer um valor acrescido na gestão de projectos de desenvolvimento de software. Esta combinação será instanciada através de um método que fornecerá critérios e pressupostos para a criação de uma metodologia adaptada às necessidades específicas de uma organização.\nThe information system’s usage has experienced an exponential growth over the past years as well an increasing impact on human life. These systems are much more software intensive than before and for that software project management presents itself as a crucial discipline.\nThe management of a software development project implies professional practices that assure the project’s scope, cost and schedule control. On the other hand, a software development project requires efficient engineering practices that assure high quality solutions, sustained and adapted to social and human behavior.\nMarket figures show that we still have a big percentage of canceled software projects, and a very high percentage of those who fail to meet the initial objectives for scope, cost and schedule.\nSoftware Engineering is recent, compared to other engineering disciplines, and it has suffered a constant evolution over the past years. Multiple models and evolution to the existent ones came up. Although presenting distinct natures, these models have proved their way in diverse contexts.\nMore recently a series of methodologies for software development emerged which put the emphasis on the capacity for a process to absorb changes, throughout the project and also on the human side, promoting self-directed teams, a trustworthy and close contact with the customer.\nThis thesis aims to bring a higher degree of clarification on the most used software development methodologies, more and less agile, and show how their combination can bring value added to the software development project management.\nThis combination will be instantiated on a method that will supply criteria and pre- requisites for a methodology adapted to the specific organization needs.\nQuero agradecer aos meus orientadores, Pascoal Faria e Ademar Aguiar pelo apoio e conhecimento prestado.\nUm agradecimento para o Jim Over do Software Engineering Institute (SEI), cujas conversas sobre engenharia de software são sempre inspiradoras.\nUma menção para Hilel Glazer do SEI que permitiu uma conversa muito interessante sobre a combinação de métodos ágeis e não ágeis – com uma perspectiva muito agnóstica e agregadora.\nAos meus sócios e equipa do FEUP CIQS (agora Strongstep), porque acima de tudo são meus amigos.\nPor fim, e mais importante do que tudo, à Susana, aos meus pais e irmãos.\n2 Gestão do desenvolvimento de software\nCombinando métodos ágeis e não ágeis\n3 Análise comparativa e critérios de selecção de modelos\nAnálise comparativa dos modelos\nCritérios na selecção de modelos de desenvolvimento\n4 Método de selecção de modelos de desenvolvimento de software\nMétodo de planeamento\n5 Conclusões e trabalho futuro\nSatisfação dos objectivos\nFigura 1 - Combinando práticas ágeis e não ágeis\nFigura 2 - Projectos de desenvolvimento de Software\nFigura 3 - Dimensões de gestão de organizações\nFigura 4 - CMMI - Framework de modelos\nFigura 5 - CMMI - Estrutura das áreas de Processo\nFigura 6 - Competência e consciência\nFigura 7 - CMMI - Níveis de maturidade\nFigura 8 - Ciclo de vida de um projecto - PMBOK\nFigura 9 - TSP/PSP - Ciclo de vida\nFigura 10 - TSP/PSP – Lançamento de iteração\nFigura 11- TSP/PSP - Equipas\nFigura 12 - Scrum\nFigura 13 - Scrum Burndown Chart\nFigura 14 - Extreme Programming - Práticas\nFigura 15 - Extreme Programming – Ciclo de vida\nFigura 16 - Cinco factores para secção de métodos\nFigura 17 - Aspectos culturais na selecção do método\nFigura 18 - Método Boehm de selecção de metodologia\nFigura 19 - Desenvolvimento de Sistemas de Informação e de Software\nFigura 20 - Comparando os métodos\nFigura 21 - Posicionamento das metodologias\nFigura 22 - CMMI, Scrum e TSP/PSP\nFigura 23 - Centro de gravidade de um processo\nFigura 24 - Custo de performance e da qualidade\nFigura 25 - Método para planear a qualidade\nFigura 26 - Combinando práticas ágeis e não ágeis\nTabela 1- Percentagem de funções realizadas por software nos aviões militares\nTabela 2 - Sucesso nos Projectos de Software\nTabela 3 - Método de selecção de metodologia\nTabela 4 - Riscos metodológicos de Boehm\nTabela 5 - Eficiência de remoção de defeitos\nAbreviaturas e Definições\nAgilidade no desenvolvimento de software\nTermo utilizado nos métodos ágeis que designa um conjunto de funcionalidades a serem implementadas numa release\nGráfico que foca no esforço a realizar num projecto\nCMMI para aquisições de software\nCMMI para desenvolvimento de software\nCMMI para serviços de software\nMétrica de gestão de projectos que foca no trabalho realizado\nProgramação de software executada por dois programadores no\nRedesenho de software\nResultado produzido que marca o final de uma iteração ou sprint\nMetodologia ágil de desenvolvimento de software focada na gestão do projecto\nSoftware Engineerig Institute\nTermo utilizado nos métodos ágeis que designa um intervalo fixo de tempo destinado ao desenvolvimento de funcionalidades\nTermo utilizado nos métodos ágeis que designa uma reunião de lições\naprendidas relativa a um sprint\nTermo utilizado nos métodos ágeis que designa uma reunião de apresentação das funcionalidades desenvolvidas\nTermo utilizado nos métodos ágeis para uma reunião, que é feita em pé, de ponto de situação de desenvolvimento\nTeam Software Process / Personal Software Process\nRequisitos escritos de uma forma funcional simplificada em forma de história\nExtreme Programming - Metodologia ágil de desenvolvimento de software focada em técnicas de engenharias software\nEste trabalho é realizado no âmbito do Mestrado Integrado em Engenharia Informática e Computação da Faculdade de Engenharia da Universidade do Porto e visa fornecer uma perspectiva sobre a utilização integrada e adequada de modelos de desenvolvimento de projectos de software mais e menos ágeis. Pretende-se promover alguma clarificação sobre os diversos modelos existentes, a sua natureza, os seus pontos comuns e os seus pontos distintos.\nCom a introdução dos modelos de desenvolvimento ágeis surgiu uma certa confusão na comunidade profissional, ao nível de gestores e técnicos sobre as características efectivas de cada modelo e o seu correcto modo de utilização. Este trabalho vai revisitar as características de cada modelo específico, dos mais proeminentes, e promover um método que permita a uma organização, ou a um projecto, conseguir tirar o melhor partido dos mesmos (ver Anexo A – Mapa conceptual).\nEste trabalho promoveu uma recolha de referências sobre a literatura mais relevante para os tópicos em questão, nomeadamente através da consulta dos autores mais relevantes, dos artigos publicados nos últimos anos, com subsequente consulta de referências a outros artigos, conferências da especialidade, e com reuniões com algumas pessoas de referência do Software Engineerig Institute (SEI).\n“There is no question that better management helps, but I soon realize that until we changed the practices of software professionals themselves, we could never achieve a truly expert software engineering capability. 1 ”\n“Continuous attention to technical excellence and good design enhances agility. 2 ”\n1 Winning with software – An executive strategy – Watts S. Humphrey – Addison Wesley 2002 2 Agile Manifesto – http://agilemanisfesto.org – 2001\n“For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. 3 ”\nEmbora estas três frases estejam alinhadas no essencial do seu conteúdo elas provêm de correntes completamente distintas de metodologias de gestão. Provavelmente indica-nos que a sua essência provavelmente está correcta e que é necessário perceber qual a adequabilidade dos contextos de aplicação.\nBoehm utiliza a metáfora do macaco e do elefante para ilustrar a diferença entre os métodos ágeis e não ágeis de desenvolvimento de software [Boehm2004]. O macaco que reage rapidamente às adversidade e consegue atingir pontos elevados da floresta e o elefante que suporta grandes pesos, e que depois de estar em andamento consegue percorrer grandes distâncias de uma forma robusta.\nCada um destes animais está mais adaptado para determinadas situações específicas e em conjunto conseguem alcançar mais resultados, do que se operarem de uma forma separada.\nO desenvolvimento de software apresenta-se como uma tarefa essencial no mundo actual, dada a dependência crescente na utilização de sistemas de informação. Esta dependência que é exponencialmente crescente, não está sustentada por processos de engenharia maduros, tais como os casos da engenharia civil, electrotécnica, mecânica, etc.\nNa engenharia de software tem existido uma evolução nos modelos e boas práticas que regem o seu funcionamento. Estas boas práticas, que têm uma tradição da engenharia de sistemas promoveram a qualidade técnica dos produtos implementados, sustentada por processos de desenvolvimento.\nTais boas práticas, que tiveram origem para contextos específicos de desenvolvimento de software, promoveram a elaboração de documentação detalhada em cada projecto, para que a sustentação das decisões e o capital de conhecimento adquirido pudesse ser reaproveitado nas evoluções e nos projectos futuros. Por outro lado, os modelos de qualidade utilizados de base, com uma tradição histórica na indústria automóvel japonesa, estavam orientados para a optimização de processos que se baseavam em trabalhadores industriais por contraponto com a sociedade e trabalhadores do conhecimento actual. Aliado a estes factores, um último parece ter contribuído para o nascer de uma filosofia ágil de gestão e desenvolvimento de projectos, que é o facto de que os processos de desenvolvimento precisam de ser adaptados à realidade dos clientes, empresas e projectos específicos.\n3 Project Management Body of Knowledge 4 th edition – Project Management Institute - 2008\nCada projecto de software envolve um fornecedor (ou mais) com determinada experiência, com determinados processos intrínsecos, envolve também clientes, com níveis de experiência diferentes, que por sua vez têm uma relação com níveis de maturidades específicos. Por outro lado, estas duas entidades, cliente e fornecedores, implementam um projecto de software que afecta determinado sistema, que envolve pessoas, processos e tecnologias. Os processos envolvidos podem ter diferentes graus de criticidade e dinamismo variáveis (Figura 2).\nDadas todas estas condicionantes envolvidas, existirá um único processo que responde de forma satisfatória a todo o tipo de projectos de software? E o que se entende por responder de forma satisfatória a um projecto?\nTanto as comunidades de profissionais ágeis e menos ágeis parecem ser pouco conhecedoras das práticas que ambas advogam, tomando por isso perspectivas pouco agnósticas sobre a adopção de modelos de desenvolvimento. Por outro lado, alguns profissionais, parecem ter encontrado nas filosofias ágeis o pretexto ideal para deixar de efectuar algumas práticas que não estão relacionadas directamente com a codificação de produtos de software, que promovem uma gestão sustentada, quantitativa e assente numa visão de médio e longo prazo no desenvolvimento de software. Por outro lado os movimentos ágeis vieram tornar mais explícito e trazer de novo para a ordem do dia a importância do factor humano, na gestão das equipas, na relação entre o cliente e o fornecedor (parceiro).\nEste trabalho foi realizado no seio de uma organização que é um grupo de inovação em qualidade de software que se depara regularmente com os desafios de empresas de desenvolvimento de software, que tem parcerias com os maiores referências mundiais na área do desenvolvimento de software, nomeadamente o SEI e o European Software Institute (ESI).\nApós uma experiência de gestão de dezenas de projectos de desenvolvimento de software, de diferentes dimensões, diferentes níveis de criticidade, com modelos de organização internacionais e com impactos organizacionais e sociais distintos, e após o contacto com dezenas de empresas de desenvolvimento de software, nacionais e internacionais, foi possível constatar que não existe uma orientação esclarecida sobre a forma de abordagem dos projectos de desenvolvimento de software, adaptada às diferentes realidades sociais e tecnológicas, à\nrelação entre os actores envolvidos, à maturidade e às características intrínsecas de cada projecto. Talvez como consequência da natureza humana, as organizações tendem a replicar fórmulas conhecidas, assentes sobre modelos em que se sentem confortáveis, para diferentes problemas e contextos.\n1.2 Motivação e objectivos\nA motivação deste trabalho é fornecer um contributo para a gestão do desenvolvimento de software através da indicação de formas de utilização e articulação de modelos de desenvolvimento de software mais e menos ágeis.\nEste trabalho deve conseguir responder às seguintes questões:\n• Quais as diferenças principais entre os principais modelos de desenvolvimento de software, mais e menos ágeis?\n• Que tipo de modelo de desenvolvimento de software deve uma organização adoptar?\n• Para que tipo de projectos se aplica cada tipo de modelo?\nPara este objectivo foi efectuado um levantamento sobre os modelos de desenvolvimento mais utilizados a nível mundial, nomeadamente: o Capability Maturity Model Integration (CMMI), o Team Software Process (TSP/PSP), o SCRUM e o Extreme Programming (XP), consolidada numa análise detalhada comparativa. Durante o levantamento foram efectuados alguns comentários que se focarão no levantamento de pistas para a integração e conjugação de modelos.\nForam também analisados os principais esforços da comunidade científica e empresarial, para a articulação dos diferentes modelos de desenvolvimento.\nBaseada na informação recolhida é proposto um método que permite definir, de acordo com a natureza do sistema envolvido no desenvolvimento do projecto, quais os modelos de desenvolvimento a aplicar.\nPara além da introdução, esta dissertação contém mais 4 capítulos.\nNo capítulo “Gestão do desenvolvimento de software”, é descrito o estado da arte associado aos modelos de desenvolvimento de software e são apresentados respectivos trabalhos relacionados com a articulação entre os diversos modelos.\nNo capítulo “Análise comparativa e critérios ” é feita uma análise das principais práticas que podem afectar a decisão relativa ao planeamento da gestão do desenvolvimento de software.\nNo capítulo “Método de selecção de modelos de desenvolvimento de software” é consolidada a informação do capítulo anterior e é proposto um método, para apoio na selecção das práticas de desenvolvimento de software para um determinado projecto.\nNo capítulo “Conclusões e trabalho futuro”, são apresentadas as conclusões do trabalho e perspectivas de trabalho futuro.\ndesenvolvimento de software, tanto nas áreas ditas mais como menos ágeis.\nEm primeiro lugar será focada a crescente utilização de software no mundo actual e a necessidade de processo, pessoas e ferramentas capazes para o sucesso do projecto.\nDe seguida são analisadas as principais correntes associadas à gestão de projectos de desenvolvimento de software, começando pelo modelo CMMI focado na gestão de processos de uma organização, de seguida o PMBOK, orientado para as melhores práticas de gestão de projectos, de seguida é feita uma análise do TSP/PSP que pode ser considerada uma das metodologias mais maduras (grau de definição, implementação e gestão quantitativa) em termos de desenvolvimento de software, e por fim dois métodos de desenvolvimento ágeis: Scrum mais orientado para a gestão de projecto e o XP mais orientado para a engenharia.\nPor fim é feita uma análise das iniciativas de combinação dos métodos mais e menos ágeis.\nCada vez mais o nosso mundo depende de informação e conhecimento, que são maioritariamente suportados por sistemas de informação e como tal o desenvolvimento e utilização de software são um factor exponencialmente crescente – veja-se o exemplo da utilização de software na aviação militar americana (Tabela 1).\nGestão do desenvolvimento de software\nTabela 1- Percentagem de funções realizadas por software nos aviões militares 4\nApesar da importância crescente do software nas organizações é espantoso verificar os números associados a projectos que terminam com sucesso, que são cancelados ou desafiados (Tabela 2).\nTabela 2 - Sucesso nos Projectos de Software 5\n• Aproximadamente 22% dos projectos de software em 2008 foram cancelados\n• Aproximadamente 44% dos projectos de software em 2008 foram desafiados, ou seja, terminaram sem cumprir de uma forma satisfatória um ou mais dos objectivos âmbito, prazo ou custo.\nEstes números, caso não sejam suficientemente esclarecedores, representam milhares de milhões de euros de perdas directas e outros mais de perdas indirectas.\n4 Winning with Software – An executive summary, Watts S. Humphrey, Addison-Wesley, 2002 5 Standish group report – Successful software Projects - 2008\nO número de projectos desafiados, que não cumpriram com o âmbito, custo ou prazo\ninicialmente definidos, tem mantido uma tendência estável com uma pequena variação, ao longo dos últimos 14 anos. O número de projectos com sucesso sofreu uma ligeira melhoria por contraponto com os projectos cancelados. Relativamente aos projectos cancelados, não concluídos, ou entregues e não utilizados, não deixa de ser estranho que nos últimos 6 anos tem existido uma tendência consistente de crescimento.\nEstamos a falar de projectos de software com uma engenharia associada recente (software), que procura ainda encontrar o seu estado de maturidade.\nO software é construído por pessoas que devem estar motivadas, essa disciplina é\ncatalisada através de processos (formais e informais) e tornada mais eficiente através de ferramentas – são as três dimensões críticas em que as organizações se focam [Konrad2007].\nFigura 3 - Dimensões de gestão de organizações 6\nQuando não existem processos, o sucesso dos projectos depende em grande parte dos “bombeiros” das organizações, a visibilidade sobre o estado de um projecto é limitada, não há tempo para pensar em melhorias, provocando uma postura reactiva na organização, e por vezes os bombeiros queimam-se e as “cinzas” voltam a acender-se.\nA existência de processos promove uma cultura de confiança na organização, através da\nprevisibilidade dos procedimentos existentes, e permite uma gestão quantitativa, baseada em factos.\nWatt Humphrey [Wats2002] definiu que para uma boa gestão de software devem ser observados três princípios:\n1. Reconhecer que estamos no negócio do software\n2. A qualidade deve ser a prioridade máxima\n3. Software de qualidade é desenvolvido por pessoas disciplinadas e motivadas\nEstes princípios reforçam a importância crescente que o software tem na sociedade actual, como a qualidade é fundamental na sua construção e como as pessoas são quem produz e utiliza o software.\n6 CMMI, 2nd Edition – Guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad and Sandy Shrum, Addison Wesley, 2007\nde maturidade para\nmelhoria de processos de desenvolvimento de produtos e serviços [Konra d2007]. Está dividido\nem três constelações princ ipais (Figura 4):\n• CMMI-D EV – Modelo de processos para organizaçõ es que desenvolvem\nO Capability Mat urity Model Integration (CMMI) é um modelo\n• CMMI-A CQ – Modelo de processos para organizações qu e fazem aquisições de\n• CMMI-SE RV – Modelo de processos para organizações gerem ser viços.\nque disponibilizam e\nEmbora pensadas nã o só para a indústria de software estas constelaç ões permitem abarcar o ciclo completo de dese nvolvimento de software, desde o seu desenvol vimento ou aquisição\naté a manutenção em pr odução. Neste trabalho será focado o modelo CMMI-DEV.\nEste modelo de mat uridade está dividido em áreas de processo q ue fornecem práticas processuais que as empre sas devem adoptar, não prescrevendo no entant o a forma de como o devem fazer.\nEste conceito é fund amental pois ao contrário do TSP/PSP, do Sc rum ou do XP é um\nmodelo não prescritivo, q ue permite que as práticas obrigatórias sejam in stanciadas de formas\ncombinando diversos modelos. É normal enc ontrar empresas que\nimplementam o modelo C MMI e que ao mesmo tempo, tenham práticas d e gestão de projectos\nISO 9001) ou com\nalinhadas com o PMBO K, ou com normas de gestão de qualidade (ex:\nFigura 5 - CMMI - Estrutura das áreas de Processo 7\nAs grandes áreas de processo do CMMI-DEV estão relacionadas com a organização, a gestão de projectos, engenharia e suporte.\nA área de gestão de projectos contempla práticas de planeamento, monitorização e\ncontrolo, gestão de risco, gestão integrada, gestão das aquisições e gestão quantitativa de projecto.\nA área de engenharia contempla a gestão e desenvolvimento de requisitos, a solução\ntécnica (desenho mais codificação), a integração de produto, a verificação e a validação do produto. A área de suporte prevê a gestão de configurações, métricas, análise e resolução de causas de problemas, análise e tomada de decisões, e controlo da qualidade dos produtos e dos processos da organização.\nA força deste modelo está relacionada por um lado com a componente de gestão da\norganização, onde estão previstas práticas para a construção e definição de processos, alinhados com os objectivos estratégicos da empresa, gestão da formação, gestão da performance e gestão da inovação, e por outro com as práticas genéricas que definem o grau de institucionalização dos processos da empresa, ou seja, a forma como os processos fazem parte do dia-a-dia de cada colaborador - competência inconsciente da empresa (Figura 6).\n7 CMMI, 2nd Edition – Guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad and Sandy Shrum, Addison Wesley, 2007\nNuma organização, mais importante que a definição de processos é a forma como os mesmos estão embebidos na cultura e nas actividades diárias da empresa. Mais do que o conhecimento de engenharia e de gestão de projectos que o modelo CMMI aporta, a sua vertente de organização deve ser fortemente considerada na definição de processos de uma organização.\nO elemento mais conhecido do CMMI é o facto de possuir uma representação de evolução baseada em níveis de maturidade (Figura 7):\n1. Nível de maturidade 1 – Inicial (onde todas as empresas começam)\n2. Nível de maturidade 2 – Gerido\n3. Nível de maturidade 3 – Definido\n4. Nível de maturidade 4 – Gerido quantitativamente\n5. Nível de maturidade 5 – Em optimização\nOs níveis de 4 e níveis 5 prevêem uma gestão quantitativa das áreas de processo.\nEste elemento permite um caminho de evolução para as empresas, com uma recomendação de prioridade de implementação de práticas, permite uma forma de benchmarking entre empresas e um grau de reconhecimento de mercado por parte dos contratantes.\nExiste também uma representação contínua de evolução, que não prescreve áreas de processo prioritárias, ficando ao critério da organização a evolução desejada, área de processo a área de processo. Normalmente é aconselhável uma mistura das duas representações na implementação de processos nas organizações, dado que permite por um lado uma prioridade de implementação alinhada com as necessidades da organização com uma consequente possível certificação reconhecida pelo mercado.\nA comunidade científica e o Software Engineering Institute abordam cada vez mais a\nimplementação conjunta, quando aplicável do CMMI e das práticas ágeis [Alegria2006], [Glazer2008], onde as principais conclusões se focam na complementaridade e na necessidade de definição dos contextos adequados de utilização.\nA gestão de projectos visa a concretização de um âmbito determinado, com um custo ou\ninvestimento definido num prazo determinado [PMBOK2008].\nA decisão de se avançar com um determinado projecto está intimamente ligada a retorno\nprevisto de investimento. Não basta portanto controlar uma das variáveis: âmbito, prazo e custo para que se possa considerar um projecto com sucesso. Adicionalmente podemos acrescentar os\nparâmetros qualidade e risco como variáveis importantes de controlo: a qualidade porque diferentes tipos de projecto podem requerer diferentes abordagens de controlo de qualidade (quando os projectos afectam vidas humanas, ou negócios de forma estrutural); o risco porque, por exemplo, por vezes certos projectos não podem ultrapassar, imperativamente, determinada data ou determinado orçamento.\nO Project Management Body of Knowledge é hoje o standard mais utilizado em termos\nmundiais para a gestão de projecto. Este modelo é suficientemente abrangente para funcionar para qualquer área de negócio, desde que complementado com práticas específicas do negócio\nou engenharia em questão.\nO ciclo de vida nos projectos no PMBOK compreende 5 fases principais com alguma\nsequência mas que se podem sobrepor no tempo:\n• Iniciação: onde se tomada a decisão efectiva de avançar com o projecto e se faz o arranque formal do mesmo.\n• Planeamento: onde se planeiam todas as actividades do projecto.\n• Execução: onde as actividades são executadas.\n• Monitorização e Controlo: onde se processa a monitorização e controlo das variáveis de gestão do projecto.\n• Fecho: onde se procedem às actividades de fecho do projecto.\nPara as diversas fases do projecto estão previstas as seguintes actividades de gestão:\n• Integração do projecto – controlo das actividades de ciclo de vida de projecto, bem como a integração com todas as actividades necessárias.\n• Âmbito – controlo do âmbito global do projecto - não apenas requisitos.\n• Custo – controlo do esforço de recursos humanos e custos de aquisições.\n• Tempo – controlo das estimativas, prazo.\n• Comunicação – controlo da comunicação entre os diversos stakeholders.\n• Recursos Humanos – controlo da contratação das equipas.\n• Aquisições – controlo de aquisições do projecto.\n• Qualidade – controlo da qualidade dos produtos entregues.\nEsta metodologia é importante pois é suficientemente completa para abarcar todas as actividades inerentes à gestão de projecto e por outro lado permite estar associada a diferentes métodos de engenharia, sejam eles de software ou não.\nO Team Software Process (TSP) em conjunto com o Personal Software Process (PSP)\nforam desenhados pelo SEI com o objectivo de fornecer uma estratégia e um conjunto definido de procedimentos operacionais, para a implementação de métodos de desenvolvimento de software disciplinados, tanto ao nível do indivíduo como ao nível da equipa [Watts2002]. Estas metodologias devem ser sempre implementadas em conjunto.\nO foco principal do TSP/PSP é a produção de software com zero defeitos, de acordo com\nos requisitos do cliente e no prazo estipulado. Caracteriza-se por utilizar métodos quantitativos na sua gestão, o que permite de forma rigorosa estimar e atingir os objectivos propostos como garantir qualidade de vida às equipas envolvidas.\nSegue o seguinte princípio base de funcionamento: É necessário pensar antes de executar, e depois de executar é necessário rever, inspeccionar e testar. Este princípio garante eficiência no processo, nomeadamente quando a dimensão, dispersão e criticidade dos sistemas envolvidos aumentam. É um processo bastante prescritivo e bastante detalhado nos procedimentos que promove de forma a garantir uma disseminação de práticas efectiva entre todos os elementos das equipas.\nA sua estrutura base é iterativa, prevendo um processo de lançamento inicial (launch), para um planeamento macro d o projecto e organização da equipa, seguido d e relançamentos (Re- launch) para cada iteração (Figura 9).\nO processo de lançam ento que demora tipicamente 4 dias e tem como principal objectivo o planeamento detalhado da iteração (com uma duração típica de 1 a 4 mes es) com a construção de uma equipa motivada, e nvolvida e comprometida com os resultados pre vistos (Figura 10).\nF igura 10 - TSP/PSP – Lançamento de iteraçã o\nEste lançamento [H umphrey2000] contempla a definição conjunt a dos objectivos do\nproduto e de negócio do uma estratégia e de um\nglobal e de um plano mai s detalhado para a próxima fase, o desenvolvim ento de um plano de\nqualidade, a atribuição de\ncriação de respectivo plan o de mitigação, preparação e apresentação do pla no à gestão de topo e um post mortem do própri o lançamento.\ntarefas e balanceamento de carga, uma avaliaç ão formal do risco e\nprojecto, atribuição de papéis e objectivos da e quipa, a produção de processo adaptado à realidade do projecto, def inição de uma plano\nA fase de desenvolvi mento contempla as seguintes actividades embor a possam ocorrer em\n• Captura de re quisitos e respectiva revisão e inspecção\n• Desenho de a lto nível e inspecção\n• Desenho de b aixo nível, revisão e inspecção\n• Codificação, revisão, testes unitários e inspecção\n• Testes de int egração\n• Testes de sis tema\nobrigatória de revisões e inspecções tem a ver com a eficiência que\nestes métodos possuem,\ndetalhado). A revisão é fe ita pelo autor do artefacto em causa (código ou d ocumento), enquanto que a inspecção é efectuad a por outros membros da equipa.\n(será mais à frente\nA razão da utilização\nface a testes realizados mais tarde no processo\nA gestão quantitativ a do processo é conseguida através de ferrame ntas que analisam a\ninformação de quatro métr icas base: tamanho, tempo, prazo e defeitos. Ass im, cada elemento da\nequipa, através de process os preferencialmente automáticos deve fazer o r egisto e classificação\nde todos os defeitos que processo de estimativa é\nem cada tarefa, e o\nrealizado através da avaliação do tamanho pr evisto do produto. O\nacompanhamento do proj ecto é efectuado através de algumas medidas e ntre as quais: earned\nperfil de qualidade,\nquantidade de defeitos eli minados em revisões e inspecções.\nencontrou, o registo do tempo que demorou\ndo esforço realizado e previsto de recursos,\nA utilização da métrica, tamanho do produto, permite obter uma correlação entre o tempo que foi previsto e o tempo efectivamente realizado para determinada dimensão de esforço. O processo de estimativa segue um método designado por PROBE – proxy based estimation – que primeiramente identifica quais os componentes relevantes para estimativas, para a tecnologia ou domínio concreto de desenvolvimento: classes, forms, triggers, funções, etc. De seguida as estimativas são efectuadas sobre o número de componentes que se prevê realizar, sendo que se classificam com três graus de complexidade. Para obter o tempo previsto para a realização dos componentes são utilizados os valores históricos do indivíduo, ou não existindo, valores das equipas, da organização ou médias de mercado, para a realização de cada tarefa. Desta forma científica, o grau de estimativa oferece um grau de precisão muito elevado.\nAs equipas TSP/PSP são auto dirigidas (Figura 11) na medida em que todos os elementos da equipa participam em todas as actividades de planeamento, monitorização e execução dos trabalhos, não sendo apenas dirigidas como nas equipas mais tradicionais. Uma equipa TSP/PSP prevê uma série de papéis que podem ser acumulados por uma única pessoa, sempre que necessário [Humphrey2005]:\n• Team leader – com responsabilidade por garantir os objectivos do projecto, manter a equipa motivada e o cliente satisfeito.\n• Coach – com responsabilidade por garantir e treinar os elementos no desenvolvimento das actividades TSP/PSP, normalmente é externo à equipa.\n• Gestor de planeamento – com responsabilidade pelos planos do projecto e acompanhamento das actividades individuais e do projecto.\n• Gestor de processo – responsável por ajudar toda a equipa em cumprir o processo conforme foi definido.\n• Gestor de qualidade – garantir que a equipa segue o plano de qualidade e acompanhar os indicadores respectivos.\n• Gestor de suporte – responsável por ajudar na correcta utilização de ferramentas e gestão das configurações.\n• Interface com o cliente – garantir o alinhamento do projecto com os objectivos do cliente.\n• Gestor de desenho – garantir um desenho de grande qualidade, envolvendo toda a equipa e fomentando a produção de boa documentação.\n• Gestor de implementação – garantir uma boa implementação dos desenhos definidos e com qualidade.\n• Gestor de testes – garantir que todos os membros criam e executam os planos de testes adequados.\n2.5 Modelos ágeis\nOs modelos ágeis de desenvolvimento de software foram primeiramente introduzidos através de Mikio Aoyama em 1998 junto das fábricas de software japonesa [Aoyama1998]. Agilidade significa uma boa capacidade de adaptação a requisitos e contextos envolventes e por isso é caracterizada pelos seguintes atributos:\n1. Processo de desenvolvimento incremental e evolutivo Os processos menos ágeis tendem a fazer uma entrega total no final do projecto enquanto os métodos ágeis promovem entregas constantes e incrementais do produto, promovendo a emergência de novos requisitos e soluções.\n2. Processo modular e simples (lean) Os processos devem ser simples e modulares de forma a poderem responder rapidamente - pouco baseados na produção de documentação.\n3. Orientado ao tempo Nos processos ágeis o planeamento é orientado a intervalos fixos de tempo (iterações) e não ao volume de esforço necessário.\nEstes atributos devem ser vistos e implementados como um todo e não de forma separada para que os processos possam ser considerados ágeis. Estes métodos são orientados às pessoas e menos aos processos, dado que cada indivíduo é responsável pela entrega de uma funcionalidade completa. Nesta abordagem inicial de métodos ágeis [Aoyama1998] foi referida\ncomponente da possibilidade do desenvolvimento distribuído mas não foi a da articulação com\nEm 2001, uma série de signatários juntou-se para lançar um manifesto, que impulsionou de forma significativa o movimento dos métodos ágeis, através do Manifesto para o desenvolvimento ágil de Software [AgileMan2001]. A força deste manifesto reside também no facto de ter sido elaborada por personalidades proeminentes, relacionadas como desenvolvimento de software.\nFace às ideias apresentadas em 2001 sobressai o ponto de colaboração com o cliente em relação à negociação do contrato. Este ponto é interessante pois é uma área de desafio forte para estas metodologias em relação ao trabalho distribuído e relação com o cliente.\nDe acordo com os valores apresentados pelo Manifesto foram estabelecidos 12 princípios que devem ser seguidos para que os processos de desenvolvimento sejam ágeis, apresentados de seguida de forma simplificada:\n• As mudanças de requisitos são bem recebidas pois representam vantagens competitivas para os clientes.\n• Devem existir entregas de software numa base semanal ou mensal.\n• As pessoas de negócio e os desenvolvedores devem trabalhar conjuntamente e diariamente durante todo o projecto.\n• O trabalho deve ser realizado por indivíduos motivados, sendo que para isso devem ser providenciadas as condições e o suporte necessários, bem como deve ser estabelecida uma relação de confiança.\n• A forma mais eficiente de comunicação para e com o projecto é a conversação cara a cara.\n• A principal medida de progresso é software que funciona.\n• Os processos ágeis promovem um desenvolvimento sustentado. Os sponsors, desenvolvedores e utilizadores, devem estar habilitados para manter o mesmo ritmo de desenvolvimento de forma indefinida.\n• Uma atenção contínua a bom desenho de soluções e excelência técnica são catalisadores da agilidade.\n• A simplicidade é fundamental de forma a minimizar o trabalho a realizar.\n• As melhores arquitecturas, requisitos e desenhos emergem de equipas que são autónomas, que se auto-organizam.\n• Em intervalos regulares as equipas reflectem em como podem ser mais eficazes e eficientes ajustando os seus processos e métodos de acordo com as reflexões.\nSeja qual for a metodologia de desenvolvimento de software, a aplicação da maior parte destes princípios é consensual e não representam algo de inovador naquilo que foi a evolução da história do desenvolvimento de software na sua componente de gestão de projectos e engenharia. A forma como são implementados os princípios é que pode por vezes suscitar alguma discussão. Por exemplo, é consensual que a forma mais eficaz de comunicação é a conversação cara a cara. Dizer isso não é dizer que não deve existir documentação adequada, para apoiar as comunicações entre centenas de colaboradores, ou para manter um histórico – que permite tornar eficiente evoluções futuras ou registar decisões estratégicas relevantes.\nO princípio mais desafiador é o da obrigação da localização conjunta dos elementos da equipa, negócio e desenvolvedores, durante todo o projecto.\nO Scrum nasceu de um conceito importado do desporto rugby, onde é dado ênfase à comunicação entre a equipa (passes laterais e para trás) e ao avanço por sprints. É sobretudo um modelo que foca na gestão de projectos e não tanto em técnicas de engenharia de software. Schwaber que desenvolveu o Scrum referiu que para se ser verdadeiramente ágil, um processo precisa de aceitar as mudanças em vez de procurar controlar a previsibilidade [Schwaber, 2002].\nO Scrum tem no seu esqueleto iterações que podem ir de duas semanas a um mês e reuniões diárias [Schwaber2004]. Cada iteração pressupõe a entrega de funcionalidades que foram definidas a partir de um backlog de funcionalidades e alocadas a um determinado sprint (iteração).\nEm cada iteração a equipa analisa os requisitos, considera a tecnologia disponível e avalia\na sua capacidade e conhecimento para a implementação através do sprint planning. Colectivamente a equipa determina como vai construir a funcionalidade, modificando a abordagem diariamente sempre que encontra alguma dificuldade, complexidade ou surpresa. Em cada reunião diária (daily scrum), que tem um intervalo de 15 minutos definido, cada elemento deve responder a três questões:\n• Foi efectuado alguma coisa desde a última reunião?\n• O que tem de ser feito entre esta e a próxima reunião?\n• O que é que impede que o trabalho possa ser efectuada da forma mais eficaz\npossível? Em cada iteração são realizadas duas reuniões, um sprint review para comunicar e analisar\nfuncionalidades desenvolvidas e um sprint retrospective para se analisar as lições aprendidas\nmelhoria para a próxima iteração.\nEste processo criativo define o coração da filosofia Scrum.\nEstão definidos três papéis principais: o dono do produto, a equipa e o scrum master. Todas as actividades de gestão estão divididas por estes três papéis. O dono do produto está focado nas funcionalidades do produto, os objectivos em termos de retorno de investimento e pela prioridade dos requisitos para a próxima iteração. A equipa é responsável pelo sucesso de cada iteração e o scrum master é responsável por garantir que as regras do Scrum estão a ser seguidas.\nA evolução do progresso de cada iteração é feita através de um burndown chart que mostra\no número de horas executadas e previstas para terminar.\n2.7 Extreme programming\nO Extreme Programming (XP) nasce por volta do ano 2000, por Kent Beck e visa quebrar\na premissa de que o custo de cada alteração num projecto aumenta exponencialmente à medida\nque o projecto avança [Beck2000]. Assim, através de uma série de práticas foi desenvolvido um modelo, que tenta tornar o custo das alterações do projecto igual em todas as fases do projecto e que segue os princípios dos métodos ágeis.\nO XP está sustentado através de quatro valores [Stephens2003]:\n• Comunicação: todas as equipas devem estar no mesmo sítio para evitar problemas de comunicação.\n• Simplicidade: as tarefas devem ser feitas da forma mais simples possível – a ideia é que fazer as tarefas de uma forma complexa, demora mais tempo e o resultado obtido é o mesmo.\n• Feedback: é importante fomentar a comunicação entre a equipa e com o cliente, de forma a obter a solução correcta o mais depressa possível. Seja nos requisitos, seja na arquitectura, o feedback deve ser procurado.\n• Coragem: deve ser fomentada a coragem no projecto, nomeadamente para fazer alterações de desenho.\nO XP é constituído por 12 práticas que têm de ser aplicadas em conjunto (Figura 14):\n• Test-driven development – para cada classe desenvolvida de código, primeiro deve ser desenvolvido um teste que falhe, de seguida deve ser desenvolvido o código correspondente e de seguida o teste deve passar. Esta metodologia permite implementar um custo reduzido de mudança, pois qualquer alteração efectuada será imediatamente verificada pelos testes previamente produzidos, permitindo também incutir coragem para alterações de arquitectura.\n• The planning game – Nesta prática são planeadas os requisitos, neste caso user stories, para que se decidam em que iteração devem ser desenvolvidos e entregues. As user stories devem ser estimáveis e testáveis. Cada user story (que fica num story card) é pendurada num quadro e deve ter uma estimativa de esforço que deve variar entre duas a quatro semanas. Para cada story card, devem ser criadas tarefas, de um a dois dias para facilitar a distribuição de trabalho. Para cada alteração de requisito ou pedido de documentação é criado um story card com um esforço associado. O esforço total dispendido por iteração é designado por velocity e deve ser mantido constante ao longo do projecto e como tal previsível.\n• Whole team (anteriormente on-site customer) – O XP advoga que o cliente deve sentar-se com a equipa de desenvolvimento durante o projecto. Existiu uma evolução face ao publicado inicialmente onde agora o foco é ter um único representante do cliente – proxy (cliente esse que pode ser um conjunto de pessoas). Esta prática mais relaxada, parece vir responder à dificuldade de um princípio dos métodos ágeis, relativamente à necessidade da localização conjunta da equipa de desenvolvimento e do cliente.\n• Small releases – Esta prática fundamental nos métodos ágeis é claro implementada pelo XP – o racional por detrás é o mesmo – incrementar o número de entregas o mais possível. Está também ligado ao princípio XP de obtenção de feedback o mais cedo possível. Recentemente o conceito de que uma release tem de ser algo completamente funcional num ambiente de produção foi relaxado, para algo que funcione apenas num ambiente de testes realizados por um cliente interno – algo aproximado a protótipos evoluídos.\n• Metaphor – A arquitectura de sistema complementada com uma metáfora unificadora a algo existente, como por exemplo: “O sistema é como uma padaria. Tem o pão, o forno, os padeiros, a máquina registadora, etc, … ”. Esta forma substitui a forma tradicional de documentação de arquitectura.\n• Simple design – O princípio é de que desenho simples é mais simples de manter. Mais tarde foi introduzida a prática de design emergente, ou seja, um design que vai sendo construído à medida que o problema e a solução vão sendo melhor compreendidos.\n• Refactoring – Embora seja recomendado o design simples, também é recomendado que se corrija constantemente o desenho que não esteja bem feito, tal como o código duplicado. Dado que o desenho da arquitectura não é feito previamente recomenda-se que o desenho vá emergindo e sendo corrigido ao longo do tempo.\n• Collective ownership – Cada programador é responsável por todo o código, embora sejam responsáveis individualmente por cada tarefa. Por exemplo se um programador vê uma parte de código que ache que não esteja bem feito deve procurar corrigi-lo mesmo que não tenha sido ele a fazê-lo. É um conceito interessante que forma uma responsabilidade colectiva por aquilo que é produzido, mas que não deve servir de forma de desresponsabilização dos elementos na equipa.\n• Pair programming – Esta é uma das práticas mais controversas e que diz respeito a que cada equipa, que tem de ser par, deve ser formada por conjuntos de duas pessoas, onde um codifica, outra verifica e ambos discutem os problemas e soluções. Dentro deste pair programming é aconselhado que exista uma troca de elementos regular entre os pares para fomentar a disseminação de conhecimento.\n• Continuous integration – O código deve ser testado e integrado em poucas horas, no máximo um dia, e se no final do dia ainda existirem erros o código deve ser deitado fora. No dia seguinte o código deve estar isento de erros.\n• Sustainable pace – O esforço da equipa deve ser sustentado, a semana não deve ter mais de quarenta horas, senão a qualidade diminui.\n• Programming standards – recomendados em qualquer projecto de desenvolvimento de software, promovem a facilidade de compreensão e comunicação entre a equipa.\nO XP descreve quatro actividades básicas no desenvolvimento de software: codificar,\ntestar, desenhar e ouvir. Por outra ordem poderíamos mapear em requisitos (ouvir), desenhar\n(desenho), codificar e testar.\nO ciclo de vida do XP define-se por iterações evolucionárias onde existem duas fases\nprincipais (Figura 15): o planeamento da release e a execução das iterações. Não confundir a\nevolução com pequenos incrementos, pois o processo de definição de requisitos, desenho, codificação e testes é feito quase em simultâneo [extremeorg2006].\nCada iteração está dividida em ciclos de duas semanas, onde uma versão é entregue ao cliente interno, onde posteriormente ele decide se pretende que a versão seja testada pelo utilizador final. No início de uma iteração existe uma reunião com o cliente e com os programadores, onde são definidos as funcionalidades a implementar, através de user stories, os programadores estimam o tempo necessário para implementar cada user storie, e é decido em conjunto que funcionalidades ficam na próxima release e de fora. As user stories não devem ter muito detalhe, sendo que o detalhe é efectuado na prática quando o cliente escreve os testes de aceitação automatizados – de relembrar que aqui o cliente é um representante e pode ser alguém com background técnico. Diariamente existe uma reunião de pé (stand up meeting) onde são discutidos problemas, soluções e se promove o foco da equipa.\nEstão definidos diversos papéis no XP entre os quais o programador, o testador, o tracker, responsável por seguir o tempo associado a cada tarefa e como tal a velocidade do projecto e o coach responsável por treinar os elementos nas práticas XP.\n2.8 Combinando métodos ágeis e não ágeis\nO ponto de partida de referência para a análise da combinação de modelos mais e menos\nágeis foi efectuado sobre o trabalho de Barry Boehm e Richard Turner – Balancing agility and\ndiscipline [Boehm2004] onde é proposto um método assente numa análise de risco sobre os factores considerados mais relevantes para a aplicação ajustada.\nEste método assenta sobre a análise de cinco factores principais (Figura 16):\nFigura 16 - Cinco factores para secção de métodos 8\n1. Tamanho: as metodologias ágeis estão mais adaptadas para equipas pequenas enquanto as metodologias menos ágeis são mais difíceis de adaptar para equipas pequenas.\n2. Criticidade: as metodologias ágeis, até hoje foram pouco testadas em sistemas de grande criticidade, onde se adivinham dificuldades pela utilização de design simples e pouca documentação.\n3. Dinamismo: o desenho simples de soluções e refactoring constante protege o custo de trabalho refeito em ambientes pouco estáveis em termos de alteração de requisitos, mas aumenta-o em ambientes estáveis.\n4. Maturidade dos membros da equipa: os métodos ágeis funcionam melhor com membros de equipas com mais capacidades ao nível técnico e ao nível de entendimento processual - como existem menos processos formais as decisões ficam mais dependentes de cada indivíduo, e como tal as boas decisões dependem da sua capacidade.\n5. Cultura: os métodos ágeis funcionam melhor em equipas onde os membros se sentem em ambientes com mais graus de liberdade de actuação (Figura 17).\nQuanto mais a avaliação dos factores se aproxima do centro do gráfico mais ágil deve ser o método.\n8 Balancing Agility and Discipline, Barry Boehm, Richard Turner, Addison-Wesley, 2004\nFigura 17 - Aspectos culturais na selecção do método 9\nPor outro lado considera também uma análise de risco associada ao tipo de abordagem, ponderando diversos factores, baseado num modelo de processo em espiral [Boehm2001] e\nConsiderando estes cinco factores é estabelecido um método que prescreve como devem ser utilizadas as abordagens ágeis e menos ágeis (Figura 18Figura 18 - Método Boehm de selecção de metodologia e Tabela 3).\n9 Balancing Agility and Discipline, Barry Boehm, Richard Turner, Addison-Wesley, 2004\nClassificar os riscos associados de acordo com os riscos de ambiente, ágeis e não ágeis (Tabela 4)\nSe os riscos ágeis dominarem prosseguir com métodos não ágeis baseados numa gestão de riscos com foco nos riscos não ágeis\nSe os riscos não ágeis dominarem prosseguir com métodos ágeis baseados numa gestão de riscos com foco nos riscos ágeis\nSubdividir a arquitectura e adoptar a abordagem apropriada caso parte das aplicações possam apresentar topologias distintas.\nEstabelecer um plano global do projecto com os riscos associados\nMonitorizar o progresso, os riscos e oportunidades, reajustando o balanceamento do processo conforme necessário.\nEm [Edeen2007] os autores combinam esta metodologia com o conceito de organização ambidestra, onde se podem dividir os projectos ou componentes de desenvolvimento, dos projectos de software em duas subunidades da organização separadas, vocacionadas respectivamente para métodos mais e menos ágeis. Esta abordagem endereça de forma simples os riscos das necessidades de formação dos recursos nas respectivas abordagens metodológicas, A-Skill e P-Skill (Tabela 4), obrigando no entanto a uma dimensão mínima de organização e dupla cultura, o que implica um esforço extra de gestão.\nRisco de ambiente\nComplexidade de stakeholders\nEscalabilidade e criticidade\nUso de desenho simples\nPoucos recursos formados em métodos ágeis\nRiscos métodos não ágeis\nMudança rápida de requisitos ou prioridades\nNecessidade de resultados rápidos\nRequisitos facilmente emergentes\nPoucos recursos formados em métodos não ágeis\nOs autores de [Boehm2005] identificam os principais desafios em combinar metodologias ágeis em processos de desenvolvimento tradicionais, de acordo com três áreas principais:\nprocesso de desenvolvimento, processo de negócio e conflitos com pessoas.\nVariabilidade – a integração de equipas com ciclos de vida distintos pode levar ao desenvolvimento de produtos bastante distintos e difíceis de integrar. Ciclos de vida distintos – os métodos ágeis focam em entregas contínuas e antecipadas enquanto as não ágeis focam a sua entrega nas fases finais. Sistemas legados – os sistemas legados não são facilmente redesenhados (refactoring), ou desacoplados para permitir entregas consecutivas e antecipadas. Requisitos – Os requisitos ágeis tendem a ser sobretudo funcionais e informais, dificultando processo de verificação e validação dos métodos não ágeis.\nProcesso de negócio Recursos humanos: as organizações devem aprender a acomodar assuntos relacionados com recursos humanos tais como registos de tempos, descrições de funções, prémios e gestão de competências. As pessoas por outro lado devem ser capacitadas para procurar abordagens não tradicionais. Gestão do progresso: os contractos tradicionais e as técnicas de recolha de informação podem ser consideradas desadequadas para suportar as práticas ágeis Avaliações de standards: a maior parte das práticas ágeis não estão preparadas para suportar as evidências necessárias, em termos de documentação, para suportar as avaliações relativamente a standards como o CMMI e a ISO 15504 (SPICE).\nConflitos com pessoas Atitudes de gestão: as organizações tradicionais tendem a definir papéis rígidos nas organizações, enquanto nas metodologias ágeis promove-se a flexibilidade de papéis. Assuntos logísticos: as equipas ágeis necessitam de estar colocadas de forma próxima com ferramentas específicas para pair programming. Algumas empresas não têm as condições necessárias em termos de espaço de trabalho. Gestão de pilotos: alguns gestores respondem aos sucessos dos pilotos ágeis com a separação das equipas, com vista a uma promoção ou disseminação de boas práticas. Este facto pode destruir as relações de bom trabalho que vão sendo criadas nas equipas. Gestão da mudança – lidar com recursos que se recusam a mudar de metodologia, pode ser crítico na implementação de métodos ágeis, dado que as suas práticas são baseadas em confiança e em muita comunicação directa.\nEm [Edeen2007] os autores alegam que o conceito de agilidade – metodologias que são mais orientadas às pessoas do que aos processos - tem mais a ver com a área de sistemas de informação (com preocupações sociais e organizacionais) do que com o desenvolvimento de software.\nEm [Moe2008], os autores constataram que uma das maiores dificuldades na implementação das práticas ágeis tem a ver com o grau de especialização de alguns dos recursos\ne da dificuldade na criação de redundância nas equipas.\nEm 2008, Kalpana e Jagadish da Wipro, partilharam as suas experiências na utilização de métodos ágeis, em ambientes de desenvolvimentos distribuídos, numa das maiores empresas de desenvolvimento de software offshore [Kalpana2008]. As suas principais conclusões passaram pela localização das equipas junto dos clientes em diversos momentos do projecto e pela utilização intensiva de ferramentas para a comunicação e pela utilização de documentação para permitir uma melhor colaboração entre equipas.\nOs autores em [Paasivaara2008] também reforçam estes aspectos e falam da utilização de proxys de clientes que permitam uma comunicação directa entre pessoas. Em [Young2008] os autores exploram a utilização das novas tecnologias para lidar com os desafios da comunicação\nEste capítulo começa apresentar uma série de conclusões sobre o estado da arte analisado no capítulo anterior, introduz o tema do custo da qualidade, e estabelece os princípios para um método global de planeamento de projectos de desenvolvimento de software, que integra os diversos modelos referidos.\n3.1 Análise comparativa dos modelos\nA análise dos diferentes modelos, CMMI, PMBOK, TSP/PSP, Scrum, XP (Figura 20) e\ndos métodos de combinação permitem retirar as seguintes conclusões (Figura 21).\nO CMMI é um modelo que está orientado para uma abrangência global do desenvolvimento de software, desde aos processos da organização, aos de gestão de projecto e aos de engenharia. É no entanto um modelo não prescritivo e que permite a adopção e combinação de outras metodologias ou parte delas. Em termos de certificação, de acordo com o modelo SCAMPI, obriga à apresentação das evidências de cada uma das áreas de processo, o que para uma metodologia baseada em pouca documentação pode ser desafiante. O seu factor distintivo está nos aspectos organizacionais: definição e controlo de processos, formação, inovação e análise e resolução de causas de problemas estruturais.\nO PMBOK oferece a metodologia mais completa de gestão de projectos, contemplando\naspectos como a gestão financeira, que não são abordados por nenhuma outra. Contempla também um pouco de organização mas ao nível de gestão global de projectos numa organização (portfolio management).\nO TSP/PSP é uma metodologia iterativa de desenvolvimento de software, que abarca desde\na gestão de projectos, gestão da equipa, qualidade de software, gestão quantitativa do processo,\ne prescreve uma sequência de actividades de especificação, elaboração, revisão e inspecção do trabalho produzido, sustentando por uma premissa de eficiência associada ao processo. Não apresenta indícios de problemas de escalabilidade ou de necessidade de localização.\nAnálise comparativa e critérios de selecção de modelos\nO Scrum é uma metodologia ágil iterativa, orientada para a gestão de projectos, que promove a comunicação entre os elementos das equipas, desenho simples e pouco pensado a nível estratégico e pouca documentação. Está orientado para permitir mudanças de âmbito ao longo do projecto, promove entregas constantes e não é muito prescritivo nas práticas de engenharia.\nO XP é uma metodologia ágil iterativa que foca em aspectos de engenharia, assenta sob actividades que devem ser realizadas em conjunto, tais como o pair programming, refactoring, simple desing e test driven development. É uma metodologia prescritiva em termos de processos de engenharia, que evita os requisitos detalhados e documentados, evita o desenho detalhado e a documentação.\nTanto o TSP/PSP, o Scrum como o XP assentam sobre princípios de iteração, e reconhecimento da importância e necessidade de empowerment das pessoas e equipas no processo de desenvolvimento.\nA necessidade de localização do cliente junto com a equipa de desenvolvimento não parece ser uma necessidade efectiva de nenhuma das metodologias, embora os princípios ágeis o possam fazer transparecer.\nAs grandes diferenças entre o TSP/PSP e os métodos ágeis Scrum e XP assentam sobretudo:\n• na perspectiva detalhada e documental das práticas de engenharia e gestão do projecto\n• na abordagem quantitativa da gestão dos processos de gestão e engenharia\n• no controlo de qualidade rigoroso associado\nO TSP/PSP fá-lo e o Scrum e XP não. O TSP/PSP é portanto mais previsível e como tal escalável para grandes projectos em termos de dimensão, localização ou risco.\nComo consequência o TSP/PSP apresenta maior grau de previsibilidade e o Scrum e XP maior grau de agilidade.\nNum exercício simplista de relacionamento do nível de maturidade potencial de CMMI com as metodologias TSP/PSP, XP e Scrum, o TSP/PSP estaria algures no nível 4 [Wall2007], devido à sua gestão quantitativa e completude de definição de processos, o XP estaria a apontar para o nível três, devido às práticas de engenharia já definidas, embora sem as componentes de processo, e o Scrum no nível dois devido ao seu foco na gestão de projectos.\nFoi abordado que consoante a organização, o cliente, o projecto deve ser implementada uma postura mais ou menos ágil (Figura 23).\nO modelo de Barry Boehm e Richard Turner [Boehm2004] contempla um método global de decisão sobre a aplicação de métodos ágeis e não ágeis que pressupõe a análise do contexto do projecto (mais ou menos ágil) consoante cinco factores: maturidade da equipa, dinamismo, criticidade, tamanho e cultura, e depois a subdivisão do projecto em eventuais perfis distintos de agilidade e posterior gestão de risco associado a cada perfil (ver capítulo Combinando métodos ágeis e não ágeis).\n3.2 O custo da qualidade\nO custo de um projecto de software pode ser analisado de acordo com o modelo apresentado pela Ratheon em 1995 (Figura 24), que faz uma decomposição em duas vertentes principais: o custo de performance e o custo da qualidade.\nFigura 24 - Custo de performance e da qualidade 10\nO custo da performance tem a ver com todas as actividades que visam a produção de algo que necessariamente tem que acontecer no projecto e o custo da qualidade com o custo de actividades de controlo de conformidade (testes ou actividades de prevenção) e com o custo de actividades de correcção das não conformidades (trabalho repetido ou correcção de erros).\nEm termos de performance as empresas podem utilizar várias técnicas, tais como a reutilização, através de módulos reutilizáveis, frameworks, design patterns, ou automatização, através da geração automática de código. Não podemos esquecer no entanto que as diversas actividades relacionadas com este modelo estão dependentes e relacionadas. Se eventualmente não fizermos qualquer tipo de investimento em análise de requisitos, muito provavelmente os erros encontrados vão aumentar e o trabalho repetido também. Pelo que importa garantir que as actividades relacionadas com a performance devem ser executadas de acordo com as melhores práticas.\nPara evitar as actividades de não conformidade, devemos portanto investir na excelência de execução de actividades de performance e devemos atingir um equilíbrio com as actividades de controlo de conformidade para uma remoção eficiente e eficaz de defeitos encontrados. As actividades relacionadas com a prevenção de defeitos estão relacionadas sobretudo com a organização e respectiva gestão de processos, normas, formação, etc.\n10 Raytheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017\nAnáli se comparativa e critérios de selecção de modelo s\nRelativamente às act ividades de eliminação de controlo reactivo de conformidade, como revisões, inspecções, teste s, etc, em 1996 Jones [Jones1996] publicou um e studo que analisava a eficiência associada aos m étodos de remoção de defeitos (Tabela 5).\neficiência de remoção de defeitos de diversos m étodos, que tem sido\nconfirmada através de est udos posteriores [Nichols2009], vem demonstra r que os métodos de\nremoção de defeitos em\nfases anteriores do desenvolvimento, nomeadam ente com revisões e\ninspecções formais, são m ais eficientes do que testes unitários, testes integr ados e de sistema.\nA análise efectuada à\n3.3 Critérios na s elecção de modelos de desenvolvi mento\nDentro de uma organ ização um projecto avança: ou porque é obrigató rio, por advir de uma necessidade de regulamen tação ou de mercado; ou porque representa um valor acrescentado à organização. Tanto num c aso como noutro existe a necessidade de garantir por todos os meios o retorno de investimento pr evisto ou a maior contenção possível de custos.\nestar realizados em sem retorno previsto)\ndeterminado prazo, ou po rque representam um custo muito elevado (ou\npara a organização. Se u m projecto está assente em determinados pre ssupostos de custos, prazos, risco, âmbito e q ualidade, os processos pelos quais o mesmo é i mplementado devem garantir o máximo control o destas variáveis. Este controlo está associado à previsibilidade.\nMuitas vezes alguns\nprojectos não avançam porque não poderão\ningredientes chave para o sucesso dos proj ectos, e estes estão\nespelhados em todos os m étodos apresentados: desenvolvimento em iteraçõ es, boa comunicação com o cliente e entre a eq uipa, equipa motivadas, capacitadas e comprom etidas e boas práticas de engenharia.\nAlguns valores são\npelo que devem ser estas políticas devem\nser suficientemente flexív eis para se poderem adaptar a contextos difer entes. A organização\nUma organização n ormalmente não executa apenas um projecto, definidas políticas organiz acionais para a gestão de projectos, sendo que\ndeve procurar de forma uniforme, inovar, aprender com lições aprendidas, suportar a formação de todos os colaboradores, ter processos definidos que evoluem e se adaptam conforme as necessidade e devem ser geridas com métricas.\nOs processos de engenharia de software devem procurar de forma eficiente a produção de produtos ou serviços de alta qualidade, pelo qual os mecanismos implementados devem ter em conta essa eficiência.\nTalvez faltem estudos mais rigorosos que comparem os modelos económicos associados ao Scrum e XP quando comparados com o TSP/PSP.\nPela informação disponível o TSP/PSP parece ser de uma perspectiva racional mais indicado em termos de adopção como metodologia de desenvolvimento. Tem no entanto um custo de setup inicial elevado, que deve ser encarado como um investimento. Para projectos de pequena dimensão ou criticidade, a utilização de métodos mais ágeis vai responder de forma mais rápida e por vezes mais ajustada, mas sem documentação sustentada – algo que por vezes o cliente pede.\nEm relação ao método proposto por Boehm (ver capítulo Combinando ), será feita uma proposta de modelo que abranja de uma forma mais global, a utilização dos modelos mencionados para aspectos de organização e gestão de projectos.\nSerá também complementado com alguns critérios de selecção na componente de relação com o cliente, na forma de detectar partes ágeis dos projectos e no facto da equipa estar ou não localizada em locais distintos.\nO modelo referido pressupõe a análise dos componentes para se eventualmente detectar padrões ágeis de abordagem, mas não refere, que para além dos componentes, as fases dos projectos podem ser interessantes para aplicar este tipo de metodologias. Por exemplo: Pode fazer sentido utilizar uma abordagem ágil no início de um projecto, para a realização de uma prova de conceito [Edeen2007], e depois caso o projecto avance se proceda com uma metodologia menos ágil.\nNeste capítulo será apresentado um método para o planeamento de um projecto de desenvolvimento de software, baseado no modelo de Boehm, de acordo com os princípios estabelecidos no capítulo anterior. Serão dados alguns exemplos de aplicação do método em diferentes tipologias de projectos.\n4.1 Método de planeamento\nO método de planeamento está dividido 4 fases, de A a D, com alguns componentes\ntransversais que devem ser implementados em qualquer situação e com a primeira fase opcional caso apenas se esteja a prever a realização de apenas um projecto na organização. Como\nresultado possível pode ser recomendada:\n• A aplicação de metodologias ágeis como Scrum e XP\n• Métodos ágeis (Scrum + XP) mas com geração de documentação\nO método inicia-se com a recomendação clara da necessidade de implementação de\nmetodologias que enderecem as necessidades da gestão de uma organização, ao nível de definição e controlo de processos, formação, inovação e análise dos problemas ou lições aprendidas. Esta necessidade pode ser colmatada com os modelos CMMI ou SPICE, que não são prescritivos em relação às práticas de gestão de projectos ou de engenharia. O CMMI é especialmente recomendado dado o seu grau de implementação mundial, a comunidade envolvente que o utiliza, e o facto de fornecer uma perspectiva integrada de desenvolvimento, serviços e aquisições de software.\nO segundo passo passa pela implementação de uma norma de gestão de projectos\ncompleta, que assegure todas as actividades necessárias à sua gestão. Neste caso as normas PMBOK ou Prince são aconselhadas dada a sua implantação e grau de completude.\nMétodo de selecção de modelos de desenvolvimento de software\nO terceiro passo tem a ver com a detecção de padrões de implementação de métodos ágeis\nnos projectos. A detecção destes padrões passam pelo objectivo inicial de que existe alguma indefinição ou volatilidade potencial ao nível de requisitos, para se poder explorar o conceito de agilidade, mas deve garantir que todos os pressupostos seguintes estão assegurados:\n• A equipa tem alguma maturidade técnica\n• A equipa está preparada para uma cultura não processual\n• O projecto ou fase não tem uma grande dimensão\n• O projecto ou fase não tem uma grande criticidade\n• Existe uma relação de confiança com o cliente\n• O cliente, ou representante, tem disponibilidade física e temporal\n• A equipa de projecto não está localizada em locais distintos\n• O cliente não solicita documentação exaustiva\nA detecção destes padrões pode ser efectuada ao nível de um componente do projecto ou\nde uma fase do projecto. Caso seja encontrado este padrão, uma combinação de Scrum e XP parece aconselhada, dado que são as metodologias ágeis mais utilizadas a nível mundial.\nPor fim, para as fases ou módulos restantes do projecto, deve ser adoptada uma filosofia não ágil, que pode ser baseada numa filosofia ágil mas que deve ser complementada com\nprincípios mais documentados, ou no TSP/PSP. Aqui recomenda-se a aplicação da prática a que a equipa está mais familiarizada ou em que seja oportuno investir.\nPara projectos de grande dimensão ou criticidade recomenda-se a metodologia do tipo TSP/PSP.\nIndependentemente da metodologia a implementação de componentes transversais deve estar sempre presente:\n• Gestão da equipa: deve ser promovida uma gestão de equipa que garantam a sua motivação e comprometimento. Isto é conseguido através do seu correcto envolvimento em todas as actividades que lhes afectam directamente, através de uma garantia de autonomia de actuação e com uma componente de coaching, que promova a excelência de práticas através da uma liderança baseada no exemplo.\n• Desenvolvimento em iterações: todas as metodologias modernas promovem hoje a utilização de iterações nos projectos. Os seus benefícios são claros, pois promovem uma redução do risco do projecto, através de momentos antecipados de aceitação do cliente, realizações concretas e não teóricas dos projectos, emergência de requisitos e desenhos.\n• Relação próxima com o cliente: o cliente não precisa de estar presente a todo a hora junto da equipa de desenvolvimento, mas pelo menos em pensamento sim. Deve existir um constante foco naquilo que são as necessidades do cliente, que se traduzem não só pelo garantir do âmbito correcto mas também do prazo e custo. Deve ser promovida uma relação de proximidade com o cliente, que se consegue através de um contacto frequente e de confiança. Essa confiança constrói-se com feedback, com cumprimento dos pressupostos estabelecidos.\nO tigre representa a combinação de métodos ágeis e não ágeis (Figura 26). Tem o grau de robustez necessário para grandes projectos e desafios e por outro lado é capaz de reagir rapidamente a situações imprevistas.\nNeste capítulo são apresentadas as principais conclusões do trabalho, face aos objectivos propostos e são delineadas algumas linhas potenciais de trabalho futuro.\n5.1 Satisfação dos objectivos\nEsta tese propôs-se a responder a três questões principais:\n• Quais as diferenças principais entre os principais modelos mais e menos ágeis?\n• Que tipo de modelo de desenvolvimento de projectos de software deve uma organização adoptar?\n• Para que tipo de projectos se aplicam cada tipo de modelo?\nPretendia-se com isto perceber de forma mais clara quais as diferenças, semelhanças e graus de aplicabilidade de diferentes metodologias de desenvolvimento de software, para assim conseguir uma gestão de projectos com maior sucesso. Este sucesso é medido através da satisfação do cliente e das suas expectativas indissociáveis: âmbito, custo, prazo e qualidade.\nA resposta a estas questões foi efectuada através da análise dos modelos de desenvolvimento de software mais utilizados tanto nas áreas ágeis como nas áreas menos ágeis (TSP/PSP, Scrum e XP), conjugada com modelos complementares mais orientados à gestão da organização (CMMI) ou mais à gestão de projectos (PMBOK). Esta análise revelou que mais do que as diferenças que os distinguem, existem objectivos e contextos de aplicabilidade distintos.\nDo trabalho já realizado pela comunidade científica e empresarial, foi escolhido um método base para uma evolução, que fizesse emergir um novo método que contempla critérios e pressupostos de decisão consoante o tipo de projecto, organização e cliente em causa.\nEste método utiliza os modelos aqui referidos para adquirir uma abrangência que trata a área de gestão dos processos da organização, a gestão dos projectos e as práticas de engenharia. Este método salientou também as características que são transversais a qualquer modelo seleccionado e que passam por uma evolução iterativa dos projectos, uma gestão cuidada das equipas, através do envolvimento, comprometimento, autonomia, motivação e coaching, e por um foco no cliente, uma relação próxima, alinhada e de confiança.\nA conjugação do movimento gerado pelos métodos ágeis e pelos métodos menos ágeis pode trazer uma força virtuosa à evolução engenharia de software – uma constante preocupação pela excelência dos produtos entregues, através de processos de desenvolvimento controlados e sustentados aliados a uma capacidade de adaptação e inovação, e a um foco cuidado nas pessoas.\n5.2 Trabalho futuro\nExistem vários caminhos que podem ser escolhidos como linhas futuras de avanço deste trabalho.\nPor uma lado a experimentação do método em organizações que desenvolvem software, percebendo se de facto a sua aplicação propicia os resultados pretendidos. Associada a esta experimentação devem estar previstos ajustes nos requisitos e pressupostos estabelecidos, nomeadamente para a componente de detecção de padrões ágeis e na detecção de padrões transversais de aplicação – aqueles que não podem falhar seja qual for a metodologia.\nTantos os métodos ágeis como os métodos não ágeis têm sofrido evoluções ao longo dos últimos anos, bem como têm surgido novos modelos (por exemplo o método ágil scrum-ban). Estes novos métodos devem ser analisados de forma a perceber que contribuições podem trazer para o método definido.\nPor outro lado será interessante observar a abrangência das metodologias não só na componente de desenvolvimento mas também nas componentes de gestão de serviço de software, aquisições e segurança. Por exemplo é interessante verificar a evolução do CMMI para as componentes de serviços e aquisições, a evolução de TSP/PSP para aspectos de manutenção de aplicações.\nDeve existir uma constante atenção à comunidade científica e à indústria que continuam a produzir contribuições sobre o tema. Não é fácil encontrar experiências sustentadas por dados quantitativos, especialmente nos métodos ágeis, dados que eles assentam precisamente em processos leves que não promovem a recolha de exaustiva de métricas.\nManifesto for Agile Software Development - http://agilemanifesto.org\nImplementing CMMI using a combination of agile methods, Joe Alegria, Maria Bastarrica, CLEI Electronics Journal, 2006\nAgile Software Process and Its Experience, Mikio Aoyama, IEEE, 1998\nKent Beck, Extreme Programming Explained: Embrace Change,Addison- Wesley, 2000\nBalancing Discipline and Flexibility With the Spiral Model and MBASE, Barry Boehm, Daniel Port, Crosstalk 2001\nBalancing Agility and Discipline, Barry Boehm, Richard Turner, Addison- Wesley, 2004\nManagement challenges to implementing agile processes in traditional development organizations, IEEE Software, Boehm, Turner, 2005\nAgile Software Development - A DACS State-of-the-Art Report, David Cohen, Mikael Lindvall and Patricia Costa, 2003\nAgility versus Discipline: Is Reconciliation Possible? G. Galal-Edeen, A. Riad, M. Seyan, ICCES Proceedings, 2007\nCMMI or Agile - Why not embrace both! Hilel Glazer, Jeff Dalton, David Anderson, Mike Konrada, Sandy Shrum, CMU/SEI-2008-TN-003, SEI, 2008\nIntroduction to Team Software Process, Watts S. Humphrey, 2000, Addison- Wesley\nTSP - Leading a deveopment team, Watts S. Humphrey, 2005, Addison- Wesley\nSoftware defect-removal efficiency, Jones, 1996\nAdopting agile in Distributed development, KalpanaSureshchandra, Jagadish\n[Konrad2007] CMMI, 2nd Edition – Guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad and Sandy Shrum, Addison Wesley, 2007\nFactors that Impact Implementing an Agile Software Development Methodology, Jeffrey A. Livermore, Walsh College, IEEE, 2007\nGuidelines for Model-Based (System) Architecting and Software Engineering (MBASE), Center for Software Engineering, University of South California, 2003\nTechnical Report Mapping TSP to CMMI – SEI - James McHale, Daniel S. Wall, April 2005\nAgile Software Process and Its Experience, 1988 IEEE\nUnderstanding Self-organizing teams in Agile Software Development, Nils Moe, Torgeir Dingsoyr, Tore Dyba19th Australian Conference, 2008\nDeploying TSP on a National Scale: Na expirience report from Pilot Project in Mexico, Carneggie Mellon 2009\nPMBOK Guide 4th Edition , The Project Management Institute, 2008\nSchwaber, K. and Beedle, M., Agile Software Development with SCRUM , Prentice-Hall, 2002\nAgile Project Management with Scrum, by Ken Schwaber, Microsoft Press,\nThe software development project success -rates The Standish Group – 2009\nExtreme Programming Refactored: The Case Against XP, Matt Stephens and Doug Rosenberg, Apress, 2003\n[Wall2007] Case Study: Accelerating Process Improvement by integrating TSP and CMMI, Daniel Wall, James McHale, Marsha Pomeriy-Huff, 2007, Technical report SEI\nWatts Humphrey, “Comments on eXtreme Programming”, eXtreme Programming Pros and Cons: What Questions Remain?, IEEE Computer Society Dynabook,2001\nWinning with Software – An executive summary, Watts S. Humphrey, Addison-Wesley, 2002\nHow we did adapt agile processes tou our distributed development?, Cynick Young, Hiroki tereshima, Agile 2008 Conference\nDocumentos semelhantes a Integração de modelos de desenvolvimento de software mais e menos ágeis.pdf\nRiviani Marques Saly\nQualidade de Software - Eng de SW Magazine\nAnais do SBQS 2017 - Rio de Janeiro.pdf\nCarla Gama Lustosa\nMelhorando o Processo de Aquisicao de Materiais e Componentes Para Prototipos de Novos Produtos\nMais de Gustavo Falcão\nModelos Ciclos de Vida de Software.pdf\nComparacao Metodos Ageis Tradicionais\nPlano Individual de Carreira - Gustavo Falcao - Especializacao em Gestao da Seguranca da Informacao UNIJORGE.pptx\nApresentação Diagrama de Sequência


Os melhores memes sobre o limite de franquia da Vivo - Humor\n› Os melhores memes sobre o limite de franquia da Vivo\n18.04.2016 às 09h55\nOs novos limites de internet que muitas operadoras estão adotando ainda causam muita preocupação e revolta. Desde que a Vivo anunciou que também vai partir para o sistema de franquias na sua internet fixa, as redes sociais foram invadidas por campanhas de conscientização, protesto e muita reclamação sobre a mudança que está por vir. E não sem razão. Mas como o melhor do Brasil é o brasileiro, não demorou para que algumas dessas manifestações de repúdio viessem na forma de humor. Muitas piadas surgiram a partir dessa ideia de bloqueio, assim como sátiras às próprias campanhas das empresas. A mais icônica delas foi a paródia do comercial da Vivo, que simplesmente acaba sendo interrompida como se a franquia tivesse acabado durante a transmissão. Um cutucão bastante simbólico ao que a empresa pretende fazer. Só que essa foi apenas uma pequena parte dos memes e dos comentários relacionados à polêmica. A partir da hashtag #internetjusta, usuários de todo o país começaram a brincar com o conceito de franquias e a mostrar de maneira irônica como seria esse futuro em que as conexões seriam limitadas a pacote de dados e outras brincadeiras do tipo. Selecionamos algumas para mostrar como o brasileiro é criativo mesmo na hora de protestar. E também para mostrar que uma internet justa e ilimitada é sempre o ideal — caso contrário, nem mesmo esse bom-humor vai poder ser praticado. Sobre esse negócio de limitar a internet #InternetJusta pic.twitter.com/tfyx4oqbym — CAMIS °-° (@kxoland) 15 de abril de 2016 ja pago caro, e ainda vai ter limite e cobrança extra? #InternetJusta pic.twitter.com/kdSWM7tJaQ — bruno 0 GRAMMYs (@cracudu) 15 de abril de 2016 @vivoblog Pra não ter internet decente o mês todo é melhor usar um desses aqui, assim você não passa raiva. pic.twitter.com/rhrDkAnTU4 — Renuncia Dilma (@Tasssssso) 14 de abril de 2016 #InternetJusta pic.twitter.com/me3ApFJ2XJ — João Pedro (@JooPedr36655965) 18 de abril de 2016 sobre as operadoras quererem limitar a internet #InternetJusta pic.twitter.com/PZuCcTmkq1 — juzinha 1 MÊS (@castagnoise) 15 de abril de 2016 de tanto ler bolsomitoresolveram limitar a internet mesmoculpa de vcs ai — Elisa (@mortificadas) 14 de abril de 2016 Não podem limitar a internet do povo #InternetJusta pic.twitter.com/vO67it3xIp — Vanessa McDonough (@VanessaMcDunna) 15 de abril de 2016 A internet nasceu pra ser livre! #InternetJusta pic.twitter.com/spCLKm4quK — Mundo de Ooo (@Mundo_de_Ooo) 16 de abril de 2016 sobre as empresas que apóiam limitar a internet #internetjusta pic.twitter.com/j7ogCpCxAU — rafael (@oministerio) 16 de abril de 2016 sobre quererem limitar a internet #InternetJusta pic.twitter.com/ml55coR83e — yuri (@spnwow) 15 de abril de 2016 Como assim limitar internet? #InternetJusta pic.twitter.com/veNkpezbGI — Jordana 7/27 (@EvilRegalBr) 15 de abril de 2016 indo assistir as series / vc acaba de atingir 100% da sua internet #InternetJusta pic.twitter.com/unc1Ovv4QC — cleytu (@cleytu) 15 de abril de 2016 Botando os animes em dia quando de repente "Você atingiu 100% da sua franquia" #InternetJusta pic.twitter.com/W7529emW27 — ლJuanლ (@joeyporto79) 15 de abril de 2016 Assine nosso canal e saiba mais sobre tecnologia!