MODULO 1 Introduo

Os computadores tm se tornado um elemento chave em nossas vidas. Aos poucos, eles esto assumindo muitas das funes que nos afetam de maneira decisiva. Hoje eles controlam a maioria das transaes monetrias, linhas de produo, transporte, comunicao, sistemas de defesa, sistemas de controle de processo etc. No futuro prximo, eles sero encontrados em nossos lares e podero controlar a utilizao de todos os aparelhos eletrnicos. No entanto, computadores sozinhos so mquinas (hardware) inofensivas. Com o tipo certo de programa (software), eles podem lev-lo Lua, literal e figuradamente. o software que d vida a eles. Quando precisam desempenhar um papel to importante, uma pequena falha tanto no hardware quanto no software pode levar a conseqncias desastrosas. Infelizmente, embora haja processos bem definidos, baseados em fundamentos tericos para garantir a confiabilidade do hardware, no se pode dizer a mesma coisa sobre software. Embora ainda no exista uma teoria para desenvolvimento de software, necessrio que o ele se comporte de maneira previsvel, mesmo em situaes imprevistas. Por essa razo, existe uma necessidade de gerenciar seu desenvolvimento por meio de um processo bem definido e sistemtico. A antiga abordagem "codificar e testar" (code & test) no ser suficiente. Ela pode ser boa para problemas mais simples. No entanto, o software precisa ser projetado de forma a lidar com situaes extremamente complexas. Os aspectos cruciais para o sucesso de um projeto de software so: . Esforo de Equipe Qualquer esforo para o desenvolvimento de softwares exige uma equipe de especialistas. Por exemplo, a equipe pode ser composta por especialistas em domnios, projetos, codificao, testes e hardware. Cada grupo de especialistas deve se concentrar em um aspecto especfico do problema e apresentar uma soluo adequada. No entanto, nenhum grupo pode trabalhar isoladamente, pois a interao entre os membros das equipes importantssima. . Metodologia Existem tipos de metodolofias de desenvolvimento: . voltada ao procedimento . voltado ao objeto Embora, teoricamente, ambas possam ser usadas em qualquer situao de problema, uma delas deve ser selecionada antecipadamente. . Documentao Uma documentao clara, objetiva e precisa dos componentes do processo de desenvolvimento crucial para o sucesso de qualquer projeto de software. Comunicao verbal e desenhos do pacote no so suficientes para se entender tal processo. Por exemplo, a documentao essencial para a aprovao do cliente em vrias etapas do processo. Uma vez desenvolvido, o software cria vida. Entretanto, durante sua vida, ele passar por vrias mudanas e uma documentao bem feita essencial para a realizao dessas alteraes de forma mais eficaz. . Planejamento Assim que o desenvolvimento do software ocorrer de acordo com os requisitos especificados pelo cliente, necessrio que todo o esforo seja adequadamente estimado para atender as restries de prazo e custo.

. Garantia de Qualidade Os clientes esperam retorno financeiro com a implantao do software. Alm de atender s necessidades do cliente, o software deve, necessariamente, atender aos padres de qualidade que podem ser em relao ao desempenho, segurana, etc. . Usurio Leigo Usurios leigos: usurios tpicos dos pacotes de software podem no ser conhecedores de computao. O software, portanto, precisa ser altamente robusto. . Ferramentas de Softwares A documentao importante para um projeto de desenvolvimento de software, mas uma tarefa onerosa e muitos desenvolvedores desistem de faz-la. Existem ferramentas de Engenharia de Software Assistida por Computador (Computer Aided Software Engineering CASE) que simplificam o processo da documentao. . Conformidade com os Padres Os padres so necessrios para garantir uma documentao clara, objetiva e sem ambiguidades. Por exemplo, padres IEEE para especificaes de requisitos, projetos, etc. Tambm possvel que um cliente especifique os padres a serem usados. . Reutilizao O esforo de desenvolvimento pode ser otimizado, reutilizando-se componentes j testados, como por exemplo, bibliotecas matemticas, kits de ferramentas de interface grficas de usurio etc. . Manuteno de Software Todo software precisa ser modificado periodicamente, de acordo com as solicitaes dos clientes e do uso de novas tecnologias. A equipe de desenvolvimento pode no estar disponvel para realizar a manuteno do pacote. Portanto, uma equipe de suporte dever ser reunida, sempre que necessrio, para garantir que o software continue a fornecer os servios necessrios. . Gerenciamento de Alterao Sempre que uma alterao deva ser realizada, necessrio estudar seu impacto sobre os vrios componentes do software. Por exemplo, ao modificar o tipo da varivel denominada Global, toda funo que utiliz-la ser impactada e, a menos que se tome cuidado para minimizar esse efeito, o software poder ter seu desempenho comprometido. . Controle de Verso O software est propenso a frequentes alteraes durante seu desenvolvimento. Portanto, importante que o usurio obtenha a verso mais recente. No caso de falhas, ser possvel recorrer s verses anteriores. . Gerenciamento de Risco Qualquer grande esforo de desenvolvimento de software est sujeito a riscos. Por exemplo, indisponibilidade de especialistas, tecnologia, recursos, etc. necessrio avaliar constantemente os riscos e criar medidas para reduzi-los.

MODULO 2 Qualidade de Software A meta de qualquer processo de desenvolvimento produzir um software de qualidade. Agora, o que qualidade de software? Qualidade de software foi definida de vrias maneiras, como por exemplo: . Adequao ao propsito . Zero defeito . Conformidade e segurana . Atendimento necessidade definida e implcita do cliente Alguns dos atributos importantes que podem ser usados para medir qualidade do software so: . Preciso O software deve atender s necessidades do cliente. . Confiabilidade O software deve se comportar sempre de maneira previsvel, mesmo quando entradas equivocadas/aleatrias so dadas. . Usabilidade Facilidade para se usar. Um software com uma boa interface grfica para o usurio considerado mais fcil de ser usado. . Portabilidade A facilidade com a qual um software pode ser movido de uma plataforma a outra. . Eficincia Utilizao ideal de recurso (memria e tempo de execuo). .Manuteno Facilidade com a qual o software pode ser modificado. . Flexibilidade Facilidade com a qual o software pode ser adaptado para uso em diferentes contextos. . Segurana Preveno de acesso no autorizado. . Interoperabilidade A capacidade de integrao do software com sistemas existentes. . Desempenho A capacidade do software de fornecer os resultados com diferentes restries como tempo, preciso, uso de memria. Preciso o atributo mais importante. Um software deve ser preciso, mesmo que outros atributos possam ser vlidos em graus que variam. Por exemplo, um aplicativo no fundamental pode deixar de garantir 100% de confiabilidade, como um processador de texto. J para um sistema de monitoramento de sade, 100% de preciso necessria. No entanto, a deciso final do cliente. Deve-se ter em mente, ainda, que alguns dos atributos conflitam entre si, por exemplo, portabilidade e eficincia.

Pode-se recorrer ao uso de recursos dependentes em um sistema de maneira a melhorar a eficincia, mas apenas a custo da portabilidade. Nos bons e velhos tempos, quando o DOS dominava o mundo, era possvel acessar a arquitetura interna diretamente, de modo a melhorar o desempenho. No entanto, para suportar esse programa em qualquer outra plataforma, eram necessrias mudanas drsticas. Logo, na prtica, sempre haveria uma troca.

MODULO 03 O que um processo? Vamos tentar um pequeno exerccio. Comece a ler a passagem ao lado. Conforme voc a l, conte as ocorrncias da letra 'F'. Uma vez terminada a leitura, coloque o nmero na caixa.

Um processo uma srie de tarefas defininveis, repetiveis e mensurveis que levam a um resultado til. Um processo bem definido possui muitas vantagens, so elas: . Facilita a visualizao de um projeto, auxiliando nas correes peridicas. . Ajuda os desenvolvedores a eliminar problemas no momento de sua implantao, evitando efeitos cascata. . Ajuda a organizar o fluxo de trabalho e os resultados para maximizar a utilizao de recursos. . Define de maneira clara e objetiva papis e responsabilidadesa individuais. . Aumenta a produtividade individual por causa de papis bem definidos, considerando que a produtividade da equipe aumenta devido a uma boa coordenao. Um bom processo de desenvolvimento de software deve: . Considerar o desenvolvimento de software como uma atividade de negcios de valor agregado e no meramente como uma atividade tcnica. . Garantir que haja uma adio de valor definida para todos os produtos. . Se resguardar contra perda de valor, uma vez que o produto esteja completo. . Fornecer informaes de gerenciamento para controle no local do processo. Para definir um processo como esse, os seguintes passos devem ser seguidos: . Identificar as fases de desenvolvimento e as tarefas a serem executadas em cada uma. . Modelar as transies intra e inter fases. . Usar tcnicas para executar as tarefas. . Verificar e validar cada tarefa e seus resultados. . Usar habilidades de gerenciamento de processo e projeto.

As palavras verificar e validar precisam ser explicadas. Considerando que VERIFICAR significa checar se a tarefa foi executada corretamente, VALIDAR significa checar se a tarefa correta foi executada. No contexto de software, o processo de checar se um algoritmo foi implementado corretamente, verificao, enquanto o processo de checar se o resultado da execuo do algoritmo a soluo do problema, validao. As fases genricas que normalmente so usadas em um processo de desenvolvimento de software so:

. Analise Nesta fase, as necessidades do usurio so reunidas e convertidas em requisitos de software. Por exemplo, se o usurio precisa gerar a trajetria de um missil, um requisito de software resolver as equaes reagentes. Essa fase deve responder pergunta: O que precisa ser feito para atender s necessidades do usurio? . Projeto Esta fase responde pergunta: O que precisa ser feito para atender s necessidades do usurio? Com relao ao exemlpo anterior, o projeto consiste na tomada de decises sobre o algoritmo a ser usado para solucionar as equaes regentes. Essa escolha depende dos objetivos do projeto, como tempo de execuo, preciso, etc. Nessa fase ns decidimos sobre a organizao dos vrios mdulos do sistema de software. . Construo Codificao e teste do mdulo so as principais atividades nesta fase. . Teste Existem trs categorias de teste: de unidade, de integrao e de sistema.

Existem dois tipos de teste: da caixa preta e da caixa branca. O teste da caixa preta se concentra em gerar casos de teste com base em requisitos. O teste da caixa branca se concentra em grar casos de teste com base na lgica interna de vrios mdulos. . Implementao Esta fase consiste em entregar o software aos clientes (de instalao e operacionalizao).

MODULO 4 Modelos de Ciclos de Vida do Software Na prtica, so usados dois tipos de modelos de ciclo de vida de software , so eles: . Sequencial . Interativo

Modelo sequencial, tambm conhecido por modelo de cachoeira, pode ser exibido de forma ilustrativa.

Ele representa o processo de desenvolvimento como uma sequncia de fases, exigindo que uma fase especfica seja concluda antes da prxima ser iniciada. Devido ao reconhecimento de fases e sequenciamento, ele ajuda na finalizao do contrato com referncia a entrega e planos de pagamento. Na prtica, difcil usar este modelo como ele , por causa da incerteza nos requisitos de software, que a priori, so difceis de prever. Se um erro no entendimento dos requisitos for detectado durante a fase de codificao, o processo todo dever ser reiniciado. Uma verso de trabalho do software no estar disponvel at o final do ciclo de vida do projeto. Logo, a iterao dentro de uma fase e entre fases uma necessidade.

A prototipagem discutida na literatura como uma abordagem separada do desenvolvimento de software. Como o nome sugere, exige que uma verso de trabalho do software seja desenvolvida logo no incio de projeto. Existem dois tipos de prototipagem, so eles: . Prottipo Descartvel O objetivo do prottipo descartvel entender os requisitos e as melhores metodologias de soluo. A essncia velocidade. Desta forma, recorre-se a uma abordagem de desenvolvimento rpida e especfica sem nfase na qualidade. semelhante ao codificar e testar. No entanto, uma vez tendo atingido o objetivo, o cdigo descartado e um novo desenvolvimento iniciado, garantindo que os padres de qualidade sejam atendidos. Uma vez bem entedidos os requisitos, pode-se usar a abordagem sequencial. . Prottipo evolutivo No prottipo evolutivo, os requisitos so priorizados e o cdigo desenvolvido inicialmente para os mais importantes, sempre com foco na qualidade. O software contantemente refinado em forte colaborao com o cliente.

Finalmente, a principal vantagem dos prottipos est no fato de que o cliente consegue ter uma viso do produto logo no incio do ciclo de vida do projeto. Como podemos ver, a prototipagem evolucionria um modelo iterativo. Um modelo como esse pode ser caracterizado por fazer anlise mnima, projeto, cdigo, teste e por repetir o ciclo at a concluso do produto. Modelo Espiral Barry Boehm sugeriu um modelo iterativo chamado modelo espiral. como uma estrutura que precisa ser adaptada a projetos especficos. Ele permite a melhor combinao de vrias abordagens e se concentra na eliminao antecipada de erros e alternativas inviveis. Uma caracterstica importante deste modelo , no entanto, a nfase em anlise de risco. Uma vez identificados os objetivos, alternativas e restries de uma fase, os riscos envolvidos na sua execuo so avaliados, resultando em uma deciso "ir, no ir". Para fins de avaliao, se pode usar prototipagem, simulaes etc. Esse modelo mais adequado para projetos que envolvam o desenvolvimento de novas tecnologias. Especializao em anlise de risco mais importante para esses projetos. Veja a seguir:

Modelo ETVX

A IBM lanou o modelo ETVX (durante os anos 80) para documentar seus processos. E so os critrios de entrada que precisam ser satisfeitos antes da execuo de um conjunto de tarefas, T o conjunto de tarefas a serem executadas, V o processo de verificao para garantir que as tarefas sejam executadas corretamente e X so os critrios de sada ou os resultados das tarefas. Se uma atividade falhar na checagem de verificao, uma ao corretiva tomada ou um retrabalho solicitado. Esse modelo pode ser usado em qualquer processo de desenvolvimento. Cada fase no processo pode ser considerada como uma atividade e estruturada usando o modelo ETVX. Se necessrio, as tarefas podem ser subdivididas. Modelo de Processo Unificado Racional Entre os modelos modernos de processo, o Processo Racional Unificado (Rational Unified Process RUP) desenvolvido pela Rational Corporation digno de considerao. um modelo iterativo que captura muitas das melhores prticas do moderno desenvolvimento de software. O RUP explicado mais integralmente no mdulo sobre OOAD com UML. Metodologias geis Todas as metodologias descritas anteriormente so baseadas na premissa de que qualquer processo de desenvolvimento de software deve ser previsvel. Uma das crticas contra essas metodologias que: . H nfase sobre procedimentos e preparao da documentao . So consideradas pesadas ou rigorosas . Enfatizam excessivamente a estrutura

Metodologias geis Um movimento chamado de Movimento de Software gil, est questionando essa premissa. Os proponentes argumentam que o desenvolvimento de software, sendo essencialmente uma atividade humana, ter sempre variaes em processos e entradas. O modelo deve, portanto, ser flexvel o bastante para lidar com as variaes. Por exemplo, o conjunto de todos os requisitos de software no pode ser conhecido no incio do projeto, nem pode permanecer esttico. Se o modelo no puder lidar com este dinamismo, pode haver muita perda de esforo ou o produto final pode no atender s necessidades do cliente. Deste modo, as metodologias geis defendem o princpio da construo curta, construo frequente, ou seja, o projeto dividido em subprojetos e cada subprojeto desenvolvido e integrado ao sistema j entregue. Assim, o cliente recebe constantemente sistemas teis e utilisveis. Os subprojetos so escolhidos para que tenham ciclos de entrega curtos, geralmente da ordem de 3 a 4 semanas. A equipe de desenvolvimento tambm recebe feedback constante.

Uma srie de metodologias geis foram propostas. As mais populares entre elas so: . SCRUM . MTODO DE DESENVOLVIMENTO DE SISTEMAS DINMICOS (DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM) . MTODOS CRYSTAL . DESENVOLVIMENTO VOLTADO A RECURSO . DESENVOLVIMENTO ENXUTO (LEAN DEVELOPMENT LD) . PROGRAMAO EXTREME (EXTREME PROGRAMMING XP)

SCRUM: estrutura de gerenciamento de projeto. Ela divide o desenvolvimento em ciclos curtos chamados de ciclos rpidos nos quais um conjunto especfico de recursos fornecido. Ela defende reunies dirias de equipe para coordenao e integrao. Mais informaes sobre SCRUM podem ser obtidas aqui.

DSDM MTODO DE DESENVOLVIMENTO DE SISTEMAS DINMICOS $DYNAMIC DEVELOPMENT METHOD DSDM$ caracterizado por nove princpios: 1. 2. 3. 4. 5. 6. 7. 8. 9. Envolvimento ativo do usurio Fora de equipe Entrega frequente de produtos Adequao para o propsito do negcio Desenvolvimento iterativo e incremental Todas as mudanas durante o desenvolvimento so reversveis Base de exigncias a um alto nvel Teste integrado Colaborao e cooperao entre interessados

SYSTEMS

Mais informaes sobre o DSDM podem ser obtidas aqui. CRYSTAL METODOLOGIAS CRYSTAL: conjunto de metodologias configurveis. Elas focam nos aspectos de desenvolvimento das pessoas. A configurao executada com base no tamanho , urgncia e objetivosdo projeto. Alguns dos nomes usados para as metodologias so Claro (Clear), Amarelo (Yellow), Laranja (Orange), Orange web, Vermelho (Red) etc. Mais informaes podem ser obtidas aqui. Desenvolvimento de Software Enxuto DESENVOLVIMENTO VOLTADO A RECURSO (FEATURE DRIVEN DEVELOPMENT FDD): estrutura curta de iterao para desenvolvimento de software. Ela foca na construo de um

modelo de objeto, lista de recurso de construo, plano, projeto e construo por recurso. Mais informaes podem ser obtidas aqui. DESENVOLVIMENTO ENXUTO (LEAN DEVELOPMENT - LD): esta metodologia deriva de princpios de produo enxuta, a reestruturao da indstria manufatureira automobilstica japonesa que ocorreu na dcada de 80. Ela se baseia nos seguintes princpios do pensamento enxuto: . Eliminar desperdcios . Ampliar o aprendizado . Decidir o mais tarde possvel . Entregar o mais rpido possvel . Capacitar a equipe . Construir a integridade . Enxergar o todo Mais informaes podem ser obtidas aqui. Programao Extreme

PROGRAMAO EXTREME (EXTREME PROGRAMMING - XP): esta metodologia provavelmente a mais popular entre as metodologias geis. Ela se baseia em trs princpios importantes: testar primeiro, reestruturar contnuamente e programar em par. Mais informaes podem ser obtidas aqui. Um dos conceitos mais importantes popularizados pelo XP a programao em par. O cdigo sempre desenvolvido em pares. Enquanto uma pessoa insere o cdigo, a outra revisa. Este site dedicado programao em par. O trabalho por Laurie Williams et al., demonstra a eficcia da programao em par.

O site agilealliance.com dedicado a promover metodologias de desenvolvimento de software geis.

MODULO 5 Como Escolher um processo? Entre a abundncia de processos disponveis, como podemos escolher um? No h uma nica resposta para essa pergunta. Provavelmente, a melhor maneira de resolver este problema olhando para os requisitos de software.

Estas so apenas diretrizes. Muitas organizaes escolhem um modelo e o adaptam s suas exigncias de negcios. Por exemplo, algumas organizaes usam o modelo de cachoeira modificado para incluir iteraes dentro de fases. MODULO 6 Concluso A lio mais importante deste mdulo a de que o desenvolvimento de software deve seguir um processo disciplinado. A escolha do processo, no entanto, depender da estabilidade dos requisitos, da integralidade dos requisitos, dos processos de negcios adjacentes, da estrutura organizacional e do ambiente de negcios prevalecente. "An Integrated Approach to Software Engineering", de Pankaj Jalote, Springer-Verlag "Software Engineering: A Pratictioner's Approach", de Roger S. Pressman, McGraw-Hill, Inc. "Software Engineering", de Ian Sommerville, Addison-Wesley Publishing Company "The Rational Unified Process, An Introduction", de Philippe Krutchen, Addison-Wesley Publishing Company "Agile Software Development Ecosystems", de Jim Highsmith, Addison-Wesley Publishing Company