05/05/2010. Década de 60: a chamada Crise do Software

Transcrição

1 Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: Edição: 6 2 Disciplina gerencial e tecnológica lida com a produção e manutenção de produtos de software desenvolvidos dentro de estimativas de custo e tempo. Trata aspectos relacionados a Processos, Métodos, Técnicas, Ferramentas e Ambientes de suporte Desenvolver Software não é só programação! Obter software de qualidade Com produtividade no seu desenvolvimento, operação e manutenção Dentro de custos, prazos e níveis de qualidade controlados Com o melhor custo-benefício entre Qualidade e Produtividade 3 4 Década de 60: a chamada Crise do Software Desenvolvimento fora de controle Iniciou como um problema de Custo e Produtividade. Mais importante: era um problema de Qualidade Década de 70 Programação Estruturada Projeto Estruturado 5 6 1

2 Década de 80 Análise Estruturada (DFDs, Dicionário de Dados, Diagrama ER, de Estados, etc.) Ferramentas CASE Década de 90 Análise e Projeto OO. Modelagem de acordo com o mundo real. Características e Comportamento de Objetos. Processo Unificado Anos 2000 Metodologias Ágeis Novos paradigmas: SOA, Aspectos, Model-Driven Architecture, etc. 7 8 Software Programa de computador e documentação associada. Produtos de software podem ser desenvolvidos para um cliente particular ou podem ser desenvolvidos para um mercado geral. Processo Uma série conectada de ações, atividades, mudanças, etc., realizada de forma bem definida por atores com a intenção de satisfazer um propósito ou objetivo. Define quem está fazendo o quê, quando e como para atingir um certo objetivo Entrada Processo (atividades e sub-processos) Saída 9 10 Processo de Software Conjunto de atividades, métodos, práticas e transformações que guiam pessoas na construção de Software

3 São 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. Contêm: Esqueleto do processo Ordem de precedência das atividades Artefatos e produtos gerados Seqüenciais Cascata ou Clássico Modelos Evolucionários Programação Exploratória Prototipagem Descartável Específicos Métodos formais Iterativos Espiral Incremental Modelo 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 Requisitos Análise Projeto lementação Testes Operação e Manutenção Requisitos Comunicação Análise - Iniciação do projeto - Levantamento de Requisitos Planejamento Projeto lementação - Estimativas - Cronograma - Monitoramento - Análise - Projeto Modelagem Construção Testes - Codificação - Teste lantação Operação e Manutenção - Entrega - Manutenção - Teste

4 Progresso do projeto (% codificado) 05/05/2010 É simples e fácil de aplicar, facilitando o planejamento Fixa pontos específicos para a entrega de artefatos Pressupõe que os requisitos ficarão estáveis 100% Início da integração Deadline original Porém, atrasa a redução de riscos! Tempo Planejamento Esboçar escopo e requisitos Fazer estimativas razoáveis sobre recursos, custos e prazos Análise e Especificação de Requisitos Refinar requisitos e escopo Entender o domínio do problema, com comportamento e funcionalidades esperados Projeto Incorporar requisitos tecnológicos aos requisitos essenciais do sistema Fazer o projeto da arquitetura do sistema e projeto detalhado do sistema lementação Traduzir o projeto em uma forma passível de execução pela máquina. Codificação Testes Realizar diversos níveis de teste, de forma a fazer a verificação do software. lantação, Operação e Manutenção Colocar o software em produção Treinar pessoas Manter o software Gerenciar os serviços Programação exploratória Idéia geral: Modificações sucessivas até que o sistema seja considerado adequado Desenvolvimento da primeira versão do sistema o mais rápido possível Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários

5 Programação exploratória 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 Prototipagem 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 Prototipagem Prototipagem É útil para sistemas grandes e complicados Ou quando não existe um sistema anterior ou manual que ajude a especificar os requisitos Métodos Formais Idéia geral: Uma especificação formal (definição matemática, não ambígua) do software é desenvolvida e posteriormente transformada em um programa através de regras que preservam a corretude da especificação esp. 1 esp. 2 implement. Métodos Formais O próprio processo de desenvolvimento garante que o programa faz exatamente o que foi especificado É possível gerar programas corretos e completos por construção Têm sido aplicados apenas ao desenvolvimento de sistemas críticos (por questões de segurança!)

6 Motivação: requisitos de sistema sempre evoluem durante o projeto Deve-se dividir para conquistar Duas abordagens Desenvolvimento Incremental Desenvolvimento Espiral Desenvolvimento Incremental A idéia é de desenvolver e entregar o software em incrementos, com cada incremento entregando parte da funcionalidade requerida. Requisitos são definidos antes do desenvolvimento do incremento, sendo os mais críticos priorizados. Req A&P I/T Iteração 1 Req A&P I/T Iteração 2 Req A&P I/T Iteração 3 TEMPO Incremental: são adicionados pedaços completos Iterativo: esboços ou pedaços incompletos do produto são adicionados a cada iteração Desenvolvimento em Espiral O processo é representado como uma espiral em vez de uma seqüência de atividades. Cada volta na espiral representa uma fase no processo Acrescenta aspectos gerenciais Planejamento, tomada de decisão Análise de Riscos Porém, é complexo e requer experiência na avaliação de riscos! Desenvolvimento em Espiral [Pressman] Desenvolvimento em Espiral [Boehm]

7 Progresso do projeto (% codificado) 05/05/ % Ciclo de vida iterativo Ciclo de vida tradicional Tempo Início: década de 90 Reação contra métodos pesados, vistos como lentos e burocráticos Idéia central: tornar simples o que dificultava o desenvolvimento de software Geralmente aplicado em projetos onde os Requisitos e Prioridades são instáveis Hoje representa uma família de processos de desenvolvimento. Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que: Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o cliente é mais importante do que negociação de contratos. Adaptação a mudanças é mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda extreme Programming Scrum FDD Lean Software Development Cristal Family (...) Errado - Metodologia Ágil não é o caos!

8 Surgimento Em meados de 1990, Kent Beck, procurou formas mais simples e eficientes de desenvolver Software. Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - extreme Programming Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança Levar todas as boas práticas ao extremo Se testar é bom, vamos testar toda hora! Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! Se integrar é bom, vamos integrar a maior quantidade de vezes possível! Se iterações curtas são boas, vamos deixar as iterações realmente curtas! Metáfora Procura facilitar a comunicação com o cliente, entendendo a realidade dele. Projeto simples O código está, a qualquer momento, na forma mais simples que passe todos os testes. Pequenas versões O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos Refatoração Padrão de codificação A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. Programação em Pares Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. Propriedade coletiva do código A equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Todo código é desenvolvido segundo um padrão. 40 horas por semana Cada programador trabalha 40 horas por semana, no máximo Reuniões em pé Reuniões rápidas e diárias com a equipe, para discutir apenas o essencial Cliente sempre presente E com conhecimento sobre o negócio

9 Testes de Aceitação São definidos pelo usuário e são os critérios de aceitação do software. Desenvolvimento Orientado a Testes A criação de testes leva em conta não só o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. Integração Contínua Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários. Comunicação Métodos para rapidamente construir e disseminar conhecimento Simplicidade XP encoraja que você comece, sempre, pela solução mais simples Feedback Do cliente, do sistema e da equipe Coragem Design simples, refatoração Respeito Respeito da Equipe, do Cliente, dos Usuários O nome é derivado de uma atividade que ocorre durante um jogo de Rugby Princípios: Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal. O processo precisa ser adaptável tanto a modificações técnicas como de negócio. O processo produz frequentes incrementos de software. Atividades do processo requisitos análise projeto evolução entrega. Principais papéis ScrumMaster; Product Owner; Team Início: Jeff de Luca e Peter Coad em A FDD é focada na entrega regular de funcionalidades valiosas para o cliente Tem mais estrutura do que o XP, porém é mais enxuto do que o RUP é um meio termo. Seis Papéis Project Manager Chief Architect Development Manager Chief Programmers Class Owners (aka Developers) Domain Experts

10 Cinco processos Antes da década de 90 casa de ferreiro, espeto de pau Hoje em dia as ferramentas CASE ainda não são tão variadas nem fornecem tudo aquilo que os desenvolvedores queriam, mas são um aparato essencial para o engenheiro de software O que são? São ferramentas que auxiliam o engenheiro de SW em cada atividade associada ao desenvolvimento de SW Quem usa? Gerentes de projeto e engenheiros de SW Por que são importantes? Reduzem o esforço necessário para produzir artefatos e alcançar metas Aumentam a qualidade do software Quais são os passos? Ferramentas CASE são usadas em conjunto com o modelo de processo adotado. Se for escolhida uma ferramenta completa, pode passar por quase todos os passos do desenvolvimento de SW Como são usadas? Como complemento às boas práticas de Engenharia de Software. Ferramentas CASE não substituem uma metodologia de desenvolvimento de software sólida Um tolo com ferramentas, ainda é apenas um tolo

11 Horizontais São utilizados durante todo o processo de desenvolvimento de software Verticais São específicas para uma disciplina de software Por funções [Pressman] Processos de negócio, Planejamento de projeto, Análise de Riscos, Rastreamento de Requisitos, IDEs, Gerenciamento de BDs, Análise Estática, Análise Dinâmica,... Como não há um padrão para categorizar ferramentas CASE, a seguinte proposta foi feita: Front-end ou Upper CASE apóiam as etapas iniciais da criação dos sistemas: as fases de planejamento, análise e projeto da aplicação Back-end ou Lower CASE dão apoio à parte física, i.e, código, testes e manutenção I-CASE ou Integrated CASE cobrem todo o ciclo de vida, do início ao fim