Análise e Projeto de Sistemas

31,141 views
30,810 views

Published on

Análise e Projeto de Sistemas

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
31,141
On SlideShare
0
From Embeds
0
Number of Embeds
108
Actions
Shares
0
Downloads
989
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Análise e Projeto de Sistemas

  1. 1. Objetivo da Disciplina • Apresentar os conceitos básicos de análise e modelagem de sistemas e a importância destas práticas para os projetos de software. Análise e Projeto de Sistemas • Apresentar parâmetros de comparação que possibilitem a identificação da técnica adequada para cada projeto. • Capacitar o aluno a elaborar projetos Aula expositiva 01 detalhados de sistemas através de técnicas de análise praticadas no mercado, em especial a Análise Orientada por Objetos Professor José Luiz Bastos com a utilização do padrão UML (Unified Modeling Language) e seus diagramas de representação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Ementa da Disciplina Ementa da Disciplina1. FUNDAMENTOS DA ANÁLISE DE SISTEMAS 3. ANÁLISE ORIENTADA A OBJETOS E PADRÃO1.1 Análise de sistemas e ciclo de vida dos sistemas. UML1.2 Modelagem de sistemas. 3.1 Conceitos básicos da orientação a objetos.1.3 Evolução da análise de sistemas. 3.2 Os três pilares da orientação a objetos. 3.3 Linguagem de modelagem unificada – UML.2. ENGENHARIA DE REQUISITOS 3.4 Modelos da UML.2.1 Técnicas envolvidas2.2 Dificuldades 4. MODELAGEM DE SISTEMAS ATRAVÉS DA UML2.3 Especificação e documentação 4.1 Diagrama de Casos de Uso. 4.2 Diagrama de Classes. 4.3 Diagrama de Seqüência de Casos de Uso. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Ementa da Disciplina Análise de Sistemas - Motivação5. MODELAGEM DE SISTEMAS ATRAVÉS DA UML • Por que analisar? Por que não começar logo pela5.1 Diagrama de Colaboração. implementacão?5.2 Diagrama de Estados. • Análise de sistemas: – A análise de sistemas é um processo de análise detalhada5.3 Diagrama de Atividades. das necessidades de informação de uma organização, das características e dos componentes dos sistemas de informação atualmente utilizados (se existirem) e dos requisitos dos sistemas de informação sendo propostos. – Trata da análise detalhada dos componentes e requisitos de um sistema. • Objetivos da Análise de Sistemas: – Padronizar, minimizar a redundância, evitar a ambigüidade e reduzir a manutenção corretiva das especificações do sistema. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 1
  2. 2. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral• Sistema? Sistemas de Informações – Um grupo de itens que interagem entre si ou que sejam interdependentes, formando um todo unificado, orientado para atender objetivos específicos. • Um sistema de informações é um conjunto – Um conjunto organizado de doutrinas, idéias ou de elementos inter-relacionados, processos, princípios, habitualmente previstos para explicar a dados e tecnologia, cuja finalidade é organização ou o funcionamento de um conjunto alimentar os centros de decisões com as sistemático. – Exemplos: informações necessárias à escolha de • Sistema gravitacional diretrizes de ação que permitam atingir os • Sistema digestivo objetivos da organização. • Sistema rodoviário • Sistema bancário © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral• Dados: Componentes de um Sistema de Informações: – São seqüências ordenadas de símbolos dos quais se pode extrair informações. Porém, não contêm nenhum significado quando analisados isoladamente. • Hardware; • Software;• Informações: • Pessoas; • Dados; – São dados tratados, analisados ou processados, • Procedimentos. capazes de transmitir algum conhecimento ao receptor. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão GeralClassificação quanto à forma de processamento: Classificação quanto à forma de processamento: • Sistemas em Tempo Real• Sistemas Batch – Controla um ambiente pelo recebimento de dados, seu – O usuário normalmente não interage com o computador por processamento e apresentação dos resultados com rapidez terminal e as informações são processadas em lotes, de suficiente para afetar o ambiente naquele momento. forma seqüencial. • Sistemas Baseados em Conhecimento – Esses sistemas estão associados ao campo da inteligência• Sistemas On-Line artificial. Contêm grande quantidade de conhecimentos – O usuário interage com o computador por terminal, os dados variados para utilização em determinadas tarefas. de entrada são fornecidos diretamente do local onde eles foram criados e os resultados do processamento são • Sistemas Especialistas dirigidos diretamente para onde sejam necessários. – São sistemas baseados em conhecimento. Têm embutidos o conhecimento e a capacidade que os tornam capazes de funcionar como um especialista. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 2
  3. 3. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral Classificação quanto ao nível organizacional: Sistemas de Processamento de Transações Nível operacional; Apoia operações rotineiras da empresa; Registra transações; Origem dos dados: operações internas; Grau de agregação dos dados: dados analíticos, reais e precisos; Volumes manipulados: grandes; Saídas: relatórios analíticos, alguns sintéticos; Freqüência: periódica; Exemplos: faturamento, estoque, contabilidade etc. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral Sistemas de Apoio à DecisãoSistemas de Planejamento e Controle Operacional Nível tático (média gerência); Nível tático (supervisão); Apoia processos decisórios; Apoia o planejamento e controle operacional; Trabalha com análise matemática e estatística dos Coleta informações sobre o realizado e compara com dados;o previsto; Origem dos dados: operações internas e fontes Origem dos dados: operações internas; externas; Grau de agregação dos dados: médio; Grau de agregação dos dados: alto; Volumes manipulados: médios; Volumes manipulados: pequenos; Saídas: relatórios consolidados; Saídas: gráficos e tabelas; Freqüência: periódica; Freqüência: a pedido (ad hoc); Exemplos: custos, planejamento e controle de Exemplos: análise de investimentos, análise estatística,produção, planejamento e controle de projetos. simulação de cenários. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Análise de Sistemas - Visão Geral Análise de Sistemas - Visão GeralSistemas de Planejamento Estratégico Princípios Gerais dos Sistemas: Nível estratégico (alta administração); • Quanto mais especializado é um sistema, Apoia análise de fatores críticos de sucesso da menos capaz ele é de se adaptar aempresa: desempenho, mercado e concorrência; circunstâncias diferentes; Trabalha com projeções a longo prazo e tendências • Quanto maior for um sistema, maior odo mercado; número de seus recursos que serão Origem dos dados: operações internas e fontes destinados à manutenção diária;externas; Grau de agregação dos dados: alto; • Os sistemas sempre fazem parte de Volumes manipulados: pequenos; sistemas maiores e sempre podem ser Saídas: gráficos e tabelas sofisticados; divididos em sistemas menores; Freqüência: a pedido (ad hoc); • Os sistemas CRESCEM. Exemplo: sistemas de informações executivas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 3
  4. 4. Análise de Sistemas - Mais definições Problemas• “A análise de sistemas é frustrante, repleta de relacionamentos entre pessoas, indefinida e difícil. Resumindo, é fascinante. • Depende da clareza do usuário: Depois que você é fisgado, os velhos e fáceis prazeres da – É ele o responsável por mostrar ao analista, de construção de sistemas nunca mais serão suficientes para maneira clara, quais requisitos o sistema deve satisfazê-lo.” (DeMarco, 1989) atender.• “Análise de sistemas é a atividade que tem como finalidade realizar estudos de processos a fim de encontrar o melhor e • Depende do entendimento do analista: mais racional caminho para que a informação possa ser processada.” (Wikipedia) – É ele o responsável por identificar e analisar os requisitos esperados pelo usuário.• Análise de sistemas consiste em identificar, detalhar e – Deve documentar de forma clara o seu trabalho, para documentar os processos de negócio para sua automatização que os consumidores do mesmo saibam identificar os junto aos usuários. Essa análise deve produzir como resultado requisitos esperados pelos usuários. uma especificação completa de tudo que o sistema de informação deve realizar. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Solução • Técnicas para identificação e detalhamento de requisitos • Técnicas para modelagem de sistemas © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Usuários Usuários• Principais participantes do processo: – O sistema está sendo desenvolvido PARA ELES. Cada projeto possui um elenco diferente de pessoas – O sistema automatizará os processos de negócio envolvidas. Um analista de sistemas precisa ter aptidões executados POR ELES. interpessoais (além do conhecimento da tecnologia), ou – Comprometimento dos usuários é fundamental para o seja, deve falar com outras pessoas usando uma sucesso do projeto “linguagem” diferente. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 4
  5. 5. Usuários Usuários Classificação por Tipo de FunçãoO analista de sistemas deve fazer reuniões regularescom os usuários (também chamados de clientes ou Operacionaisproprietários). O ideal seria ter um usuário dedicadointegralmente ao projeto. Alguns defendem que o usuário Têm visão local, isto é, não conhecem o processo dedeveria fazer o projeto. forma global; Responsáveis por executar as funções do sistema; Têm uma visão física do sistema, ou seja, imaginam o funcionamento do sistema considerando a tecnologia de implementação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Usuários Usuários Supervisores Executivos Podem ou não ter uma visão local; Não têm experiência operacional; Geralmente conhecem as operações, pois muitos já Têm iniciativa sobre o projeto; foram usuários operacionais. Além disso, têm que supervisionar os usuários operacionais; Possuem uma visão global; Orientados por considerações orçamentárias (ex.:reduzir Têm preocupações estratégicas; o quadro de funcionários ou aproveitá-los melhor); Capazes de lidar com modelos abstratos. Normalmente, agem como intermediários em relação aos níveis mais elevados. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Usuários UsuáriosClassificação por Nível de Experiência Novato arrogante Amador Participou de alguns projetos; Nunca trabalhou com um computador; Possui ou trabalha com computadores; Tem dificuldade para entender os modelos produzidos pelos analistas; Por conhecer algumas ferramentas, gosta de opinar sobre as tecnologias a serem usadas para implementar Receia ser substituído pelo sistema ou ter sua o sistema (normalmente, tem certeza que opina certo, importância minimizada. mas opina errado!). © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 5
  6. 6. Usuários Usuários Classificação quanto ao conhecimento de tecnologia:Experiente – Baixo: • Não compreende a linguagem técnica Conhece a análise de sistemas; – Médio • Tem algum conhecimento tecnológico Tem experiência de outros projetos; • Pode perder o foco e se preocupar com a solução tecnológica Discute sobre as ferramentas de modelagem sendo utilizadas. – Alto • Tem um bom conhecimento tecnológico • Pode perder o foco e se preocupar muito com solução tecnológica © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Equipe do Projeto Equipe do Projeto Gerente de Projeto Auditores, Controle de Qualidade e PadronizadoresAs principais funções de um gerente de projeto são: Podem ser internos ou externos. Responsáveis por Gerenciar e alocar recursos de toda a equipe técnica; garantir que o sistema será desenvolvido de acordo com os vários padrões internos e externos da organização, Prestar constas junto à administração superior; especialmente aqueles voltados à segurança e ao Encaminhar problemas identificados no decorrer do controle de qualidade do produto final.projeto; Gerentes de níveis mais altos se concentram nos aspectosmais abstratos do sistema. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Equipe do Projeto Equipe do ProjetoAlguns problemas dos Auditores que devem ser Analistas de sistemasconsiderados: Normalmente não se envolvem no projeto até que ele tenha sido • Analisam, detalham e documentam osconcluído. Nesse ponto, modificar o sistema é muito mais difícil; processos de negócios que serão Às vezes não estão habituados com a notação utilizada; automatizados • Ajudam os usuários a encontrarem as Geralmente, estão mais interessados na forma do que nasubstância. soluções mais apropriadas • Atuam como mediadores entre os diversos Verificam conformidades com padrões: Padrões governamentais participantes do processo Padrões internos da empresa Padrões do processo de desenvolvimento © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 6
  7. 7. Equipe do Projeto Equipe do ProjetoUm analista de sistemas deve ter: O analista desempenha as seguintes funções: Mediador: como os usuários dificilmente chegam a um consenso, o Habilidade de relacionamento social; analista deve usar a arte da diplomacia e da negociação. O sistema deve ser feito da forma como os usuários solicitaram; Conhecimento da tecnologia; Líder de projeto: Como o analista entrou antes no projeto, freqüentemente também é o projetista e normalmente é uma pessoa Conhecimento dos processos de negócio mais experiente, existe uma tendência natural de que ele assuma o papel de gerente de projeto. Mente lógica e organizada (visualizar osistema sob diferentes perspectivas), ou seja,raciocínio lógico e abstrato © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Equipe do Projeto Equipe do Projeto Projetistas de Sistemas Arqueólogo e escriba: deve trazer à luz os detalhes edocumentar as atividades cujos detalhes passam de geração em • Arquitetos do sistemageração de usuários; • Recebem o resultado do trabalho dos analistas de sistemas Inovador: não se limitar apenas a implementar as funçõesatuais do sistema mas ajudar a encontrar produtos e mercados • Usam os requisitos levantados para desenhar a arquitetura donovos; sistema que servirá de base para o trabalho dos programadores • Interação constante com os analistas • Podem verificar a inviabilidade de alguns requisitos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Equipe do Projeto Equipe do Projeto Projetistas de Sistemas Programador• O analista de sistemas deve fornecer informaçõessuficientemente detalhadas para que o projetista elabore um • Responsável por codificar e testar (usando umaprojeto tecnologicamente bom. linguagem de programação) os módulos dos sistemas modelados pelos projetistas.• O projetista deve fornecer informações suficientes para que oanalista possa dizer se os requisitos dos usuários podem ser • Em um cenário ideal, o programador não deveria tercompletamente atendidos ou devem ser modificados. contato com o analista, já que se baseia apenas no trabalho feito pelo projetista. • Há programadores que são responsáveis apenas por dar manutenção em um sistema. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 7
  8. 8. Equipe do Projeto Equipe do Projeto ProgramadorSegundo Zvegintzov (1987) - (autor do artigo SoftwareMaintenance News): Até o presente momento, o principal profissional da computação era alguém que podia aprender o suficiente sobre as necessidades das empresas para expressá-las na linguagem dos computadores. No futuro, quando nossa sociedade tornar-se irreversivelmente computadorizada, o principal profissional será alguém que possa aprender o suficiente sobre sistemas computadorizados para expressá-los em linguagem humana. Sem essa pessoa, teremos perdido o controle de nossa sociedade. Esse alguém é o engenheiro às avessas. Os mantenedores de software são os engenheiros às avessas da sociedade. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Equipe do Projeto Ciclo de vida de um projeto • Mais integrantes? Definição: – Testadores • “Um ciclo de vida de projeto bem definido – Analistas de usabilidade oferece mecanismos para planejar e – Engenheiros de processo acompanhar atividades de forma mais – Gestores de configuração precisa, possibilitando a detecção de – E por aí vai... problemas de forma rápida (YOURDON, 1990)”. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Etapas do ciclo de vida clássico Questões 1) Quais são os problemas do ciclo de desenvolvimento de sistemas apresentado na figura acima? De que forma esses problemas podem ser solucionados ou pelo menos minimizados? 2) Esse ciclo de vida pode ser considerado realístico para projetos de software? Por quê? 3) De que forma a fase de análise interfere e sofre interferência das outras etapas? © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 8
  9. 9. Etapas do ciclo de vida de Fases desenvolvimento de software Concepção Fase na qual necessidades dos usuários e conceitos da aplicação são analisados o suficiente para justificar a especificação de um produto de software, resultando em uma proposta de especificação. Elaboração Fase na qual a especificação do produto é detalhada o suficiente para modelar conceitualmente o domínio do problema, validar os requisitos em termos deste modelo conceitual e permitir um planejamento acurado da fase de construção. Construção Fase na qual é desenvolvida (desenhada, implementada e testada) uma liberação completamente operacional do produto, que atende aos requisitos especificados. Transição Fase na qual o produto é colocado à disposição de uma comunidade de usuários para testes finais, treinamento e uso inicial. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Fluxos Modelos de ciclo de vidaRequisitos Visa obter um conjunto de requisitos de um produto, Modelo Codifica-Remenda: acordado entre cliente e fornecedor.Análise Visa detalhar, estruturar e validar os requisitos, em termos de um modelo conceitual do problema, de forma que estes possam ser usados como base para o planejamento e acompanhamento detalhados da construção do produto.Desenho Visa formular um modelo estrutural do produto, que sirva de base para a implementação, definindo os componentes a desenvolver e a reutilizar, assim como as interfaces entre eles.Implementação Visa detalhar e implementar o desenho através de componentes de código e de documentação associada.Testes Visa verificar os resultados da implementação, através do planejamento, desenho e realização de baterias de testes. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Modelos de ciclo de vida Modelos de ciclo de vidaModelo Codifica-Remenda: Modelo em cascata: • As fases são executadas em estrita sequencia• Provavelmente o mais usado • Pouco realiza, não permite erros• Não exige sofisticação técnica ou gerencial • Pontos de controle bem definidos facilitam• Alto risco gestão• Impossível de gerir • Teoricamente é confiável e utilizável em• Não permite assumir compromissos projetos de qualquer escala confiáveis • Rígido e burocrático • Baixa visibilidade para o usuário, que só recebe o resultado no final do projeto © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 9
  10. 10. Modelos de ciclo de vida Modelos de ciclo de vidaModelo em cascata com realimentação: Modelo em espiral:• E possível voltar à fase anterior• Mais fexível © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Modelos de ciclo de vida Modelos de ciclo de vidaModelo em espiral: Modelo de entrega evolutiva:• Software é desenvolvido em uma série de iterações • Combinação entre o modelo de Espiral e• Cada nova iteração é um novo ciclo na Cascata espiral• Construção é feita de forma incremental• Utilizado em processos ágeis, como o XP © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.Projeto – Empresas de pequeno porte Projeto – Empresas de grande porte• Normalmente é iniciado após um acordo • Existe um processo formal de engenharia de verbal entre os usuários e a equipe do software projeto • Existem meios para verificar se o processo• O desenvolvimento é feito logo após esse está sendo seguido acordo verbal, geralmente sem a existência • Todos conhecem o processo de análise. • O gerente é o responsável por organizar o• Geralmente não existe um processo de projeto de acordo com o processo desenvolvimento formal. Se existe, geralmente não é seguido ou verificado. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 10
  11. 11. Modelos Modelos• A criação de um modelo corresponde à • É a partir das especificações dos clientes e utilização de uma linguagem que possa ser usuários que os modelos serão construídos e empregada por analistas e compreendida por a partir dos modelos que o produto será usuários, para representar um sistema. desenvolvido, portanto, o envolvimento do• Os modelos são os principais produtos da cliente é de fundamental importância nesta análise e são fundamentais para se obter um etapa. Os modelos podem ser utilizados produto de software de qualidade, dentro de também para a validação inicial do produto, o prazos e custos preestabelecidos. que os torna ainda mais importantes. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. ModelosObservação Importante:• Um analista de sistemas, além de saber Análise e Projeto de Sistemas construir modelos, deve se aprofundar no que está sendo modelado, seja um sistema de matrícula, vendas, controle de estoque, bancário, etc. Durante a modelagem, o Aula expositiva 02 analista muitas vezes se torna um especialista na área. Professor José Luiz Bastos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Fatores de insucesso em projetos de Premissas software Por que os projetos de software são cancelados antes de serem concluídos?Para desenvolver sistemas úteis, de alta qualidade eque realmente satisfaçam as necessidades dos Fator de insucesso % dos projetosusuários, é necessário considerar os seguintes Requisitos incompletos 13,1aspectos: Falta de envolvimento dos usuários 12,4 Falta de recursos 10,6 Produtividade; Expectativas não-realistas 9,9 Falta de suporte executivo 9,3 Confiabilidade; Alterações nos requisitos e especificações 8,7 Manutenibilidade. Falta de planejamento 8,1 O software não é mais necessário 7,5 Falta de gerenciamento de TI 6,2 Outros 14,2 © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 11
  12. 12. Engenharia dos Requisitos Engenharia dos Requisitos • Motivação • Princípios • Os problemas têm que ser enunciados antes de serem • Boas especificações de requisitos são indispensáveis. resolvidos. • Não representam custos supérfluos, mas investimentos necessários. • Nada é mais caro do que resolver os problemas errados. • A participação dos usuários na engenharia de requisitos é • A boa engenharia de requisitos reduz a instabilidade de fundamental para que suas necessidades sejam corretamente sistemas de informação: atendidas pelo produto. • Ajuda a obter os requisitos corretos em um estágio anterior • Uma boa especificação de requisitos custa tempo e ao desenvolvimento. dinheiro; • O custo de correção de defeitos cresce muito ao longo do • A ausência de uma boa especificação de requisitos custa tempo. muito mais tempo e dinheiro. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Fase de Elaboração Levantamento dos Requisitos• Fase na qual a especificação do produto é detalhada o suficiente para modelar conceitualmente o domínio • Levantamento das funções, interfaces e do problema, validar os requisitos em termos deste requisitos não-funcionais desejados para o modelo conceitual e permitir um planejamento produto. acurado da fase de construção. • Requisitos levantados apenas em nível necessário para o estabelecimento de um• É dividida em duas iterações: entendimento inicial entre usuários, clientes e desenvolvedores. • Levantamento dos Requisitos: captura dos requisitos • Levantamento de requisitos focalizando os junto aos usuários. usuários. • Análise dos Requisitos: detalhamento e validação dos requisitos levantados junto aos usuários. • Método típico: * oficinas de levantamento de requisitos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Análise dos Requisitos Análise dos Requisitos • Detalhamento e análise dos requisitos. • Foco na visão que os desenvolvedores têm dos requisitos do produto, ainda dentro do • Modelagem conceitual dos elementos espaço de problema e não do espaço de relevantes do domínio do problema e uso solução. desse modelo para validação dos requisitos e planejamento detalhado da fase de Construção. • Métodos típicos: * oficinas de detalhamento de requisitos; * entrevistas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 12
  13. 13. Técnicas para Levantamento e Análise de Técnicas para Levantamento e Análise de Requisitos Requisitos• Freqüentemente, falhas de comunicação e de entendimento entre a equipe de • Metodologia mais utilizada pelas empresas: desenvolvimento e clientes envolvidos • Entrevista individual entre o analista de sistemas e os usuários. resultam em erros de especificação cuja • Vantagens: posterior correção em sistemas já • Praticidade e fácil aplicação. construídos compromete prazos e custos • Desvantagens: previstos. • Lentidão do processo; • Comprometimento: • Da qualidade dos requisitos resultantes; $$$ • Da convergência de interesses entre os usuários; • Consenso na priorização dos requisitos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Técnicas para Levantamento e análise de Requisitos Metodologia JAD • Técnicas de dinâmica de grupo: • Benefícios: • Eficazes na agilização do processo; • Redução da necessidade de manutenção nos aplicativos • Redução nas falhas de comunicação; desenvolvidos com o seu auxílio; • Metodologia JAD*: • Redução de custos; • Maior satisfação dos usuários, pois as aplicações atendiam ao • Uma abordagem usando um líder NEUTRO para que eles realmente desejavam; orientar usuários através de um processo interativo e flexível, obtendo-se CONSENSO sobre um • Maior entrosamento entre a área de Sistemas de Informações assunto pré-determinado. e os Departamentos Usuários; • Menor necessidade de modificações durante o processo de desenvolvimento; • Nivelamento das expectativas de ambas as partes entre outros. *Joint Application Design • Metodologia desenvolvida nos anos 70 pela IBM – Canadá; • Objetivo inicial: levantamento de requisitos e desenho de interfaces de sistema; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Metodologia JAD Metodologia JAD• Com o passar do tempo, JAD passou a ser utilizado: • Componentes básicos de um JAD: • Em todas as fases do cliclo de desenvolvimento de software • Patrocinador do projeto: e não apenas durante o levantamento de requisitos (Joint Application Development); • Possui poder de decisão e fornece os recursos necessários para o projeto. • Planejamento de projetos em geral; • Planejamento estratégico; • Líder da sessão: • Tomada de decisões, de qualquer natureza, que necessita • Responsável por conduzir a sessão de forma de um consenso entre várias pessoas das diversas áreas de NEUTRA. uma organização (Workshops). • Documentador: • Responsável por redigir as decisões tomadas em ata; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 13
  14. 14. Metodologia JAD Metodologia JAD• Componentes básicos de um JAD: • Por que usar JAD? • Usuários finais: • Redução do tempo de desenvolvimento do software; • Conhecedores do negócio da aplicação; • Aumento da qualidade do software; • Aumento da produtividade; • Definem as necessidades do sistema em nível • Redução do custo; apropriado de detalhes; • Maior motivação e comprometimento da equipe; • Desenvolvedores: • Redução de alteração de requisitos; • Tomam conhecimentos das necessidades dos • Visão global do sistema pelos envolvidos; usuários finais e da aplicação durante a sessão de JAD; • Respondem questões técnicas; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Metodologia JAD Oficina de Requisitos• Sucesso de um JAD depende: • Liderança da sessão de forma eficiente; • Definição do Local: • Participação de usuários finais, executivos e ☺ Afastado do local de trabalho, onde os desenvolvedores; participantes não possam ser interrompidos; • Alcance da sinergia do grupo durante a sessão. ☺ Sem interferências externas (celular, bip, etc...); ☺ Baixo nível de ruído; ☺ Mesas arrumadas em “U” (se possível); ☺ Serviço de café. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas Demanda reprimida Problemas de Produtividade O backlog dos sistemas pode ser dividido em trêsOs dois aspectos mais importantes desse problema categorias:são: • Visível: A demanda reprimida (backlog) por novos sistemas; Sistemas solicitados oficialmente pelos usuários e que O tempo necessário para construir um novo sistema. foram aceitos e tiveram suas verbas aprovadas pela gerência. Ainda não foram iniciados por falta de recursos humanos (analistas, programadores etc.). © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 14
  15. 15. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas• Invisível: Tempo de desenvolvimentoSistemas que os usuários sabem que precisam, mas não Existe a preocupação com a perda de oportunidades dese dão ao trabalho de solicitar oficialmente, porque ainda negócios, devido à incapacidade de desenvolver osestão aguardando outros projetos. sistemas de apoio necessários no tempo necessário. Muitos projetos nem são terminados. Dentre os principais• Desconhecido: motivos para estouro de tempo em projetos, podemos citar:Sistemas que os usuários ainda não sabem que precisammas que emergirão logo que sejam concluídos outros Problemas técnicos;sistemas dos backlogs visível e invisível. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas O tempo necessário para criar um sistema pode ser Problemas gerenciais; reduzido através de algumas técnicas: Inexperiência da equipe; Contratação de mais programadores e analistas de sistemas; Falta de tempo para análise e projeto; Contratação de programadores e analista de sistemas Escasso envolvimento por parte da gerência ou mais talentosos, oferecendo-lhes melhores condições deusuários. trabalho; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas Razões para os analistas terem ciência dos Deixar que usuários desenvolvam seus próprios problemas de produtividade:sistemas; A produtividade e qualidade do trabalho dos Melhores linguagens de programação; programadores está diretamente ligada ao serviço feito pelo analista; Ferramentas automatizadas de desenvolvimento. Algumas das técnicas de aumento de produtividade têm importância direta para os analistas; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 15
  16. 16. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas Problemas de Confiabilidade A produtividade da análise é um problema politicamente Os erros em sistemas podem passar desapercebidos (ex.:sensível; uma impressão de relatório não formatada corretamente) ou causar graves acidentes (problema em sistema de Usuários e gerente têm ansiedade pelo início da tráfego aéreo).programação; Os erros em software são difíceis de serem extintos Usuários não entendem a importância da especificação. porque: É difícil descobrir como solucionar o erro; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas A figura 1 mostra o número de erros encontrados em Deve-se encontrar todos os pontos de correção; função do tempo decorrido (YOURDON, 1990). Alta probabilidade de introduzir novos erros (efeitoscolaterais); Nem sempre são reportados pelos usuários; Dificuldade de reproduzir o erro. Figura 1 – Erros descobertos em função do tempo © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas ManutenibilidadeSobre a curva na figura 1 é importante notar: A correção de erros é apenas um dos aspectos da Inicialmente o nº de erros encontrados é pequeno (usuários semsegurança para apontar erros), como indica T1; manutenção de sistemas. A manutenção também está vinculada a fatores como: À medida que os usuários se familiarizam com sistema os erros sãopercebidos e reportados (entre T1 e T2); Modificações no hardware; Após um tempo (após T2) o nº de erros encontrados começa a Novos dispositivos;diminuir (sistema começa a tornar-se mais estável); Necessidade de melhorar o desempenho; O número de erros volta a crescer devido a correções ou modificaçõesque introduzem novos erros (após T3); Garantir maior confiabilidade; A curva nunca atinge zero. Alterações dos requisitos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 16
  17. 17. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas A manutenção de um sistema deve ser sempre Outros Problemas – Portabilidade acompanhada de modificações na especificação do sistema. Entretanto, isso nem sempre ocorre devido a Consiste em escrever sistemas que podem ser fatores como: transferidos para outras plataformas; Analista alocado para outro projeto; Apesar de não ser um problema da alçada do analista, ele deve especificar que há essa necessidade; Urgência na implantação das modificações; A portabilidade geralmente provoca ineficiência já que Inexistência de uma política que valorize a recursos disponíveis de determinada plataforma não são manutenção da especificação. aproveitados. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas Principais causas dos Problemas Outros Problemas – SegurançaÀ medida que os sistemas de informações crescem em Ausência de Planejamento de Sistemas; número e importância, o risco de violações aumenta. Ausência de Administração de Dados;A segurança de sistemas de informações consiste basicamente em: Não utilização de Métodos e Técnicas Formais de Desenvolvimento; Impedir o acesso de pessoas não autorizadas; Não utilização de Técnicas e Ferramentas; Conceder acesso a certas funcionalidades apenas a algumas pessoas. Adoção de Metodologias não ambientadas à realidade da empresa; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Principais Problemas no Principais Problemas no Desenvolvimento de Sistemas Desenvolvimento de Sistemas Principais causas dos Problemas(cont.) Nota Especial Sobre Qualidade Falta de definição precisa dos objetivos e A qualidade de um sistema pode ser mensurada requisitos do sistema; considerando a eficácia e a eficiência obtidas: Dificuldade de comunicação e/ou falta de Eficácia = Resultados Obtidos / Resultados Pretendidos entrosamento entre as pessoas envolvidas no processo, causada por problemas de linguagem Eficiência = Resultados Obtidos / Recurso Consumido ou rivalidade entre usuários; Falta de precisão e clareza na especificação dos sistemas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 17
  18. 18. Principais Problemas no Identificação, análise e gerência de Desenvolvimento de Sistemas requisitos Problemas que denotam falta de qualidade em 1 Técnicas de Entrevistas e de Coleta de Dados sistemas: Por que e para que fazemos entrevistas ? Não contribuem para os objetivos da empresa; Para coletar informações armazenadas em cérebros sobre o comportamento de um sistema atual ou um novo sistema; Não atendem às necessidades dos usuários; Para verificar como compreendemos o comportamento de Não são confiáveis; um sistema; Para elaborar um estudo de viabilidade de desenvolvimento São ineficientes; de um sistema. Têm manutenção constante, difícil e onerosa. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Identificação, análise e gerência de Identificação, análise e gerência de requisitos requisitos2 Tipos de Entrevistas 3 Problemas ao Entrevistar Usuários Entrevista em forma de reunião pessoal; Entrevistar a pessoa errada no momento errado; Entrevista em forma de questionários abertos e fechados; Fazer perguntas erradas e obter respostas erradas; Gravação de descrição de expectativas do usuário em relação Criar ressentimentos recíprocos.ao sistema. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Identificação, análise e gerência de Identificação, análise e gerência de requisitos requisitos4 Diretrizes para a realização de entrevistas Desenvolva um plano geral de entrevista; 5 Possíveis Formas de Resistência na Entrevista Certifique-se de que você tem autorização para falar com os Você está tomando muito o meu tempo;usuários; Você está ameaçando o meu emprego; Planejar a entrevista para fazer uso eficiente do tempo; Utilize ferramentas automatizadas que sejam adequadas, mas não Você não conhece nossa empresa e ainda quer nos dizer como deveabuse; ser feito o novo sistema? Tente descobrir em que informações o usuário está maisinteressado; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 18
  19. 19. Identificação, análise e gerência de Identificação, análise e gerência de requisitos requisitos 6 Outros Problemas a Enfrentar5 Possíveis Formas de Resistência na Entrevista(cont.) Uma discussão que focalize mais os problemas de Você está tentando mudar o modo como as coisas são feitas implementação do que os problemas de requisitos;aqui; Confusão entre sintomas e problemas; Nós, usuários, não queremos este sistema; O usuário pode ser incapaz de explicar o que ele quer que o Por que você está desperdiçando nosso tempo com esta sistema faça ou pode mudar de opinião;entrevista? Desentendimento entre usuários de mesmo nível, subordinados e chefes. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Identificação, análise e gerência de Identificação, análise e gerência de requisitos requisitos7 Formas Complementares de Coleta de Dados Requisitos Funcionais: Descrevem a funcionalidade ou os serviços que se espera que o sistema forneça. Demonstrações feitas pelos fornecedores; Descrevem a função de sistema detalhadamente, suas entradas e saídas, excessões, etc. Exemplos: Visitas a outras empresas com sistemas semelhantes; “O sistema deve permitir que cada professor realize o Coleta de dados em manuais, formulários, relatórios, listagens de lançamento de notas das turmas nas quais lecionou”;programas, etc.; “O sistema deve permitir que um aluno realize a sua Pesquisa externa em instituições como IEEE e ACM. matrícula nas disciplinas oferecidas em um semestre”; “O sistema deve permitir que o aluno consulte todo o seu histórico de disciplinas cursadas”. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Identificação, análise e gerência de Identificação, análise e gerência de requisitos requisitos Requisitos Não Funcionais:Requisitos Não Funcionais: São aqueles que nãodizem respeito diretamente às funções específicas Requisitos nãofornecidas pelo sistema. Eles podem estar relacionados funcionaisa propriedades de sistemas emergentes, comoconfiabilidade, tempo de resposta e espaço em disco. Requisitos do Requisitos Requisitos produto organizacionais externosAlternativamente, podem definir restrições para osistema, como por exemplo, a capacidade dos Facilidade Confiabili Portabili Interoperadispositivos de E/S e as representações de dados de uso Eficiência dade dade bilidade Legais Éticosutilizados nas interfaces de sistema. Desempe Privacida Seguran Espaço nho de ça Implemen Entrega Padrões tação © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 19

×