Portfolio Individual - Curso Superior de ADS - II Semestre

UNIVERSIDADE NORTE DO PARANÁ - UNOPAR

SISTEMA DE ENSINO PRESENCIAL CONECTADO
CURSO SUPERIOR DE TECNOLOGIA EM
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

 

 

 

WANDERLEY NUNES CRISTO

FUNDAMENTOS DE TECNOLOGIA DA INFORMAÇÃO
Produção Textual Interdisciplinar – Portfolio
Modelo de Processo de Software - Cascata

 

 

 

Trabalho apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas à Universidade Norte do Paraná - UNOPAR, para as disciplinas de Sistemas de Computação e Informação - Adaptação, Ética, Política e Sociedade - Adaptação, Interação Humano-computador - Adaptação, Segurança da Informação - Adaptação, Metodologia Científica, Processo de Negócio e Software, Introdução ao Desenvolvimento de Sistemas Web e Seminários  II.

 

 

 

 

Breves
2013

SUMÁRIO
1    Introdução    3
2    Objetivo    4
3    Modelo Cascata ou Clássico    5
3.1    Descrição do Modelo    6
3.2    As Diferentes Etapas de Desenvolvimento    7
3.2.1    Análise e Definição dos Requisitos    7
3.2.2    Implementação    7
3.2.3    Teste do Sistema    8
3.2.4    Manutenção    8
4    Problemas    9
5    Domínio de Aplicações    10
5.1    Vantagens do Modelo    10
5.2    Desvantagens do Modelo    10
6    Modelo Cascata eo Php (Hypertext Preprocessor)    11
7    Conclusão    12
Referências    13


1    INTRODUÇÃO
O modelo em cascata é um modelo de desenvolvimento de software sequencial no qual o desenvolvimento é visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, Royce defendia um abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata. Royce originalmente descreve o que é hoje conhecido como o modelo em cascata como um exemplo de um método que ele argumentava ser um risco e um convite para falhas.
2    OBJETIVO
Este trabalho tem por objetivo levar o aluno a conhecer as principais características do Modelo de Processo de Software Cascata. Apresentando um pouco de sua história, de seu desenvolvimento, de suas vantagens e desvantagem e por fim apresentar um uma linguagem de programação onde poderíamos utilizar esse modelo de processo de software.
3    MODELO CASCATA OU CLÁSSICO
    O modelo cascata ou clássico, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo.
O modelo cascata é um dos mais importantes modelos, e é referência para muitos outros modelos, servindo de base para muitos projetos modernos. A versão original deste modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em dia.
Grande parte do sucesso do modelo cascata está no facto dele ser orientado para documentação. No entanto deve salientar-se que a documentação abrange mais do que arquivo de texto, abrange representações gráficas ou mesmo simulação.
Uma abordagem incorporando processos, métodos e ferramentas deve ser utilizada pelos criadores de software. Esta abordagem é muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem três abordagens de modelos de processo de desenvolvimento de software. Elas tentem colocar ordem numa atividade inerentemente caótica.
Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo:
     Cascata pura;
     Incremental;
     Evolucionária.
Toda esta secção constitui uma interpretação do disposto na referência [FAI96].



3.1    DESCRIÇÃO DO MODELO


O modelo Cascata é um modelo de engenharia projectado para ser aplicado no desenvolvimento do software. A ideia principal que o dirige é que as diferentes etapas de desenvolvimento seguem uma sequência:
a saída da primeira etapa “fluí” para a segunda etapa e a saída da segunda etapa “fluí” para a terceira e assim por diante. As actividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado.
O modelo em cascata tem a vantagem que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa activamente no projecto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projecto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas ideias sobre o sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projecto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objectivo final, ou seja disponibilizar o sistema a funcionar.


3.2    AS DIFERENTES ETAPAS DE DESENVOLVIMENTO
3.2.1    ANÁLISE E DEFINIÇÃO DOS REQUISITOS
Nesta etapa, estabelecem-se os requisitos do produto que se deseja desenvolver, o que consiste usualmente nos serviços que se devem fornecer, limitações e objetivos do software. Sendo isso estabelecido, os requisitos devem ser definidos de uma maneira apropriada para que sejam úteis na etapa seguinte. Esta etapa inclui também a documentação e o estudo da facilidade e da viabilidade do projeto com o fim de determinar o processo de início de desenvolvimento do projeto do sistema; pode ser vista como uma concepção de um produto de software e também como o início do seu ciclo de vida.
O projeto do sistema é um processo de vários passos que se centraliza em quatro atributos diferentes do sistema: estrutura de dados, arquitetura do software, detalhes procedais e caracterização das interfaces. O processo de projeto representa os requisitos de uma forma que permita a codificação do produto (é uma prévia etapa de codificação). Da mesma maneira que a análise dos requisitos, o projeto é documentado e transforma-se em uma parte do software.

3.2.2    IMPLEMENTAÇÃO
Esta é a etapa em que são criados os programas. Se o projeto possui um nível de detalhe elevado, a etapa de codificação pode implementar-se automaticamente. A princípio, sugere-se incluir um teste unitário dos módulos nesta etapa; nesse caso, as unidades de código produzidas são testadas individualmente antes de passar a etapa de integração e teste global.
3.2.3    TESTE DO SISTEMA
Concluída a codificação, começa a fase de teste do sistema. O processo de teste centraliza-se em dois pontos principais: as lógicas internas do software e as funcionalidades externas. Esta fase decide se foram solucionados erros de “comportamento” do software e assegura que as entradas definidas produzam resultados reais que coincidam com os requisitos especificados.
3.2.4    MANUTENÇÃO
Essa etapa consiste na correção de erros que não foram previamente detectados, em melhorias funcionais e de preferência e outros tipos de suporte. A etapa de manutenção à parte do ciclo de vida do produto de software e não pertence estritamente ao seu desenvolvimento.
Melhorias e correções podem ser consideradas como parte do desenvolvimento.
As etapas descritas são as principais, porém existem sub-etapas dentro de cada etapa, as quais diferem muito de um projeto para outro. Também é possível que certos projetos de software exijam a incorporação de uma etapa extra ou a separação de uma etapa em outras etapas.
Com certeza, todas essas variações do modelo Cascata possuem o mesmo conceito básico: a ideia de que uma etapa fornece saída que serão usadas como entradas para a etapa seguinte. Portanto, o processo de desenvolvimento de um produto de software de acordo com o modelo Cascata é simples de conhecer e controlar.
Outras atividades que também são levadas em consideração em cada uma das etapas de desenvolvimento do software: a documentação, a verificação e a administração das etapas serem documentos. A verificação, por sua vez, é necessária para que uma etapa forneça os dados corretos para a etapa seguinte. Já a administração, efetua a gestão e o controle da etapa.
4    PROBLEMAS
O ciclo de vida Cascata é o paradigma mais visto e mais amplamente empregue na engenharia de software, porém sua aplicabilidade, em muitos campos, tem sido questionada.
Entre os problemas que surgem quando se aplica o modelo são:
     Na realidade, os projetos raramente seguem o fluxo sequencial que o modelo propõe. A interação é sempre necessária e está presente, criando problemas na aplicação do modelo;
     Em princípio, é difícil para o cliente especificar os requisitos explicitamente, o que acarreta a incerteza natural do início de qualquer projeto;
     O cliente deve ser paciente, pois uma versão funcional não estará disponível até o final do desenvolvimento. Qualquer erro ou mal-entendido, se não for detectado até que o software seja revisado, pode ser desastroso.
Apesar desses problemas, o modelo Cascata tem um lugar bem definido e importante nos trabalhos de engenharia de software. Ele fornece um padrão do qual se encaixam métodos para a análise, projeto, codificação e manutenção.
5    DOMÍNIO DE APLICAÇÕES
O modelo Cascata aplica-se bem em situações em que o software a ser desenvolvido é simples, os requisitos são bem conhecidos, a tecnologia usada é bem acessível e os recursos para o desenvolvimento estão disponíveis.

5.1    VANTAGENS DO MODELO
     Torna o processo de desenvolvimento estruturado. Tem uma ordem sequencial de fases. Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do início da seguinte;
     Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa;
     Esta abordagem é atualmente a norma e provavelmente permanecerá como tal nos próximos tempos.
5.2    DESVANTAGENS DO MODELO
     Não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;
     Não suporta modificações nos requisitos;
     Não prevê a manutenção;
     Não permite a reutilização;
     É excessivamente sincronizado;
     Se ocorrer um atraso todo o processo é afetado;
     Faz aparecer o software muito tarde.
     O modelo conduz a uma rígida divisão de trabalho (analistas, arquitetos, programadores, controladores de qualidade, programadores de manutenção);
     Só o chefe do projeto tem uma visão global do problema;
     Quando algo corre mal, a culpa é dos outros... Ninguém se sente realmente responsável.
6    MODELO CASCATA EO PHP (HYPERTEXT PREPROCESSOR)
PHP (“Hypertext Preprocessor”, originalmente Personal Home Page) é uma linguagem interpretada livre, usada originalmente apenas para o desenvolvimento de aplicações presentes e atuantes no lado do servidor, capazes de gerar conteúdo dinâmico na World Wide Web. Nesse contexto por ser uma linguagem muito utilizada atualmente e bastante dinâmica é preciso termos tudo muito bem definidos desde o início do planejamento até a conclusão. Pois, dessa forma no momento de realizar a manutenção do software não teremos problemas. Além disso, os projetos construídos com PHP são simples e pequenos comparados com outras linguagens usadas na construção de sistemas ERPs, por exemplo. E, para o desenvolvimento em PHP os requisitos exigidos são mínimos, o que para o planejamento com com modelo Cascata é muito bem atendido. 
7    CONCLUSÃO
    Para o planejamento com qualquer modelo de processo de software é preciso estudar muito bem o objetivo do software a ser desenvolvido para a partir daí iniciar o planejamento do mesmo, analisando os requisitos, como vai se dar a implementação, os testes e as futuras manutenções para o funcionamento perfeito do software. Em geral o Modelo Cascata possui uma característica que, pessoalmente, gosto muito, pois podemos “amarrar” tudo no planejamento do software, ou seja, antes de sua implementação. Para softwares desenvolvidos com PHP, esse modelo aplica-se muito bem, pois por ser uma linguagem interpretada é muito comum mudanças bruscas no projetos o que proporciona problemas no desenvolvimento do mesmo.




REFERÊNCIAS
WIKIPEDIA, Modelo em Cascata. Disponível em: (http://pt.wikipedia.org/wiki/Modelo_em_cascata) Acesso em: 01 de setembro de 2013.
Engenharia de Software I, Modelo Cascata. Universidade do Vale do Sapucaí 2005.
BLOGSPOT, Modelo em Cascata. Disponível em: (http://modelocascata.blogspot.com.br/) Acesso em: 01 de setembro de 2013.
WIKIPEDIA, PHP. Disponível em: (http://pt.wikipedia.org/wiki/PHP) Acesso em: 01 de setembro de 2013. 

 

 

Clique ao lado para ver o trabalho (Portfolio Individual - Curso Superior de ADS - II Semestre)