TÉCNICAS DE DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 TÉCNICAS DE DESENVOLVIMENTO DE SISTEMAS Nesta disciplina trataremos de vários aspectos que se referem ao desenvolvimento de software. É uma disciplina intrinsecamente teórica onde discutiremos tópicos que vão desde a origem conceitual dos sistemas, passando por questões inerentes à engenharia de software, organização das empresas de desenvolvimento de sistemas e seus profissionais e, finalmente ferramentas de definição e especificação de sistemas. Apesar do conteúdo teórico, teremos oportunidade de aplicação de diversos conceitos em exercícios, projetos e seminários. O conteúdo da disciplina é o seguinte (1) : Capítulo I - Sistemas conceitos e características; Cibernética e Sistemas Classificação dos Sistemas Parâmetros dos Sistemas Hierarquia dos Sistemas Representação dos Sistemas (os Modelos) Conceito de entrada ( Input ) Conceito de Saída ( Output ) Conceito de Caixa Preta ( Black Box ) Conceito de Retroação ( Feedback ) Fronteiras ou limites Capítulo II - Ciclo de vida dos sistemas; Introdução Conceitos Tipos de Ciclo de Vida Ciclo de Vida Clássico Prototipação Espiral b) Processo de desenvolvimento de software; Levantamento de Dados; Análise; Ferramentas; c) Profissionais da área de informática; d) Diagrama de Fluxo de Dados; Características; Simbologia; Regras de criação Modelo Lógico / Modelo Físico; e) Dicionário de Dados Conceitos Gerais Definição de dicionário de Dados para: Elementos de Dados Estruturas de Dados

2 Depósitos de Dados Fluxo de Dados; Entidades Externas; Processos: Definição Lógica dos Processos i. Português Estruturado ii. Árvores de Decisão iii. Tabelas de Decisão iv. Pseudocódigo (1) Os itens em negrito estão cobertos pelo presente material. Os demais itens ainda estão em edição.

3 CAPÍTULO I - SISTEMAS: CONCEITOS E CARACTERÍSTICAS Cibernética e Sistemas Origens A Cibernética é uma ciência relativamente jovem. Foi criada por Norbert Wiener (1) entre os anos de 1943 e Nessa mesma época, Von Bertalanffy (1947) já definia a Teoria Geral dos Sistemas. Em sua origem, a Cibernética surgiu como ciência destinada a estabelecer relações entre as várias ciências, no sentido de preencher tanto os espaços vazios interdisciplinares não pesquisados por nenhuma ciência, como também de permitir que cada ciência utilizasse para seu desenvolvimento os conhecimentos desenvolvidos pelas demais ciências. A Cibernética logo ampliou o seu campo de ação com o desenvolvimento da Teoria Geral dos Sistemas inicia do por Von Bertalanffy (1947) e com a Teoria da Comunicação por Shannon e Weaver em Objeto de estudo A Cibernética é a ciência da comunicação e do controle, seja no animal (homem, seres vivos) seja na máquina. A comunicação é que torna os sistemas integrados e coerentes e o controle é que regula o seu comportamento. A Cibernética compreende os processos e sistemas de transformação da informação e sua concretização em processos físicos, fisiológicos, psicológicos. Seu núcleo são os sistemas de processamento das mensagens. Os aspectos operacionais da Cibernética estão relacionados com qualquer campo científico de estudo, como a Engenharia, a Biologia, a Física, a Sociologia, a Psicologia. Bertanlanffy salienta que A Cibernética é uma teoria dos sistemas de controle baseada na comunicação (transferência de informação) entre o sistema e o meio e dentro do sistema e do controle (retroação) da função dos sistemas com respeito ao ambiente Assim sendo fica claro que o campo de estudo da Cibernética são os sistemas. Sistema é qualquer conjunto de elementos que estão dinamicamente relacionados entre si formando uma atividade para atingir um objetivo, operando sobre entradas (dados, energia ou matéria) e fornecendo saídas (informação, energia ou matéria) processadas. Os elementos, as a relações entre eles e os objetivos ou propósitos constituem os aspectos fundamentais na definição de um sistema. Estão dinamicamente relacionados entre si mantendo uma constante interação. A rede que caracteriza as relações entre os elementos define o estado do sistema isso revela se ele esta operando todas essas relações ou não. As linhas que formam a rede de relações constituem as comunicações existentes no sistema. A posição das linhas reflete a quantidade de informações do sistema e os eventos que fluem para a rede que constitui o sistema são as decisões. Essa rede é fundamentalmente um processo decisório; as decisões são descritíveis (e mesmo previsíveis) em termos de

4 informação no sistema e de estruturação das comunicações. Assim sendo, no sistema, temos: Um conjunto de elementos (que são as partes ou órgãos do sistema) Dinamicamente relacionados em uma rede de comunicações (em decorrência da interação entre os elementos) Formando uma atividade (que é a operação ou o processamento do sistema) Para atingir um objetivo ou propósito (finalidade do sistema) Operando sobre dados / energia / matéria (que são os insumos ou entradas de recursos para o sistema operar) Para fornecer informação/energia / matéria (que são as saídas do sistema) Como ciência aplicada a Cibernética restringiu suas aplicações à criação de maquinas de comportamento auto-regulável semelhante a aspectos do comportamento do homem ou do animal tais como os robôs, o computador e o radar entre outras. Classificação dos Sistemas Como vimos anteriormente, um sistema é: Um conjunto de elementos Dinamicamente relacionados Formando uma atividade Para atingir um objetivo Operando sobre dados / energia / matéria Para fornecer informação / energia / matéria Há uma grande variedade de sistemas e uma ampla gama de tipologias para classifica-los de acordo com suas características básicas. Quanto à sua constituição, os sistemas podem ser físicos ou abstratos: a) Sistemas físicos ou concretos, quando compostos de equipamentos, de maquinaria e de objetos e coisas reais. Podem ser descritos em termos quantitativos e de desempenho b) Sistemas abstratos, quando compostos de conceitos, planos, hipóteses e idéias. Aqui os símbolos representam atributos e objetos que muitas vezes só existem no pensamento das pessoas. Em certos casos o sistema físico opera em consonância com o sistema abstrato. Exemplo uma escola com suas salas de aula, carteiras, lousas, iluminação para desenvolver um programa de educação (sistema abstrato) ou um centro de processamento de dados onde o equipamento e circuitos processam programas de instruções de computador.

5 Quanto à natureza, os sistemas podem ser fechados e abertos: a) Sistemas fechados: são sistemas que não apresentam intercâmbio com o meio ambiente que os circunda pois são herméticos a qualquer influência ambiental. Sendo assim, os sistemas fechados não recebem nenhuma influencia do ambiente e, por outro lado, também não influenciam o ambiente. Não recebem nenhum recurso externo e nada produzem que seja enviado para fora. A rigor não existem sistemas fechados na acepção exata do termo. Os autores tem dado o nome de sistemas fechados àqueles sistemas cujo comportamento é totalmente determinístico e programado e que operam com muito pequeno intercâmbio de matéria e energia com o meio ambiente. O termo é utilizado também para os sistemas completamente estruturados onde os elementos e relações combinam-se de uma maneira peculiar e rígida produzindo uma saída invariável. b) Sistemas abertos: são os sistemas que apresentam relações de intercâmbio com o ambiente através de entradas e saídas. Os sistemas abertos trocam matéria e energia regularmente com o ambiente. São eminentemente adaptativos, isto é, para sobreviverem devem reajustar-se às condições do meio. Um sistema aberto mantém a si próprio em um contínuo fluxo de entrada e saída.o conceito de sistema aberto pode ser aplicado a diversos níveis de abordagem: ao nível do indivíduo; ao nível do grupo; ao nível da organização; ao nível da sociedade, indo desde um microssistema até um supra-sistema. Em termos mais amplos, vai da célula ao universo. Ambiente Entradas Dados Energia Recursos Materiais Transformação ou Processamento Saídas Informação Energia Recursos Materiais Ambiente MODELO GENÉRICO DE SISTEMA ABERTO

6 Parâmetros dos Sistemas Um sistema se caracteriza por determinados parâmetros. Parâmetros são constantes arbitrárias que caracterizam, por suas propriedades, o valor e a descrição dimensional de um sistema específico ou de um componente do sistema. Os parâmetros de um sistema são: Entrada ou insumo ( input ); Processamento ou transformador ( throughput ); Saída ou resultado ou produto ( output ); Retroação ou retroalimentação ou retroinformação ( feedback ); Ambiente ( environment ) Ambiente Entrada Processamento Saída Ambiente Retroação Hierarquia dos Sistemas Os sistemas são hierárquicos ou piramidais, isto é, são constituídos de sistemas ou de subsistemas relacionados entre si por um processo ou padrão de interação. O próprio universo é um sistema constituído por uma infinidade de sistemas e subsistemas intimamente relacionados entre si Representação dos sistemas: Os Modelos Um dos grandes problemas da Cibernética é a representação dos sistemas originais através de outros sistemas comparáveis que são denominados modelos. No sentido literal da palavra, modelo é a representação de alguma coisa. A importância dos modelos reside exatamente no sentido em que são usados para um melhor entendimento do funcionamento dos sistemas e da relação entre seus elementos. Exemplos típicos de modelos são maquetes ou plantas de edifícios, diagramas de circuitos elétricos ou eletrônicos, organogramas de empresas, fluxogramas e rotinas de procedimentos, modelos matemáticos, diagramas de fluxos de dados (DFD s).

7 Conceito de entrada ( Input ) Entrada é todo tipo de elemento, dados, energia, materiais que dos quais os sistemas se utilizam para poder operar, processando ou transformando-os em saídas (output). Através da entrada o sistema importa elementos do seu meio ambiente. Conceito de Saída ( Output ) Saída ou Output é o resultado final da operação ou processamento de um sistema. Todo sistema produz uma ou mais saídas. Através da saída o sistema exporta o resultado de suas operações para o meio ambiente. Conceito de Caixa Preta ( Black Box ) Utiliza-se o conceito de caixa preta em nessas circunstâncias: Quando o sistema é impenetrável ou inacessível por alguma razão (p. exemplo cérebro humano) Quando o sistema é excessivamente complexo, de difícil explicação ou detalhamento (p ex-computador, economia nacional). Quando desejamos conceituar uma abstração da funcionalidade de um sistema ou subsistema dentro de seu contexto sem, no entanto detalha-lo. O importante a destacar nesse conceito é que podemos usa-lo para entender melhor o funcionamento dos sistemas. Pode-se olhar um determinado problema ou comportamento apenas pelas suas entradas e saídas, assumindo que o processo é representado por uma caixa preta que não se deseja detalhar no momento. Uma vez entendido o processo através de suas interações, pode-se então tentar entender o processo inerente à caixa preta, detalhando seu funcionamento. Muitos problemas são tratados inicialmente pelo método da caixa preta atuando apenas nas entradas e saídas e posteriormente, transforma-lo numa caixa branca, ou seja, desvendando seus aspectos operacionais e de processamentos. De uma maneira geral, dentro de um sistema todo processamento pode ser representado por uma caixa preta por onde se inserem entradas e se obtém saídas.

8 O exemplo mostrado no gráfico acima é um exemplo de caixa preta que representa o processo de exibir filmes. Coloca-se uma mídia em um dispositivo que ao funcionar é capaz de exibir um filme. Perceba que a abstração não fixa qualquer tipo de tecnologia, e assim sendo podemos ter a liberdade de analisar o processo independente de como seja o processo internamente. O dispositivo acima poderia ser um videocassete, um DVD, um rolo de filme e um projetor, ou mesmo um filme sendo exibido dentro de seu computador pessoal. Conceito de Retroação ( Feedback ) A retroação é um mecanismo segundo o qual uma parte da energia de saída de um sistema ou de uma máquina volta à entrada. A retroação, também chamada de servomecanismo, retroalimentação ou realimentação ou em ingl6es feedback é basicamente um sistema de comunicação do retorno proporcionado pela saída do sistema à sua entrada, no sentido de altera-la de alguma maneira. As principais funções da retroação são: Controlar a saída enviando mensagens geradas após a saída ao regulador de entrada Manter um estado estável da operação dos sistemas quando se defronta com variáveis externa que podem ocasionar sua flutuação Por causa disto, aumentar a probabilidade de que o sistema sobreviva em face das pressões externas. Pode-se dizer de uma maneira geral que o processo de retroação é que permite que os sistemas mantenham sua integridade. É o que permite o exato funcionamento entre seus elementos garantindo que cada entrada possa ser exatamente adequada ao processo que a recebe. Imagine por exemplo o corpo humano sem sistemas de controle. Pare de respirar por alguns segundos e verá que seu corpo reage de uma maneira bastante peculiar exigindo que o seu pulmão volte a funcionar para garantir o funcionamento. Quando se senta para almoçar, em algum momento seu sistema nervoso manda uma mensagem a seu estomago que é hora de parar. Sem esses controles internos possivelmente você morreria, ou seja, seu sistema não se manteria em funcionamento.

9 Fronteiras ou Limites É a linha que serve para demarcar o que está dentro e o que está fora do sistema. Nem sempre a fronteira de um sistema existe fisicamente. Uma definição operacional de fronteira, por exemplo, consiste numa linha fechada ao redor de variáveis selecionadas entre aquelas que tenham maior intercâmbio (de energia, de informação) com o sistema. Imagine por exemplo uma organização com todos os seus departamentos (Controle de estoque, vendas, faturamento). É claro que cada departamento pode ser encarado em si como um sistema autônomo. No entanto é possível perceber que, se colocados lado a lado, existem camadas de superposição entre eles. O sistema de vendas não pode vender algo que não tenha em estoque. O sistema de faturamento não pode faturar algo que não tenha sido vendido. Bibliografia desde Capítulo Chiavenato, Idalberto, Introdução à Teoria Geral da Administração, McGraw-Hill, 3 a Edição, 1983.

10 CAPÍTULO II CICLO DE VIDA DOS SISTEMAS 1. Introdução Qualificar um produto é muito bom para que tenhamos certeza de que há seriedade e preocupação com a satisfação em tê-lo, mas, qualificar o processo de produção é mais importante para obter um produto melhor. Ambas as qualificações (da produção e do produto) são largamente utilizados na produção de muitos produtos inclusive no desenvolvimento de softwares. Hoje, temos normas da ISO 9003 que certificam o processo de produção de software bem como o software pronto. Tais normas exigem cada vez mais qualidade no gerenciamento do projeto e tais exigências são convertidas em benefícios para os usuários e desenvolvedores. Todo desenvolvimento de um software é caracterizado por fases que quando colocadas em seqüência obtem-se um Ciclo de Vida do Sistema e é este ciclo de vida que deve ter qualidade. 2. Conceitos Conforme observações feitas durante os últimos 20 anos, em centenas de organizações que variam de tamanho de algumas até milhares de pessoas, com uma faixa de 1 até 1000 projetos simultaneamente a caminho. Como pode ser esperado, as menores firmas costumam ser relativamente informais: os projetos são iniciados como resultado de uma discussão verbal entre o usuário e o gerente do projeto, e o projeto prossegue da análise de sistemas até o projeto e implementação sem muita algazarra. Em grandes organizações, no entanto, as coisas são feitas em uma base muito mais formal. As várias comunicações entre os usuários gerência e equipe do projeto costumam ser documentados por escrito, e todos entendem que o projeto passará por diversas fases antes que seja terminado. Ainda assim existe grandes diferenças entre o modo com que dois gerentes de projetos na mesma organização conduzem seus respectivos projetos. Normalmente fica a cargo do gerente de projeto determinar de que fases e atividades o seu projeto consistirá e como essa fases serão conduzidas. Recentemente, no entanto, o método assumido para o desenvolvimento de sistemas começou a mudar. Mais e mais grandes e pequenas organizações estão adotando um único e uniforme ciclo de vida do projeto, ou simplesmente "o modo com que fazemos as coisas por aqui". Normalmente contido em um livro tão exuberante quanto o manual de padrões que se encontra (fechado) a mesa de cada programador, o ciclo de vida documentado do projeto fornece uma forma comum para que todos na organização passem a entender como pode ser desenvolvido um sistema de computador. O método pode ser caseiro, ou alternativamente, a organização pode decidir comprar um pacote de gerenciamento de projeto e depois moldá-lo às necessidades da companhia. Deve ser aparente que, além de fornecer emprego para as pessoas que criam manuais de ciclo de vida de projetos, a metodologia de projeto é desejável. Qual, então, é a finalidade de se ter um ciclo de vida de projeto? Há três objetivos principais: 1. Definir as atividades a ser executadas em um projeto. 2. Introduzir a coerência entre muitos projetos na mesma organização 3. Fornece pontos de checagem para controle de gerência e pontos de checagem para a decisão "ir / não ir". O primeiro objetivo é particularmente importante numa grande organização em que novas pessoas estão constantemente entretanto nas fileiras da gerência de projeto. O gerente de projeto inexperiente pode não examinar ou subestimar a significância de importantes fases do projeto se Seguir apenas sua própria intuição.

11 Na verdade, pode acontecer que os programadores e analistas de sistemas júnior não entendam onde e como os seus esforços se encaixam no projeto de um modo geral, a menos que tenham recebido uma descrição apropriada de todas as fases do projeto. O segundo objetivo é importante em uma grande organização. Para os níveis mais altos de gerência, pode ser extremamente desconcertante tentar supervisionar 100 projetos diferentes, cada um deles sendo executado de uma forma diferente. O terceiro objetivo de um ciclo de vida padrão do projeto refere-se à necessidade de gerência em controlar um projeto. Em projetos triviais, o único ponto de checagem é provavelmente o fim do projeto: ele foi terminado dentro do prazo e com o orçamento previsto? Mas, para grande projetos, a gerência deve ter uma série de pontos de checagem intermediários, gerando oportunidade para determinar se o projeto está atrasado e se precisam ser obtidos recursos adicionais. Além disso, um usuário inteligente também pedirá pontos de checagem em diversos estágios no projeto, de modo que possa determinar se quer continuar prorrogando o prazo! Apesar de tudo isto o ciclo de vida não irá fazer o projeto, mais ele ajudará a organizar as atividades, tornando mais provável que você atinja os problemas exatos na hora exata. 3. Tipos de Ciclo de Vida Não existe uma regra ou um ciclo de vida padrão para desenvolvimento de sistema. Você pode usar um ciclo pré-definido por um determinado autor, pode usar o ciclo de um autor e moldá-lo conforme seu trabalho ou ainda criar seu próprio ciclo. Porém, a escolha deve ser feita analisando dois fatores: Características do fornecedor (equipe de desenvolvimento) Habilidade - Analisar os conhecimentos técnicos da equipe. Visão - A equipe deve ter conhecimento do domínio do problema a ser informatizado. Recursos - Equipamentos e material humano Tempo - Tempo disponível para o desenvolvimento Características do cliente (usuário) Visão - Conhecimento de suas necessidades Tempo - Aceitável para a implantação Recurso financeiro - Ter disponibilidade financeira para o investimento em software e hardware Insegurança - Confiabilidade nos resultados a serem gerados pelo sistema Mesmo adotando um modelo de desenvolvimento, se os itens acima não forem bem avaliados, a qualidade do produto final poderá não ser satisfatório. Tanto modelagem estrutural quanto na modelagem orientada existem muitos ciclos sendo os mais utilizados 3.1. Ciclo de Vida Clássico Baseado em uma estrutura linear, exige um bom analista de sistemas pois as fases seqüenciais e dependentes.

12

13 3.2. Prototipação Prototipação O modelo de prototipação se baseia na utilização de um protótipo do sistema real, para auxiliar na determinação de requisito. Um protótipo deve ser de baixo custo e de rápida obtenção, para que possa ser avaliado. Para isto, uma determinada parte do sistema é desenvolvida com o mínimo de investimento mas sem perder as características básicas, para ser analisada juntamente com o usuário. A prototipação é um processo que habilita o desenvolvedor a criar um modelo do software que deve ser construído. O modelo pode tomar uma das 3 formas: a) no papel ou num modelo baseado em PC em que a interação homem-máquina é desenhada para permitir ao usuário entender como tal interação irá ocorrer; b) um protótipo trabalhando, que implementa algum subconjunto da função requerida no software desejado ou c) um programa existente que executa parte ou toda a função desejada mas tem outras características que serão melhoradas no desenvolvimento do novo. O protótipo pode servir como um "primeiro sistema". Alguns problemas surgem: a) o cliente vê o que parece ser uma versão trabalhando do software, sem perceber que na pressa de oferecer algo trabalhando, não foram considerados aspectos de qualidade e de manutenção. Quando é informado de que o produto deve ser reconstruído, o cliente "implora" para não mude. b) o desenvolvedor muitas vezes assume um compromisso de implementação para obter um protótipo trabalhando rapidamente. Um sistema operacional ou linguagem de programação inadequados podem ser usados simplesmente porque estão disponíveis e são conhecidos.

14 3.3. Espiral O modelo espiral foi desenvolvido para abranger as melhores características tanto do modelo clássico como da prototipação, acrescentando ao mesmo tempo, um novo elemento - a análise dos riscos - que falta nos modelos anteriores. O modelo define quatro importantes atividades representadas pelos quatro quadrantes da figura: Planejamento: determinação dos objetivos do sistema que será desenvolvido, restrições impostas à aplicação, tais como: desempenho, funcionalidade, capacidade de acomodar mudanças, meios alternativos de implementação; Análise de risco: análise das alternativas e identificação/resolução dos riscos. Uma vez avaliados os riscos, pode-se construir protótipos para verificar se estes são realmente robustos para servir de base para a evolução futura do sistema; Engenharia: desenvolvimento do produto do "próximo nível ; Avaliação do cliente: avaliação dos resultados de engenharia, pode-se efetuar a verificação e validação. Com cada iteração ao redor da espiral (começando no centro e trabalhando para fora), versões progressivamente mais completas do software são construídas. Durante o primeiro circuito ao redor da espiral, os objetivos, alternativas e restrições são definidas e riscos são identificados e analisados. Se a análise de risco indica que existem dúvidas nos requisitos, a prototipação pode ser usada no quadrante de engenharia para assistir tanto o desenvolvedor como o cliente. Simulações e outros modelos podem ser usados depois para definir o problema e refinar os requisitos. O cliente avalia o trabalho de engenharia (quadrante de avaliação do cliente) e faz sugestões para modificações. Com base nas entradas do cliente, ocorre a próxima fase do planejamento e análise de risco. A cada loop ao redor da espiral, o ponto culminante da análise de risco resulta na decisão "continuar ou não". Se os riscos forem muito altos, o projeto pode ser encerrado. No entanto, em muitos casos, o fluxo ao redor da espiral continua, com cada caminho movendo os desenvolvedores para fora em direção a um modelo mais completo do sistema e, ultimamente, o modelo operacional. Todo circuito ao redor da espiral requer engenharia (o quadrante inferior) que pode ser executado usando a abordagem de prototipação ou o modelo clássico de ciclo de vida. O modelo espiral para engenharia de software pode ser considerado como o modelo mais realista para o desenvolvimento de sistemas grandes. Ele usa uma abordagem "evolucionária" para engenharia de software habilitando o desenvolvedor e o cliente a entender e a reagir aos riscos na evolução de cada nível. Usa o mecanismo de prototipação como um mecanismo de redução, mas mais importante, habilita o desenvolvedor a aplicar a prototipação em qualquer estágio na evolução do produto. Mantém também a abordagem por etapas do modelo clássico, mas incorpora uma estrutura interativa que reflete de forma mais realista o mundo real. O modelo espiral demanda uma consideração direta dos riscos técnicos em todos os estágios do projeto, e se propriamente aplicado, reduziria os riscos antes que eles se tornem problemáticos.

15 4. Bibliografia deste capítulo Yourdon, Edward - Administrando o ciclo de vida do sistema / Edward Yourdon ; tradução de Daniel Vieira. Rio de Janeiro. Campus, 1989.