TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS ANLISE

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula 6 14/08/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 1

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 14/08/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 2

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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 4

Principais Modelos de ciclo de vida Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 5

Principais Modelos de ciclo de vida - Continuação Ø Modelo Tradicional (Cascata) 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 6

Principais Modelos de ciclo de vida - Continuação Modelo Tradicional (Cascata) – Visão Pratica 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 7

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 8

Principais Modelos de ciclo de vida - Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 9

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 10

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 11

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 12

Principais Modelos de ciclo de vida - Continuação 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). 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 13

Principais Modelos de ciclo de vida - Continuação Ø 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 completamentendidos. Ø Permite gerência do baseline, que identifica um conjunto fixo de documentos produzidos ao longo do processo de desenvolvimento. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 14

Principais Modelos de ciclo de vida - Continuação Ø Espiral 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 15

Principais Modelos de ciclo de vida - Continuação Ø 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); 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 16

Principais Modelos de ciclo de vida - Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 17

Principais Modelos de ciclo de vida - Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 18

Principais Modelos de ciclo de vida - Continuação Ø 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” 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 19

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 20

Principais Modelos de ciclo de vida - Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 21

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 22

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 23

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 24

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 25

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 26

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 27

Principais Modelos de ciclo de vida - Continuação Ø Prototipação - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 28

Principais Modelos de ciclo de vida - Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 29

Principais Modelos de ciclo de vida - Continuação Ø 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 30

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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 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- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 37

RAD (Rapid Application Development) Ø É 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. 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 38

RAD (Rapid Application Development) - Continuação 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 39

RAD (Rapid Application Development) – Continuação Ø 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 07/02/2012 Professor Leomir J. Borba- professor. leomir@gmail. com –http: //professorleomir. wordpress. com 40

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