A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software I

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software I"— Transcrição da apresentação:

1 Engenharia de Software I
Prof. Josué Froner

2 Introdução Objetivo: apresentar conceitos sobre ciclo de vida do software, reutilização, medição, ferramentas e ambientes integrados, trabalhar a distinção entre engenharia de software e ciência da computação;

3 Elementos fundamentais
Métodos Ferramentas Procedimentos metas: melhorar a qualidade de produtos de software, aumentar a produtividade do pessoal técnico e aumentar a satisfação do cliente

4 Métodos Detalhes de como fazer para construir software
Tarefas básicas: Planejamento e estimativa de projeto; Análise de requisitos de software e de sistemas; Projeto da estrutura de dados; Arquitetura de programa; Algoritmo de processamento; Codificação; Testes; Manutenção.

5 Ferramentas Suporte, apoio aos métodos;
Computer – Aided Software Engineering CASE – combinação de software, hardware e BD sobre ES

6 Procedimento Ligação entre ferramentas e métodos;
Definem a seqüência de aplicação dos métodos, a exigência de entrega de produtos, o controle relacionados a qualidade Métodos, Ferramentas e Procedimento estão presentes em etapas da engenharia de software, assim como Paradigmas utilizado para automatizar tarefas. nada mais é um conjunto de comandos que são rodados sequencialmente. Criado para o MS-DOS, o batch foi utilizado para o sistema operativo carregar programas para preparar o ambiente para rodar outros programas

7 Uma abordagem de sistema
Um projeto é composto por hardware e software interagindo com: usuários, partes de hardware, BD, sistemas computadorizados Financia o desenvolvimento do sistema CLIENTE necessidades Obrigações contratuais necessidades Utiliza o sistema USUÁRIO DESENVOLVEDOR Sistema de software

8 Uma abordagem de sistema
Identificar, conhecer os elementos de um sistema: nomear as partes do sistema Verificar como as partes se relacionam Podemos chamar os elementos de objetos ou entidades Conhecer as relações e fronteiras do sistema Verificar se há sistemas inter-relacionados (fronteiras) Auxilia o conhecimento sobre o projeto

9 Projeto de Software é um processo
Processo : conjunto de tarefas ordenadas, etapas que envolvem atividades, restrições e recursos almejando um fim; Descrição da principais atividades; Utilização de recursos, tempo de uso e finalizações, geração de produtos intermediários e finais; Pode ser subdivido, ter hierarquia, sequenciação de atividades e seus objetivos; As atividades desenvolvidas devem ser controladas, assim como o suo de recursos

10 Processo  ciclo de vida
Concepção – implementação – entrega – utilização – manutenção Fator importante pois dá consistência e estrutura a um conjunto de atividades Conjunto de procedimentos Sequenciação de execução – reutilização Experiência para o futuro Documentação facilitada

11 Paradigmas de ES Abordagem filosófica da construção de soft.
Ciclo de vida clássico; Prototipação; Modelo Espiral; Técnicas de 4ª Geração Combinação de Paradigmas ou processo de software

12 O paradigma está relacionado
A natureza do projeto e da aplicação Aos métodos e ferramentas a serem usados Aos controles e produtos que precisam ser entregues

13 Ciclo de vida Clássico Conhecido como modelo em cascata-linear e sequencial; modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, seqüencial ao desenvolvimento de software

14 Cascata Engenharia de Sistemas Análise de Requisitos Projeto
Levantamento de requisitos Compreensão do domínio da informação, função, desempenho e interface Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção Múltiplos passos: est. Dados, arquit, procedim e caract. de interface  documentação Lógicos e funcionais Reaplicação do processo

15 Detalhes modelo cascata
ANÁLISE E ENGENHARIA DE SISTEMAS envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados ANÁLISE DE REQUISITOS DE SOFTWARE 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 os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Engenharia de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais

16 PROJETO se concentra em 4 atributos do programa: Estrutura de Dados, Arquitetura de Software, Detalhes Procedimentais e caracterização de Interfaces; tradução dos requisitos do software para um conjunto de representações que possam ser avaliadas quanto à qualidade, antes que a codificação se inicie. É documental; CODIFICAÇÃO transformação das representações do projeto para uma linguagem computacional resultando em instruções e procedimentos executáveis pelo computador IEEE STD , IIEEE Sttandard Gllossary off Soffttware Engiineeriing Termiinollogy, IEEE, Piscataway, NJ, 1997. PAULK, M.C. et al. The Capattiibiilliitty Matturiitty Modell – Guiidelliines ffor iimproviing tthe soffttware process, Addison Wesley, SEI series, 1995.

17 aspectos lógicos internos do software, garantir teste das instruções;
TESTES aspectos lógicos internos do software, garantir teste das instruções; aspectos funcionais externos, para descobrir erros e garantir que a entrada produza resultados esperados MANUTENÇÃO 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 IEEE STD , IIEEE Sttandard Gllossary off Soffttware Engiineeriing Termiinollogy, IEEE, Piscataway, NJ, 1997. PAULK, M.C. et al. The Capattiibiilliitty Matturiitty Modell – Guiidelliines ffor iimproviing tthe soffttware process, Addison Wesley, SEI series, 1995.

18 Problemática levantada
projetos reais raramente seguem o fluxo seqüencial que o modelo propõe logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento

19 Prototipação processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes

20 Demonstração 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

21 Prototipação: atividades
Obtenção dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída Construção Protótipo: implementação do projeto rápido Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo

22 Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteração que pode conduzir a 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito Construção Produto: identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

23 Problemática levantada
desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo. Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final. cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final.

24 Espiral engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um novo elemento: a Análise de Risco segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos

25 Espiral - gráfico Planejamento Análise dos riscos Avaliação do cliente
Análise dos riscos baseada nos requisitos iniciais Coleta inicial dos requisitos e planejamento do projeto Análise dos riscos baseada na reação do cliente Planejamento baseado nos comentários do cliente DECISÃO Protótipo de software inicial Nível seguinte do protótipo Avaliação do cliente Sistema finalizado Avaliação do cliente Engenharia

26 Fases - Espiral Planejamento: determinação dos objetivos, alternativas e restrições Análise de Risco: análise das alternativas e identificação / resolução dos riscos Construção: desenvolvimento do produto no nível seguinte Avaliação do Cliente: avaliação do produto e planejamento das novas fases

27 Observações é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala; usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva; pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável; exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso; o modelo é relativamente novo e não tem sido amplamente usado

28 Técnicas de 4ª Geração Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que: o sistema seja especificado em uma linguagem de alto nível e o código fonte seja gerado automaticamente a partir dessas especificações

29 Gráfico – F4G Obtenção dos Requisitos Estratégia do “Projeto”
Implementação usando 4GL Testes

30 Modelo Incremental O projeto de software constitui-se da possibilidade de entregar ao cliente um conjunto mínimo do sistema que seja usável, sendo que o processo continuará ao longo do ciclo de vida do software através de incrementos adicionados ao software. Obs: as vantagens incluem fornecer logo ao cliente um sistema e novas versões de trabalho

31 Modelo de processo de software-MPS
Composto por: Tarefas Artefatos (arquivos, dados...) Atores Decisões Modelagem de utiliza notação como elipse, retângulos, figuras e losangos formando fluxograma e/ou diagramas

32 Combinando Paradigmas
obtenção dos requisitos preliminares modelo espiral técnicas 4G protomodelagem análise dos requisitos projeto codificação testes manutenção no. interação sistema completo

33 Atividades do Ciclo de Vida
Viabilidade – desenvolvimento proposto é viável; Análise de mercado – existe mercado potencial para o produto? Requisitos – quais funcionalidades o software deverá ter? refinamento dos requisitos – obtem-se os requisitos do usuário Análise de domínio – quais tarefas e estruturas são comuns ao problema? Planejamento do projeto – como o software será desenvolvido Estimativas de custo – qual o custo do projeto Cronograma – cronologia de datas do desenvolvimento;

34 Mais atividades Garantia da qualidade – determina atividades que irão auxiliar a garantir a qualidade do produto; Estrutura de decomposição de trabalho – determinação de subtarefas no decorrer do desenvolvimento; Projeto – determina como o software deverá prover as funcionalidades; Projeto arquitetural – projeta a estrutura do sistema; Projeto de interface – especifica as interfaces entre as partes do sistema; Detalhamento do projeto – projeta os algoritimos para cada parte

35 Mais atividades Implementação – construção do software através de código; Teste: de unidade, de integração, do sistema, alpha, beta, de aceitação, de regressão; Entrega – o cliente recebe um software eficiente que soluciona suas necessidades; Instalação – disponibiliza o software no ambiente operacional do cliente; Treinamento – ensina a operação aos usuários; Help desk – responde a questões do usuário; Manutenção – atualização e evolução – garantia de usabilidade constante Teste execução do software com dados para ajudar a garantir que o software funciona corretgamente Teste de unidade – teste do desenvolvedor original; Teste de integração– teste durante a integração do software Teste de sistema – teste do sof. Em um ambiente semelhante ao ambiente operacional; Teste alpha – teste pelo cliente no ambiente do desenvolvedor; Teste beta – teste pelo clente no seu ambiente De aceitação – teste para satisfazer o clente e regressõ – teste de rmazenamento da versão anterior para garantir que a nova possui toas as capacidades anteriores

36 Documentos gerados Contrato de trabalho,
especificação dos requisitos de software, modelagem de objetos, cenários de casos de uso, cronograma do projeto, plano de testes de software, testes de aceitação, projeto de software, projeto arquitetural, projeto detalhado, plano da garantia da qualidade do software (SQA), manual do usuário, código fonte, relatório de teste, relatório de falhas

37 MÉTODO E METODOLOGIA Não são sinônimos;
metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo

38 exemplificando A exemplo disso, pode-se citar a Metodologia Estruturada, a qual é composta por vários métodos, tal como Análise Estruturada e Projeto Estruturado (muitas vezes denominados SA/SD), e Análise Essencial. E tanto a Análise Estruturada quanto a Análise Essencial utilizam-se da ferramenta Diagrama de Fluxos de Dados para modelar o funcionamento do sistema.

39 Metodologias Estruturadas
Análise Estruturado Projeto Estruturado Análise Essencial SADT Outras Metodologias Rational Unified Process (RUP) Microsoft Solution Framework (MSF Metodologias Ágeis Feature Driven Development (FDD) Enterprise Unified Process (EUP) Scrum Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web) Programação Extrema (XP) Outras Metodologias Rational Unified Process (RUP) Microsoft Solution Framework (MSF Metodologias Ágeis Feature Driven Development (FDD) Enterprise Unified Process (EUP) Scrum

40 Referências PRESSMAN, ROGER.S.ENGENHARIA DE SOFTWARE. SÃO PAULO: MAKRON, 2006 JURAN, J. GRYNA, FRANK. CONTROLE DA QUALIDADE: COMPONENTES BÁSICOS DA FUNÇÃO QUALIDADE - V.2 - SÃO PAULO : MAKRON, 1991. PFLEEGER, SHARI L. ENGENHARIA DE SOFTWARE: TEIORIA E PRÁTICA. 2.ED.SÃO PAULO: PRENTICE HALL, 2004. FAIRLEY, RICHARD. SOFTWARE ENGINEERING CONCEPTS. SINGAPORE: MCGRAW-HILL, 1985. e

41 Tarefa Para cada um dos seguinte documento, indique a fase do ciclo de vida do software - modelo cascata - em que são desenvolvidos: manual final do usuário, projeto arquitetural, plano de SQA, especificação de módulos, código fonte, seqüência de trabalho, plano de teste, manual de usuário preliminar, projeto detalhado, estimativas de custo, plano de projeto, relatório de teste, documentações.


Carregar ppt "Engenharia de Software I"

Apresentações semelhantes


Anúncios Google