1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade de desenvolvimento de software: 1. Desenvolvimento de software como um artesanato: o projetista é um artesão. As diversas legislações sobre software de vários países considerando o software protegido pela lei de direito autoral podem ser vistas nesse contexto. Métodos que auxiliam o desenvolvimento de software não fazem muito sentido aqui. Programas são obras pessoais Quando se considera grandes sistemas desenvolvidos em ambientes industriais, torna-se (no mínimo) inadequado esse paradigma. 2. Matemática como modelo de desenvolvimento de software Um programa é um algoritmo escrito em uma linguagem Desenvolver algoritmos é resolver problemas, o que é uma atividade básica da matemática Portanto, desenvolver software é uma atividade intelectual muito próxima da matemática Uso de métodos formais em todo o ciclo de desenvolvimento de software 3. Desenvolvimento de software como engenharia Leva à abordagem empírica A pesquisa está na busca de métodos e técnicas que aproximem ao máximo o processo de desenvolvimento de software do desenvolvimento das características de produtos em áreas tradicionais de engenharia A preocupação em se conseguir visualizar o produto de software já nas fases iniciais de desenvolvimento é um resultado da aplicação desse paradigma. A tendência em buscar paradigmas em outras áreas de conhecimento é natural dada a tenra idade da computação. Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. Na medida em que esse produto não tem a solidez de uma máquina ou obra civil, nos afastamos da engenharia e nos aproximamos de sua analogia com uma obra intelectual, de autoria. Pode-se dizer que o processo de desenvolvimento de software é um novo híbrido desses paradigmas. Esse processo, chamado de engenharia de software, é uma disciplina que engloba métodos, ferramentas e técnicas para o desenvolvimento de software.
2 Especificação de sistemas ciclo de vida Todos os sistemas têm ciclo de vida bem definido, ou seja, todos eles passam pelos estágios de: Concepção: enfoca a questão o que? o que é o sistema Engloba: análise do sistema Planejamento do projeto de software Análise de requisitos Desenvolvimento: enfoca a questão como como implementar o sistema Engloba: projeto de software Codificação Testes Manutenção: enfoca mudanças no sistema e no ambiente Engloba: correção Adaptação Expansão Nesse contexto, 4 modelos para especificação de sistema, ou modelos de ciclo de vida de sistemas de software, têm sido mais considerados. Modelo Clássico ou Cascata: Modelo interativo baseado na idéia de que o desenvolvimento de software pode ser visto à semelhança dos seres vivos: do nascimento à morte. Abordagem sistêmica seqüencial para desenvolvimento de software que começa no nível de definição do problema e evolui par análise, projeto, codificação, teste e manutenção. Modelo mais consagrado de ciclo de vida. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento. Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção
3 Etapas: 1. ANÁLISE E ENGENHARIA DE SISTEMAS: envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível. visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados). Envolve os altos escalões da empresa. Percepção da necessidade e estudo de viabilidade. 2. ANÁLISE DE REQUISITOS DE SOFTWARE: processo de coleta dos requisitos é intensificado e concentrado especificamente no software. deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos. os requisitos (para o sistema e para o software) são documentados e revistos com o cliente. Quando concluída, deve atender os seguintes requisitos: o Satisfazer os objetivos da organização. o Especificações aceitas pelos usuários. o Especificações devem ser táticas e economicamente viáveis. o Lógica do processamento bem definida. 3. PROJETO: tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie. se concentra em 4 atributos do programa: o Estrutura de Dados, o Arquitetura de Software, o Detalhes Procedimentais e o Caracterização de Interfaces Define, dentro das restrições existentes, os seguintes pontos: o Organização do processamento (tempo real, of line, etc) o O S.O. utilizado. o Os pacotes utilizados e de suporte necessário. o A especificação dos programas do sistema. o Estrutura e organização do B.D. o Os controles do sistema. 4. CODIFICAÇÃO: tradução das representações do projeto para uma linguagem artificial resultando em instruções executáveis pelo computador. Engloba: o Revisão das especificações dos programas. o Desenvolvimento da lógica dos programas. o Codificação em si. o Construção das tabelas do B.D. o Testes dos programas. o Elaboração dos manuais de operação. 5. TESTES: Concentram-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.
4 Começa quando os componentes do sistema, já testados individualmente, são reunidos para testes e aceitação como sistema. Engloba: o Treinamento para implantação. o Testes do sistema. o Revisão dos procedimentos operacionais. o Conversão do sistema 6. MANUTENÇÃO: 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 em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho. No instante em que as alterações necessárias se avolumam, o sistema em sua forma deixa de ser útil à organização estudo de novo sistema. Prototipação: Abordagem operacional cuja idéia principal é criar um protótipo executável e, através de transformações sucessivas, chegar ao sistema completamente implementado. As transformações devem preservar o comportamento externo do sistema, mas poderão alterar os mecanismos pelos quais este comportamento é produzido. processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software. apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. Pode gerar falsas expectativas. Etapas: 1. Obtenção dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais 2. Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) 3. Construção Protótipo: implementação rápida do projeto 4. Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo. 5. Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteração que pode conduzir à 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito.
5 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. início fim construção produto obtenção dos requisitos projeto rápido refinamento protótipo avaliação protótipo construção protótipo Modelo Espiral: Desenvolvido para abranger as melhores características do modelo de ciclo de vida clássico e prototipação, acrescentando um novo elemento: análise de riscos. É a abordagem mais realista para o desenvolvimento de sistemas de software em grande escala. O modelo é relativamente novo e não tem sido amplamente usado. Etapas: 1. Comunicação com o cliente: tarefas requeridas para estabelecer uma efetiva comunicação entre desenvolvedor e cliente. 2. Planejamento: tarefas requeridas para definir recursos, referenciais de tempo e outras informações de projeto. 3. Análise de Risco: tarefas requeridas para fazer levantamento de riscos técnicos e de gerenciamento. 4. Engenharia: tarefas requeridas para construir uma ou mais representações da aplicação. 5. Construção e Release: tarefas requeridas para construir, testar, instalar e dar suporte ao usuário (p.ex., documentação e treinamento). 6. Avaliação do cliente: tarefas requeridas para obter um feedback do cliente baseado na avaliação da representação do software criado durante a fase de engenharia e implementado durante a fase de instalação.
6 Planejamento Análise de Risco Comunicação com o Cliente Engenharia Avaliação do Cliente Construção e Release Especificação Formal utilizando Técnicas de Quarta Geração: A partir da especificação informal, deve-se fazer uma especificação em alguma linguagem formal de quarta geração. Feita a especificação formal, ela servirá como entrada para um ambiente computacional (conjunto de ferramentas) que gera automaticamente o software do sistema. Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que: o o sistema seja especificado em uma linguagem de alto nível e o código fonte seja gerado automaticamente a partir dessas especificações. A proposta é a redução dramática no tempo de desenvolvimento do software (aumento de produtividade) Entretanto, as 4GL atuais não são mais fáceis de usar do que as linguagens de programação o o código fonte produzido é ineficiente o a manutenibilidade de sistemas usando técnicas 4G ainda é questionável