Aula 02

Prévia do material em texto

Aula 2
O processo de desenvolvimento de Software
1 - 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.
2 - 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 – XP e Scrum) e RUP (Processo Unificado).
3 - 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.
4 - 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.
Concepção -> Analise -> Projeto -> Implementação -> Testes -> Manutenção -> Implantação
O Contexto da Análise de Sistema
A análise de sistemas é uma 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: 
1 - 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.
2 - 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.
[Usuário] <Entendimento> [Analista de sistema] <Especificação> [Equipe de desenvolvimento]
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.
Paradigmas de Analise 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.
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.
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 as funções de um sistema? Mal se sabia que esse questionamento viria mais tarde a ser respondido pela análise orientada a objetos, que integrou as 2 perspectivas (funções e dados), mostrando que são igualmente relevantes.
A cada nível, mais detalhes são inseridos. O DFD de contexto representa o relacionamento do sistema com as entidades externas e o diagrama de nível ZERO mostra as principais funções. Em um DFD, as funções são representadas por processos (representados pelos círculos), que quando não forem mais detalhados em outros níveis, devem ter sua lógica de funcionamento devidamente especificada, conforme ilustra a figura 5 (Especificação de processo).
O Dicionário de Dados (DD) é a ferramenta que complementa o DFD, explicando o conteúdo de cada um de seus elementos, conforme ilustra a figura 6 (Dicionário de dados).
Paradigma da análise essencial
Antes da Análise OO, que revolucionaria a formade pensar e estruturar os sistemas e programas viria a análise essencial como uma evolução (melhoria) da técnica de análise estruturada, na tentativa de solucionar os problemas surgidos com a aplicação prática desta. Os principais problemas da análise estruturada eram:
1 - Por onde começar a fase de análise? 
Não havia uma diretriz clara de como iniciar a modelagem na fase de análise. A decisão ficava a cargo dos profissionais, ditada pelas experiências desses profissionais. Ou seja, mostrava ser um processo de extrema subjetividade, como em geral são os processos analíticos que dependem dos seres humanos.
2 - Separação entre aspectos lógicos e físicos, ao modelar o sistema: 
Dizia-se que o DFD devia ser um modelo lógico, sem considerar aspectos físicos (tempo, forma de fazer e etc). Mas esse era um conceito abstrato e muitas vezes não considerado. Na verdade, o que se desejava era se concentrar nos reais requisitos dos usuários, sem confundi-los com aspectos irrelevantes.
3 - A identificação das principais funções do sistema (nível zero do DFD) era subjetiva e o mesmo sistema podia ter diferentes formas de agrupar e duvidir funções, dependendo da visão de quem o modelava.
4 - O DFD dava pouca ênfase a análise de dados, por isso, somente mais tarde, quando Peter Chain cria o MER (Modelo de Entidade e Relacionamentos), pouco antes do surgimento da análise estruturada, é que o modelo de dados foi incorporado à fase de análise.
5 - Um DFD desenvolvido com a técnica de análise estruturada sempre é diferente se feito por profissionais diferentes, dada a subjetividade da técnica.
Para tentar resolver o problema acima, surge a Analise Essencial de Sistemas, trazendo consigo o conceito de Evento e da construção da Lista de Eventos que afetam o sistema, na tentativa de criar diretrizes para facilitar o processo de desenvolvimento e sanar o primeiro problema acima apresentado, ou seja, “[1] – por onde começar a análise?”. A análise essencial responde, identificando os eventos que afetam o sistema, através da elaboração da lista de Eventos, conforme ilustrado na figura 8 (Lista de Eventos do Sistema).
Ou seja, os eventos são a pedra fundamental dos sistemas e a especificação de um sistema deve começar pela identificação dos eventos (Lista de Eventos).
Conforme ilustrado na figura 7 (Conceito de Evento da Analise Essencial), no link, Evento, segundo a Análise Essencial é um acontecimento que afeta o sistema, que reage ativando uma de suas funções. A ideia central é que “para cada função a ser executada pelo sistema precisa já haver um estimulo a sua ativação”. Assim, pode-se concluir que: para se descobrir as funções de um sistema devemos primeiro identificar quais estímulos chegam ao sistema. Para cada estimulo que chega ao sistema deve a ocorrência de um evento, no mundo externo, ao sistema. Esse evento é que vai provocar o estimulo a que o sistema vai responder.
Acredita-se que a adoção da técnica de análise essencial levaria ao desenvolvimento de sistemas mais eficientes, comparativamente aos desenvolvidos sob a técnica de análise estruturada. Na pratica, analise essencial preservou os mesmos modelos de analise estruturada como: DFD (em níveis), dicionário de dados especificação de processos, tendo acrescido: a lista de eventos, DFD particionando por evento, Modelo de Entidade e Relacionamento de DTE (Diagrama de transição de Estados).
A Análise Essencial, também chamada de Análise Estruturada Moderna surgiu como uma estratégia de modelar o que o sistema deve fazer para satisfazer os requisitos dos usuários, partindo do princípio que dispomos de tecnologia perfeita, obtida a custo zero. Essa característica visa resolver o problema de número [2] - Separação entre aspectos lógicos e físicos, ao modelar o sistema. Ao separar a tecnologia e dando-a como perfeita, capaz de processar tudo, de armazenar tudo, sem custo, concentra-se no problema do usuário e com isso aumentar as chances de sucesso do sistema.
Com relação ao problema [3] – A identificação das principais funções do sistema (nível zero do DFD) era subjetiva, a Analise Essencial tentou minimizar, porque na verdade não conseguiu, mostrando que esse nível de funções podia ser obtido através do agrupamento das funções do DFD Preliminar que, por sua vez, seria a junção de todos os DFDs particionados. Todavia, esse “agrupamento de funções de funções do DFD preliminar” também era de certa forma subjetivo e, como consequência, continuávamos a ter diferentes soluções dadas por diferentes analistas de sistemas.
O problema [4] – O DFD dava pouca ênfase à análise de dados; foi resolvido na medida em que a partido do DFD particionado, elaborava-se o MER (Modelo de Entidade e Relacionamento), que já estava sendo usado ao final pela Analise Estruturada. A figura 9-B (Modelo Conceitual de dados - MER) mostra o MER, que mostra os dados tratados pelo sistema e o relacionamento entre eles.
O problema [5] – Um DFD desenvolvido com a técnica de análise estruturada sempre é diferente, se feito por profissionais diferentes; no final das contas, não foi totalmente solucionado, em função do que fora explicado no parágrafo acima onde foi retratada a solução para o problema [3]. Ou seja, o agrupamento de funções do DFD particionado já representa, por si só, uma atividade subjetiva, pois, podem ser seguidos diferentes critérios de agrupamento.
Para suportar a modelagem dos sistemas complexos e grandes, característicos daquele momento, a Análise Essencial não atendia plenamente. Ainda havia lacunas a serem preenchidas e estávamos no meio da crise do Software, onde o mercado clamava por uma metodologia de análise e projeto de sistemas mais efetiva, que apresentasse, na prática, melhores resultados. Em termos de programação, as pessoas já haviam aprendido a usar rotinas e funções de bibliotecas, otimizando o tempo de desenvolvimento, mas faltava algo mais, que pudesse aumentar o índice de aproveitamento de código e otimizar o desenvolvimento. A fase de manutenção também não apresentava resultados satisfatórios, com custos elevados, dispêndio de tempo excessivo e programas de baixa qualidade.
Estávamos no auge da crise do software e os problemas mais contundentes da época eram:
Duplicação de esforços na construção do software.
Dificuldade em estimar (poucos dados iniciais). 
Não cumprimento de prazos (cronograma) de desenvolvimento.
Alto Custo de desenvolvimento (tempo e mão de obra).
Software não atende aos requisitos.
Alto custo de manutenção.
Alto volume de documentação demandada pelos sistemas e dificuldade em mantê-los atualizados durante a fase de manutenção.
As pesquisas e desenvolvimento, em nível de linguagens de programação, já apontavam para as primeiras experiências com as linguagens orientadas a objeto. O conceito de objeto vem de encontro do que se precisa em termos de melhorias na implementação do código e potencializa a solução dos problemas que são apresentados a seguir, na medida em que:
Facilita o controle da complexidade inerente ao software.
Promove a reusabilidade componentes de código reutilizáveis.
Promove o desenvolvimento de sistemas de fácil manutenção, como consequência dos dois itens acima.
Como já dito 1º. Aula, o surgimento de um novo paradigma de desenvolvimento começa com a produção de linguagens de programação que implemente os conceitos de novo paradigma, na sequencia são criadas as técnicas de modelagem de projeto e, por fim, as técnicas de modelagem de análise do sistema. Com o paradigma orientado a objeto, que surge no contexto acima apresentado, não foi diferente.
Paradigma da análise orientada a objeto (OO)
O paradigma orientado a objeto, doravante paradigma OO, trouxe uma grande revolução na forma de se pensar “o desenvolvimento de um sistema”, comparativamente ao paradigma antecessor, a Análise Essencial.  A visão de sistema, ilustrado na figura 10 (Mudança de Paradigma: Módulo x Objeto), até aquele momento visto como um “conjunto de módulos (partes, ou subsistemas) integrados”, passaa ser a de um “conjunto de objetos relacionados”.
Conforme ilustrado na imagem, ao passo em que na análise essencial (e estruturada) o sistema era visto sob duas perspectivas isoladas (procedimentos que realizam operações sobre os dados), na análise OO, os objetos possuem características próprias, modeladas por seus atributos (dados) e métodos (procedimentos) e as classes representam um conjunto de objetos com as mesmas características. Ou seja, houve uma integração entre procedimentos (agora chamados de métodos) e os dados (atributos) das duas perspectivas sobre as quais se modelavam os sistemas.
Sugerimos o acesso aos seguintes sites, referentes aos diferentes paradigmas de desenvolvimento, no que tange a linguagens de programação e os métodos (e técnicas) de análise de sistemas. 
 
Procure explorar todos os links existentes nas URLs, abaixo relacionadas.
 
Todos os sites abaixo foram acessados em 12/11/2011
http://walterdominguez.com/contextoconteudo/tema/analise%20de%20sistemas/analise%20de%20sistemas.html
http://dsgomes-tec-info.blogspot.com/2011/10/paradigmas-de-analise-de-sistemas.html