INTRODUÇÃO A ANÁLISE DE SISTEMAS

Transcrição

1 INTRODUÇÃO A ANÁLISE DE SISTEMAS 1

2 PROGRAMAR É DIVERTIDO! DESENVOLVER SOFTWARE COM QUALIDADE É DIFÍCIL! CRAIG LARMAN 2

3 Ambientes de Desenvolvimento de Software Empresas que têm o software como atividade fim. _ Analista programador autônomo 1 Coitado autonomo _ Pequena Software House 1 Proprietários Alguns Analistas/Programadores _ Média Software House 1 Gerente de Desenvolvimento Alguns Líderes de Equipe/Analista Vários Analistas/Programdores Vários Programadores _ Grande Software House 1 Diretor de Desenvovimento Alguns Líderes de projeto Alguns Lideres de Equipe Poucos Analistas de Negócio Vários Analistade de Sistemas Vários Programadores 1 Gerente de Banco de Dados Alguns DBA s 3

4 Ambientes de Desenvolvimento de Software Empresas que têm o software como atividade meio. _ Funcionário faz tudo de pequenas empresas. 1 Coitadinho _ Analista/Programador de médias empresas. 1 Coitado _ Equipe de desenvolvimento de médias empresa. 1 encarregado do desenvolvimento Alguns analistas/programadores Alguns programadores _ Gerência de Desenvolvimento de Grande Empresas. 1 Gerente de Desenvolvimento Alguns Lideres de projeto Alguns Lideres de Equipe Alguns Analistas de Negócio Vários Analistas de Sistemas Vários Programadores Poucos DBA s 4

5 Parque de Softwares de uma empresa Softwares Legados Software de Terceiros Novos Softwares Em desenvolvimento Na fila para desenvolvimento 5

6 FUNÇÃO BÁSICA DO DESENVOLVIMENTO DE UM SOFTWARE 6

7 Gap semântico Distância entre o problema no mundo real e o modelo abstrato(software) construído; Quanto menor for a Gap Semântico: _mais rápida será a construção da solução; _menos retrabalho será feito. _menos desgaste haverá da equipe desenvolvedora com o cliente. _ menos atraso na entrega haverá _ menos dinheiro será desperdiçado. Portanto, diminuir o gap semântico tornou-se um dos objetivos da Engenharia de Software; Os diagramas da análise de sistemas buscam de reduzir este gap. 7

8 Ilustração do Gap semântico 8

9 Ilustração do Gap semântico 9

10 Ilustração do Gap semântico 10

11 Ilustração do Gap semântico 11

12 Ilustração do Gap semântico 12

13 Ilustração do Gap semântico 13

14 Ilustração do Gap semântico 14

15 Ilustração do Gap semântico 15

16 Ilustração do Gap semântico 16

17 Ilustração do Gap semântico 17

18 A Engenharia de Software é uma disciplina dos cursos de informática que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção desse sistema, depois que ele entrou em operação. Levantamento de requisitos Análise de Custos Analise de Riscos Estimativas Análise e projeto de Sistemas Projeto de Interfaces Implementação Verificação e Validação(testes) Implantação Gerência de Configuração(Manutenção) Gerência de Projeto Qualidade de Software 18

19 Ciclo de Vida do Software O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum. Para se padronizar o desenvolvimento de software e se ter uma forma documentada de iteração da equipe de desenvolvimento do software e o cliente, foram criados modelos de ciclo de vida, ou processo de software. Estes modelos definem as etapas do desenvolvimento, assim como os artefatos(documentos e desenhos) que devem ser produzidos para permitir a validação de uma etapa antes de passar à próxima etapa. 19

20 Ciclo de Vida do Software Os modelos de ciclo de vida têm dois propósitos principais: 1 Reduzir o Gap Semântico 2 Detectar erros, provindos do Gap Semântico, nas fases iniciais do projeto. As fases do ciclo de vida de um software variam com o processo que é utilizado para desenvolver o software. Apresentaremos a seguir algumas propostas de processos de software. 20

21 PROCESSO É uma sequência coordenada e padronizada de atividades, com o objetivo de ser repetido para produzir várias vezes o mesmo resultado. As pessoas desempenham as mesmas tarefas a cada ciclo do processo. O controle de produtividade é estabelecido em torno de metas de produção. Ex: Desenvolvimento de um novo carro. PROJETO É o planejamento de atividades não padronizadas que serão executadas para atingir um resultado único. A equipe planeja e executa o projeto. Enfrenta escopos que podem ser desconhecidos. Ex: produzir o novo carro. 21

22 PROCESSO DE SOFTWARE É o roteiro ou sequência de passos, que devem ser executados para se criar um software. Existem diferentes processos padronizados. Empresas adequam um determinado processo à sua necessidade. O processo fornece uma estabilidade, controle e organização no desenvolvimento de um software. Sem um processo definido a atividade de criação de um software se torna caótica. Existem vários mecanismos para avaliar a qualidade de um processo de software e e maturidade deste processo. Um processo maduro tende a criar software de maior qualidade. 22

23 PADRONIZAÇÃO Definição do padrão. Reconhecimento do padrão. Obediência ao padrão. 23

24 ISO é a sigla de International Organization for Standardization, ouorganização Internacional para Padronização, em português. A ISO é uma entidade de padronização e normatização, e foi criada em Genebra, na Suiça, em A sigla padrão no mundo é ISO, em grego isos significa "igual. A ISO tem como objetivo principal aprovar normas internacionais em todos os campos técnicos, como normas técnicas, normas de procedimentos e processos, e etc. No Brasil, a ISO é representada pela ABNT (Associação Brasileira de Normas Técnicas). Nos Estados Unidos, a ISO é representada pela - American National Standards Institute(ANSI) 24

25 25

26 O Instituto de Engenheiros Eletricistas e Eletrônicos ou IEEE (pronuncia-se I-3-E) é uma organização profissional sem fins lucrativos, fundada nos Estados Unidos, em É a maior (em número de instituições, não em popularidade) organização profissional do mundo. O IEEE tem filiais em muitas partes do mundo, sendo seus sócios engenheiros eletricistas, engenheiros da computação, cientistas da computação, profissionais de telecomunicações, dentre outros. Sua meta é promover conhecimento no campo da engenharia elétrica, eletrônica e computação. Um de seus papéis mais importantes é o estabelecimento de padrões para formatos de computadores e dispositivos. 26

27 A Comissão Eletrotécnica Internacional (em inglês: International Electrotechnical Commission, IEC) é uma organização internacional de padronização de tecnologias elétricas, eletrônicas e relacionadas. Alguns dos seus padrões são desenvolvidos juntamente com a Organização Internacional para Padronização (ISO). A sede da IEC, fundada em 1906, é localizada em Genebra, Suíça. 27

28 A norma internacional ISO/IEC tem como objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de softwares visando ajudar as organizações a compreenderem todos os componentes presentes na aquisição e fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz. 28

29 A norma brasileira NBR ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, ela define um conjunto de parâmetros com o objetivo de padronizar a avaliação da qualidade de software. A norma 9126 foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, com cada uma delas divididas em sub-características. 29

30 A Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software, isto é, a aplicação de engenharia ao software(ieee,iee93). 30

31 PADRÕES DE QUALIDADE DE SOFTWARE 31

32 A Associação para Promoção da Excelência do Software Brasileiro (Softex) executa, desde 1996, iniciativas de apoio, desenvolvimento, promoção e fomento para impulsionar a Indústria Brasileira de Software e Serviços de TI. O MPS.BR é um programa mobilizador que foi criado em 2003 pela Softex para melhorar a capacidade de desenvolvimento de software nas empresas brasileiras. A iniciativa foi responsável pelo desenvolvimento do Modelo de Referência para Melhoria do Processo de Software Brasileiro (MPS-SW), que levou em consideração normas e modelos internacionalmente reconhecidos, boas práticas da engenharia de software e as necessidades de negócio da indústria de software nacional. 32

33 O CMMI (Capability Maturity Model - Integration ou Modelo de Maturidade em Capacitação - Integração) é um modelo de referência que contém práticas necessárias à maturidade de processos. O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas, quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. 33

34 Processo de Desenvolvimento de Software Interativo É um processo que prioriza a interação da equipe de desenvolvimento de software com os usuários. 34

35 Processo de Desenvolvimento de Software Iterativo É um processo no qual a desenvolvimento do software e realizado por meio da repetição de um conjunto de passos. 35

36 ARCABOUÇO DE PROCESSO O arcabouço de processo estabelece atividades que devem ser realizadas em qualquer processo de software. Pressman define 5 atividades genéricas que definem o arcabouço de um processo de software. 1 COMUNICAÇÃO: Interação com o usuário/cliente 2 PLANEJAMENTO: Define as técnicas que serão realizadas, os riscos prováveis, os recursos necessários, os produtos do trabalho a ser produzido e um cronograma. 3 MODELAGEM: Criação de modelos para esclarecer os requisits e reduzir o Gap Semântico. 4 CONSTRUÇÃO: Codificação e testes. 5 IMPLANTAÇÃO: Entrega do software ao cliente. 36

37 Modelo Prescritivo de Processo de Software Um Modelo Prescritivo de Processo de Software é um conjunto de elementos que inclui ações de engenharia de software, produtos de trabalho e mecanismos que garantam a qualidade e controle de modificações em cada projeto de desenvolvimento de um software (PRESSMAN, 2010). Não considere um modelo prescritivo de processo como estático, mas sim um processo dinâmico e adaptável ao desenvolvimento do software. Modelos prescritivos devem ser adaptados ao pessoal, ao problema e ao projeto. 37

38 Modelo Prescritivo de Processo de Software 1 Modelo em Cascata 2 Modelos Incrementais 2.1 Modelo Incremental 2.2 RAD (Rapid Application Development) 3 Modelos Evolucionários 3.1 Prototipagem 3.2 Modelo Espiral 4 Modelos Especializados de Processo 4.1 Desenvolvimento Baseado em Componentes 4.2 Modelos de Metodos Formais 4.3 Desenvolvimento de Software Orientado a Aspectos 5 Processo Unificado 38

39 1 Modelo em Cascata Também conhecido como Ciclo de Vida Clássico, é ideal para problemas nos quais os requisitos são bem definidos. Implementa uma abordagem sistemática e sequencial, isto é, uma nova atividade só pode ser iniciada quando a anterior estiver totalmente concluída, conforme figura abaixo: 39

40 1 Modelo em Cascata Vantagens: Torna o processo de desenvolvimento estruturado; Tem uma ordem sequencial de fases; Permite que os desenvolvedores descrevam o que deve ser realizado; Fácil gerenciamento; Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa; Esta abordagem ainda é utilizada, principalmente em grandes projetos. 40

41 1 Modelo em Cascata Desvantagens: Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores; Só há uma etapa para o levantamento de requisitos e não permite a modificação de requisitos; Propicia pouca interação da equipe com o cliente(usuário); É excessivamente sincronizado; Se ocorrer um atraso, todo o processo é afetado; O cliente só pode ver o produto funcionando quando este estiver completamente pronto; 41

42 2 Modelos Incrementais Há muitas situações em que os requisitos iniciais do software são razoavelmente bem definidos, mas não é possível se definir o escopo total do projeto. Nessa situação não é adequado seguir um processo puramente linear. O modelo incremental normalmente, é escolhido quando há uma necessidade de entrega rápida de algumas funcionalidades do software, mesmo que sejam limitadas. Posteriormente, as funcionalidades que foram entregues serão refinadas e expandidas em versões seguintes; Cada conjunto de funcionalidades que é entregue é chamado de incremento. 42

43 2-1Modelo Incremental O software é dividido em incrementos Desenvolve-se pequenas parte do software em um curto prazo; Para incremento realiza-se as etapas básicas do arcabouço de um processo de software. 43

44 2-1Modelo Incremental Exemplo Um software de processamento de texto: 1º Incremento: Entregar a gestão básica de arquivos, edição e produção de documentos. 2º Incremento: Capacidades de edição e de produção de documentos mais sofisticados. 3º Incremento: Verificação ortográfica e gramatical. 4º Incremento: Capacidade avançada de formatação de páginas. 44

45 2-1Modelo Incremental O 1º Incremento do modelo incremental é chamado de núcleo do produto: requisitos básicos são satisfeitos. Nos próximos incrementos é feita a revisão e incorporação de características suplementares. O objetivo do modelo é oferecer ao usuário um produto operacional a cada incremento, versões simplificadas do produto final, mas que oferecem capacidades que servem ao usuário. 45

46 2-1Modelo Incremental Quando usar: Quando não há mão-de-obra disponível para uma implementação completa. Quando o cliente não aceita esperar muito para começar a utilizar o software. Quando não é possível especificar completamente todos os requisitos Para gerir riscos técnicos. Exemplo: um sistema exige um hardware novo que ainda está em desenvolvimento. Os primeiros incrementos podem ser planejados de maneira a evitar o uso desse,sem atrasar o prazo de entrega do software. 46

47 Vantagens: 2.1 Modelo Incremental Versões do software são fornecidas ao cliente após cada iteração do modelo incremental; O Modelo Incremental inclui o uso do software pelo usuário para que as mudanças sejam feitas de acordo com o mesmo; Melhor gerenciamento de riscos, porque você pode confirmar o resultado com o cliente depois de cada versão do sistema. Riscos críticos são resolvidos antes que grandes investimentos sejam realizados; Permite verificar se o software está sendo construído conforme a expectativa do cliente. Caso não esteja, a correção pode ser feita na próxima versão do software; Os testes são mais simples. 47

48 2.1 Modelo Incremental Desvantagens: Podem surgir problemas relativos à arquitetura do sistema, porque nem todos os requisitos são levantados no início do ciclo de vida do software. Cada incremento deve ser relativamente pequeno. Se for muito grande este modelo se aproxima do modelo em cascata O escopo completo do software pode não ser levantado no início do projeto. Dificuldade para se precificar o software. 48

49 2.2 Modelo Incremental RAD(Rapid Application Development) Processo incremental com trabalho de equipes de desenvolvimento em paralelo. 49

50 2.2 Modelo Incremental RAD(Rapid Application Development) Na construção enfatiza o uso de componentes de software preexistentes e a aplicação da geração automática de código. Prevê a entrega de um software completo em um período curto de tempo( 60 a 90 dias) Vantagens: Entrega do software em tempo muito curto. Divisão do trabalho em equipes. 50

51 2.2 Modelo Incremental RAD(Rapid Application Development) Desvantagens: Para projeto muito grandes e que ainda podem sofrer aumento de escopo é necessário ter corpo técnico que possibilite formar várias equipes. Se desenvolvedores e clientes não estiverem comprometidos com as atividades no seu determinado tempo, o projeto RAD falhará. Se o sistemas não for adequadamente modularizado o processo pode falhar. O RAD não é adequado para projetos onde existem riscos técnicos altos. 51

52 3 MODELOS EVOLUCIONÁRIOS O software evolui com o passar do tempo. Os requisitos podem mudar durante a construção do software. Os prazos reduzidos podem tornar impossível entregar um software completo mas pode-se entregar uma versão reduzida e deixar para definir as extensões do software posteriormente. Os modelos evolucionários foram criados para acomodar as mudanças dos requisitos e do escopo de um software. Os modelos Evolucionários são iterativos. 52

53 3.1 PROTOTIPAGEM Utiliza-se protótipos para auxiliar na identificação dos requisitos de software porque, nem sempre, os requisitos de entrada, de processamento e de saída são bem definidos; Os protótipos produzidos devem focar os interesses do cliente como, por exemplo, a interface de páginas, estrutura de relatórios; 53

54 Os protótipos podem ser: 3.1 PROTOTIPAGEM 1. Um modelo em papel ou em um software de desenho no qual o usuário tenha a visão da interação humanocomputador e quantas interações ocorrerá. 2. Um protótipo de trabalho que implementa algumas funcionalidades exigidas pelo software e que a equipe de desenvolvimento ainda não saiba como construir. 3. Um programa existente que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas posteriormente. 54

55 3.1 PROTOTIPAGEM 55

56 3.1 PROTOTIPAGEM Vantagens: Facilita a definição de requisitos. Reduz os riscos e incertezas do desenvolvimento. A experiência de produzir o protótipo pode reduzir o custo das etapas seguintes. O cliente valida aspectos gerais de interação dele com o software. 56

57 3.1 PROTOTIPAGEM Desvantagem: O cliente precisa estar ciente de que o produto deverá ser refeito, uma vez que foi construído apenas um protótipo. 57

58 3.2 Modelo Espiral É um Modelo Evolucionário que combina a natureza iterativa da Prototipagem com os aspectos controlados e sistemáticos do Modelo em Cascata. Possibilita o desenvolvimento rápido de versões cada vez mais completas. As versões iniciais podem ser um modelo de papel ou protótipo. As últimas são cada vez mais completas do sistema submetido à engenharia. Pode ser utilizado até na fase de manutenção do software. 58

59 3.2 Modelo Espiral No modelo espiral cada giro na espiral (iniciando a partir do centro e avançando para fora) representa uma nova fase do processo. Este modelo introduz a análise de riscos antes de se começar uma nova fase do projeto. 59

60 3.2 Modelo Espiral Vantagens: Aceita mudanças na definição do software ao longo do seu desenvolvimento. São feitas muitas análises de riscos. É indicado para softwares grandes. 60

61 3.2 Modelo Espiral Desvantagens: O escopo completo do software não é levantado no início do projeto. Pode ser difícil convencer o cliente que o modelo será controlável. 61

62 Desenvolvimento Interativo No desenvolvimento de software interativo o cliente(usuário) participa ativamente da construção do software, reunindo-se frequentemente com a equipe de desenvolvedores. Normalmente é utilizado junto com os modelos incrementais e evolucionários. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema. 62

63 Vantagens: Desenvolvimento Interativo Baseia-se fortemente na participação e uma boa comunicação entre desenvolvedores e usuários. Há um grande envolvimento do usuário e do cliente. Isto leva superação rápida dos malentendidos entre os desenvolvedores e usuários. Porque há resultados mais rápidos e "tangíveis", os usuários também serão capazes de dar um melhor feedback; Os resultados mostrados permitirão que os usuários tenham confiança em um bom resultado final; A cada ciclo do sistema, os usuários e clientes poderão utilizar o sistema diretamente. Eles são os "testadores" no processo de desenvolvimento e eles estarão interagindo com o sistema durante o desenvolvimento; Os riscos podem ser melhor administrados por pequenos pedaços do sistema a serem desenvolvidos em pequenos espaços de tempo; Alterações nos requisitos podem ser rapidamente incorporada no processo de desenvolvimento. 63

64 Desenvolvimento Interativo Desvantagens: Durante o processo de desenvolvimento necessita-se adaptar e refinar o sistema, com isso pode ser que no final o software fique totalmente diferente da ideia original; Durante o construção do software podem aparecer muitos requisitos novos, aumentando constantemente o escopo do software. Gerentes que estão acostumados com a forma linear do desenvolvimento de um software podem ter alguns problemas ao trabalharem com uma forma mais flexível; O usuário pode não ter tempo para tantas interações com a equipe desenvolvedora. 64

65 Desenvolvimento Ágil Processos de desenvolvimento de software com características evolucionárias e muito interativo. Valorizam a interação entre pessoas. Não valorizam documentação escrita. É o processo que está na moda. Exemplos: Programação Extrema e Scrum. REPRESENTAÇÃO DO SCRUM 65