O que é software? Programas de computador Entidade abstrata.

Apresentação em tema: "O que é software? Programas de computador Entidade abstrata."— Transcrição da apresentação:

1

2 O que é software? Programas de computador Entidade abstrata.
Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas resolvemos problemas. interagimos com a máquina. tornamos o computador operacional.

3 O que é software? Conceito mais amplo que inclui também:
Instruções que executam uma função desejada. Estrutura de dados para manipular informação. Documentos para desenvolver, operar e manter os programas. Para operar o software deve incluir configurações necessárias.

4 O que é software? Software como um produto!
Sw pervasivo – incorporado em todas as atividades humanas cotidianas: cultura, comércio, lazer, etc. É preciso ver o software como um produto. Que vai ser vendido, diferentemente de construir um sw para uso próprio. Então tem um cliente específico, e cada vez mais, um cliente genérico! O sw pode ser um veículo para vender-se a si próprio.

5 Tipos de Sistemas de Software
Software básico Software stand-alone – aplicativos para PC que náo precisam estar conectados à rede Software para sistema em tempo real Software baseado em transações: comércio eletrônico Software comercial e sistemas financeiros Software para engenharia e aplicações científicas Software embarcado (ex. microwave, celulares) Software baseado em inteligência artificial Software de entretenimento: jogos, cinema Stand-alone – não conectados a rede Baseados em transações que geralmente acessam um computador remoto fazendo por exemplo uso de navegadores web, Por exemplo sistemas de comércio eletrônico.. Diferentes tipos requerem diferentes técnicas e métodos de desenvolvimento. Desenvolvimento incremental. Ex sist web, requerem desenvolvimento baseado em componentes, prototipos telas usuarios.

6 A Evolução do Software 1950 2010 1960 1970 1980 1990 2000 A quarta era
sistemas desktop poderosos tecnologia de orientação a objetos sistemas especialistas redes neurais computação paralela A quinta era Netbooks Web 2.0 Serviços Web Computa-ção em nuvens A terceira era sistemas distribuídos incorporação de inteligência hardware de baixo custo impacto do consumidor A segunda era sistemas multiusuários sistemas em tempo real banco de dados software produto Os primeiros anos sistemas batch distribuição limitada software personalizado 1950 2010 1960 1970 1980 1990 2000

7 Dificuldades para desenvolver software
Saber o que o software deve fazer : quais os requisitos (abstração); Ferramentas; linguagem; so – tecnologias diferentes Tempo e custos elevados de desenvolvimento. Prever falhas (antes de entregar). Tratar manutenção e versões. Produtividade não cresce com a demanda de serviços.

8 Características do Software
software não é um elemento físico; é um elemento lógico (não tem propriedades físicas, como visualizar, medir ...) abstração maior; o produto final é diferente o software não pode ser manufaturado; custos estão concentrados no desenvolvimento e não na manufatura. o processo de gerenciamento é diferente; o relacionamento entre as pessoas é diferente; Não são regulados pelas leis da física.

9 Características do Software
existem diferentes abordagens para se chegar no produto final o software não se desgasta com o uso; mas deteriora-se não há peças de reserva. => manutenção, correção, aperfeiçoamento. não é construído aproveitando-se componentes prontos porque muitas vezes é personalizado. Um erro durante um teste => mais difícil de testar. Colocar a curva do Presmman.

10 “mortalidade infantil”
Curvas de falhas no hw tempo “desgaste” “mortalidade infantil” índice de falhas

11 Curva de falhas no sw mudança índice de falhas curva real
curva idealizada tempo Curva de falhas no sw Sistemas legados: construídos em uma outra geraçao, legado da geração anterior. Construídos há décadas atrás que ainda funcionam e sofreram diferentes modificações/adapatações. Longevidade e criticidade dos negócios.

12 Falso ou verdadeiro? 1. Já temos um manual repleto de padrões e procedimentos para a construção de sw. Neles está tudo o que a equipe precisa saber para produzir com qualidade. 2. Meu pessoal tem ferramentas de última geração, isso é suficiente. 3. Se nós estamos atrasados nos prazos podemos adicionar mais programadores e isso irá resolver o problema com o cronograma 4. Podemos terceirizar o projeto de software. Assim a responsabilidade será da empresa contratada.

13 Falso ou verdadeiro? 1 Assim que colocarmos o programa em funcionamento posso ficar tranquilo porque meu trabalho estará finalizado. 2. A engenharia de software irá nos fazer criar documentação volumosa e desnecessária e, invariavelmente nos retardar. 3. Só poderemos avaliar a qualidade do software quando tivermos o programa funcionando.

14 Falso ou verdadeiro? Uma definição geral dos objetivos é suficiente para começar a escrever programs, podemos adicionar detalhes depois. Os requisitos de software mudam constantemente mas mudanças podem ser facilmente assimiladas pois o software é flexível. Eu, cliente, sei o que preciso.

15 Mitos da ES Mitos atuais
1. O teste de sw ou sua verificação formal pode remover todos os erros. Para garantir qualidade é só aumentar a confiabilidade do software. O reúso de componentes prontos me traz segurança com relação à qualidade. Mitos: Propagaram desinformação e confusão administrativos cliente profissional

16 Crise de Software Alguns autores associam a palavra “crise” aos problemas para desenvolver software estimativas de prazo e de custo  produtividade das pessoas  qualidade de software  software difícil de manter 

17 Crise de Software Problemas: Software inadequado.
Cronogramas e custos imprecisos - dificuldades em prever o progresso durante o desenvolvimento. Inexistência de dados históricos sobre o processo de desenvolvimento. Mitos da ES Comunicação deficiente - insatisfação de usuários. Carência de conceitos quantitativos sobre confiabilidade, qualidade, reusabilidade. Software existente é de difícil manutenção.

18 Crise de Software Solução:
Combinar métodos para as fases de desenvolvimento. Ferramentas para automatizar esses métodos. Técnicas para assegurar qualidade. => Disciplina: Engenharia de Software. Mas estes problemas continuam até hoje, não serve de nada a eng. De sw. O sw ainda contina em crise, há décadas…. Mas acontecem que os sistemas de sw estão cada vez mais complexos e só conseguimos chegar Até aqui com a ES. Antigamente se fabricava um sapato artesanalmente, por encomenda, o sw tb. Hoje já não, temos um produção industrial e um usuário genérico. Revolução industrial, capitalismo industrial,financeiro, hoje é o capitalismo informacional…

19 Engenharia de Software
Abordagem sistemática para o desenvolvimento, operação, manutenção e descarte de software. Aplicação prática de conhecimento científico ao projeto e construção de software. Disciplina que utiliza princípios de engenharia para produzir e manter softwares dentro de prazos e custos estimados. “.. construção por muitas pessoas de um software com múltiplas visões”. (Parnas 1987)

20 Engenharia de Software
Objetivos: Melhorar a qualidade do software e aumentar a produtividade e satisfação profissional de engenheiros de software. Definição: Disciplina que utiliza um conjunto de métodos, técnicas e ferramentas para analisar, projetar e gerenciar desenvolvimento e manutenção de software.

21 Engenharia de Software

22 Engenharia de Software
Métodos e Técnicas: detalhes de como fazer Metodologias: como aplicar Ferramentas: automatizam os métodos, dão apoio a utilização CASE => (Computer-Aided Software Engineering): Ferramentas integradas para desenvolver software.

23 ES e outras áreas

24 Princípios da Engenharia de Software
Formalidade: reduz inconsistências Abstração: aspectos importantes, ignorar detalhes Decomposição: lidar com complexidade Generalização: reutilização, custo Flexibilização: mudanças, processo incremental Diferentes níveis de abstracao são possíveis, Por exemplo um sw ser descrito como um diagrama de caso de uso, alto nível.

25 Processo de Software À E. S. está associado um conjunto de passos
(que englobam métodos, ferramentas, etc) denominado paradigma

26 Processo de Software Um conjunto estruturado de atividades requeridas para desenvolver um produto de software Envolve: fases, atividades, pessoas (responsáveis, participantes, papéis), entradas e saídas (artefatos), recursos, passos para execução, regras, procedimentos. Não confundir com projeto.

27 Processo de Software Fases – grandes divisões (marcos) dos processos, períodos de tempo no qual algumas atividades são executadas. Atividades- possui entradas e saídas bem definidas, pessoas (responsáveis, participantes, papéis), entradas e saídas. Artefatos: quaisquer documentos que possa ser produzido ao longo do desenvolvimento de software. Recursos: hardware, software, material consumível ou não. Passos para execução: o que precisa ser feito em cada atividade Quais são as pessoas que participam: Gerentes: é responsável pelos prazos, custo, planejamento. – a gente sempre fala que eles não sabem nada :0( Desenvolvedores – an. E projeto Programadores – codificação, Eng de softw, geralmente é o responsável pelo processo, fornecer as ferramentas, cuidar,ser responsável por fazer as escolhas do desenvolvimento de sw … precisa saber um pouco de tudo.

28 Processo de Software Modelos de processo de sw: representação abstrata de um proceso de sw. Podem ser instanciados Projeto: execução de um proceso, uma instância de um proceso. Padrão de processo: resolvem problemas recorrentes relacionados a processos de sw. Normas de avaliação de processos: NBR ISO/IEC 12207 Não confundir com projeto.

29 Modelo de Processo de Software
Apresenta uma descrição de um processo de alguma perspectiva particular. Modelos prescritivos: definem uma ordem (um planejamento inicial) para realizar as atividades e um fluxo de trabalho previsível, assim como possíveis entradas e saídas. São modelos definidos. Modelos ágeis: planejamento é gradativo, mais fácil adaptação. Considera mudança e incerteza como inevitáveis. Controle com acompanhamento frequente e pequenos ajustes. São modelos empíricos. O que é um modelo? Um modelo pode capturar tudo? Não existe um modelo ideal, lembram? Assim, tb não existe um processo ideal. Estes modelos apresentam apenas um aspecto do processo de software Por exemplo os modelos prescritivos tem mais foco nas atividades, são orientados a planos, As atividades são planejadas com antecedência, e o progresso avaliado com o que foi planejado. Os modelos ágeis possuem foco nas pessoas

30 1. Ciclo de Vida Clássico (cascata)
modelo mais antigo e o mais amplamente conhecido da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, seqüencial ao desenvolvimento de software o resultado de uma fase é entrada para outra fase. existem variações/adaptações : modelo original, duplo, em V, orientado a riscos

31 Ciclo de Vida Clássico (cascata)

32 Engenharia de sistemas
envolve a coleta de requisitos em nível do sistema, com uma pequena quantidade de projeto e análise de alto nível esta visão é essencial quando o software deve fazer interface com outros elementos(hardware, pessoas e banco de dados)

33 Análise de Requistos de Software
o processo de coleta dos requisitos é intensificado e concentrado especificamente no software deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos

34 Projeto tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie

35 Codificação tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador

36 Teste Concentra-se: nos aspectos lógicos internos do software,garantindo que todas as instruções tenham sido testadas nos aspectos funcionais externos, paradescobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

37 Manutenção provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

38 Ciclo de Vida Clássico Problemas para aplicação:
Na prática, projetos não seguem o fluxo seqüencial. Acomodações de incertezas no início do projeto é difícil. Versão funcional dos programas disponível após os últimos estágios do projeto

39 Ciclo de Vida Clássico O modelo Cascata trouxe contribuições importantes para o processo de desenvolvimento de software: imposição de disciplina, planejamento e gerenciamento; a implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos Ele possui fragilidades mas é significativamente melhor que uma abordagem casual de desenvolvimento de sw.

40 2. Evolutivo Tudo merece uma nova chance – situações para acomodar um processo que evolui com o tempo Incorporação de diferente partes e criação de diferentes versões São iterativos – repetem atividades Inclui prototipação Permite o desenvolvimento exploratório Evolutivos – evolui versões existentes., circular, ciclos Paralelos –

41 Evolutivo

42 3. Incremental Abordagem intermediária
Combina vantagens dos paradigmas ciclo de vida clássico e evolutivo Identificação das funções do sistema, estabelecimento de incrementos e prioridades Cada incremento pode utilizar um paradigma de desenvolvimento diferente Dificuldade para dividir e gerenciar versões

43 Incremental O valor agregado ao Cliente está na entrega em cada incremento de modo que a funcionalidade do sistema estará disponível mais cedo Incrementos iniciais funcionam como protótipos para ajudar a evocar requisitos para incrementos posteriores Menores riscos de falha no projeto em geral Os serviços do sistema de alta prioridade tendem a receber a maioria dos testes

44 Incremental

45 Variações do modelo incremental
Orientado a funcionalidades – a cada versão novas funcionalidades são entregues Orientado a cronograma – entrega em tempos determinados

46 4. Espiral Modelo que acopla a natureza iterativa da prototipação com os aspectos controlados e sitemáticos do modelo cascata Dividio em regiões ou atividades de trabalho. Cada volta do espiral representa um desenvolvimento completo. O loop mais interno se concetra mais na definição dos requisitos A gerência pode adaptar o modelo e suas fases

47 Espiral

48 Espiral Paradigma mais realístico - sistemas grandes É um metamodelo
Incorpora análise de riscos. Permite prototipação em mais de um estágio Problemas: O modelo é relativamente novo. Requer esperteza. Pode nunca terminar, precisa ser evolutiva e controlável.

49 Considerações sobre processos
Que processo usar ? Depende da natureza da aplicação. Métodos e ferramentas disponíveis, etc.

50 Outros processos - objetivos específicos, mais especializados
RAD (Rapid Application Development)- enfatiza rapidez e um ciclo mais curto Prototipação Processo formal Modelo de componentes Processo unificado – UP Orientados a reúso Linguagem de quarta geração Engenharia de Linha de Produto de Sw (LPS)

51 1. Prototipação Possibilita que o desenvolvedor crie um modelo (protótipo) do software a ser construído para auxiliar a entender os requisitos do usuário Apropriado para quando os requisitos não estão claramente definidos Derivado da técnica de extração de requisitos

52 Prototipação

53 refinamento protótipo obtenção dos requisitos
Prototipação fim início construção produto refinamento protótipo avaliação protótipo construção protótipo projeto rápido obtenção dos requisitos

54 Abordagem Prototipação
Validar a precisão dos requisitos ou aceitabilidade das decisões O usuário irá colaborar? Validar a viabilidade de uma estratégia proposta. O software é particionável? Observações: protótipos só são válidos se construídos rapidamente

55 Prototipação O protótipo pode ser descartado ou fazer parte do produto final. Conerstone (pedra fundamental): Prototipação evolutiva Throw away: descartável

56 Prototipação Localiza “aspectos visíveis” para o usuário (E/S).
A iteração pode adequar o protótipo às necessidades do usuário. Problemas: Cliente insiste que o protótipo seja com ligeiras modificações, a versão final do produto. Decisões e soluções improvisados tornam-se parte do produto final.

57 2. Linguagens de Quarta Geração

58 Linguagens de Quarta Geração
Ferramentas para especificação de alto nível (L4G): Consulta a base de dados. Geração de relatórios. Manipulação de dados. Definição e interação com Telas. Geração de código.

59 Linguagens de Quarta Geração
Domínio predominante : Sistemas comerciais de informação. Boa produtividade para sistemas pequenos e médios e aplicação específicas. Problemas: Para sistemas grandes, demanda muito tempo; e ainda permanece a necessidade de projeto

60 3. Desenvolvimento de sistemas formais
Baseado na transformação de uma especificação matemática através de diferentes representações para um programa executável Transformações são ‘preservadoras de exatidão’, portanto, são diretas para mostrar que o programa está de acordo com sua especificação Contido na abordagem ‘Cleanroom’ para desenvolvimento de software

61 Desenvolvimento de sistemas formais

62 Transformações Formais

63 Desenvolvimento de sistemas formais
Problemas Necessidade de habilidades especializadas e treinamento para aplicar a técnica Difícil de especificar formalmente alguns aspectos do sistema como a interface de usuário Aplicabilidade Sistemas críticos, especialmente aqueles no qual um case de segurança deve ser feito antes do sistema ser posto em operação

64 4. Desenvolvimento Baseado em Componentes
Baseado no reuso sistemático, onde os sistemas são integrados de componentes existentes ou sistemas padronizados Estágios do Processo Análise do componente Modificação dos requisitos Projeto do sistema com reúso Desenvolvimento e integração Esta abordagem está se tornando mais importante, mas a experiência ainda é limitada com ela

65 Desenvolvimento orientado a componentes

66 Que processo usar? Sempre deve existir um processo de software definido - padrões de qualidade. Criar um processo baseado em fases específico para cada projeto. O profissional deve estar apto a avaliar a aplicação a ser desenvolvida e a situação do ambiente de desenvolvimento para decidir qual o melhor processo de software a ser definido. Sistemas web – baseado em componentes, reúso. Se tem telas, usuário – games – protótipos.

67 Combinação

68 Uma Visão Genérica da E.S.

69 Planejamento do Projeto de Software
Uma Visão Genérica da E.S. Análise do Sistema Planejamento do Projeto de Software Análise de Requisitos Definição O Que? Projeto do Software Codificação Testes Processo de Software Desenvolvi mento O Como? Correção Adaptação Melhora mentos Manutenção A Obrigação ...

70 Uma Visão Genérica da E.S.
1) Definição Função, desempenho, interface, restrições de projeto, critérios de validação. Análise de sistemas Planejamento de projeto de software Análise de requisitos.

71 Uma Visão Genérica da E.S.
2) Desenvolvimento: Estrutura de dados, arquitetura de software, detalhes procedimentais, programas, testes. Projeto de software. Codificação. Testes

72 Uma Visão Genérica da E.S.
3) Manutenção Corretiva: para corrigir defeitos; Adaptativa: para acomodar mudanças no ambiente externo do software (S.O., periféricos, etc) Perfectiva: para inclusão de novas funcionalidades

73 Uma Visão Genérica da E.S.

74 Uma Visão Genérica da E.S.

75 Uma Visão Genérica da E.S.

76 O Ciclo de Vida Canônico
Estudo de Viabilidade Iniciação do projeto Especificação de requisitos Projeto da arquitetura Projeto detalhado Codificação Teste de unidade Teste de aceitação Teste operacional Encerramento do projeto Operação Desativação do produto O modelo canônico deve ser tratado como uma referência que deve ser adaptada para cada situação.

77 Referências Pressman, R. Software Engineering: A Practitioner's Approach. McGraw-Hill, 6th edition, 2006. Sommerville, I. Software Engineering:) International Computer Science Series) 8th edition, 2006. Ferramenta: Jude ->Astah Software Engineering: (Update) (8th Edition) (International Computer Science Series) by Ian Sommerville (Hardcover - Jun 4, 2006) UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition) (Addison-Wesley Object Technology Series) by Jim Arlow and Ila Neustadt, 2005. The Unified Modeling Language Reference Manual (2nd Edition) (The Addison-Wesley Object Technology Series) by James Rumbaugh, Ivar Jacobson, and Grady Booch (Hardcover - Jul 29, 2004). Unified Modeling Language User Guide, The (2nd Edition) (Addison-Wesley Object Technology Series) by Grady Booch, James Rumbaugh, and Ivar Jacobson (Hardcover - May 29, 2005). JACOBSON, I BOOCH, G., RUMBAUGH, J., Unified Software Development Process, Addison-Wesley, Janeiro Software Engineering: A Practitioner's Approach by Roger Pressman (Hardcover - Jan 20, 2009). Análise e Projetos de Sistemas de Informaçao - Raul Sidnei Wazlawick, Editora Campus.

78 Programação Extrema – XP (eXtreme Programming)
Nova abordagem para o desenvolvimento de software baseado no desenvolvimento e entrega de incrementos de funcionalidade bem pequenos Conta com melhoramento constante do código, envolvimento do usuário no time de desenvolvimento e programação em pares