Análise e Projeto Orientado a Objetos filepreço, prazo, qualidade, complexidade... Mais de 30% dos...
Transcript of Análise e Projeto Orientado a Objetos filepreço, prazo, qualidade, complexidade... Mais de 30% dos...
Análise e Projeto Orientado a Objetos
Contextualizando
Por que Análise e Projeto?
Análise versus Projeto
Análise e Projeto OO
Processo de Desenvolvimento de Software
Alguns Processos de Desenvolvimento
Um pouco de engenharia de software...:◦ Softwares estão presentes em todas as áreas e a
socidade é cada vez mais dependente deles. Em bancos, empresas de telecom, pesquisas médicas, produções cinematográficas, exploração espacial, etc.
◦ Analistas e desenvolvedores sofrem pressão por preço, prazo, qualidade, complexidade...
◦ Mais de 30% dos projetos são cancelados (alguns já nascem fadados ao fracasso – projetos “marcha da morte”);
◦ Custos superam até 3 vezes o que foi orçado;◦ Cronogramas executados ultrapassam facilmente
100% em relação ao planejado ou linha de base.
Para pensar nos riscos...:◦ Software Construção de casa
Você deixaria um pedreiro construir uma casa, sem planta?
Em que tipo de casa isso seria aceitável?
◦ Software Instalação elétrica
Você levaria a um eletricista do “meio de rua”, um transformador, sem o desenho do circuito?
Em que tipo de transformador isso seria aceitável?
◦ Software, simplesmente
Você deixaria o primo do vizinho do seu tio implementar um software, só com uma conversa?
Em que tipo de software isso seria aceitável?
Um carro!
Um avião!
Uma casa!
Construir um software sem realizar análise e projeto, é como construir uma casa sem ter plantas estruturais, hidráulicas, elétricas, arquitetônicas...
Pode ser aceitável para certos tipos de software de complexidade e risco baixos;
Nos demais casos, análise e projeto são a base para a construção de um software, trazendo a segurança do que exatamente está especificado e o que será implementado;
Análise e projeto oferecem recursos para garantir que melhoramentos na descrição de um sistema preservam o comportamento e funcionalidade do mesmo.
A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito); É uma atividade investigativa e de levantamento;
O projeto/design enfatiza a proposta de uma solução que atenda ao identificado na análise(como pode ser feito); É uma atividade de criação.
A análise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar;
O projeto inclui as atividades que resultam em informação que interessa ao programador;
Em alguns casos (fortemente em MDD) o cliente estará interessado em artefatos de projeto.
Pode-se dizer que o resultado da análise é o enunciado do problema, e que o projeto será a sua resolução;
Problemas mal enunciados podem até ser resolvidos, mas a solução não corresponderá às expectativas;
Análise e projeto bem-feitos são importantes!
Um erro verificado na fase de análise tem um custo; na fase de projeto tem um custo maior; na fase de implementação maior ainda, e na fase de implantação do sistema tem um custo incalculável.
Custos de correção de software, de acordo com as fases do projeto em que são descobertos:
Um novo paradigma de análise e projeto;
A perspectiva empregada é da abstração de objetos (coisas, conceitos ou entidades), tanto na análise quanto no projeto;
A ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema e entender suas relações;
Por exemplo, num sistema de informação para uma locadora de DVDs, alguns dos conceitos são: Locadora, Funcionário, Cliente, Locação, DVD;
Tais objetos podem ter atributos (características) e responsabilidades.
Testando outros cenários...◦ Farmácia
◦ Biblioteca
◦ Controle de Estacionamento
Nestes 3 casos acima, o domínio do problema parece ser amplamente conhecido.
E nos cenários abaixo:◦ Financiamentos Bancários
◦ Processos Judiciais
◦ Meteorologia
◦ Fiscalização Fazendária
◦ Emissão de Passaportes
Exemplo da Biblioteca e seus objetos, com a visáodetalhada do objeto Livro (atributos e operações).
As abstrações do mundo real são objetos que correspondem às coisas do domínio do problema:◦ Pensar em objetos é mais natural do que pensar apenas em
funções;
Os objetos servem de instrumentos para comunicação e entendimento do software que será desenvolvido;
Promovem decomposição do problema, flexibilidade e reutilização;
As abstrações e suas decomposições podem ser representadas por uma linguagem visual chamada UML (a ser vista a diante).
DISCIPLINA!
Define atividades, papéis, artefatos e um fluxo que tem como objetivo padronizar o ciclo de vida de um projeto de desenvolvimento de software.
Quem, O que, Quando e Como Objetivo.
Normalmente o objetivo é: ◦ Evoluir um software existente;
◦ Implementar um novo software;
◦ Com qualidade!
Atividades de análise e projeto estão no contexto dos processos de desenvolvimento de software.
Metodologias ≠ Processos ≠ Modelagem
Metodologias de desenvolvimento:◦ Estruturada, Orientada a Objetos e Ágil
Processos de desenvolvimento:/ Frameworks◦ RAD, UP, RUP, Scrum, XP, MDD, Crystal, Lean
Modelagem de software◦ Análise essencial, Análise estruturada, UML
Mas, podemos dizer que:
Metodologias = Processos + Modelagem
Algumas consultorias, vendedores de ferramentas ou marqueteiros vendem qualquer processo, para qualquer empresa, como a SOLUÇÃO DE TODOS OS PROBLEMAS de (falta de) qualidade dos softwares ou projetos fracassados.
Ao contrário do que dizem os “torcedores”
(que são diferentes dos marqueteiros...):
Não existe A MELHOR metodologia ou processo;
Existe a escolha certa para o cenário certo, e para a realidade da empresa, das equipes e seus projeto;
Optar por uma metodologia e processo no ciclo de vida de um projeto de software, não é garantia de sucesso e objetivos atingidos;
Ferramentas de apoio ao processo não necessariamente direcionam um projeto ao seus objetivos.
O importante não é escolher um processo porquê este está “na moda” ou lhe garante um certificado.
Identificar objetivos para aderência a um processo;
Relacionar boas práticas e a melhor forma de trabalho;
Relacionar ferramentas de apoio;
Envolver as pessoas.
RUP – Rational Unified Process O RUP é um processo de desenvolvimento que
descreve:◦ O que deve ser executado (atividades e disciplinas);
◦ Quem deve executar (papéis);
◦ Qual resultado deve ser gerado (artefatos).
O RUP prevê o desenvolvimento de sistemas de modo iterativo-incremental;
Requisitos funcionais são tratados como casos de uso.
XP – Extreme Programming O XP (Extreme Programming) busca menos
burocracia, mais produtividade e redução de custos;
Quatro elementos principais:◦ Comunicação;◦ Simplicidade;◦ Feedback;◦ Coragem.
XP também prevê o desenvolvimento iterativo-incremental;
Requisitos extraídos de user stories.
Scrum Iterativo-incremental e empírico;
Processo ágil e simples (poucas “regras”), que pode vem sendo aplicado na execução de qualquer projeto, inclusive de natureza complexa e incerta;
Entregas rápidas (em sprints de duas a quatro semanas) e contínuas, com valor agregado de negócio e novas ou melhoradas funcionalidades;
Times de desenvolvimento pequenos e auto-gerenciáveis;
Requisitos compõem um backlog do produto.
Outros...◦ Cleanroom - Processo estruturado “pesado”◦ RAD – Processo baseado em prototipagem “leve”◦ Kanban – Processo “mais-ágil”
Lembrando: não há processo ideal, há o melhor processo para uma realidade de projeto de software. Não existem “balas-de-prata” no desenvolvimento de software (termo de Fred Brooks em seu clássico The Mythical Man-Month).
Frederick Brooks
Robert Glass
Ed Yourdon - Death March
RUP
XP
Scrum das Trincheiras
Atribuição-Uso Não-Comercial 2.5 Brasil