Workshop

1. Workshop Engenharia deSoftware e Sistemas

2. Engenharia de Software (Def.) Disciplina gerencial e tecnológica que lida com a produção e manutenção sistemática de produtos de software desenvolvidos dentro de estimativas de custo e tempo Deve-se entender por engenharia a ciência relacionada com o uso prático de conhecimentos científicos

3. O que é software? • Programas de computador e documentação associada • Produtos de software podem ser desenvolvidos para um cliente particular ou podem ser desenvolvidos para um mercado geral

4. Objetivos de Engenharia de Software • Obter software de qualidade • Com produtividade no seu desenvolvimento, operação e manutenção • Empregando profissionais que desenvolvam o software dentro de custos, prazos e níveis de qualidade controlados • E, além disso, que obtenham o melhor custo-benefício possível entre Qualidade  Produtividade

5. Motivação • Desenvolver sistemas de acordo com a intenção do cliente/usuário • Estabelecer noção sobre tempo e custo de desenvolvimento • Elaborar artefatos além do código • Analisar artefatos para estabelecer a qualidade do produto

6. Ciclo de Vida e Processo de Desenvolvimento de Software

7. O que é um modelo de ciclo de vida de processo de software? • Uma representação abstrata e simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de software

8. Principais Modelos do Ciclo de Vida de Software • Cascata • Modelo de Desenvolvimento Evolucionário • Programação Exploratória • Prototipagem descartável • Modelos Iterativos • Espiral • Incremental

9. Modelo Cascata(ou clássico) • Derivado de modelos existentes em outras engenharias • Sua estrutura é composta por várias etapas que são executadas de forma sistemática e seqüencial • Na prática, existe uma interação entre as etapas e cada etapa pode levar a modificações nas etapas anteriores

10. Definição de Requisitos Projeto do Sistema e do Software Implementação e Testes Unitários Integração e Teste do Sistema Operação e Manutenção Modelo Cascata

11. Definição de Requisitos Projeto do Sistema e do Software Implementação e Testes Unitários Integração e Teste do Sistema Operação e Manutenção Modelo Cascata na Prática

12. Versão Inicial Especificação Atividades Concorrentes Esboço de Descrição Desenvolvimento Versões Intermediárias Validação Versão Final Modelo de Desenvolvimento Evolucionário • Programação Exploratória • Prototipagem Descartável

13. Programação Exploratória • Idéia geral: • Desenvolvimento da primeira versão do sistema o mais rápido possível • Modificações sucessivas até que o sistema seja considerado adequado • Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários • Adequado para o desenvolvimento de sistemas onde é difícil ou impossível se fazer uma especificação detalhada do sistema • Principal diferença para os outros modelos é a ausência da noção de programa correto

14. Prototipagem Descartável • Como na programação exploratória, a primeira fase prevê o desenvolvimento de um programa para o usuário experimentar • No entanto, o objetivo aqui é estabelecer os requisitos do sistema • O software deve ser reimplementado na fase seguinte • A construção de protótipos com os quais os usuários possam brincar é uma idéia bastante atrativa: • Para sistemas grandes e complicados • Quando não existe um sistema anterior ou um sistema manual que ajude a especificar os requisitos

15. Prototipagem Descartável • Os objetivos do protótipo devem estar bem claros antes do início da codificação. Possíveis objetivos: • Entender os requisitos dos usuários • Definir a interface com os usuários • Demonstrar a viabilidade do sistemas para os gerentes. • Uma decisão importante a ser tomada é escolher o que será e o que não será parte do protótipo • Não é economicamente viável implementar todo o sistema! • Os objetivos do protótipo são o ponto de partida

16. Modelos Iterativos • Requisitos de sistema SEMPRE evoluem durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas • Iterações podem ser aplicadas a quaisquer dos modelos de ciclo de vida • Duas abordagens (relacionadas) • Desenvolvimento espiral • Desenvolvimento incremental

17. Desenvolvimento Espiral • Acrescenta aspectos gerenciais ao processo de desenvolvimento de software. • análise de riscos em intervalos regulares do processo de desenvolvimento de software • planejamento • controle • tomada de decisão • O processo é representado como uma espiral em vez de uma seqüência de atividades • Cada volta na espiral representa uma fase no processo • Não há fases fixas como especificação ou projeto - voltas na espiral são escolhidas dependendo do que é requerido • Riscos são avaliados explicitamente e resolvidos ao longo do processo

18. Determinação dos objetivos, alternativas e restrições Análise das alternativas e identificação e/ou resolução de riscos Análise de Riscos Simulações, modelos e benchmarks Planejamento Desenvolvimento e validação da versão corrente do produto Desenvolvimento Espiral

19. Desenvolvimento Incremental • Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida • Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais • Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores • Em certos aspectos é similar à programação exploratória. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento

20. Desenvolvimento Incremental

21. Processo • Conjunto de atividades • bem definidas • com responsáveis • com artefatos de entrada e saída • com dependências entre as mesmas e ordem de execução • com modelo de ciclo de vida

22. Processo • é uma ação regular e contínua (ou sucessão de ações) realizada de forma bem definida, levando a um resultado • é um conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo • define quem está fazendo o que, quando e como para atingir um certo objetivo

23. Modelo de Processo • é uma representação de um processo, usualmente envolvendo • atividades a serem realizadas • agentes que realizam as atividades • artefatos (produtos) gerados • recursos necessários (consumidos)

24. Exemplos de processos • Processos tradicionais (pesados) • RUP, OPEN, Catalysis • Processos ágeis (leves) • XP, Agile modeling, Crystal, pragmatic programming, Internet Speed, Scrum, ...

25. Exemplos de processos • Consenso em torno de • Iteratividade • Participação de usuários • Flexibilidade de configuração para projetos específicos • Comunicação entre membros da equipe

26. Exemplos de processos • Divergências em torno de • Detalhamento de atividades a serem seguidas • Critério de conclusão da execução das atividades • Arquitetura robusta (RUP) • Arquitetura para o contexto da iteração atual (agile modeling) • Rigor na atribuição de tarefas a responsáveis • workers (RUP) • alocação sob demanda e interesse (XP) • Artefatos (documentação) gerados

27. elaboração construção transição concepção tempo Ciclo de Vida • O ciclo de vida de um sistema consiste de quatro fases: • Concepção (define o escopo do projeto) • Elaboração (detalha os requisitos e a arquitetura) • Construção (desenvolve o sistema) • Transição (implanta o sistema)

28. Inception Elaboration Construction Transition Preliminary iteration Architect. iteration Architect. iteration Devel.. iteration Devel.. iteration Devel.. iteration Transition iteration Transition iteration • Cada fase é dividida em iterações: Minor Milestones: Releases

29. Cada iteração • é planejada • realiza uma seqüência de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas • geralmente resulta em uma versão executável do sistema • é avaliada segundo critérios de sucesso previamente definidos

31. Planejamento/Gerenciamento

32. Conteúdo • Erros clássicos de planejamento e gerenciamento • O que é projeto? • Ciclo de vida de projetos • Elementos essenciais • Objetivos gerais do planejamento e gerenciamento do projeto de software

33. Erros Clássicos Desenvolvimento de Software é uma atividade complicada, então evite erros tais como ...

34. Pessoas • Motivação incoerente • Esforço do pessoal e chefe de férias … • Pessoal problemático • Uma pessoa pode desconcentrar uma equipe … • Heroísmo • Posso fazer tudo, não preciso da equipe …

35. Pessoas • Mais pessoas no final do projeto • Em pequeno incêndio, jogue gasolina … • Atrito entre desenvolvedores e clientes • Se você não adicionar isso, não quero mais … • Falha de contratos • Com o módulo M, a ser criado pela empresa E, vamos melhorar nosso cronograma …

36. Pessoas • Expectativas irreais • Vamos terminar o projeto em 6 meses … • Falta de interação com o usuário • Isso é ambíguo …, então vamos decidir sozinhos. • Crença cega • Essa parte do sistema é muito simples, em 1 ou 2 dias removemos todos os erros …

37. Processo • Planejamento insuficiente • Esse sistema é simples, não há o que planejar … • Abandono de plano sob pressão • Devido ao cronograma apertado, vamos codificar logo depois da especificação de requisitos e não vamos testar …

38. Processo • Garantia de qualidade prejudicada • Só precisamos fazer os testes a partir da GUI • Controle de gerenciamento insuficiente • O que já fizemos? Não sei, mas sem problema … • Sem estimativas para tarefas necessárias • Não precisamos registrar o tempo para tarefa T

39. Processo • Planejamento para controlar depois • Fizemos em 3 meses, o que planejamos fazer em 2, mas depois nós ganhamos tempo … • Programação sem padronização • Vou codificar de qualquer jeito; ganho tempo …

40. Produto • Requisitos demais • Sei que o usuário não pediu, mas vamos melhorar a performance do sistema … • Desenvolvedor exagerado • Sei que o sistema não precisa e que não domino a tecnologia, mas vou usar o recurso R … • Desenvolvimento orientado a pesquisa • Sei que vou desenvolver funcionalidade F, que é estado-da-arte, mas minha estimativa é razoável …

41. Tecnologia • Síndrome da bala de prata • Vou usar o gerador de GUIs e não terei problemas quanto ao desenvolvimento das GUIs … • Estimativa otimista com novas ferramentas ou métodos • Vou usar ferramenta F, no lugar de G, daí vou ganhar tempo …

42. Tecnologia • Troca de ferramentas no meio do projeto • Vou usar a nova versão de F, pois tem mais recursos … • Falta de controle sobre o código-fonte • Vamos trabalhar em paralelo no módulo M (único arquivo) para ganharmos tempo …

43. Projeto: Definição PMI • Um empreendimento temporário realizado para criar um produto ou serviço único

44. Por que Gerenciar? • Para atingir objetivos e produzir resultados • Concentrar responsabilidade e autoridade para atingir objetivos • Coordenar e integrar todas as atividades para chegar aos resultados

45. Objetivos do Gerenciamento Custo • Objetivo: • Limite de orçamento • Prazo de entrega • Desempenho Almejado Tempo Desempenho

46. Qualidades de Gerente • Liderança • Comunicação • Resolver problemas • Negociação • Influenciar a organização • Mentor • Especialista técnico e em processo

47. Gerenciamento das Tarefas • Milestones • Ponto final de uma atividade do processo de software (um marco no cronograma) • Deliverables • Resultado do projeto a ser entregue ao cliente. Usualmente entregue ao final de uma fase.

48. Por que Planejar? • Criar propostas que sejam • Econômicamente viáveis e • Realizadas com recursos financeiros pré-estabelecidos • E que estejam de acordo com as necessidades requisitadas • Representar precisamente o que se pode fazer

49. Planejamento e Estimativa • Registre suas estimativas para comparar com os resultados reais no final do projeto • Planejamento continua durante desenvolvimento e manutenção • Planejamento inicial não é suficiente • Planejamento detalhado só ocorre após a especificação de requisitos

50. Planejamento e o Processo de Software