Engenharia de Software

Processos de Software Sequencial Linear (cascata). Prototipagem. RAD. Modelos Evolucionrios. Engenharia de Software baseada em componentes. Processo Unificado. Programao Extrema (XP). Scrum, Kanban.

Modelo em cascata Maior organizao baixa adaptabilidade Prototipagem Ferramenta de auxilio a levantamento de requisitos Cliente acredita que o prottipo o software final Rad Exige muito RH para criar a equipe RAD Modelos evolucionrios Iterao

Espiral

Aps criarmos o ncleo com as funcionalidades mais importantes expandimos o ncleo com novos mdulos e para cada incremento temos um plano

Modelo espiral se preocupa em preparar o software para o ps termino de projeto, Modelo espiral se preocupa com os riscos do projeto

Engenharia de Software baseada em componentes

(CBSE Surgiu provocada pelo advento da orientao de objetos a partir do momento que eu tenho uma classe esta classe quando eu istncio ela como objeto em certos momentos eu consigo encarala como algo reaproveitvel .)

CBSE Component-Based Software Engineering).

Apoiada pela orientao a objetos. Classes se adequadamente projetadas e implementadas, so reusveis ao longo de diferentes aplicaes e arquiteturas de sistemas baseados em computadores.

(A CBSE tem como base o reaproveitamento de componentes.)

(As classes quando desenvolvidas para um determinado sistema poderia ser reutilizada mas era extremamente especializada, Com um nvel de detalhamento especfico muito alto. E quando falamos de componentes pensamos em um repositrio(ba) repleto de componentes onde eu coloco a mo e seleciono um componente e fao uso dele Ento se eu tiver um componente colado com milhares de outros componentes ele invivel, no ter utilidade . Ento foi isso que aconteceu com o advento da OO,no se conseguia desacoplar estes componentes quando estava caracterizado como classe.)

Final da dcada de 90 como frustrao dos projetistas quanto ao OO no conduzir ao reuso amplo. (detalhamento e classes demasiado).

Engenharia de Software baseada em componentes Incorpora muitas das caractersticas do modelo espiral evolucionrio.
(modelo espiral evolucionrio = modelo espiral) (Eu tenho componentes disponveis e voc tem necessidades de negcios a ser atendida eu preciso pegar toda a sua necessidade de negcio entender e depois sair montando um mosaico de componentes e te entregar isso no final??? no!!!! O que posso fazer neste momento? posso dividir uma fatia de sua rea de negocio que possa ser atendida neste primeiro momento de acordo com componentes que j sei que existem na minha empresa ento irei atender esta faixa de negocio que mais prioritria em seguida iremos avaliar os riscos para uma evoluo )

Compe a aplicao de software a partir de componentes de software previamente preparados.

(basicamente pegamos esta necessidade de negocio, trabalhamos esta necessidade de negocio priorizando o que ser melhor atendido junto ao cliente concludo esta parte nos voltamos para o ba e analisados para esta determinada necessidade ser atendida por este componente, esta outra necessidade ser atendida por este componente, a prxima necessidade ser atendida por este componente at que um certo momento no ter nenhum componente feito para atender uma determinada necessidade, esta necessidade ter de ser desenvolvida e como este modelo baseado em OO este componente ser desenvolvido com a conceituao do OO)

Processo de definio, implementao e integrao ou composio de componentes independentes, no firmemente acoplados ao sistema.

(Um componente no uma classe)

Engenharia de Software baseada em componentes Um componente uma unidade de composio com interfaces contratualmente especificadas e dependncias de contexto explcitas somente. Um componente de software pode ser implantado independentemente e est sujeito composio por terceiros. (Szyperski, 2002).
(Basicamente a parte externa sistema foram pr definidas e o contesto interno do sistema invisvel para quem usa.

Componente: Entidade executvel independente. Seus servios esto disponveis por meio de uma interface, por onde todas as suas interaes ocorrem.

Engenharia de Software baseada em componentes Caractersticas de um componente: Padronizado.(deve seguir um padro) Independente. (no depende de outros componentes para trabalhar) Passvel de composio.(deve trabalhar com outros componentes) Implantvel. (tem de ser auto executvel) Documentado. (o componente deve estar documentado) Interfaces de um componente: Requires: quais servios devem ser fornecidos por outros componentes do sistema. Provides: servio fornecido pelo componente.

Engenharia de Software baseada em componentes

Engenharia de Software baseada em componentes Pontos essenciais: Componentes independentes completamente especificados por suas interfaces. Padres de componentes que facilitam a integrao de componentes. Middleware que fornece apoio de software para integrao de componentes.
(Middleware um software que faz um inter relacionamento entre vrias aplicaes)

Processo de desenvolvimento voltado engenharia de software baseada em componentes.

(basicamente pegamos esta necessidade de negocio, identificamos os componentes a serem usados e implantamos estes componentes)

Engenharia de Software baseada em componentes Componentes X OO: Componentes so entidades implantveis. Componentes no definem tipos. Componentes so independentes de linguagem. Componentes so padronizados. Modelos de componentes:

COM+. EJB. CORBA.

Engenharia de Software baseada em componentes O fato de um componente ser reusvel depende de seu domnio de aplicao e funcionalidade. Quanto mais genrico, mais reusvel um componente. Reusabilidade X usabilidade.
Quanto mais aumento a reusabilidade mais diminuo a usabilidade especfica do sistema

Processos de CBSE.

Engenharia de Software baseada em componentes Processo de identificao de componente.

Engenharia de Software baseada em componentes A primeira iterao ser composta pelos componentes extrados da biblioteca e novos componentes construdos. O fluxo volta para ao espiral e tudo se repete. Tem como palavra chave o reuso. Reduz em at 70% a montagem de componentes. Reduz em at 84% o custo do projeto. Podemos dizer que o Processo Unificado foi originado da Engenharia de Software baseada em componentes.

Engenharia de software

Processo Unificado Rational Unified Process - RUP Podemos dizer que o PU foi originado da Engenharia de Software baseada em componentes.
idealizando o seguinte um processo que contivesse internamente tanto a conceituao da iteratividade quanto de um processo incremental. O PU trouxe a idia da componentizao para dentro do desenvolvimento de um processo, no em um conceito CBSE. Para que se tivesse as coisas acontecendo dentro de um ciclo de desenvolvimento iterativo e incremental. Iterativo porque o PU ir realizar as entregas iterao por iterao e quando chegar no final do projeto ter todo software desenvolvido. Incremental pela adapdabilidade do processo e das boas prticas aplicveis ao desenvolvimento. )
(A CBSE tem como premissa o reuso de componentes, PU levou a idia adiante

Processo Unificado Rational Unified Process - RUP (Resumindo eu te entrego o sistema de forma iterativa pedacinho por pedacinho
enquanto de forma que no final voc ter seu software completo enquanto eu dentro do meu processo de desenvolvimento de software realizo de maneira incremental a melhoria do processo para que no final eu consiga atender a demanda registrada por voc. ) (O PU consegue na natureza do processo transformar um grande sistema em pequenos sistemas, pequenas entregas.) (O PU tem um grande foco no desenvolvimento baseado em O.O)

O RUP um modelo derivado do UML e do PU.

(Processo Unificado no Rational Unified Process, muitos estudiosos e bancas avaliadoras consideram RUP e PU como a mesma coisa por que o RUP foi totalmente baseado em PU, basicamente podemos dizer que o RUP a unio entre o PU e a UML)

Processo Unificado Rational Unified Process - RUP Trata-se de um modelo hbrido. Traz elementos de todos os modelos genricos. Apia a iterao. Ilustra boas prticas de especificao e projeto
(Alinha os processos de software com as regras de negocio) (Nos primeiros processos de software basicamente seguamos fases etapas, mas tnhamos uma necessidade crescente do alinhamento da maneira como era realizado os processos de software com as regras de negocio, e o que aconteceu quando comeamos a falar de processos de software modernos Processos a partir de CBSE e que com quando comeo a me preocupar em ter componentes independentes, componentes que no se acoplem diretamente a sistema, componentes reutilizveis estou me preocupando com as regras de negocio. ) (Se eu tirar um componente de dentro do sistema eu posso dizer que identifiquei uma caracterstica de uma regra de negocio que comum a vrias reas. )

Processo Unificado Rational Unified Process - RUP Descrito a partir de trs perspectivas: Dinmica fases do modelo ao longo do tempo. Esttica atividades realizadas no processo. Prtica boas prticas a serem usadas durante o processo.

Processo Unificado Rational Unified Process RUP Viso dinmica Modelo constitudo por 4 fases discretas: Concepo: estabelecer um business case para o sistema. Avaliao do ambiente de negcio em relao contribuio de um sistema para o negcio. (escopo) Elaborao: desenvolver um entendimento do domnio do problema, estabelecer um framework, desenvolver um plano de projeto e identificar os riscos principais do projeto. (modelo de requisitos para o sistema, arquitetura, planejamento).

Processo Unificado Rational Unified Process RUP Viso dinmica Modelo constitudo por 4 fases discretas: Construo: relacionada ao projeto, programao e teste de sistema. As partes so desenvolvidas separadamente e integradas. Software funcional documentao. (desenvolvimento) Transio: fase final do RUP. Transferncia do desenvolvimento para o usurio. Entrada do sistema em produo. Fase onerosa e problemtica. (implantao).

Processo Unificado Rational Unified Process RUP Cada fase pode ser realizada de forma iterativa, com resultados desenvolvidos incrementalmente. O conjunto total de fases pode ser realizado de forma incremental.

(Em negrito se encontra as disciplinas principais as 3 restantes so auxiliares. As disciplinas principais se caracterizam pela identificao de algo que esta acontecendo dentro do projeto em compensao as auxiliares acompanham todo andamento do projeto )

Processo Unificado Rational Unified Process RUP Viso esttica do RUP (as Disciplinas):

Modelagem de negcios: processos de negcio so modelados usando casos de uso de negcios. Requisitos: agentes que interagem com o sistemas so identificados e os UCs so desenvolvidos para modelar os requisitos de sistema. Anlise e projeto: modelo de projeto criado e documentado usando modelos de arquitetura,modelos de componente,modelos de objeto e modelos de seqncia. Implementao: componentes de sistema so implementados e estruturados em subsistemas de implementao.

Processo Unificado Rational Unified Process RUP Viso esttica do RUP (as Disciplinas): Teste: processo iterativo realizado em conjunto com a implementao. Implantao: verso do produto criada, distribuda aos usurios e instalada. Gerenciamento de configurao e mudanas: gerencia as mudanas do sistema.(mudanas que ocorrem no decorrer do projeto) Gerenciamento de projetos: gerencia o desenvolvimento do sistema.(acompanha desde o inicio do projeto at o final) Ambiente: est relacionado disponibilizao de ferramentas apropriadas de software para a equipe de desenvolvimento.(a cada iterao de construo dever ser reavaliado)

Processo Unificado Rational Unified Process RUP Viso prtica

O RUP recomenda 6 melhores prticas fundamentais
(linhas mestras):

Desenvolver o software iterativamente: incrementos de software priorizados e entregues.(Dividir o software em pedaos priorizando a entrega das partes mais
complexas)

Gerenciar requisitos: documentao e acompanhamento das mudanas dos requisitos.(gerenciar os requisitos trazendo menor impacto para o projeto) Usar arquiteturas baseadas em componentes: estruturar a arquitetura de sistema de componentes.(trazer os componentes para a interao) Modelar o software visualmente: modelos grficos UML.(representar
graficamente atravs de padres)

Verificar a qualidade do software: atendam aos padres de qualidade da organizao. (atravs da analise inicial temos os padres da empresa) Controlar as mudanas do software: usando um SGM Sistema de gerenciamento de mudanas e procedimentos.

Processo Unificado Rational Unified Process - RUP

Engenharia de Software

Processos de Software Sequencial Linear (cascata). Prototipagem. RAD. Modelos Evolucionrios. Engenharia de Software baseada em componentes. Processo Unificado. Programao Extrema (XP). Scrum, Kanban.

Manifesto Overhead dominando o processo de software.

(overhead geralmente considerado qualquer processamento ou armazenamento em excesso) (Escopo quer dizer aquilo que se pretende atingir) (Tnhamos processos de softwares bem maduros que atendiam desde desenvolvimento para fabricas at controles gerenciais de empresas, um Processo que atende uma empresa provavelmente no se encaixara em um sistema de automatizao de um avio. Alguns pensadores descobriram que esta mesma aplicabilidade de processos dentro de alguns softwares como softwares sem escopo bem definido no inicio, software que sofrem mudanas no meio do projeto causavam grandes atrasos e perda de foco principal do projeto)

Inicio da dcada de 90 alguns desenvolvedores se manifestaram sobre a realidade encontrada no desenvolvimento de software de pequeno porte. Manifesto gil e declarao de interdependncia. 2001 no Resort Snowbird, em Utah para seu rascunho (www.agilemanifesto.org).

Manifesto Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a faz-lo. Ao longo deste trabalho, comeamos a valoriza: Indivduos e interaes em vez de processos e ferramentas. Software funcional em vez de documentao extensiva. Colaborao com o cliente em vez de negociao de contrato. Resposta mudana em vez de seguimento de um plano. Ou seja, mesmo havendo valor nos itens da direita, valorizamos mais os itens da esquerda.

Manifesto Kent Beck, Mike Beedel, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martim Fowler, James Grenning, Jim Highsmith, Andrew Hung, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Scwaber, Jeff Sutherland, Dave Thomas.

Manifesto Doze princpios do manifesto gil. Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua de software de valor. Aceitar mudanas de requisitos,mesmo no fim do desenvolvimento. Processos geis se adquam a mudanas, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqncia, na escala de semanas at meses, com preferncia aos perodos mais curtos. Pessoas relacionadas negcios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Manifesto Doze princpios do manifesto gil. Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e suporte necessrio, e confiar que faro seu trabalho. O Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um time de desenvolvimento, atravs de uma conversa cara a cara. Software funcional a medida primria de progresso. Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolvedores e usurios, devem ser capazes de manter indefinidamente, passos constantes. Contnua ateno excelncia tcnica e bom design, aumenta a agilidade.

Manifesto Doze princpios do manifesto gil. Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times autoorganizveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, ento, se ajustam e otimizam seu comportamento de acordo.

Declarao de Independncia DOI

(Manifesto feito por desenvolvedores foco no operacional declarao feito por gerentes e lideres de projetos foco no gerencial)

Elaborada em 2005. Foco na Gesto de Projetos geis. Somos uma comunidade de lderes de projeto que tem sido altamente bem-sucedida em entregar resultados. Para alcana tais resultados: Aumentamos o retorno do investimento, tornando o fluxo contnuo de valor o nosso foco. Entregamos resultados confiveis, engajando os clientes em interaes freqentes e propriedade compartilhada. Esperamos incertezas e gerenciamos levando-as em conta, por meio de iteraes, antecipao e adaptao.

Declarao de Independncia - DOI Promovemos criatividade e inovao reconhecendo que os indivduos so a fonte ltima de valor e criamos um ambiente em que eles fazem a diferena. Impulsionamos o desempenho por meio do compromisso do grupo em obter resultados e da responsabilidade compartilhada pela eficcia do grupo. Melhoramos a eficcia e a confiabilidade por maio de estratgias situacionais especficas, processos e prticas.

Necessidades que levaram aos mtodos geis Negcio atual extremamente voltado a mudanas e surgimento de servios concorrentes. Impossvel ento gerar requisito completos e estveis de um software. Os processos tradicionais no esto voltados ao desenvolvimento de software. Para sistemas de negcios especficos, processos de desenvolvimento voltados para o desenvolvimento e entrega rpidos so essenciais.

Processos de desenvolvimento rpido

Projetados

para criar software til rapidamente. Em geral so iterativos nos quais a especificao, o projeto, o desenvolvimento e o teste so intercalados. Processos de especificao, projeto e implementao so concorrentes. Documentao mnima (necessria) gerada pelo ambiente de programao.

(Agilidade no rapidez Mtodos geis no significam mtodos rpidos Significa dinmico entregar algo til no menor tempo possvel)

Processos de desenvolvimento rpido Documento de requisitos define somente as caractersticas mais importantes do sistema. Sistema desenvolvido em uma srie e incrementos. Usurios finais e Stakeholders da especificao e avaliao dos incrementos.
(stakeholter = parte interessada )

Podem propor alteraes e novos requisitos para um prximo incremento. Interfaces desenvolvidas utilizando um sistema de desenvolvimento interativo.

Processos de desenvolvimento rpido Vantagens: Entrega acelerada dos servios ao cliente. Engajamento do usurio com o sistema (envolvimento). Problemas na implantao: Problemas de gerenciamento (mudanas rpidas, ausncia de
documentao, tecnologias no conhecidas).

Problemas de contrato (preo fixo?). Problemas de validao (TDD test drive develop desenvolvimento
voltado a testes).

Problemas de manuteno.

Engenharia de Software

Processos de desenvolvimento rpido

(prototipagem analise de requisitos / protodipao evolucionaria desenvolvimento de software incremental)

Prototipao evolucionria: sinnimo de desenvolvimento de software incremental e neste caso o prottipo no descartado, mas sim desenvolvido para atender aos requisitos do cliente. Metodos

Comum:Inicia pelos requisitos mais bem compreendidos e com a prioridade mais alta. (vagos e baixa prioridade fica pra depois). Throw-away: comea com requisitos no muito bem compreendidos para saber mais sobre eles, requisitos simples talvez nunca sejam implementados.

Processos de desenvolvimento rpido Seus implementadores enfatizam tanto sua utilizao que as vezes esquecem de suas desvantagens: Envolvimento com o cliente (cad ele?). Membros da equipe podem no interagir bem com outros membros da equipe. Priorizao de mudanas pode ser bem difcil, principalmente onde existem muitos Stakeholders. Manter a simplicidade requer trabalho extra.

Extreme Programming - Caractersticas Foi durante um bom tempo a ferramenta gil mais conhecida do mercado. Tem seu nome do desenvolvimento iterativo e envolvimento extremo do cliente. Todos os seus requisitos so expressos como cenrios (histrias de usurios) e so implementados diretamente como uma srie de tarefas. Os programadores trabalham em pares. Testes so desenvolvidos antes da escrita do cdigo. Todos os testes executados com sucesso quando um novo cdigo integrado ao sistema.

Extreme ProgrammingCaractersticas Pequeno espao de tempo entre as releases do sistema que apia assim o desenvolvimento incremental. Envolvimento do cliente apoiado pelo engajamento em tempo integral deste na equipe do desenvolvimento sendo responsvel pela definio de teste de aceitao do sistema.(analogia do taxi) Dentro da trplice restrio ele est focado no escopo.(Escopo, tempo e custo)

Extreme ProgrammingPrincpios

Feedback rpido(respostas rpidas a problemas)

Presumir simplicidade Mudanas incrementais(qualquer mudana deve trazer novos
incrementos ao sistema)

Abraar mudanas Trabalho de alta qualidade.

Extreme ProgrammingValores Comunicao. Simplicidade.

Feedback.
Coragem. Respeito.

Extreme ProgrammingPrticas Jogo de planejamento.(reunio com o cliente onde elabora-se uma

historia que descrevem cada funcionbilidade desejada , Programadores as implementa ,tambm se define prazos e prioridades) um incremento no software)

Planejamento incremental. (A cada entrega ao cliente estou fazendo

Pequenas verses (menores ainda que no RUP). Metfora.(Evitar termos tcnicos em reunies) Projeto Simples (no confundir com projeto fcil). Time coeso (pessoas engajadas e multidisciplinar). Testes de aceitao/Cliente on-site.(analogia do taxi) Ritmo sustentvel (trabalho motivado e hora extra quando trouxer vantagens). Reunies em p.(reunies curtas para tratar de temas especficos)

Extreme ProgrammingPrticas Posse coletiva (o cdigo no tem dono). Programao em pares. Padres de codificao. Desenvolvimento orientado a testes. (TDD, Test-first) Refatorao.(Recriao do cdigo constate para melhoria continua) Integrao contnua.

Extreme ProgrammingCarto de Histria

( um documento que traz uma viso descritiva de como as coisas devem acontecer , o que o cliente espera que seja realizado qual a funcionabilidade que seja entregue a ele em um momento especifico dentro do sistema. Ele substitui o caso de uso)

Template de Carto de Historia

Como um [usurio papel], quero [meta], para que eu possa [motivo].

(Como um Administrador do sistema quero acessar o sistema de forma completa para que eu possa administrar o sistema da forma correta. Como um Estagirio do sistema quero visualizar os contratos para que eu possa analiza-los e emitir o meu parecer)

Aps a sua definio, a equipe de desenvolvimento dever dividi-lo em tarefas e estimar o esforo e os recursos necessrios para implementao. Plainning poker. (Tcnica para medir nveis de complexidade) O cliente prioriza as histrias para implementao. Mudana sem histrias no implementadas podem gerar alteraes ou descarte.

Extreme Programming Abordagem Extrema Novas verses podem se compiladas vrias vezes por dia. Incrementos so entregues aproximadamente a cada duas semanas. Quando o desenvolvedor compila o sistema para criar uma nova verso, ele deve executar todos os testes automatizados existentes e os testes para a nova funcionalidade.

Extreme Programming - Testes O processo de testes dentro do XP mais enfatizado que em outros mtodos geis. Caractersticas: TDD Test Driven Development (test-firt): define tanto uma interface quanto um comportamento para a funcionalidade. (entrada, testes, sada). Desenvolvimento incremental de teste a partir de cenrios. Envolvimento do usurio no desenvolvimento e validao de testes. O uso de ferramentas de teste automatizadas: teste escrito como um componente executvel antes do cdigo. Deve possibilitar a entrada e verificar se a sada atende.