TRABALHO UNIP

Prévia do material em texto

Metodologias tradicionais de desenvolvimento de software
Quando a computação surgiu, os programas desenvolvidos eram criados para resolver problemas pontuais, como ler informações do disco ou realizar cálculos matemáticos. Com o crescimento da tecnologia, surgimento de sistemas operacionais e sistemas corporativos, criou-se a necessidade de gerenciar estes grandes projetos. As metodologias tradicionais de desenvolvimento apareceram como uma resposta a essa necessidade.
Na criação destas metodologias, os projetos de engenharia foram utilizados como referência. Portanto as metodologias tradicionais seguem o paradigma de coletar requisitos, desenhar, construir e dar manutenção. Sequencialmente. Por isso a primeira metodologia utilizada foi a metodologia em cascata, ou waterfall. 
Modelo em Cascata
 Nesse modelo as atividades do processo de desenvolvimento são estruturados em um cascata onde a saída de uma etapa é a entrada para a próxima etapa. As suas principais atividades são:
Estudo de Viabilidade
Análise e Especificação de Requisitos
Design da Arquitetura
Design Detalhado
Codificação e Testes de Unidades
Integração e Testes do Sistema
Entrega e Instalação
Manutenção
Existem variações desse modelo apresentando, porém, a principal característica comum é um fluxo linear e sequencial de atividades semelhantes a descritas anteriormente.
O modelo Cascata é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.
Vantagens:
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á por um tempo, mas temos o desenvolvimento ágil chegando com muita força na maioria das empresas de grande porte;
Desvantagens:
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;
Demora muito para ser entregue o software;
Prototipação
A Prototipação é uma metodologia surgida posteriormente à Cascata. Ela possibilita a equipe de desenvolvimento a criar uma aplicação protótipo que pode assumir três formas distintas. A primeira delas é um protótipo em papel ou mesmo no computador que retrate a interação homem-máquina. A segunda opção é implementar uma funcionalidade que já está no escopo do software a ser desenvolvido. Por fim existe a possibilidade de utilizar-se de um software já pronto que tenha parte ou todas as funcionalidades desejadas. Esta forma é mais comumente adotada em softwares que apesar de prontos ou parcialmente prontos possuem características que precisam ser incrementadas ou melhoradas em um novo esforço de desenvolvimento.
Assim como a metodologia Cascata a Prototipação também apresenta os seus pontos negativos. Um deles, é que o cliente pode acreditar que o protótipo já é o software pronto ou em fase de término e começar pressionar para que se faça pequenos ajustes e entregue o software rapidamente. Diante de um quadro assim, muitas vezes, a equipe de desenvolvimento cede e a qualidade final, bem como a manutenibilidade podem ficar comprometidas. Outro ponto negativo é que algumas vezes a equipe de desenvolvimento pode fazer concessões temporárias a fim de colocar o protótipo em funcionamento que acabam permanecendo no software final.
Apesar desses problemas, a prototipação ainda é uma eficiente metodologia de desenvolvimento de software. A fim de se obter sucesso no projeto, tanto cliente quanto desenvolvedor devem chegar a um consenso de que o protótipo servirá apenas para ajudar na definição dos.
Apesar de resolverem muitos dos problemas do desenvolvimento de software alguns parâmetros ainda não eram fornecidos pelas metodologias existentes.
Espiral
A metodologia espiral foi concebida para englobar as melhores práticas tanto do ciclo de vida clássico quanto da prototipação. Essa metodologia inovou ao trazer também um novo elemento, a análise de riscos. Além disso, foi uma das primeiras metodologias a adotar o conceito de iteração. Sucessivas iterações moldam aos poucos soluções mais completas do software (PRESSMAN, 2006).
Na primeira iteração, os objetivos, alternativas e restrições são definidos e os riscos são identificados e analisados. O cliente avalia o resultado da iteração e baseado nos apontamentos do mesmo a próxima iteração é iniciada. Isso possibilita ao cliente e ao desenvolvedor perceber e reagir a riscos em cada uma das etapas evolutivas. Entretanto a metodologia espiral exige considerável experiência para avaliar os riscos e se baseia nela para obter sucesso. Encara-se que se um grande risco não for detectado indubitavelmente ocorrerão problemas.
Métodos Ágeis
Os métodos ágeis (AG - Agile Modeling) visam reduzir o ciclo de vida do software (e, por conseguinte, acelerar o seu desenvolvimento), desenvolvendo uma versão mínima e, em seguida, integrando as funcionalidades por um processo interativo para atender as necessidades do cliente e controlar todo o ciclo de desenvolvimento. 
A origem dos métodos ágeis está ligada à instabilidade do ambiente tecnológico e ao fato do cliente ser incapaz de definir as suas próprias necessidades no início do projeto. O termo ágil se refere à capacidade de adaptação às mudanças do contexto e às modificações de especificações que atuam durante o processo de desenvolvimento. 
Os princípios do Manifesto para Desenvolvimento Ágil de Software
Em 2001, um grupo de 17 pessoas, redigiu o Manifesto para Desenvolvimento Ágil de Software no qual expressaram os seguintes pontos principais: indivíduos e interações em vez de processos e instrumentos; desenvolvimento de software em vez de documentação exaustiva; colaboração com o cliente em vez de negociação contratual; abertura à mudança em vez de planos rígidos. 
Graças a esses métodos, o cliente controla o seu projeto e consegue implementar o software mais rapidamente. Desta forma, o usuários poderá se participar das decisões desde a concepção do projeto.
RAD: Desenvolvimento Rápido de Aplicativos
O RAD (Rapid Application Development), definido por James Martin no início dos anos 1980, consiste num ciclo de desenvolvimento curto baseado em três fases: requisitos, design e construção. Seu prazo de entrega ideal é de 90 a 120 dias. 
DSDM: Método Dinâmico de Desenvolvimento do Sistema
O método DSDM (Dynamic Software Development Method) foi desenvolvido para completar o que faltava no método RAD, oferecendo estrutura que considera o ciclo de desenvolvimento completo. Suas características principais são participação do usuário, desenvolvimento iterativo e incremental, frequência de entrega melhorada, integração de testes em cada etapa e aceitação dos produtos entregues, que vai depender diretamente do cumprimento dos requisitos. 
UP: Processo Unificado
O método UP (Unified Process) é um processo de desenvolvimento iterativo e incremental. Isso significa que o projeto é dividido em fases mais curtas e uma nova versão incrementada é entregue ao final de cada uma delas. Essa abordagem é baseada no modelo UML (linguagem padrão para montagem da estrutura de projetos de software) para descrever a arquitetura do software (funcional, de aplicação e física). Esse modelo descreve as necessidades e as exigências dos usuários.RUP: Processo Unificado Racional
É um método de desenvolvimento por interações, promovido pela empresa Rational Software, hoje propriedade da IBM. Ele propõe um método que especifica a composição das equipes e os cronogramas, assim como o número de modelos de documento. 
XP: Programação Extrema
O método XP (Extreme Programming) define um conjunto de práticas que permitem desenvolver um software em boas condições, colocando o cliente no meio do processo de criação. Ele baseia-se nos seguintes conceitos: equipes de desenvolvimento trabalham diretamente com o cliente em ciclos muito curtos de uma a duas semanas; entrega das versões do software ocorrem muito rapidamente e em intervalos curtos para maximizar a interação com os usuários; equipe de desenvolvimento trabalha em colaboração total com base em binômios; código é testado e depurado ao longo de todo o processo de desenvolvimento; indicadores permitem medir o progresso do projeto para poder atualizar o plano de desenvolvimentos.