Estudo de Viabilidade> Estudo que indica se o esforo em desenvolver a idia vale a pena * Visa tanto a tomada de deciso *Como

a sugesto de

possveis alternativas de soluo. # Deve oferecer informaes para ajudar na deciso * Se o projeto pode ou no ser feito *Se o produto final ir ou no beneficiar os usurios interessados *Escolha das alternativas entre as possveis solues *H uma melhor alternativa? #O Que Estudar? *Sistema organizacional apresentado *Usurios, polticas, funes, objetivos, etc. *Problemas com o sistema apresentado *Inconsistncias, funcionalidades inadequadas, performance, etc. *Objetivos e outros requisitos para o novo sistema *O que precisa mudar? *Restries *Incluindo requisitos no-funcionais do sistema (superficialmente) *Alternativas possveis *Sistema atual geralmente uma das alternativas *Vantagens e desvantagens das alternativas. #Testes de Viabilidade *Operacional *Medida do grau de adequao da soluo para a organizao *Avaliao de como as pessoas se sentem sobre o sistema/projeto *Tcnica *Avaliao da praticidade de uma soluo tcnica especfica e a disponibilidade dos recursos tcnicos e dos especialistas Cronograma * Avaliao de quo razovel est o cronograma do projeto *Econmica * Avaliao de custo-eficincia de um projeto ou soluo *Conhecida como anlise de custo/benefcio #Viabilidade Operacional *Avalia a urgncia do problema (viso e fases de estudo) ou a aceitao da soluo (definio, seleo, aquisio, e fases do projeto) *H dois aspectos da viabilidade operacional a serem considerados *O problema vale a pena ser resolvido ou a soluo proposta para o problema funcionar? *Como o usurio final e a gerncia sentem-se sobre o problema (soluo)? #Viabilidade Tcnica *A soluo ou a tecnologia proposta prtica? *J possumos a tecnologia necessria? *J possumos o conhecimento tcnico necessrio? #Viabilidade de Cronograma *Dado nosso conhecimento tcnico, os prazos dos projetos so razoveis? *Alguns projetos so iniciados com prazos especficos *Voc precisa determinar se os prazos so obrigatrios ou desejveis *Se so mais desejveis que obrigatrios, o analista pode propor outros cronogramas. #Viabilidade Econmica *Talvez a mais crtica *Durante as fases iniciais do projeto, a anlise da viabilidade econmica consiste em julgar se os possveis benefcios de solucionar o problema so ou no vantajosos *To logo os requisitos especficos e solues sejam identificados, o analista pode levar em considerao os custos e benefcios de cada alternativa *Isso chamado de anlise de custobenefcio #Tipos de Custos *Custos de desenvolvimento de sistemas *Desenvolvimento e aquisio *Custos de instalao e de converso *Custos operacionais (contnuo) *Manuteno *Pessoal #Anlise Custo-Benefcio *H trs tcnicas principais *Anlise do retorno financeiro (payback analysis) *Retorno do investimento (return on investments) *Valor atual lquido (Net present value) #Anlise de Retorno do Investimento *A tcnica de anlise de retorno do investimento (ROI) compara os benefcios das diferentes solues ou projetos *O ROI para uma soluo ou projeto a taxa percentual que mede a relao entre a quantia que a empresa obtm de retorno ao seu investimento e a quantia investida *O ROI para uma soluo ou projeto potencial calculado como a seguir: (ROI = (Benefcios totais - Custos totais) / Custos totais) *(ROI = valor atual lquido / Custos totais) *Ex: ROI = (22508,6417321,20)/ 17321,20= 29,95% *EX: ROI = 5187,44/ 17321,20 = 29,95% *A soluo que oferecer o ROI mais alto a melhor alternativa #Matriz de Viabilidade *Como ns comparamos alternativas quando existem vrios critrios de seleo e nenhuma das alternativas superior em todos os aspectos? *Use uma Matriz de Anlise de Viabilidade! #Documento de Viabilidade *Aps o esforo inicial, discutido anteriormente, deve-se elaborar um relatrio de viabilidade *Para cada aspecto apresentado, deve haver seo de avaliao *Deve haver uma seo conclusiva sobre a melhor alternativa ou que o sistema no vivel. Engenharia de Requisitos #Documento de Viso do Sistema *O propsito expor as necessidades e funcionalidades gerais do sistema. *Ser desenvolvido aps coleta e anlise dos requisitos preliminares, que podem estar descritos no Documento de Requisitos e no *Documento de Regras de Negcio. *Seu foco est nas necessidades dos patrocinadores (stakeholders) e no motivo da existncia destas necessidades. #Escopo *Descreve aspectos e funes que devem fazer parte do produto, incluindo projetos associados e qualquer coisa que possa ser afetada por este projeto. #Gestores *Quem vai gerenciar e as funcionalidades que emergem a partir desse gestor. #Levantamento de Necessidades *Problema *O que afeta *Impacto disso *Soluo #Classificao das Necessidade por categoria *Crtico *Importante *til #Funcionalidade do Produto *Caractersticas funcionais levantadas com o objetivo de satisfazer as necessidades identificadas anteriormente. *As funcionalidades devem estar ordenadas por prioridade, conforme os critrios do prprio usurio. * A granularidade destas funcionalidades maior que a de um caso de uso. #Interligao com outros Sistemas *Descreve de forma simples, ou atravs de um diagrama, outros sistemas com os quais este sistema se relacione. *Caso no exista, no precisa existir esse tpico. #Restries *So descritos requisitos, tcnicos ou no, sem os quais o sistema ser invivel, ou que limitem as alternativas de soluo possveis. #Documentao *Documentao prevista para o sistema: manuais do usurio; help online guia de instalao; Arquivos; Readme; etc.. #Estrutura de um Documento de Requisitos *Introduo *Glossrio *Definio dos Requisitos do Usurio *Arquitetura do Sistema *Especificao dos Requisitos do Sistema *Modelos do Sistema *Evoluo do Sistema *Apndices *ndice #Documento de Requisitos *Arquitetura do Sistema *Modelos do Sistema> Diagrama de Atores -Modelo de Caso de Uso -Modelo de Anlise -Modelo de Projeto -Diagrama de Pacotes *Evoluo do Sistema (Futuro) *Apndices *ndice Requisitos de Software #Elicitao de requisitos e anlise *Esta atividade divide-se em dois esforos maiores: *Elicitao dos requisitos em si *Tcnicas de elicitao *Anlise do que foi elicitado *Processo de anlise #Que um requisito? *Tanto pode ser *Uma declarao abstrata de alto nvel de um servio *Como uma restrio do sistema *Quanto uma especificao funcional matemtica detalhada #Elicitao de Requisitos *Tambm denominada de descoberta de requisitos *Envolve pessoal objetivando descobrir o domnio de aplicao, servios que devem ser fornecidos bem como restries *Deve envolver usurios finais, gerentes, pessoal envolvido na manuteno, especialistas no domnio, etc. (Stakeholders). #Viso dos Requisitos *Requisitos do Usurio *Declaraes em linguagem natural com diagramas de servios que o sistema deve oferecer e suas restries operacionais. Escrito para os clientes *Requisitos do Sistema *Documento estruturado com descries detalhadas sobre os servios do sistema. Contrato entre cliente e fornecedor #Tipos de Requisitos *Requisitos Funcionais *Requisitos No-Funcionais *Requisitos de Domnio #Requisitos Funcionais *Descreve funcionalidade e servios do sistema *Depende do Tipo do software Usurios esperados Tipo do sistema onde o software usado #Exemplos de R.F. *[RF001] Usurio pode pesquisar todo ou um sub-conjunto do banco de dados *[RF002] Sistema deve oferecer visualizadores apropriados para o usurio ler documentos armazenados *[RF003] A todo pedido deve ser associado um identificador nico (PID), o qual o usurio pode copiar para a rea de armazenamento permanente da conta #Requisitos No-Funcionais *Definem propriedades e restries do sistema (tempo, espao, etc) *Requisitos de processo tambm podem especificar o uso de determinadas linguagens de programao, mtodo de desenvolvimento *Requisitos no-funcionais podem ser mais crticos que requisitos funcionais. No satisfaz, sistema intil. *Devido sua prpria definio, requisitos nofuncionais so esperados mensurveis *Assim, deve-se associar forma de medida/referncia a cada requisito no-funcional elicitado #Classificao de R. N. F. *Requisitos do Produto *Produto deve comportar-se de forma particular (velocidade de execuo, confiabilidade, etc.) *Requisitos Organizacionais *Conseqncia de polticas e procedimentos organizacionais (padres de processo usados, requisitos de implementao, etc.) *Requisitos Externos *Conseqncia de fatores externos ao sistema e ao processo de desenvolvimento (legislao, etc.) #Exemplos de R. N. F. *Requisitos do Produto *[RNF001] Toda consulta ao B.D., baseada em cdigo de barras, deve resultar em at 5s *Requisitos Organizacionais *[RNF002] Todos os documentos entregues devem seguir o padro de relatrios XYZ-00 *Requisitos Externos *[RNF003] Informaes pessoais do usurio no devem ser vistas pelos operadores do sistema #Requisitos de Domnio *Derivados do domnio da aplicao e descrevem caractersticas do sistema e qualidades que refletem o domnio *Podem ser requisitos funcionais novos, restries sobre requisitos existentes ou computaes especficas *Se requisitos de domnio no forem satisfeitos, o sistema pode tornar-se no prtico #Requisitos de Domnio (Problemas) *Entendimento *Requisitos so descritos na linguagem do domnio da aplicao *No entendido pelos engenheiros de software que vo desenvolver a aplicao *Implicitude *Especialistas no domnio entendem a rea to bem que no tornam todos os requisitos de domnio explcitos #Tcnicas de Elicitao *Entrevistas *Questionrios *Casos de Uso *Jogo de Funes *Brainstorming *Workshop de Requisitos #Entrevistas *Tcnica direta *Pode ser usada na anlise do problema e na elicitao de requisitos *Objetivo *Entender os problemas reais e solues potenciais das perspectivas dos usurios, clientes, e outros stakeholders *Quem so o cliente e o usurio? *Possuem necessidades diferentes? *Quais so suas Capacidades Backgrounds -Ambientes, etc. *Qual o problema? *Como resolvido atualmente? *Qual a razo para resolv-lo? *Qual o valor de uma soluo bemsucedida? *Onde mais uma soluo pode ser encontrada? Note que algumas dessas perguntas j foram feitas no estudo de viabilidade. #Questionrios *Aplicabilidade a mercados especficos *Onde perguntas so bem definidas *Hipteses *Perguntas relevantes podem ser decididas antecipadamente *Leitor ouve da maneira desejada *Suprime o que bom sobre anlise *teis aps uma entrevista inicial #Casos de Uso *Discuta com o cliente o que o sistema far *Identique quem interage com o sistema *Identique que interfaces o sistema ter *Verifique se no h requisitos faltando *Verifique que os desenvolvedores entendem os requisitos *Vantagem ter apelo visual dos requisitos mais relevantes do cliente #Jogo de Funes *Engenheiro de requisitos *Assume a funo do usurio ou cliente *Entender o domnio do problema *Cliente *Assume a funo do usurio *Entender os problemas que podem passar #Brainstorming *Regras para Brainstorming *Estabelea o objetivo da sesso *Gere quantas idias for possvel *Deixe sua imaginao livre *No admita crticas ou debates *Ajuste e combine as idias #Workshop de Requisitos *Pe todos os stakeholders juntos por um perodo intensivo (focado) *Facilitador conduz a reunio *Todos tm sua vez de falar *Resultados so disponveis imediatamente *Prov um ambiente para aplicar outras tcnicas de elicitao.

Diagramas de Casos de Uso > #Use Case Seqncia de aes, executada pelo sistema, que gera um resultado *De valor observvel *E para

ator particular Procedimento computacional/algortmico atmico. #ATOR *Algum ou alguma coisa (fora do sistema) que interage com o sistema *A descrio de um use case define o que o sistema faz quando o use case realizado *A funcionalidade do sistema definida por um conjunto de use cases, cada um representando um fluxo de eventos especfico #Exemplo de Use Case e Ator *Cliente de banco pode usar um caixa automtico para sacar dinheiro, transferir dinheiro ou consultar o saldo da conta *Ator: Cliente *Use cases: Sacar dinheiro, transferir dinheiro e consultar saldo #Identificando Use Cases *Em geral, difcil decidir entre um ou vrios use cases *Por exemplo, seriam use cases *Inserir carto em um Caixa Automtico? *Entrar com a senha? *Receber o carto de volta? *Representar valor observvel para ator *Pode-se determinar *De interaes (seqncia de aes) com o sistema que resultam valores para atores *Satisfaz um objetivo particular de um ator que o sistema deve prover *Facilitar gerenciamento durante ciclo de desenvolvimento *A razo para agrupar funcionalidades e cham-las de use cases #Evoluo de Use Cases *Inicialmente use cases so simples *Apenas esboo sobre funcionamento suficiente *Mas com a sedimentao da modelagem *Descrio mais detalhada do fluxo de eventos faz-se necessria *Fluxo de eventos deve ser refinado *Todos os stakeholders envolvidos devem estar de acordo com a descrio #Organizando Use Cases *Sistema pequeno no demanda estruturao *Exemplo, seis use cases, com dois/trs atores *J sistemas maiores requerem princpios de estruturao e organizao *Caso contrrio, planejamento, atribuio de prioridades, etc., podem se tornar difceis #Pacote de Use Case *Primeiro esforo de estruturao *Agrupam-se use cases relacionados em nico container #Reuso em Use Cases *Comportamento comum a mais de dois use cases(ou forma parte independente) *Pode-se modelar como use case para ser reusado *H trs possibilidades *Incluso *Extenso *Generalizao/Especializao #Incluso *Vrios use cases possuem texto de fluxo de eventos *Comum/idntico *Sempre usado *Equivalente a fatorao feita em programao atravs de sub-programas *#include da linguagem C *Como exemplo, tanto Sacar dinheiroquanto Consultar saldonecessitam da senha *Pode-se criar novo use case Autenticar usurioe inclu-lo *Mas ateno NO SE DEVE CRIAR USE CASES MNIMOS Deve haver ganho no reuso *Descrio de Consultar saldo *Fluxo de Eventos Principal: *include (Autenticar usurio). Sistema pede a Cliente que selecione tipo de conta (corrente, etc). #Extenso *Use case pode ser estendido por outro *Extenso de funcionalidade/Caso excepcional *Extenso ocorre em pontos especficos *Pontos de extenso *H tambm incluso de texto (fluxo de eventos) *Porm sob condies particulares *Pode ser usada para: Simplificar fluxos de eventos complexos *Representar comportamentos opcionais *Lidar com excees *Descrio de Atendimento *Fluxo de Eventos Principal: Colete os itens do pedido. (urgente). Submeta pedido para processamento. #Especializao *Use case pode especializar outro *Adio/refinamento do fluxo de eventos original *Especializao permite modelar comportamento de estruturas de aplicao em comum #Fluxo de Eventos *Parte mais importante de um use case *Atividade de requisitos *Define a seqncia de aes entre o ator e o sistema *Geralmente em linguagem natural *Uso preciso de termos definidos no glossrio de acordo com o domnio do problema *Tambm expresso formalmente *Pr e ps-condies (ou pseudo-cdigo) #Exemplo de Fluxo de Eventos *Um esboo inicial sobre Sacar dinheiro seria 1.O use case inicia quando o Cliente insere um carto no CA. Sistema l e valida informao do carto 2.Sistema pede a senha. Cliente entra com a senha. Sistema valida a senha. 3.Sistema pede seleo do servio. Cliente escolhe Sacar dinheiro 4.Sistema pede a quantia a sacar. Cliente informa. 5.Sistema pede seleo da conta (corrente, etc). Cliente informa. 6.Sistema comunica com a rede para validar a conta, senha e o valor a sacar. 7.Sistema pede remoo do carto. Cliente remove. 8.Sistema entrega quantia solicitada. *Na descrio do que o sistema faz atravs de fluxos de eventos completos *Surgem caminhos alternativos *Casos diferentes a considerar *Efeitos/valores diferentes a produzir *Eventualmente descreve todos esses caminhos possveis #Sub-fluxos de Eventos *Fluxo de eventos visto como *Vrios sub-fluxos de eventos *Sub-fluxos so descritos como *Principal *Alternativos/excepcionais *Abordagem visa reuso de fluxos de eventos (subfluxos) #Exemplo de Sub-fluxos *Seja o use case Validar usurio *Fluxo principal: O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra com senha. Sistema verifica se a senha vlida. Se a senha vlida, sistema confirma e termina o use case. *Fluxo excepcional: Cliente pode cancelar a transao a qualquer momento pressionando a tecla ESC, reiniciando o use case. Nenhuma modificao feita na conta do Cliente. *Fluxo excepcional: Se Cliente entra com senha invlida, o use case reinicia. #Diagrama de Atividades *Descreve fluxo de tarefas *Aspectos dinmicos de um sistema *Podem tambm ser usados para criar sistemas executveis *Depende do nvel de detalhamento e grau de execuo dos elementos usados *Alternativa para modelar fluxos de eventos de casos de uso #Diagramas de Use Cases *Caracterizar limites da funcionalidade do sistema *Use cases so organizados dentro de um diagrama *Em diagramas de use cases *Atores so relacionados por generalizao/especializao Anlise & Projeto de Software> #Modelo *Para criarmos um modelo do sistema, temos que identificar: Objetos, Classes, Atributos, Mtodos, Associaes entre classes, Outros relacionamentos entre classes #Uma Abordagem... *Para identificar objetos, classes e interfaces, liste todos os nomes(substantivos), pronomes e frases do seu documento de requisitos/casos de uso *Nomes prprios e frases que indiquem unicidade representam objetos *Joo, ela, minha conta, o elevador1 *Nomes comuns ou no plural indicam classes ou interfaces *Clientes, contas, um elevador *Para identificar servios(mtodos), atente para os verbos ou frases verbais *Clientes podem depositar na poupana *Para identificar atributos, analise as frases que expressam propriedades de objetos/classes *Clientes possuem uma senha, ou A senha do cliente deve ser de no mnimo 8 caracteres *Verbos tambm podem identificar associaes entre objetos, classes ou interfaces *Uma disciplina tem pelomenos3 alunos matriculados *Assim como, relacionamentos de herana, dependncia, etc. *Uma poupana um tipo especial de conta bancria #Infelizmente... *Na documentao informal, existiro nomes que no sero objetos, classes e nem interfaces *No h um algoritmo que nos permita modelar um sistema da forma perfeita *Tudo depende de experincia e julgamentos corretos na hora de escolher o grau de abstrao certa #Utilidade dos casos de uso *Casos de uso so mais interessantes que texto informal pois so mais estruturados e orientados a servios *Casos de uso naturalmente so vistos como mtodos *As intenes de um subconjunto de casos de uso revelam as classes *Demais elementos so obtidos pelos fluxos de aes #Granularidade *Casos de uso revelam dois maiores nveis de abstrao: O visual apresenta os principais mtodos do sistema e Os fluxos revelam interaes entre classes, associaes, dependncias, herana, etc. Projeto de Software e Arquitetura> #Contexto *Aps a etapa de anlise temos um primeiro modelo do sistema *Queremos agora melhorar esse modelo, a ponto de gerarmos facilmente a implementao do sistema *Este modelo chamado de modelo de Projeto #Anlise X Projeto *Abstrato X Concreto *Independente X dependente da tecnologia de implementao *Simples X detalhado *Modelos por caso de uso X unificao em um nico modelo #Atividades Projeto *Refinar o modelo de classes *Projetar arquitetura *Camadas *Separao em pacotes *Projetar Banco de Dados #Refinar o modelo de classes *Juntar todas as classes em um s diagrama *Analisar se necessrio criar novas classes ou remover classes existentes *Eliminar os esteretipos de anlise *Adicionar modificadores de visibilidade aos mtodos e atributos *Definir os tipos dos atributos *Detalhar assinatura dos mtodos *definir todos os parmetros dos mtodos, seu tipos e o tipo de retorno dos mtodos *Mapear associaes em atributos *Analisar a possibilidade de utilizar herana *Identificar padres de projeto *Fachada*Revisar as classes #Projetar arquitetura *Dividir o sistema em camadas *Arquitetura bem comum: Apresentao-Interface com o usurio, Comunicao-Comunicao entre apresentao e negcio e com outros sistemas, Negcio- Regras de negcio inerentes aplicao, Dados- Cdigo relacionado ao mecanismo de persistncia utilizado Projetar Arquitetura *Por que dividir em camadas? *Aumentar modularidade *Diminuir dependncias *Facilitar possvel troca de camadas #Diviso do sistema em pacotes *Agrupar classes em pacotes *Possveis critrios: Camadas, Lgica do sistema *Critrios escolhidos devem minimizar a dependncia entre os pacotes *Criar um diagrama de pacotes indicando as dependncias entre os pacotes Re-engenharia de Software Engenharia Reversa> #Atividades de ciclo de Vida *Lembram das famosas atividades do ciclo de Vida? Comunicao, Planejamento, Modelagem, Construo, Implantao - Iniciao do projeto, Levantamento de requisitos, Estimativas, Cronogramao, Monitorao, Anlise, Projeto, Codificao, Teste, Entrega, Manuteno, Feedback, Mtricas, Testes, Reengenharia #Manuteno *A mais de trs dcadas, a manuteno de software foi caracterizada como um iceberg. [CAN72] *Esperamos que o imediatamente visvel seja tudo o que existe, mas sabemos que uma enorme massa de possveis problemas e custo fica sob a superfcie. *A manuteno de software existente pode ser responsvel por mais de 60% de todo o esforo despendido por uma organizao de desenvolvimento. [PRE06] *Mas voc poderia pensar: *Mas eu no gasto 60% do meu tempo consertando erros nos programas que desenvolvi. #Reengenharia *Michel Hammer lanou as fundaes de uma revoluo no modo de pensar gerencial a respeito de processos do negcio e computao: J hora de parar de pavimentar trilhas de gado. Em vez de embutir processos desatualizados em silcio e software, deveramos descart-los e comear de novo. Deveramos reengenheirar os nossos processos de negcio a fim de conseguir aperfeioamentos drsticos em seu desempenho. *Toda empresa opera sob muitas regras desarticuladas... A reengenharia procura romper com as antigas regras sobre a conduo e a organizao do negcio. *A ligao entre a reengenharia de negcio e a engenharia de software est em uma viso de sistema.*O software freqentemente a realizao das regras de negcio. medida que essas regras se modificam, o software tambm deve ser modificado. * medida que os gerentes trabalham para modificar as regras, a fim de conseguir maior eficincia e competitividade, o software deve acompanhar o ritmo. *Em alguns casos, isso significa a construo de novos sistemas importantes baseados em computador. Mas em muitos outros,

significa a modificao ou a reconstruo de aplicaes existentes. Abstrao *Definio de Abstrao: habilidade de se ignorar os aspectos de assuntos no relevantes para o propsito em questo *Nvel de Abstrao:Cada passo no processo de desenvolvimento de software um refinamento do nvel de abstrao do software. Nos estgios iniciais do ciclo de vida as informaes possuem alto nvel de abstrao e nos estgios finais baixo nvel de abstrao *Grau de Abstrao:Est relacionado a uma mesma atividade no ciclo de vida do software. Informaes numa forma mais global possuem alto grau de abstrao, numa forma mais detalhada possuem baixo grau de abstrao. Engenharia Progressiva X Reversa *Engenharia Progressiva: *Processo tradicional de engenharia de software, caracterizado pelas atividades progressivas do ciclo de vida, que partem de um alto nvel de abstrao, para um baixo nvel de abstrao. *Engenharia Reversa: O processo inverso a Engenharia Progressiva, caracterizado pelas atividades retroativas do ciclo de vida, que partem de um baixo nvel de abstrao para um alto nvel de abstrao. Re-Engenharia *A partir de um sistema pronto realizar a documentao completa e continuar realizando as atividades de manuteno e continuidade. Ex. Genexus