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

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

Processos de desenvolvimento de software FACULDADE DE CIÊNCIAS DE ENGENHARIA E TECNOLOGIA 1º CICLO DE AULAS MAGNAS.

Apresentações semelhantes


Apresentação em tema: "Processos de desenvolvimento de software FACULDADE DE CIÊNCIAS DE ENGENHARIA E TECNOLOGIA 1º CICLO DE AULAS MAGNAS."— Transcrição da apresentação:

1 Processos de desenvolvimento de software FACULDADE DE CIÊNCIAS DE ENGENHARIA E TECNOLOGIA 1º CICLO DE AULAS MAGNAS

2 Minha apresentação

3

4

5

6

7 Engenharia de Software

8

9

10

11  O processo de software é visto por uma sequência de actividades que produzem uma variedade de documentos, resultando num programa satisfatório e executável.  O desenvolvimento de software é caracterizado por uma sobreposição de actividades necessárias para especificar, projectar e testar retorno dos resultados do software que está a ser criado.

12

13 Modelos de Processo de Software  Existem vários modelos de processo de software (ou paradigmas de engenharia de software)  Cada um representa uma tentativa de colocar ordem em uma actividade inerentemente caótica

14 Modelos de Processo de Software  O Modelo Sequencial Linear também chamado Modelo Cascata  O Modelo de Prototipação  O Modelo RAD (Rapid Application Development)  Modelos Evolutivos de Processo de Software O Modelo Incremental O Modelo Espiral O Modelo de Montagem de Componentes  Técnicas de Quarta Geração  Metodologias Ágeis

15

16 16 Regra geral… Ouvir o cliente Ouvir o cliente Construir, Rever o protótipo Construir, Rever o protótipo O cliente Testa o protótipo O cliente Testa o protótipo

17 O Modelo em Cascata  modelo mais antigo e o mais amplamente Utilizado na engenharia de software  modelado em função do ciclo da engenharia convencional  requer uma abordagem sistemática, sequencial ao desenvolvimento do software  o resultado de uma fase constitui-se na entrada da/para a outra

18 Modelo em cascata

19  Envolve a licitação de requisitos do sistema, com uma pequena quantidade de projecto e análise de alto nível;  Preocupa-se com aquilo que se como engenharia progressiva do produto de software;  Inicia com um modelo conceitual de alto nível para um sistema e prossegue com o projecto, implementação e teste do modelo físico do sistema.

20 Modelo em cascata Análise de Requisitos do Software  O processo de licitação dos requisitos é intensificado e concentrado especificamente no software  deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidas  os requisitos (para o sistema e para o software) são documentados e revistos com o cliente

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

22 Implementação  tradução das representações do projecto para uma linguagem “artificial” resultando em instruções executáveis pelo computador e implementado num ambiente de trabalho.

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

24 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 no ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

25 Alguns Problemas com o Modelo em Cascata  Projectos 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 projectos 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).

26 Dica  Embora o Modelo em Cascata tenha fragilidades, ele é significativamente melhor do que uma abordagem casual de desenvolvimento de software

27

28  o objectivo é entender os requisitos do utilizador 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.

29

30 1- OBTENÇÃO DOS REQUISITOS: desenvolvedor e cliente definem os objectivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais.

31 2- PROJECTO RÁPIDO: representação dos aspectos do software que são visíveis ao utilizador (abordagens de entrada e formatos de saída) 3- CONSTRUÇÃO DO PROTÓTIPO: implementação rápida do projecto

32 4 -AVALIAÇÃO DO PROTÓTIPO  Cliente e desenvolvedor avaliam o protótipo 5.REFINAMENTO DO PROTÓTIPO: Cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.

33 6- 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.

34 Alguns Problemas com a Prototipação  O 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  O desenvolvedor frequentemente faz uma implementação comprometida (utilizando o que está disponível) com o objectivo de produzir rapidamente um protótipo

35 Comentários sobre o Paradigma de Prototipação  ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente.  a chave é definir as regras do jogo logo no começo.  o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo para definir os requisitos

36

37  RAD ( Rapid Application Development) é um modelo sequencial linear que enfatiza um ciclo de desenvolvimento extremamente curto  O desenvolvimento rápido é obtido usando uma abordagem de construção baseada em componentes.

38  Os requisitos devem ser bem entendidos e o alcance do projecto restrito  O modelo RAD é utilizado principalmente para aplicações de sistema de informação  Cada função principal pode ser direccionada para uma equipa RAD separada e então integrada para formar o todo.

39

40 Desvantagens:  Exige recursos humanos suficientes para todas as equipas  Exige que desenvolvedores e clientes estejam comprometidos com as actividades de “fogo-rápido” a fim de terminar o projecto num prazo bem curto

41

42 Existem situações em que a engenharia de software necessita de um modelo de processo que possa acomodar um produto que evolui com o tempo.

43  quando os requisitos de produto e de negócio mudam conforme o desenvolvimento prossegue  quando uma data de entrega apertada (mercado) - impossível a conclusão de um produto completo  quando um conjunto de requisitos importantes é bem conhecido, porém os detalhes ainda devem ser definidos

44  Os modelos evolutivos são iterativos  possibilitam o desenvolvimento de versões cada vez mais completas do software Modelos Evolutivos de Processo de Software  O Modelo Incremental  O Modelo Espiral  O Modelo de Montagem de Componentes

45

46  As Metodologias Ágeis de Desenvolvimento de Software são indicadas como sendo uma opção alternativa às abordagens tradicionais para desenvolver softwares;  Comparadas a outras metodologias, produzem pouca documentação.  É recomendado documentar o que realmente será útil;

47  São recomendadas para projetos que:  existem muitas mudanças;  os requisitos são passíveis de alterações;  a recodificação do programa não acarreta alto custo;  a equipe é pequena;  as datas de entrega curtas acarretam alto custo;  o desenvolvimento rápido é fundamental.  Em essência, as Metodologias Ágeis foram desenvolvidas com o objectivo de vencer as fraquezas percebidas e reais da Engenharia de Software (Pressman, 2010).

48 O Manifesto Ágil  Em 2001, Kent Beck e mais 16 desenvolvedores, produtores e consultores de software, que formavam a Aliança Ágil, assinaram o Manifesto de Desenvolvimento Ágil de Software, declarando:

49  Estamos descobrir melhores métodos de desenvolvimento de software fazendo-o e ajudando outros a fazê-lo. Por meio desse trabalho, passamos a valorizar:  Indivíduos e interacções em vez de processos e ferramentas.  Software a funcionar em vez de uma documentação abrangente.  Colaboração do cliente em vez da negociação de contractos.  Resposta a modificações em vez de seguir um plano.  Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda.

50 Os 12 princípios do Manifesto Ágil I. Garantia da satisfação do consumidor com entrega rápida e contínua de softwares funcionais. II. Mudanças de requisitos, mesmo no fim do desenvolvimento, ainda são bem-vindas. III. Frequentemente são entregues softwares funcionais (semanas, em vez de meses). IV. Desenvolvedores e pessoas relacionadas aos negócios devem trabalhar, em conjunto, até o fim do projecto. V. Construir projectos com indivíduos motivados, dar-lhes ambiente e suporte necessários e confiar que cada um fará o seu trabalho. VI. Uma conversa face a face é o método mais eficiente e efectivo de transmitir informações para e dentro de uma equipa de desenvolvimento.

51 Os 12 princípios do Manifesto Ágil VII. Software em funcionamento é a principal medida de progresso. VIII. Desenvolvimento sustentável, de modo a manter um ritmo constante indefinidamente. IX. Atenção contínua para com a excelência técnica e para com bons projectos aumenta a agilidade. X. Simplicidade – a arte de maximizar a quantidade de trabalho não efectuado – é essencial. XI. As melhores arquitecturas, requisitos e projectos emergem de equipes auto-organizáveis. XII. Em intervalos regulares, a equipa deve reflectir sobre como se tornar mais eficiente.

52 Algumas metodologias  XP (Extreme Programming)  DAS (Desenvolvimento Adaptativo de Software)  DSDM (Dynamic Software Development Method)  Scrum  Kanban  Crystal  FDD (Feature Driven Development)  Modelagem Ágil (AM)  Processo Unificado Ágil (AUP)

53

54  As plataformas oferecem suporte a aplicativos e soluções projectadas para os menores dispositivos, bem como para as maiores empresas.

55 Ferramentas de desenvolvimento e linguagens  Ferramentas existem várias dependendo da linguagens.  As linguagens também são muitas mas é possível destacar algumas  A linguagem Java, apesar de ter uma curva de aprendizagem um pouco grande é o destaque dos últimos 20 anos  A linguagem C nos últimos tempos tem vindo a concorrer com o java  C#, C++, Python… têm a sua fatia no mercado

56 Por áreas de desenvolvimento temos…  Desenvolvimento Web  PHP, ASP.NET, Java (Servlets, JSP e JSF)  Ferramentas auxiliares: Drupal, Joomla, Plone  Desenvolvimento corporativo e de servidores  Java EE e A plataforma.NET tem várias propostas  Desenvolvimento embedded e móvel  Android, IOS, Windows Mobile, BlackBerry  Desenvolvimento para a nuvem  Existem propostas para quase todas a lingugagens

57 Esta foi apenas uma conversa… há um grande caminho a se fazer… Entretanto

58 58 Selecção do modelo  Deve haver flexibilidade na escolha  Projectos pequenos: ciclo clássico  Limites severos de tempo: DRA  Data entrega muito próxima: modelo incremental Os modelos vistos até agora não são, por si só, suficientes para o sucesso de projectos baseados no Paradigma Orientado a Objectos

59 Selecção do modelo…  Para escolha de um Modelo de Processo de Software:  natureza do projecto e da aplicação  métodos e ferramentas a serem utilizadas  controlos e produtos que é preciso entregar

60

61 Joaquim José Hangalo facebook jaiKim Jaime hangalo.centrofsd.org


Carregar ppt "Processos de desenvolvimento de software FACULDADE DE CIÊNCIAS DE ENGENHARIA E TECNOLOGIA 1º CICLO DE AULAS MAGNAS."

Apresentações semelhantes


Anúncios Google