Professor: Curso: Disciplina:

Transcrição

1 Professor: Curso: Disciplina: Aula 1 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Dinâmica da disciplina, plano de curso e avaliação 03º semestre Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 1

2 Apresentação Professor: Contato: Resumo profissional: Formação acadêmica e titulação: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com Desde 1995 atua profissionalmente na área de infraestrutura, desenvolvimento, automação comercial, consultoria em gestão da informação e reengenharia de processos; conhecimentos das linguagens CLIPPER, DELPHI, JAVA e C# bem como na área de banco de dados, redes e segurança da informação; Experiência na área de coordenação estratégica e gerencial de equipes; atua em mais de 10 empresas na região de Jequié, Ipiaú e Itabuna. Especialista em Gestão da Tecnologia e Informação. Bacharel em Sistemas de Informação. Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 2

3 Apresentação da ementa, Dinâmica da disciplina, plano de curso e avaliação Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 3

4 Professor: Curso: Disciplina: Semana 01 (aula 2-3): Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Processos de Software Modelos de processos, Ciclos de Vida 03º semestre Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 4

5 Processos de Software

6 Introdução Estamos envolvidos por processos Para atingirmos objetivos, realizamos uma ou mais atividades O objetivo poderá ser ou não atingido, com um maior ou menor grau de exatidão. Por que? Exemplos: A construção de um edifício A fabricação de um carro A organização de uma festa

7 Introdução Programação era vista como uma forma de arte Perguntas que surgiam: Por que demora tanto tempo para que os programas sejam construídos? Por que os custos são tão elevados? Por que não descobrimos todos os erros antes de entregarmos o software aos nossos clientes?

8 Introdução Desenvolver software de qualquer maneira não é Engenharia de Software Estamos corretos ao dizer que escrever o código, rodar e testar é um processo de software Processos surgiram com o objetivo de organizar o desenvolvimento de software Aumentar a qualidade Diminuir a manutenção e custos

9 Introdução O importante na Engenharia de Software é escolhermos bem o processo que será utilizado Temos que saber as vantagens e desvantagens de cada modelo Atividades fundamentais de um modelo de processo Especificação Projeto Implementação Validação Implantação

10 Processos de Software Um processo é organizado em atividades. Atividades são de responsabilidade de um ou mais membros da equipe. Atividades devem gerar um artefato de saída, que possa ser verificado, e podem requisitar um artefato de entrada. Um artefato é um modelo, documento ou código produzido por uma atividade. Uma entrega (liberação) é um artefato entregue ao cliente Um processo deve estabelecer uma série de marcos. Um marco é um ponto final de uma atividade de processo.

11 Exemplo Atividades de um Processo

12 Exemplo Artefatos de um Processo

13 Modelo de Processo É uma representação abstrata de um processo de software É uma proposta teórica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem A descrição deve ser apresentada em níveis de abstração formal e completa

14 Modelos de Processo A escolha de um modelo envolve: O tipo de software O tipo de empresa que está desenvolvendo O público que irá utilizar o software Alguns Modelos (mais genéricos) Cascata Evolucionário Baseado em componentes São amplamente usados São combinados frequentemente Dão origem a diferentes processos

15 Modelos de Processo Modelos adaptados: Incremental Espiral RUP Metodologias Ágeis

16 Modelo em Cascata Definição dos Requisitos Serviços, restrições, objetivos, origem a especificação do sistema Projeto de Sistema de Software Implementação e teste de unidade Desenvolve a arquitetura do software de forma abstrata Conjunto de programas ou unidades do programa. Verificação Integração e teste do sistema completo Integração e teste de Sistema Operação e Manutenção Fase mais longa do ciclo de vida.

17 Modelo em Cascata O resultado de cada fase consiste de um ou mais documentos aprovados A fase seguinte não deve começar antes que a fase anterior tenha terminado Na prática isso não ocorre...por que? Desvantagens: Custo de produção e aprovação de documentos Retrabalho significativo Problemas são resolvidos posteriormente Congelamento prematuro dos requisitos Pode levar a sistemas mal estruturados Divisão inflexível do projeto em estágios distintos

18 Modelo em Cascata Durante a fase final (operação e manutenção): Software é colocado em uso Erros e omissões nos requisitos originais são descobertos Erros de programação e projeto emergem Necessidades de novas funcionalidades é identificada Sistema deverá evoluir para permanecer útil Mudanças poderão implicar na repetição de estágios anteriores do processo.

19 Modelo em Cascata Sua vantagem consiste na documentação produzida em cada fase Deve ser usado somente: Quando os requisitos forem bem compreendidos Houver pouca probabilidade de mudanças radicais durante o desenvolvimento O Modelo em Cascata reflete o seu uso na maioria de outros processos de Software

20 Modelo de Desenvolvimento Evolucionário Descrição do Esboço Análise Projeto Desenvolvimento 1a. Versão Testes Análise Projeto Desenvolvimento 2a. Versão Testes

21 Modelo de Desenvolvimento Evolucionário É frequentemente mais eficaz do que a abordagem em cascata Produz subsistemas que atendam às necessidades imediatas do cliente A especificação pode ser desenvolvida de forma incremental Problemas: O processo não é visível Gerentes precisam de produtos para medir o progresso Sistemas desenvolvidos rapidamente torna inviável economicamente a produção de documentos Os sistemas são frequentemente mal estruturados

22 Modelo de Desenvolvimento Evolucionário Para sistemas de grande porte o modelo se torna inviável: Dificuldade em estabelecer uma arquitetura estável Dificuldade em integrar a contribuição das equipes Para sistemas de grande porte é interessante incorporar melhores práticas do modelo em cascata e evolucionário Tipos fundamentais de desenvolvimento evolucionário: Desenvolvimento exploratório Trabalhar com os requisitos e desenvolver um sistema final a cada etapa Desenvolvimento throwaway Trabalhar com os requisitos a fim de refiná-los utilizando um protótipo (prototipação)

23 Modelo Baseado em Componentes Especificação de requisitos Análise de componentes Modificação de requisitos Projeto de Sistema com Reuso Engenharia de Software baseada em componentes Depende de uma grande base de componentes reusáveis Depende de um Framework de integração destes componentes Alguns componentes podem ser comerciais e fornecem uma interface para comunicação com o sistema que irá utilizá-lo Desenvolvimento e Integração Validação de Sistema

24 Modelo Baseado em Componentes Vantagens: Tem a vantagem óbvia de reduzir a quantidade de software a ser desenvolvido Consequentemente reduzir custos e riscos Leva geralmente a uma entrega mais rápida do software Desvantagens: Compromissos com requisitos são inevitáveis Controle da evolução do sistema tende a ser perdido se novas versões dos componentes não estiverem sob o controle da organização que as utilizada

25 Modelo Incremental Definir requisitos iniciais Atribuir requisitos aos incrementos Projetar arquitetura de sistema Desenvolver incremento de sistema Validar incremento Integrar incremento Validar sistema Sistema Final Sistema incompleto

26 Modelo Incremental Identificam os serviços mais e menos importantes Um número de incrementos de entrega é definido Cada incremento fornecerá um subconjunto de funcionalidades do sistema Requisitos dos incrementos posteriores podem ser refinados, porém do incremento atual não poderá ser modificado

27 Modelo Incremental Vantagens: Os clientes não precisam esperar muito tempo até que uma versão do sistema esteja pronta Podem usar os incrementos iniciais como protótipos Existe um risco menor de falha geral do projeto Serviços com prioridade mais alta são entregues primeiro, consequentemente tendem a passar por uma bateria maior de testes

28 Modelo Incremental Desvantagens Pode ser difícil mapear os requisitos do cliente em incrementos de tamanho adequado Como os requisitos não são definidos detalhadamente até que um incremento seja implementado, pode ser difícil identificar os recursos comuns exigidos por todos os incrementos

29 Modelo Espiral

30 RUP Rational Unified Process Perspectiva Dinâmica Perspectiva Estática

31 Engenharia de Software Auxiliada por Computador (CASE) Classificação Ferramentas de planejamento Ferramentas de edição Ferramentas de gerenciamento de mudanças Ferramentas de gerenciamento de configuração Ferramentas de prototipação Ferramentas de apoio à métodos Ferramentas de processamento de linguagens Ferramentas de análise de programa Ferramentas de teste Ferramentas de depuração Ferramentas de documentação Ferramentas de reengenharia

32 Modelos de Processo adaptados: Incremental MARLA Espiral FELIPE MEIRA RUP ED Metodologias Ágeis - BRUNO Atenção: apresentação expositiva com slide entregar pesquisa escrita sobre os quatro modelos acima por marcosmoraisdesousa@gmail.com VALE ATÉ 01 PONTO NO TRABALHO EM GRUPO DA I UNIDADE Obs. Terminar antes ou depois do tempo estipulado (25 minutos) perde ponto! Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 32

33 Até a próxima Professor: Curso: Disciplina: Semana 01 (aula 2-3): Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Processos de Software Modelos de processos, Ciclos de Vida 04º semestre Prof. Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com 33