Você está na página 1de 6

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 (p 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
obtenção
dos
requisitos
construção projeto
produto rápido

refinamento construção
protótipo protótipo
avaliaçã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

Você também pode gostar