410 likes | 566 Views
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula 6. 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)
E N D
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMASANÁLISE E PROJETO DE SISTEMASAula 6 14/08/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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
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
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
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
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
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
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
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
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
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 errose 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
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
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
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 desenvolvimentode 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. 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Espiral 15 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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); 16 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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 17 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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 18 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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” 19 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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. 20 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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 21 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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. 22 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 23 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 24 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 25 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 26 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 27 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Principais Modelos de ciclo de vida - Continuação • Prototipação - Continuação 28 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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 29 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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. 30 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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
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
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
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
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
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
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
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. 38 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
RAD (Rapid Application Development) - Continuação 39 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
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 40 07/02/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com
Bibliografia 14/08/2012 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com