Paradigmas de Análise e Desenvolvimento 02
9 pág.

Paradigmas de Análise e Desenvolvimento 02


DisciplinaParadigmas de Análise e Desenvolvimentos698 materiais3.654 seguidores
Pré-visualização3 páginas
Paradigmas de Análise e Desenvolvimento
Aula 02
Paradigmas de Análise e Projeto de Software
Nesta aula, você irá: 
1 - Conhecer os conceitos e os principais paradigmas de análise de sistemas.
2 - Conhecer a evolução histórica dos paradigmas de análise de sistemas, identificando os problemas de cada um, propiciando o surgimento do próximo.
3 - Conhecer as principais características e ferramentas (modelos) das análises tradicional, estruturada, essencial e orientada a objetos.
O processo de desenvolvimento de Software
A tarefa de desenvolver software com qualidade não é fácil e demanda uma série de atividades com diferentes níveis de abstração, valendo-se de diferentes técnicas e propósitos. Conforme vimos nas aulas de PDS (Processos de Desenvolvimento de Software), o desenvolvimento de software requer algumas ETAPAS que, de acordo com a forma com que se relacionam entre si, originam os diferentes processos de desenvolvimento.
Estudamos, ainda na disciplina PDS, alguns processos, dentre os quais podemos citar: Processo em Cascata Clássico, Processo em Cascata com Retroalimentação, Processo Iterativo-Incremental, Processo Prototipação, Processo Espiral, Processos Ágeis (como Extreme Programming \u2013 XP e Scrum) e RUP (Processo Unificado).
Os processos têm em comum a existência de etapas ou fases e diferem na forma como o sistema é desenvolvido e na integração e relacionamento entre as respectivas fases (ou etapas) do processo. Por exemplo, no processo em Cascata Clássico, os requisitos tinham que ser TODOS identificados na fase de análise (início do processo) e caso alguma mudança fosse necessária, não haveria possibilidade de ajuste, devendo congelar os novos requisitos identificados até que o conjunto inicial de requisitos estivessem implementados.
Já o Modelo Iterativo-Incremental divide os requisitos em partes e o sistema vai sendo construído aos poucos e as partes recém criadas vão sendo integradas às já existentes, repetindo este processo até que todos os requisitos do sistema estejam implementados.
De acordo com o processo de desenvolvimento e a forma de sua implantação nas empresas, podem acontecer pequenas variações nas fases (ou etapas). Em alguns processos, algumas podem ser agrupadas em única fase, outras podem ser suprimidas, mas de uma forma geral: análise, projeto e implementação tendem a existir.
O contexto da análise de sistemas
A análise de sistemas é um das principais fases de um processo de desenvolvimento de software, qualquer que seja este. Geralmente, uma das fases iniciais. As principais atividades a serem desenvolvidas na fase de análise, onde é feito um estudo do problema, ou seja, estudo do sistema e do contexto em que está inserido (na organização) são:
Identificar os requisitos do sistema, através do levantamento de dados com os usuários. Aqui, são usadas diversas técnicas, conforme as necessidades: entrevistas individuais, ou em grupo, questionário, reuniões planejadas, brainstorm, análise de documentos, visitas in locco (ou análise de campo), dentre outras.
Especificar O QUE o sistema deve fazer, em termos essenciais e com base nos requisitos identificados, ou seja, definir as funcionalidades que o sistema deve ter para atender ao que desejam seus usuários.
As definições da fase de análise independem de tecnologia, ou seja, são as soluções para o problema em estudo. É salutar que haja essa independência tecnológica para que a solução perdure no tempo, com diferentes possíveis implementações. Por exemplo, se fizermos uma solução lógica de divisão das partes do sistema dependendo de determinada linguagem de programação, amanhã, quando essa linguagem estiver obsoleta, a divisão terá que ser refeita. Se não houvesse tal dependência, mesmo que houvesse a troca da linguagem, a solução de análise continuaria a funcionar com várias tecnologias diferentes.
A tarefa de análise é desenvolvida pelos analistas de sistemas, que precisam ter ou desenvolver algumas aptidões, para conseguir lidar, de um lado, com o alto nível de abstração dos usuários e, de outro, com o alto nível técnico da equipe de desenvolvimento (projetistas, programadores, analistas de dados de dados, especialistas em redes, dentre outros).
A imagem (Relacionamento do Analista com usuários e equipe) mostra que o analista de sistemas precisa entender as necessidades e expectativas dos usuários a cerca do sistema e comunicar esse entendimento a equipe de desenvolvimento, através da especificação e modelagem do sistema.
Desde os primórdios da computação, a insatisfação dos usuários com o atendimento de suas necessidades e expectativas é causa de transtorno para os profissionais da área, sendo este mais um motivo para uma atenção efetiva do analista para com os usuários do sistema.
Os paradigmas de Análise de Sistemas
Os paradigmas que categorizam as técnicas e métodos usados na fase de Análise de Sistemas, conforme já explicado na aula 1, têm relação íntima com os paradigmas de programação que, por sua vez, ditam o estado da arte, posto que as linguagens de programação surgem antes das técnicas de análise e projeto de sistemas.
Todavia, ao escolher a técnica de análise a ser usada, conforme mostrou a imagem anterior, é feita, também, a escolha do paradigma da linguagem de programação que será usada, conforme ilustra a tabela.
Paradigmas de Análise x Paradigmas de LPs
Para saber mais sobre esse assunto, leia o texto "Processo de desenvolvimento de software"
Paradigma da Análise Tradicional
A análise tradicional é a técnica que era usada na fase anterior ao surgimento da análise estruturada. Basicamente, produzia documento textual com a descrição do sistema e seus requisitos e, eventualmente, fazia uso de uma ferramenta bastante popular chamada fluxograma. A abordagem usada era exclusivamente voltada para a perspectiva das funcionalidades do sistema, mais especificamente dos programas (daí o uso dos fluxogramas).  Traçando um paralelo, no tempo, com os paradigmas de LPs, corresponde ao momento onde surgiam as linguagens de 3ª geração (alto nível), mas os programas não eram estruturados sob nenhum aspecto e os GOTOs (desvios incondicionais) eram usados em demasia.
Corresponde ao momento inicial da crise do software (anos 70), pois, a complexidade dos sistemas demandados crescia dia a dia e os programas escritos eram de difícil manutenção o que não facilitava as melhorias nos sistemas já desenvolvidos. Pouco havia de testes no processo de desenvolvimento, que ainda não estava formalizado e firmado como era necessário, ou seja, a qualidade do software era relegada ao segundo plano.
Paradigma da Análise Estruturada
Esse contexto, nada positivo, foi o pano de fundo para o surgimento (com esperança) da chamada análise estruturada, no início da década de 70, juntamente com as linguagens de 3ª geração (alto nível) ditas estruturadas, ou seja, que permitiam a escrita de programas com apenas 3 estruturas: sequencial, decisão e repetição, abolia o uso de GOTOs, surgia a programação modular com refinamentos sucessivos, ou top-down. Como os sistemas demandados aumentavam em complexidade, a técnica de análise estruturada trouxe a idéia da documentação do sistema através de diagramas, ou seja, de modelos que representavam a realidade. O reconhecimento da importância da modelagem de sistemas foi um marco muito importante no processo de desenvolvimento.
Para saber mais sobre esse assunto, leia o texto "Paradigma da Análise Estruturada"
Outra característica relevante foi a percepção da necessidade em se dividir o processo de desenvolvimento de sistemas em fases, em que cada uma representava um nível de abstração do sistema. Enquanto a sua percussora, a análise tradicional considerava apenas a perspectiva da análise funcional (como os processos funcionavam), a análise estruturada mostrou a importância de outra perspectiva fundamental: dos dados. O reconhecimento da importância dos dados gerou questionamentos do que era mais relevante: os dados ou