Processos de Software. Aécio Costa

Transcrição

1 Processos de Software Aécio Costa

2 Processos de Software Atributos de Qualidade no Software

3 Processo Podemos considerar um conjunto de tarefas ordenadas como sendo um processo: uma s é rie de etapas que envolvem atividades, restri ç õ es e recursos para alcan ç ar a sa ída desejada. Pfleeger (2004)

4 Processo

5 Processo de Software Um conjunto coerente de atividades para a produ ç ã o de software. (SOMMERVILE, 2011) Um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um produto de software. (SOFTEX, 2010)

6 Quando falamos em Software... Podem ser desenvolvidos do zero. Podem ser desenvolvidos por meio da extensão/modificação de softwares existentes. 6

7 Software Controle da Aeronave Site Comércio Eletrônico Ou até mesmo...

8

9 H á v á rios processos de software, mas todos devem incluir quatro atividades fundamentais. Especificação de software Desenvolvimento de software Validação de software Evolução do software

10 Especificação de software Clientes e engenheiros definem o software a ser produzido e as restrições de sua operação.

11 Desenvolvimento de software Momento onde o software é projetado e programado.

12 Validação de software Onde o software é verificado para garantir que é o que o cliente quer.

13 Evolução do software Momento em que o software é modificado para refletir a mudança de requisitos do cliente e do mercado.

14 Apesar disso... Não existe processo de Software ideal. (SOMMERVILLE) NÃO EXISTE BALA DE PRATA

15 Mas, os processos podem incluir t é cnicas garantidas e tirar vantagens das melhores pr á ticas na engenharia de software industrial. Processos de software podem ser aprimorados por meio de padronização de processo: Diversidade de Processos na organização é reduzida ao longo do tempo; Aprimoramento da comunicação; Redução no tempo de treinamento.

16 Processos em Software geram Produtos de Trabalho: Documento de requisitos Modelo de arquitetura de software Diagrama de classes Etc.

17 Modelo de Software

18 Um modelo é uma representação simplificada de um processo de software. (SOMMERVILLE, 2011) Quando o processo envolve a elabora ç ã o de um produto, algumas vezes nos referimos a ele como CICLO DE VIDA. (PFLEEGER, 2004)

19 Existem v á rios modelos de processo de software (ou paradigmas de engenharia de software); Cada um representa uma tentativa de colocar ordem em uma atividade inerentemente caótica; Muitos são pequenas variações dos modelos básicos.

20 Codifica-remenda; Modelo Cascata; Modelo de Prototipação; Modelo Incremental; Modelo Espiral; Técnicas de 4ª Geração; Desenvolvimento Baseado em Componentes - COTS.

21 Codifica-remenda Corresponde a desenvolver sem planejar; Documentação zero; Nenhum controle gerencial; Os desenvolvedores v ã o remendando o c ó digo à medida que os erros são encontrados. 21

22 Codifica-remenda

23 Modelo Cascata Introduzido em 1970 por Royce; É o modelo mais antigo e comumente o mais usado da engenharia de software; Requer uma abordagem sistemática, sequencial ao desenvolvimento de software; O resultado de uma fase se constitui na entrada da outra.

24 Modelo Cascata

25 Modelo Cascata 1. Análise e definição dos requisitos. Os serviços, restrições e metas do sistema s ã o estabelecidos por meio de consultas aos usu á rios. Em seguida, s ã o definidos em detalhes e funcionam como uma especificação do sistema. 2. Projeto de sistema e software. O processo do projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para os sistemas de software, por meio da definição de uma arquitetura geral do sistema. O projeto de software envolve identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos.

26 Modelo Cascata 3. Implementa ç ã o e teste unit á rio. Durante esse est á gio, o projeto de software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atenda a sua especificação. 4. Integra ç ã o e teste de sistema. As unidades individuais do programa ou programas s ã o integradas e testadas como um sistema completo para assegurar que os requisitos de software tenham sido atendidos. Ap ó s o teste, o sistema de software é entregue ao cliente.

27 Modelo Cascata 5. Opera ç ã o e manuten ç ã o. Normalmente (embora n ão necessariamente), essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve a correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhoria de implementação das unidades do sistema e ampliação de seus serviços em resposta às descobertas de novos requisitos.

28 Modelo Cascata Vantagens Facilidade de entendimento e implementação; Muito usado e conhecido (na teoria); Refor ç a bons h á bitos: defina antes de modelar, modele antes de codificar; Identifica entregas e marcos; Orientado por documentos; Funciona bem com produtos maduros e equipes fracas.

29 Modelo Cascata Desvantagens Projetos reais raramente seguem o fluxo sequencial 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 (na instalação); Difícil identificação de sistemas legados (não acomoda a engenharia reversa).

30 Modelo de Prototipação O objetivo é entender os requisitos do usuário e, assim, obter uma melhor definição dos requisitos do sistema; Possibilita que o desenvolvedor crie um modelo (prot ó tipo) do software que deve ser construído; Apropriado para quando o cliente n ã o definiu detalhadamente os requisitos.

31 Modelo de Prototipação (PRESSMAN, 2005)

32 Modelo de Prototipação (RAMOS, 2009)

33 Modelo de Prototipação Vantagens Reduz o risco de requisitos incorretos/mal elicitados; Bom quando os requisitos estão em constante mudança/evolução.

34 Modelo de Prototipação Desantagens O cliente n ã o sabe que o software que ele v ê n ã o considerou, durante o desenvolvimento, a qualidade global e a manutenabilidade a longo prazo; O desenvolvedor frequentemente faz uma implementa ç ão comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo.

35 Modelo Incremental Sugerido por Mills em 1980 (SOFTEX, 2011); O modelo incremental combina elementos do modelo sequencial linear (cascata) com a filosofia interativa da prototipagem (PRESSMAN, 2005); Objetiva a elabora ç ã o de um produto operacional a cada incremento;

36 Modelo Incremental Durante o desenvolvimento de um incremento: Podem ocorrer análise dos requisitos de outros incrementos; Mudança dos requisitos do incremento atual não são aceitas.

37 Modelo Incremental

38 Modelo Incremental A versão inicial é frequentemente o núcleo do produto (a parte mais importante); A evolução acontece quando novas características são adicionadas à medida que são sugeridas pelo usuário.

39 Modelo Incremental Este modelo é importante quando é dif ícil estabelecer a priori uma especificação detalhada dos requisitos; As novas vers õ es podem ser planejadas de modo que os riscos t é cnicos possam ser administrados (Ex. disponibilidade de determinado hardware).

40 Modelo Incremental

41 Modelo Incremental

42 Modelo Incremental Vantagens O custo de acomodar as mudan ç as nos requisitos do cliente é reduzido. A quantidade de análise e documentação a ser refeita é muito menor do que o modelo em cascata; É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer coment á rios sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução do software por meio de documentos e projetos de software;

43 Modelo Incremental Vantagens É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se toda a funcionalidade n ã o for inclu í da. Os clientes podem usar e obter ganhos a partir do software inicial antes do que é possível com um processo em cascata. 43

44 Modelo Incremental Desvantagens O processo não é visível. Os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas são desenvolvidos com rapidez, n ã o é economicamente vi á vel produzir documentos que reflitam cada uma das versões do sistema; A estrutura do sistema tende a se degradar com a adição de novos incrementos. A menos que tempo e dinheiro sejam dispendidos em refatora ç ã o para melhoria de software, as constantes mudan ças tendem a corromper sua estrutura. Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso. 44

45 Modelo Espiral Proposto por Boehm em 1986; É um modelo de processo de software evolucionário que combina a natureza interativa da prototipagem com os aspectos controlados e sistemáticos do modelo sequencial linear (PRESSMAN, 2005); O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa; (RAMOS, 2009)

46 Modelo Espiral DETERMINA OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES AVALIA ALTERNATIVAS E RISCOS

47 Modelo Espiral DETERMINA OBJETIVOS, ALTERNATIVAS E RESTRIÇÕES AVALIA ALTERNATIVAS E RISCOS Cada volta no espiral é dividida em quatro setores Estabelecimento de objetivos Avaliação e redução de riscos Planejamento Desenvolvimento e validação

48 Modelo Espiral Não existem fases fixas no modelo; A gerência decide como estruturar o projeto em fases; Os riscos s ã o explicitamente avaliados e resolvidos durante todo o processo.

49 Modelo Espiral É composto por quatro setores: Estabelecimento dos objetivos: determina ç ã o dos objetivos e alternativas (compra, projeto, reutilização). As restrições também são identificadas e registradas; An á lise dos riscos: avalia ç ã o das alternativas e do potencial de riscos que cada uma apresenta visando definir melhor a estratégia a ser adotada;

50 Modelo Espiral Desenvolvimento e valida ç ã o: caracteriza-se pelo desenvolvimento e verificação do produto; Planejamento: o projeto é revisado, e uma decis ã o é tomada a respeito da continuidade do modelo com mais uma volta no espiral. Caso se decida pela continuidade, planos s ã o elaborados para a próxima fase do projeto (SOMMERVILLE, 2011);

51 Modelo Espiral As diversas voltas na espiral são utilizadas para se construir as partes do produto; Partes intermedi á rias e ainda incompletas do produto n ã o s ão entregues ao cliente; Essa abordagem é utilizada apenas para a redução dos riscos e para o enfoque maior naquilo que é mais importante/complexo/crítico no sistema.

52 Técnicas de 4ª Geração O paradigma Técnicas de Quarta Geração (4GT) da engenharia de software concentra-se na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa; Depende basicamente de ferramentas que permitem construir a especifica ç ã o e a partir dela derivar a aplica ç ão automaticamente.

53 Técnicas de 4ª Geração

54 Estratégia para um PROJETO em 4ª Geração Para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementa ç ã o usando uma linguagem de quarta geração; Para grandes projetos é necess á rio desenvolver uma estrat é gia de projeto. De outro modo ocorrer ã o os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade).

55 Testes O desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.

56 PROPONENTES redução dramática no tempo de desenvolvimento do software (aumento de produtividade). OPONENTES As 4GL atuais não são mais fáceis de usar do que as linguagens de programação; o código fonte produzido é ineficiente; a manutenibilidade de sistemas usando t é cnicas 4GL ainda é questionável.

57 Desenvolvimento Baseado em Componentes Baseada em reuso sistem á tico onde os sistemas s ã o integrados a partir de componentes existentes ou de sistemas COTS (Commercial-of-the-shelf); Sistemas COTS são, geralmente, sistemas de aplicação completos que oferecem uma API (Application Programming Interface).

58 Desenvolvimento Baseado em Componentes Estágios do processo Análise de componentes; Modificação de requisitos; Projeto de sistema com reuso; Desenvolvimento e integração.

59 Para escolha de um Modelo de Processo de Software: Natureza do projeto e da aplicação; Métodos e ferramentas a serem usados; Controles e produtos que precisam ser entregues.

60 Identificando Modelos de Software Entrega Individual Qual o modelo você utilizaria e porque? Cite qual tecnologia você utilizaria.

61 Caso 1 Uma empresa do ramo de Confec ç õ es Confex deseja desenvolver um software ERP com os m ó dulos de Contabilidade, CPR, Folha de Pagamento, PDV e RH. A empresa necessita do m ó dulo RH e Folha de Pagamento dentro de 4 meses da data de início do Projeto. Após 3 meses o CPR e 1 mês o de Contabilidade e RH. O funcionamento e regras do sistema é compat í vel com os existentes no mercado. A empresa necessita que haja documenta ç ã o, pois n ã o h á garantia que o software ap ós desenvolvido será mantido pelo setor de tecnologia da mesma posteriormente. 61

62 Caso 2 Uma empresa do ramo de mobilidade MobileS deseja criar um novo conceito no uso de dispositivos m ó veis como smartphones e tablets utilizando uma nova tecnologia desenvolvida por uma empresa Chinesa que promete uma invovação na área mobile. Sua empresa será contratada para construir estudos de viabilidade técnica e testes com Usuário sobre usabilidade e funcionamento, al é m de desenvolver o software utilizando essa tecnologia. A empresa precisa de rapidez para entender o funcionamento da tecnologia e n ão perder o time to market (perde o tempo de ir a mercado).

63 Caso 3 A OpenOffice deseja desenvolver um novo processador de texto. Ela necessita que em 4 meses sua empresa entregue o processador com funcionalidades básicas para manipulação de arquivos. Depois disso a OpenOffice quer funcionalidades de edição e produção de textos avançadas em 2 meses e por ultimo funções de verificação e grafia ortográfica. O cliente necessita que cada vers ã o entregue do software esteja totalmente estável, pois irá apresentá-la para outros clientes, além de fazer revisões detalhadas sobre o produto.

64 Caso 4 A padaria P ã o de L ó deseja desenvolver um sistema para gerenciar seu negó cio que é simples e funciona basicamente como todas as padarias. Ela adiquiriu uma ferramenta chamada Maker da empresa Softwell para desenvolver esse sistema. A padaria espera que em no máximo 1 mês o software esteja pronto e funcionando em seu estabelecimento.

65 Caso 5 A Atrix Soluções Industriais pretende desenvolver um Sistema integrado para sua f á brica, um dos fatores levados em considera ç ã o pela empresa é que ela ir á terceirizar em empresas diferentes os m ó dulos do sistema que devem se comunicar quando tudo estiver pronto. Sua empresa é responsável por desenvolver o módulo de automação que se comunica com outros 2 m ó dulos feitos por empresas de outros pa í ses. (China e Í ndia), seu cliente espera que voc ê permita que os outros softwares se utilizem de fun ç ões básicas desenvolvidas na sua solução.