Unidade I Conceitos BásicosB. Conceitos BásicosB

Transcrição

1 à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 1961 a 1963 Surgimento de novos Hardwares Crise do Software! Incapacidade de se utilizar adequadamente os recursos computacionais disponíveis 1968 Surgimento da Engenharia de Software Termos surgiu em 1968 NATO Software Engineering Conference Objetivo de discutir alternativas para contornar a Crise do Software Dijkstra ministrou o discurso: O Pobre Programador! A A maior causa da crise do software é que as máquinas tornaram-se várias v ordens de magnitude mais poderosas! Para esclarecer melhor: quando não havia máquinas, m a programação não era um problema; quando tínhamos t poucos computadores, a programação tornou-se um problema razoável, e agora, que nós n s temos computadores gigantes, a programação tornou-se um problema igualmente grande.. Crise do Software 4% - Usado como foi entregue 29% - Pago e nunca entregue Projetos estourando o orçamento amento. Projetos estourando o prazo. Software de baixa qualidade. Software muitas vezes não atendiam os requisitos. Projetos ingerenciaveis e o 45% - Impossível de ser usado código difícil de manter. 22% - Modificado e refeito para ser utilizado Será que a crise acabou? 1

2 Será que a crise acabou? Será que a crise acabou? Como os clientes explicaram Como o líder do Como o analista projeto entendeu projetou Como o programador escreveu tor Como o consul- descreveu Como o projeto foi documentado O que foi instalado O que foi cobrado O que foi dado suporte O que o cliente realmente queria Aplicação de um abordagem sistemática, tica, disciplinada e quantificável para o desenvolvimento de software. Unidades Integração Requisitos Outros conceitos: "O estabelecimento e uso de sólidos s princípios pios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas m reais.", NAUR PETER, Projeto e Simulações Integração Produto Concluído Outros conceitos: A A aplicação prática do conhecimento científico para o projeto e a construção de programas computacionais e a documentação necessária à sua operação e manutenção. ão.,, BARRY BOEHM, Outros conceitos: Conjunto de métodos, m técnicas t e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto.,, SACHA KRAKOWIAK,

3 Por que os sistemas informatizados: não fazem o que deveriam fazer? são entregues com atraso? custam mais caro do que o previsto? Problemas são resolvidos por pessoas, processos e tecnologia. Deve haver equilíbrio entre tais elementos... Solução Processos Pessoas Tecnologia Sistemas são usados dentro de processos de negócio. portanto, os processos de negócio têm que ser definidos. Solução Sistemas são usados por pessoas portanto, as pessoas têm que ser: levadas em conta, treinadas, ajudadas. Solução Processos Pessoas Processos Pessoas Tecnologia Tecnologia Problemas são resolvidos por sistemas; não apenas por software. O Sistema é algo bem maior... Solução O Sistema é algo bem maior... Solução Processos Pessoas Hardware Vias de comunicação Tecnologia Bases de dados Software 3

4 Por que os sistemas informatizados... não fazem o que deveriam fazer? porque os problemas têm que ser enunciados; antes de serem resolvidos. É comum pessoas quererem saber o preço o de um software, antes de enunciá-lo. Mas elas sabem que é impossível obter um preço para um prédio, uma ponte, sem que haja uma definição precisa dos requisitos associados! Precisamos expor mais a área, para que as pessoas entendam que construir software é um processo de engenharia e segue os mesmos preceitos de um produto de engenharia O valor de um produto deriva de suas características: Funcionais (comportamento) Deve ter um cadastro X, Y, uma função Z,... não-funcionais (características ligadas ao comportamento). X e Y devem suportar 100 acessos simultâneos, Z tem que responder em até 8s Os requisitos: características que definem os critérios rios de aceitação de um produto. O valor de um produto deriva de suas características: Funcionais (comportamento) Deve ter um cadastro X, Y, uma função Z,... não-funcionais (características ligadas ao comportamento). X e Y devem suportar 100 acessos simultâneos, Z tem que responder em até 8s Requisitos características que definem os critérios rios de aceitação de um produto. Princípios da Engenharia de Requisitos: uma boa especificação de requisitos custa: tempo e dinheiro; a a ausência de uma boa especificação de requisitos custa: muito mais tempo e dinheiro. Problemas no Desenvolvimento de Software provenientes de mitos que surgiram durante a história inicial dessa atividade Antigos mitos interessantes histórias e freqüentemente entemente fornecem lições humanas merecedoras de atenção Mitos do software propagam desinformação e confusão tinham certos atributos que os tornavam parecidos com afirmações razoáveis, tendo aspecto intuitivo divulgados por profissionais experientes e que deveriam entender do assunto 4

5 Diversos mitos Mitos gerenciais Advém m de gerentes sobre pressão de orçamento e tempo. Mitos do cliente Advém m de falsas expectativas e insatisfação com o desenvolvedor. Mitos do Profissional Advém m de se considerar o software como uma forma de arte. Será que o software é uma arte ou uma engenharia? Mitos gerenciais Mito 1 (Manual de Práticas): se a equipe dispõe de um manual repleto de padrões e procedimentos de desenvolvimento de software, então a equipe será capaz de conduzir bem o desenvolvimento Isso não é o suficiente! É preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual e que eles sejam atualizados! Mitos gerenciais Mito 2 (Computador Moderno): A equipe tem ferramentas de desenvolvimento de software de última geração, uma vez que eles dispõem de computadores modernos Mais importante do que ter um hardware de última geração é ter ferramentas para a automação do desenvolvimento de software e sabê-las utilizar adequadamente. Mitos gerenciais Mito 3 (Horda de Mongóis): Se o desenvolvimento do software estiver atrasado, aumentando a equipe poderemos reduzir o tempo de desenvolvimento Acrescentar pessoas em um projeto atrasado provavelmente vai atrasá-lo ainda mais. Mitos do cliente Mito 4 (Especificação): Uma descrição breve e geral dos requisitos do software é o suficiente para iniciar o seu projeto o cliente deve procurar definir o mais precisamente possível todos os requisitos importantes para o software, antes do desenvolvimento Conceitos BásicosB Mitos do cliente Mito 5 (Mudanças): as): os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isto não representa um problema... não existe software, por mais flexível que suporte alterações de requisitos significativas sem um adicional em relação ao custo de desenvolvimento Custo de introdução de mudanças Definição Desenvolvimento Manutenção De Até 5

6 Mitos do profissional Mito 6 (Terminar mais cedo): Após s a finalização do programa e a sua implantação, o trabalho está terminado 50 a 70% do esforço o de desenvolvimento de um software é empregado após s a sua entrega ao cliente (manutenção). Mitos do profissional Mito 7 (Qualidade): Enquanto o programa não entrar em funcionamento, é impossível avaliar a sua qualidade a preocupação com a garantia do da qualidade do software deve fazer parte de todas as etapas do desenvolvimento. Mitos do profissional Mito 8 (Executável): O produto a ser entregue no final do projeto é o programa funcionando Além m do software em si, um bom projeto deve ser caracterizado pela produção de um conjunto importante de documentos. Um produto de software possui um ciclo de vida Isso é composto pelas seguintes fases: a concepção, onde o produto é idealizado. o desenvolvimento, onde ocorrem as transformações dos requisitos em itens a serem entregues ao cliente. a operação, quando o produto é instalado para ser utilizado. a retirada, quando o produto tem sua vida útil finalizada. A A codificação é apenas uma parte do ciclo de vida do software Muitos profissionais acreditam que isso é tudo! Existem muitas outras atividades Um processo de software é um guia que detalha todas as atividades relacionadas ao desenvolvimento de software Porém, existem muitos processos» Cada um com um formato diferenciado Mas o que é um processo de software: Conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, m práticas e transformações, utilizados para se atingir uma meta. Uma meta está associada a resultados, que são os produtos resultantes da execução do processo.» Wilson de PáduaP 6

7 Processo é um guia de como se fazer algo Projeto é o uso de um processo para se construir um produto de software É importante saber essa diferença! um processo deve ter uma documentação que o descreve o que é feito (produto) quando (passos) por quem (agentes) o que usa como entrada (insumo) o que é produzido (resultado). A A documentação de um processo pode ser simples e informal, como é o caso dos Processos Ágeis ou completamente detalhada como é o caso dos processos baseados no Processo Unificado. Existem processos que abrangem todo o ciclo de vida do software Mas também m existem processos específicos para partes do desenvolvimento processos para testes processos para manutenção» são considerados subprocessos O O ponto inicial para seleção de um processo é entender qual modelo de ciclo de vida ele utiliza. Um modelo de ciclo de vida pode ser apropriado para um projeto mas não ser apropriado para outro. É necessário entender bem os conceitos relacionados para que as escolhas feitas sejam baseadas em conhecimento e não no acaso. Ciclo de vida todas as atividades relacionadas a um software, desde a concepção de suas idéias ias até a descontinuidade do produto Para entender melhor o conceito de ciclo de vida é importante entender melhor cada um dos subprocessos mais importantes ligados às s tarefas de desenvolvimento 7

8 Principais subprocessos da Engenharia de Software Requisitos Análise Desenho (ou projeto) Implementação Teste Modelos de Ciclo de Vida: Codifica-Remenda Especificação (???) Produto Modelos de Ciclo de Vida: Codifica-Remenda provavelmente o mais usado; não exige sofisticação técnica t ou gerencial; alto risco; impossível de gerir; não permite assumir compromissos confiáveis. Modelos de Ciclo de Vida: Codifica-Remenda provavelmente o mais usado; não exige sofisticação técnica t ou gerencial; alto risco; impossível de gerir; não permite assumir compromissos confiáveis. Modelos de Ciclo de Vida: Cascata Requisitos Análise Desenho Implementação Modelos de Ciclo de Vida: Cascata subprocessos executados em estrita seqüência: pontos de controle bem definidos facilitam gestão; teoricamente, confiável e utilizável; em projetos de qualquer escala; interpretado literalmente: é rígido e burocrático; Testes 8

9 Modelos de Ciclo de Vida: Cascata requisitos, análise e desenho: têm de ser muito bem dominados: não são permitidos erros; de baixa visibilidade para o cliente: só recebe o resultado final do projeto. Modelos de Ciclo de Vida: Espiral Ativação Análise Operação Desenvolvimento Modelos de Ciclo de Vida: Prototipagem Evolutiva ou Incremental Nova iteração Planejamento da iteração Requisitos Análise Desenho Modelos de Ciclo de Vida: Prototipagem Evolutiva ou Incremental espiral é usada para versões provisórias; rias;» Chamadas de protótipos; tipos; cobrem cada vez mais requisitos;» até que se atinja o produto desejado; permite que requisitos sejam definidos progressivamente; alta flexibilidade e visibilidade para os clientes; Avaliação da iteração Testes Implementação Projeto terminado Modelos de Ciclo de Vida: Prototipagem Evolutiva ou Incremental requer gestão sofisticada; desenho deve ser muito robusto; requer equipe muito disciplinada e experiente; aplicada em processos ágeis geis. Requisitos Análise Desenho arquitetônico Modelos de Ciclo de Vida: Entrega Evolutiva Desenho detalhado Implementação Nova iteração Avaliação da iteração Testes Projeto terminado 9

10 Modelos de Ciclo de Vida: Entrega Evolutiva em pontos bem definidos: usuários podem avaliar partes do produto: fornecendo realimentação quanto às s decisões tomadas; facilita acompanhamento dos projetos: por parte de gerentes e de clientes; a a arquitetura é chave: deve ser robusta; deve permanecer íntegra; ao longo das liberações. Engenharia de Software As grandes áreas da Engenharia de Software Corpo de conhecimento e práticas recomendadas Padrões éticos e profissionais Currículo educacional para graduação, pós-p graduação à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 10