TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula /08/2012 Professor Leomir J. Borba- –

Agenda  Processo de desenvolvimento de software e ciclo de vida de software.  Processo de desenvolvimento de software  Os principais modelos de ciclo de vida  Modelo tradicional (Cascata)  Modelo Espiral  Modelo de prototipação  Modelo Iterativo e Incremental  Processo Unificado – RUP  Rapid Application Development RAD  Bibliografia 2 14/08/2012 Professor Leomir J. Borba- –

Processo de desenvolvimento de software e ciclo de vida de software.  Existem vários modelos de processo de software (ou paradigmas de engenharia de software)  Cada um representa uma tentativa de colocar ordem em uma atividade inerentemente caótica 07/02/2012 Professor Leomir J. Borba- – 3

Processo de desenvolvimento de software e ciclo de vida de software. - Continuação  Levantamento de requisitos  Analise  Projeto  Desenho (Padua Filho, Wilson de, 2009)  Implementção  Testes  Manutenção 07/02/2012 Professor Leomir J. Borba- – 4

Principais Modelos de ciclo de vida 07/02/2012 Professor Leomir J. Borba- – 5  Modelo Tradicional (Cascata) – Continuação  Mais antigo e o mais amplamente usado da engenharia de software  Modelado em função do ciclo da engenharia convencional  Requer uma abordagem sistemática, seqüencial ao desenvolvimento de software o resultado de uma fase se constitui na entrada da outra

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 6  Modelo Tradicional (Cascata)

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 7 Modelo Tradicional (Cascata) – Visão Pratica

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 8  Modelo Tradicional (Cascata) – Ponto a ponto  Exploração de Conceitos / Informação e Modelagem  Envolve a elicitação de requisitos do sistema, com uma pequena quantidade de projeto e análise de alto nível;  Preocupa-se com aquilo que conhecemos como engenharia progressiva de produto de software;  Iniciar com um modelo conceitual de alto nível para um sistema e prosseguir com o projeto, implementação e teste do modelo físico do sistema.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 9  Modelo Tradicional (Cascata) – Ponto a ponto  Análise de Requisitos de Software  O processo de elicitação dos requisitos é intensificado e concentrado especificamente no software  Deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos os requisitos (para o sistema e para o software) são documentados e revistos com o cliente

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 10  Modelo Tradicional (Cascata) – Ponto a ponto  Projeto  Tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação inicie  Implementação  Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador e implementado num ambiente de trabalho.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 11  Modelo Tradicional (Cascata) – Ponto a ponto  Testes  Concentra-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 12  Modelo Tradicional (Cascata) – Ponto a ponto  Manutenção  Provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente  Causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 13 Modelo Tradicional (Cascata) - Analise  Problemas com o Modelo em Cascata  Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe  Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural  O cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento (na instalação);  Difícil identificação de sistemas legados (não acomoda a engenharia reversa).

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 14  Modelo Tradicional (Cascata) – Considerações  O Modelo de processo em Cascata trouxe contribuições importantes para o processo de desenvolvimento de software:  Imposição de disciplina, planejamento e gerênciamento  Implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos.  Permite gerência do baseline, que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 15  Espiral

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 16  Espiral – Continuação  O Modelo Espiral (Boehm, 1986)  O modelo espiral acopla a natureza iterativa da prototipação com os aspectos controlados e sistemáticos do modelo cascata.  O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa.  Existem tipicamente de 3 a 6 regiões de tarefa.  Combina as características positivas da gerência baseline (documentos associados ao processo);

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 17  Espiral – Continuação  Cada ciclo na espiral representa uma fase do processo de software.  O ciclo mais interno esta concentrado nas possibilidades do sistema  O próximo ciclo está concentrado na definição dos requisitos do sistema  O ciclo um pouco mais externo está concentrado no projeto do sistema  Um ciclo ainda mais externo está concentrado na construção do sistema

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 18  Espiral – Continuação  Não existem fases fixas no modelo as fases mostradas na figura são meramente exemplos a gerência decide como estruturar o projeto em fases  Estabelecimento de Objetivos  São definidos objetivos específicos para a fase do projeto  São identificadas restrições sobre o processo e o produto é projetado.  Um plano de gerenciamento detalhado é criado  São identificados riscos do projeto dependendo dos riscos, estratégias alternativas podem ser planejadas

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 19  Espiral – Continuação  Avaliação e Redução de riscos  Para cada um dos riscos identificados, uma análise detalhada é executada.  Passos são tomados para reduzir o risco  Desenvolvimento e validação  Depois da avaliação do risco, um modelo de desenvol;vimento é escolhido para o sistema.  Planejamento  O projeto é revisto e é tomada uma decisão de continuidade se é decidido continuar, são projetados planos para a próxima fase do projeto ou próximo “loop”

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 20  Espiral – Continuação  Engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento, a Análise de Risco  Segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real.  Usa a Prototipação em todas as etapas da evolução do produto, como mecanismo de redução de riscos.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 21  Espiral – Considerações  É, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.  Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.  Pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável.  Exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso.  O modelo é relativamente novo e não tem sido amplamente usado. Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 22  Prototipação  O objetivo é entender os requisitos do usuário e, assim, obter uma melhor definição dos requisitos do sistema.  Possibilita que o desenvolvedor crie um modelo (protótipo)do software que deve ser construído apropriado para quando o cliente ainda não definiu detalhadamente os requisitos.

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 23  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 24  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 25  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 26  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 27  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 28  Prototipação - Continuação

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 29  Prototipação – Continuação  Problemas  Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo.  Desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo

Principais Modelos de ciclo de vida - Continuação 07/02/2012 Professor Leomir J. Borba- – 30  Prototipação – Continuação  Considerações  Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente.  A chave é definir as regras do jogo logo no começo.  O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo para definir os requisitos.

Processo Unificado – RUP  Técnica Unified Process  Proposto por Grady Booch, James Raunbaugh e Ivar Jacobson  Fortemente associada a notação UML  Se baseia em tres valores  Dirigido por estudos de caso  Centrado na arquitetura  É iterativo e incremental  RUP – Rational Unified process  Implementação mais conhecida do UP (Krutchen, 2003)  Atualmente IRUP - IBM  UML – Unified Modeling Language  UML Não é linguagem de programação mas sim de modelagem  Padrão mundial da industria de engenharia de software. 07/02/2012 Professor Leomir J. Borba- – 31

Processo Unificado – RUP  Técnica Unified Process - continuação  Não é uma série especidica de etapas que se forem seguidas resultaram na construção de um produto de Software.  Deve ser encarado como uma metodologia adaptativa, que pode ser modificada para o produto de software especifico a ser desenvolvido.  Apesar de alguns recursos não poderem ser aplicados a software de pequeno e médio porte, grande parte é utliza 07/02/2012 Professor Leomir J. Borba- – 32

Processo Unificado – RUP  Linhas mestras :  Gestão de requisitos  Uma documentação apropriada é essencial para qualquer grande projeto; RUP descreve como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.  Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, considerados muito mais eficazes na captura de requisitos funcionais. 07/02/2012 Professor Leomir J. Borba- – 33

Processo Unificado – RUP  Linhas mestras :  Uso de arquitetura baseada em componentes  A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na programação orientada a objetos.  O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala. 07/02/2012 Professor Leomir J. Borba- – 34

Processo Unificado – RUP  Linhas mestras :  Uso de software de modelos visuais  Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução.  O uso de modelos visuais também pode permitir que indivíduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.  A linguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP 07/02/2012 Professor Leomir J. Borba- – 35

Processo Unificado – RUP  Linhas mestras :  Verificação da qualidade do software  Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento.  O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento. 07/02/2012 Professor Leomir J. Borba- – 36

Processo Unificado – RUP  Linhas mestras :  Gestão e Controle de Mudanças do Software  Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto.  O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema. 07/02/2012 Professor Leomir J. Borba- – 37

RAD (Rapid Application Development) 07/02/2012 Professor Leomir J. Borba- – 38  É um modelo sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto  O desenvolvimento rápido é obtido usando uma abordagem de construção baseada em componentes.  Os requisitos devem ser bem entendidos e o  alcance do projeto restrito  Esse modelo é usado principalmente para aplicações de sistema de informação.  Cada função principal pode ser direcionada para uma equipe RAD separada e então integrada para formar o todo.

RAD (Rapid Application Development) - Continuação 07/02/2012 Professor Leomir J. Borba- – 39

RAD (Rapid Application Development) – Continuação 07/02/2012 Professor Leomir J. Borba- – 40  Desvantagens  Exige recursos humanos suficientes para todas as equipes  Exige que desenvolvedores e clientes estejam comprometidos com as atividades de “relampago” a fim de terminar o projeto num prazo curto  Nem todos os tipos de aplicação são apropriadas para o RAD:  Deve ser possível a modularização efetiva da aplicação  Se alto desempenho é uma característica e o desempenho é obtido sintonizando as interfaces dos componentes do sistema, a abordagem RAD pode não funcionar

Bibliografia 14/08/2012 Professor Leomir J. Borba- – 41 BIBLIOGRAFIA BÁSICA 1 ARAUJO, L. LIMA. C. A. UML Aplicada – Da teoria à implementação. 1ª Ed. Rio de Janeiro: Ciência Moderna, LARMAN, Craig. Utilizando UML e Padrões. 3ª Edição. Porto Alegre: Bookman, MELO, Ana Cristina. Desenvolvendo Aplicações com UML ª Edição. São Paulo: Brasport, BIBLIOGRAFIA COMPLEMENTAR 1 PAULA FILHO, W. P. Engenharia de Software. Rio de Janeiro: LTC TONSIG. S. L. Engenharia de Software – Análise e Projeto de Sistemas. 2ª Edição. Rio de Janeiro: Ciência Moderna, Mike Cohn. Desenvolvimento de software com Scrum - Aplicando métodos ágeis com sucesso. 1 Bookman 2011 ISBN / Eudes Diônatas Silva Souza(11720) 4 Pressman, Roger S., Engenharia de Software: Uma Abordagem Profissional ”, 7ª edição, Ed. McGraw-Hill, ISBN , Martin Fowler. Refatoração - Aperfeiçoando o Projeto de Código Existente, Bookman Companhia Ed ISBN Gamma; Helm; Johson; Vlissides. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos. Bookman, ISBN: