Aula 1 – Práticas Recomendadas na Engenharia de Software FEEC-UNICAMP Ricardo Gudwin Ivan Ricarte Mário Jino.

Apresentação em tema: "Aula 1 – Práticas Recomendadas na Engenharia de Software FEEC-UNICAMP Ricardo Gudwin Ivan Ricarte Mário Jino."— Transcrição da apresentação:

1 Aula 1 – Práticas Recomendadas na Engenharia de Software FEEC-UNICAMP Ricardo Gudwin Ivan Ricarte Mário Jino

2 Análise da Situação Atual no Desenvolvimento de Software zEconomia Mundial ycrescentemente dependente de software zMercado de Software ydemanda mais produtividade e qualidade em menos tempo zAplicações de Software yexpandindo em tamanho, complexidade e disseminação zMão de Obra Qualificada ycada vez mais difícil de encontrar zGerenciamento de Equipes de Desenvolvimento yequipes numerosas yindivíduos especializados, distribuídos geograficamente yrápida mudança nas tecnologias disponíveis

3 Sintomas de Problemas no Desenvolvimento de Software zNecessidades dos usuários não atendidas zMudanças nos requisitos não implementadas zMódulos que não conseguem interagir adequadamente zProgramas de difícil manutenção zDescoberta tardia de erros sérios no projeto zBaixa qualidade do software zDesempenho inaceitával do software zEquipes de desenvolvimento sem compromissos com o projeto yincapazes de rastrear os passos do desenvolvimento zProcessos de desenvolvimento não confiáveis ybuild and release

4 Causas dos Problemas no Desenvolvimento de Software zGerenciamento de Requisitos inadequado zComunicações imprecisas e/ou ambíguas zArquiteturas Inflexíveis (inadequadas a mudanças) zComplexidade incontrolável e avassaladora zInconsistências não detectadas durante a especificação de requisitos, análise, design ou implementação zTestes insuficientes zFalta de referência na estimativa do estado do projeto zGerenciamento de Risco comprometido devido a um desenvolvimento do tipo cascata (waterfall) zPropagação de mudanças sem o controle adequado zFalta de automação no processo de desenvolvimento

5 Sumário dos Problemas zPor que isso acontece ? yMetodologia de Desenvolvimento (Processo) inadequado yGerenciamento do Processo de Desenvolvimento inadequado zPor que inadequados ? yO perfil do software mudou zO que fazer para resolver ? yAdotar (criar, desenvolver) novas metodologias e novas formas de gerenciamento zComo desenvolver essas novas metodologias yObservar os projetos de software que deram certo yTentar capturar os princípios que fizeram com que eles dessem certo yTentar reproduzir as decisões que se mostraram promissoras

6 Práticas Consagradas da Engenharia de Software zPráticas “que deram certo” em projetos de software yDesenvolvimento Iterativo yGerenciamento dos Requisitos yArquiteturas baseadas em Componentes yModelagem Visual do Software yControle de Qualidade do Software yGerenciamento de Mudanças zResultados ymais projetos concluídos com sucesso ygerenciamento adequado de grandes equipes de software yqualidade do software melhorada ydiminuição dos custos de desenvolvimento

7 Desenvolvimento de Software Iterativo zPor quê ? yO primeiro design muito provavelmente será deficiente com respeito aos requisitos principais do projeto xnem todos os requisitos são claramente identificáveis a princípio, e aqueles que são podem as vezes ser ambíguos ou simplesmente inconsistentes xrequisitos podem mudar ou ficar obsoletos clientes podem mudar de opinião mercado competitivo pode exigir mudanças yA descoberta tardia de defeitos no design resultarão em aumentos de custos ou cancelamento do projeto yO tempo e o dinheiro gastos na correção de um design defeituoso não são recuperáveis !

8 Desenvolvimento do Tipo Cascata e Redução de Risco Especificação de Requisitos Análise Design Implementação Teste Tempo Risco

9 Desenvolvimento Iterativo zAplicação da Cascata Iterativamente ao Sistema zPrimeiras iterações carregam os maiores riscos zCada iteração gera uma versão executável com algum incremento ao sistema zCada iteração inclui integração e testes R A D I T tempo R A D I T R A D I T R A D I T I1 I2I3I4

10 Redução de Risco no Desenvolvimento Iterativo Tempo Risco Cascata Iterativo Iteração Iteração Iteração Iteração

11 Gerenciamento de Requisitos zRequisitos são dinâmicos ydevemos esperar que eles mudem durante o desenvolvimento de um software zObjetivo yelicitar, organizar e documentar as funcionalidades e restrições necessárias zMudanças nos Requisitos ynão podem ser impedidas, mas devem ser gerenciadas yavaliação das mudanças necessárias e determinação de seu impacto no projeto - relação custo/benefício yacompanhar e documentar as mudanças, as decisões tomadas e suas consequências

12 Documentação dos Requisitos zEspecificação dos Requisitos ydocumentada de forma clara e explícita zPor que ? yNem sempre poderemos ter um acesso direto ao cliente a todas as horas yClientes podem mudar de idéia e se não há nada registrado a respeito dos requisitos … yLigado a vários outros elementos do projeto xdesign e implementação, teste e qualidade, gerência do projeto zRequisitos ycapturados em uma forma que seja inteligível tanto ao cliente como à equipe de desenvolvimento xmeta para a equipe de desenvolvimento xcritério de aceitação e validação por parte do cliente

13 Arquitetura Baseada em Componentes zArquitetura de Software yabrange decisões significativas relativas à organização de um sistema de software xSeleção dos elementos estruturais que irão compor o sistema e suas interfaces xComportamento do sistema especificado como uma colaboração entre esses elementos xComposição destes elementos estruturais e comportamentais em sub-sistemas progressivamente maiores xEstilo arquitetural que dirige a organização, os elementos e suas interfaces, suas interações e colaborações, bem como sua composição yescolha da arquitetura tem um impacto crucial na capacidade do sistema de evoluir, se modificar e se integrar com outros sistemas

14 Arquitetura Baseada em Componentes zRequisitos Arquiteturais yuso, funcionalidade, desempenho, flexibilidade, capacidade de reutilização, compreensibilidade, aspectos econômicos e tecnológicos, aspecto estético zBoas Arquiteturas yflexíveis e baseadas em componentes zArquitetura Flexível yfacilidade de manutenção, extensão e reuso ypermite a divisão de trabalho entre elementos da equipe de desenvolvimento yencapsula detalhes do hardware e dependências do sistema zArquitetura Baseada em Componentes yReutilização e customização de componentes existentes yEscolha dentre milhares de componentes comercialmente disponíveis yPermitem a evolução incremental do software existente

15 Modelagem Visual do Software zCaracterísticas ycaptura a estrutura e comportamento de arquiteturas e componentes ymostra como os elementos se agregam entre si yesconde ou expõe detalhes, quando apropriado a uma tarefa ymantém a consistência entre um design e sua implementação ypromove a comunicação entre elementos da equipe sem ambiguidades yaumentam a capacidade de gerenciamento da complexidade do software zModelo ysimplificação da realidade que provê uma descrição completa do sistema a partir de uma perspectiva em particular

16 Modelagem Visual do Software zLinguagem de Modelagem yLinguagem Visual - Diagramas zO que é UML (Unified Modeling Language) ylinguagem visual de modelagem para especificar, visualizar, construir e documentar as partes de um sistema de software, durante todas as fases de desenvolvimento do mesmo yadotada como uma norma para modelagem de software (OMG) yindependente de plataforma ou linguagem de implementação zDiferentes tipos de diagramas yDiagramas de Casos de Uso, diagramas de Classes, diagramas de objetos, diagramas de estados, diagramas de componentes, diagramas de deployment, diagramas de colaboração, diagramas de sequência e diagramas de atividades

17 Modelagem Visual de Software zFerramentas CASE ypermitem a criação de modelos visuais usando o UML yrequisitos diferenciais: xsincronização com o código fonte xengenharia reversa xrevisão das mudanças efetuadas no código fonte zRevisão das Mudanças e Gerenciamento de Mudanças ydurante a sincronização do código fonte, a ferramenta pode detectar automaticamente as mudanças e solicitar que o usuário confirme se elas estão corretas ycaso as mudanças sejam efetuadas, elas devem ser registradas no modelo visual e no registro de mudanças

18 Verificação da Qualidade do Software zQualidade y“a característica de ter demonstrado, após a produção de um produto, produzido de acordo com um processo previamente acordado, o sucesso em atingir ou exceder os requisitos previamente acordados, de acordo com os critérios de medição previamente acordados” yAtingir ou superar os requisitos yEstabelecimento de métricas para demonstrar que os requisitos foram atingidos yImplementação de um Processo de desenvolvimento que garanta um nível de qualidade repetível e gerenciável zTeste de Software yalto custo e grandes deficiências, na maioria das organizações

19 Verificação da Qualidade do Software zDesenvolvimento Iterativo yPermite que o sistema seja continuamente testado e debugado yDistribui a tarefa de teste em doses mais administráveis yErros são encontrados mais cedo no ciclo de vida do software, quando os custos para sua correção são menores zAutomação dos Testes yFerramentas computacionais podem ser utilizadas para automatizar parte dos testes de um sistema yEssas ferramentas devem ser utilizadas desde as primeiras iterações yOs primeiros testes devem compreender os módulos isoladamente yPosteriormente, quando os módulos são integrados, deve ser feito um teste de integração

20 Dimensões da Qualidade de Software

21 Gerenciamento de Mudanças zMudanças devem ser controladas ycomo e quando elas são introduzidas yquem as introduziu ysincronização das mudanças entre as diferentes equipes participantes do projeto zPor que ? yMúltiplas equipes trabalhando simultaneamente em múltiplos projetos, com múltiplas versões de múltiplos componentes ysem um controle disciplinado, o desenvolvimento se degrada num verdadeiro caos zProblemas yatualizações simultâneas ynotificação de atualizações inadequada ymúltiplas versões

22 Gerenciamento de Mudanças zPráticas recomendáveis ydecompor a arquitetura em subsistemas e atribuir a responsabilidade de cada subsistema a uma equipe yestabelecer espaços de trabalhos seguros para cada desenvolvedor xisolamento de mudanças feitas em outros espaços de trabalho xcontrole dos artefatos de software - modelos, código, documentação, etc. yEstabelecer um espaço de trabalho de integração yEstabelecer um mecanismo de controle de mudanças necessário xou seja, ninguém efetua mudanças sem passar pelo mecanismo ySaber que mudanças aparecem em que releases do software yLiberar um release testado do software a cada iteração

23 Processos de Desenvolvimento de Software zEngenharia de Software ydiversos processos de desenvolvimento de software ygrande similaridade entre os processos ydivergências em alguns detalhes ylinguagens de modelagem diferentes zExemplos de Processos yProcesso Cascata (Waterfall) yProcesso Schlaer-Mellor yProcesso Microsoft (Build-and-Release) yFusion ySyntropy yCatalysis yXP - Extreme Programming

24 O Processo Unified zProcesso Unified yunificação das idéias de Jacobson, Rumbaugh e Booch yderivado e desenvolvido a partir do Objectory de Jacobson ydesenvolvido para o UML e junto com o UML yinstanciado na forma de um produto da Rational Corporation, o RUP - Rational Unified Process zUma definição em três tempos ydirecionado por casos de uso yfocalizado na arquitetura yiterativo e incremental zBaseado em Componentes ymódulos de software interconectados por meio de interfaces bem definidas

25 O Processo Unified zDirecionado por Casos de Uso ypropósito de um software é servir a seus usuários ylevantamento das necessidades dos usuários é feita por meio do levantamento de casos de uso zCasos de Uso ySequências de eventos envolvendo como protagonistas o usuário (ou usuários) e o sistema yCaptura dos requisitos por casos de uso substitui a tradicional captura de funcionalidades e atributos de um sistema yA captura dos casos de uso direciona todo o processo de desenvolvimento xespecificação de casos de uso xdesign de casos de usos xcasos de usos são implementados xcasos de uso são utilizados para desenvolver os testes

26 O Processo Unified zFocalizado na Arquitetura yarquitetura: plano conceitual antevendo a construção de um sistema ypermite um desenvolvimento lógico antes do desenvolvimento concreto yarquitetura é concebida em função das necessidades do usuário yinfluenciada por diversos fatores xplataforma de hardware, sistema operacional, protocolos de comunicações, outros softwares com os quais deve se integrar, módulos re-utilizáveis, considerações de distribuição, desempenho e confiabilidade ydefinição de uma arquitetura se realiza na definição de sub- sistemas que devem compor o sistema, os componentes, classes e objetos que os compõem

27 O Processo Unified zIterativo e Incremental yprevê um crescimento gradativo ao sistema ya cada iteração, novos casos de uso são agregados ao sistema, equipando-o com novas funcionalidades ou modificando as funcionalidades existentes zCiclo de Vida yConcepção, Elaboração, Construção, Transição zCada uma dessas fases ycorresponde a várias iterações, onde cada iteração deve passar pelas fases de especificação, análise, design, implementação e testes zDependendo da fase yênfase na especificação, análise, design, implementação ou testes pode variar

28 O Processo Unified

29 Desenvolvimento de Software Ágil zProcessos Ágeis de Desenvolvimento de Software yAgile Software Development Manifesto xIndivíduos e interações antes de processos e ferramentas xUm software funcionando, antes de uma documentação compreensiva xColaboração com o cliente, antes de uma negociação de contrato xResponder à necessidade de mudar, antes de seguir um plano zPor quê ? yUm software não é uma ponte nem uma casa yCusto de modelagem pode ser muito alto yRequisitos mudam constantemente yAdaptação pode ser uma estratégia melhor do que a predição yUm código documentado pode ser um modelo melhor do que um diagrama

30 XP - Extreme Programming http://www.extremeprogramming.org

31 XP – Extreme Programming zXP e o Processo Unified yProcesso Unified é um processo ágil ? zProcesso Unified é um Framework, não um processo yPode ser customizado para diferentes tipos de projetos yMínimo processo Unified ? xCasos de Usos e Diagramas de Classes zO Processo dX yRobert Martin - http://www.objectmentor.com/publications/RUPvsXP.pdf