Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Apostila Engenharia Software
Tipologia: Notas de estudo
1 / 109
Esta página não é visível na pré-visualização
Não perca as partes importantes!
No inicio da década de 1980, uma reportagem de primeira pagina da revista Business Week apregoava a seguinte manchete: "Software: A Nova Força Propulsora". O software amadurecera - tornara-se um tema de preocupação administrativa. Em meados da década de 1980, uma reportagem de capa da Fortune lamentava "Uma Crescente Defasagem de Software" e, ao final da década, a Business Week avisava os gerentes sobre a "Armadilha do Software - Automatizar ou Não?". No começo da década de 1990, uma reportagem especial da Newsweek perguntava: "Podemos Confiar em Nosso Software?" enquanto o Wall Street Journal relacionava as "dores de parto" de uma grande empresa de software com um artigo de primeira página intitulado "Criar Software Novo: Era Uma Tarefa Agonizante...". Essas manchetes, e muitas outras iguais a elas, eram o anuncio de uma nova compreensão da importância do software de computador - as oportunidades que ele oferece e os perigos que apresenta.
O software agora ultrapassou o hardware como a chave para o sucesso de muitos sistemas baseados em computador. Seja o computador usado para dirigir um negocio, controlar um produto ou capacitar um sistema, o software é um fator que diferencia. A inteireza e a oportunidade. das informações oferecidas pelo software (e bancos de dados relacionados) diferenciam uma empresa de suas concorrentes. O projeto e a capacidade de ser "amigável ao ser humano" (human-friendly) de um produto de software diferenciam-no dos produtos concorrentes que tenham função idêntica em outros aspectos. A inteligência e a função oferecidas pelo software muitas vezes diferenciam dois produtos de consumo ou industrias idênticas. E o software que pode fazer a diferença.
Há 20 anos, menos de 1% do público poderia descrever de forma inteligível o que significa "software de computador". Hoje, a maioria dos profissionais bem como a maior parte do público, acham que entendem o que é software. Será que entendem?
Uma descrição de software num livro didático poderia assumir a seguinte forma: "Software é: (1) instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados; (2) estruturas de dados que possibilitam que os programas manipulem adequadamente a informação; e (3) documentos que descrevem a operação e o uso dos programas". Não há duvida de que outras definições, mais completas, poderiam ser oferecidas. Mas precisamos de algo mais que uma definição formal.
O software é um elemento de sistema lógico, e não físico. Portanto, o software tem características que são consideravelmente diferentes das do hardware:
microeletronicos que são capazes de processar 200 milhões de instruções por segundo. Em livros populares sobre a "revolução do computador", Osborne caracterizou uma "nova revolução industrial", Toffler chamou o advento da microeletronica de "a terceira onda de mudança" na historia humana e Naisbitt previu que a transformação de uma sociedade industrial em uma "sociedade de informação" terá um profundo impacto sobre nossas vidas. Feigenbaum e McCorduck sugeriram que a informação e o conhecimento (controlados por computador) serão o foco principal de poder no século XXI, e Stoll argumentou que a "comunidade eletrônica" criada por redes e software e a chave para a troca de conhecimentos em todo o mundo. Quando se iniciava a década de 1990, Toffler descreveu uma "mudança de poder", em que as velhas estruturas de poder (governamental, educacional, industrial, econômico e militar) se desintegrarão enquanto os computadores e o software levarão a uma "democratização do conhecimento".
Primeiros Anos 1950 a 1960
Segunda Era 1960 a 1970
Terceira Era 1970 a 1980
Quarta Era 1980 a 2000 Orientação Batch Multiusuário Interativo Sistemas Distribuídos Sistemas de Desktop poderosos Distribuição Limitada Tempo Real Hardware de Baixo Custo Tecnologias Orientadas à Objetos Software Customizado Banco de Dados Microprocessadores Sistemas Especialistas Programação Artesanal Produto de Software Impacto de Consumo Computação paralela Sem Administração Específica Software House “inteligência” embutida Ferramentas CASE Sem Documentação Reutilização Redes Neurais artificiais
A tabela descreve a evolução do software dentro do contexto das áreas de aplicação de sistemas baseados em computador. Durante os primeiros anos do desenvolvimento de sistemas computadorizados, o hardware sofreu continuas mudanças, enquanto o software era visto por muitos como uma reflexão posterior. A programação de computador era uma arte "secundaria" para a qual havia poucos métodos sistemáticos. O desenvolvimento do software era feito virtualmente sem administração - ate que os prazos começassem a se esgotar e os custos a subir abruptamente. Durante esse período, era usada uma orientação batch (em lote) para a maioria dos sistemas. Notáveis exceções foram os sistemas interativos, tais como o primeiro sistema de reservas da American Airlines e os sistemas de tempo real orientados a defesa, como o SAGE. Na maior parte, entretanto, o hardware dedicava-se a execução de um único programa que, por sua vez, dedicava-se a uma aplicação específica.
Durante os primeiros anos, o hardware de propósito geral tornara-se lugar comum. O software, por outro lado, era projetado sob medida para cada aplicação e tinha uma distribuição relativamente limitada. O produto software (isto e, programas desenvolvidos para serem vendidos a um ou mais clientes) estava em sua infância. A maior parte do software era desenvolvida e, em ultima analise, usada pela própria pessoa ou organização. Você escrevia-o, colocava-o em funcionamento e, se ele falhasse, era você quem o consertava. Uma vez que a rotatividade de empregos era baixa, os gerentes podiam dormir tranqüilos com a certeza de que você estaria lá se defeitos fossem encontrados.
Por causa desse ambiente de software personalizado, o projeto era um processo implícito realizado no cérebro de alguém, e a documentação muitas vezes não existia. Durante os primeiros anos, aprendemos muito sobre a implementação de sistemas baseados em computador, mas relativamente pouco sobre engenharia de sistemas de computador. Por justiça, entretanto, devemos reconhecer os muito surpreendentes sistemas baseados em computador desenvolvidos durante essa época. Alguns deles permanecem em uso ate hoje e constituem feitos que são um marco de referência e que continuam a justificar a admiração.
A segunda era da evolução dos sistemas computadorizados estendeu-se de meados da década de 1960 até o final da década de 1970. A multiprogramação e os sistemas multiusuários introduziram novos conceitos de interação homem-máquina. As técnicas interativas abriram um novo mundo de aplicações e novos níveis de sofisticação de software e hardware. Sistemas de tempo real podiam coletar, analisar e transformar dados de múltiplas fontes, dai controlando processos e produzindo saída em milissegundos, e não em minutos. Os avanços da armazenagem on-line levaram à primeira geração de sistemas de gerenciamento de bancos de dados.
A segunda era também foi caracterizada pelo uso do produto de software e pelo advento das "software houses". O software era desenvolvido para ampla distribuição num mercado interdisciplinar. Programas para mainframes e minicomputadores eram distribuídos para centenas e, às vezes, milhares de usuários. Empresários da industria, governos e universidades puseram-se "desenvolver pacotes de software" e a ganhar muito dinheiro.
A medida que o numero de sistemas baseados em computador crescia, bibliotecas de software de computador começaram a se expandir. Projetos de desenvolvimento internos nas empresas produziram dezenas de milhares de instruções de programa. Os produtos de software comprados no exterior acrescentaram centenas de milhares de novas instruções. Uma nuvem negra apareceu no horizonte. Todos esses programas - todas essas instruções - tinham de ser corrigidos quando eram detectadas falhas, alterados conforme as exigências do usuário se modificavam ou adaptados a um novo hardware que fosse comprado. Essas atividades foram chamadas coletivamente de manutenção de software. O esforço despendido na manutenção de software começou a absorver recursos em índices alarmantes.
E, ainda pior, a natureza personalizada de muitos programas tornava-os virtualmente impossíveis de sofrer manutenção. Uma "crise de software" agigantou-se no horizonte.
A terceira era da evolução dos sistemas computadorizados começou em meados da década de 1970 e continua ate hoje. Os sistemas distribuídos - múltiplos computadores, cada um executando funções concorrentemente e comunicando-se um com o outro - aumentaram intensamente a complexidade dos sistemas baseados em computador. As redes globais e locais, as comunicações digitais de largura de banda (handwidth) elevada e a crescente demanda de acesso "instantâneo" a dados exigem muito dos desenvolvedores de software.
A terceira era também foi caracterizada pelo advento e generalização do uso de microprocessadores, computadores pessoais e poderosas estações de trabalho (workstations) de mesa. O microprocessador gerou um amplo conjunto de produtos inteligentes - de automóveis a fornos de microondas, de robôs industriais a equipamentos para diagnostico de soro sangüíneo. Em muitos casos, a tecnologia de software esta sendo integrada a produtos por equipes técnicas que entendem de hardware mas que freqüentemente são principiantes em desenvolvimento de software.
O computador pessoal foi o catalisador do crescimento de muitas empresas de software. Enquanto as empresas de software da segunda era vendiam centenas ou milhares de copias de seus programas, as empresas da terceira era vendem dezenas e ate mesmo centenas de milhares de cópias. O hardware de computador pessoal está se tornando rapidamente um produto primário, enquanto o software oferece a característica capaz de diferenciar. De fato, quando a taxa de crescimento das vendas de computadores pessoais se estabilizou em meados da década de 1980, as vendas de software continuaram a crescer. Na industria ou em âmbito domestico, muitas pessoas gastaram mais dinheiro cm software do que aquilo que despenderam para comprar o computador no qual o software seria instalado.
A quarta era do software de computador esta apenas começando. As tecnologias orientadas a objetos estão rapidamente ocupando o lugar das abordagens mais convencionais para o desenvolvimento de software em muitas áreas de aplicação. Autores tais como Feigenhaum, McCorduck e Allman prevêem que os computadores de "quinta geração", arquiteturas de computação radicalmente diferentes, e seu software correlato exercerão um profundo impacto sobre o equilíbrio do poder político e industrial em todo o mundo. As técnicas
problemas complexos que não apresentam facilidades computacionais numéricas ou de análise direta.
Urna primeira definição de engenharia de software foi proposta por Fritz Bauer na primeira grande conferencia dedicada ao assunto: "O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que funcione eficientemente cm máquinas reais."
A engenharia de software é uma derivação da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais - métodos, ferramentas e procedimentos
Os métodos de engenharia de software proporcionam os detalhes de "como fazer" para construir o software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento c estimativa de projeto, análise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada a linguagem especial e introduzem um conjunto de critérios para a qualidade do software.
As ferramentas de engenharia de software proporcionam apoio automatizado ou semi- automatizado aos métodos. Atualmente, existem ferramentas para sustentar cada um dos métodos anotados anteriormente. Quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa ser usada por outra, é estabelecido um sistema de suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador (CASE - Computer-Aided Software Engineering). O CASE combina software, hardware e um banco de dados de engenharia de software (uma estrutura de dados contendo importantes informações sobre analise, projeto, codificação e teste) para criar um ambiente de engenharia de software que seja análogo ao projeto auxiliado por computador/engenharia auxiliada por computador para o hardware.
Os procedimentos da engenharia de software constituem o elo de ligação que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador. Os procedimentos definem a seqüência em que os métodos serão aplicados, os produtos (deliverables) que se exige que sejam entregues (documentos, relatórios, formulários etc.), os controles que ajudam a assegurar a qualidade e a coordenar as mudanças, e os marcos de referencia que possibilitam aos gerentes de software avaliar o progresso.
A engenharia de software compreende um conjunto de etapas que envolve métodos, ferramentas e os procedimentos. Essas etapas muitas vezes são citadas como paradigmas da engenharia de software. Um paradigma de engenharia de software e escolhido tendo-se como base a natureza do projeto e da aplicação, os métodos e as ferramentas a serem usados, os controles e os produtos que precisam ser entregues.
É um conjunto integrado de métodos e ferramentas utilizadas para especificar, projetar, implementar e manter um sistema.
Segundo Ariadne Carvalho & Thelma Chiossi no livro Introdução à Computação, a Engenharia de Software é “Uma disciplina que reúne metodologias, métodos e ferramentas a
ser utilizados, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolve problemas inerentes ao processo de desenvolvimento e ao produto de software.” Pode-se definir como:
Abordagem estruturada caracterizada pela decomposição das funções. Os tipos de modelos que representam as funções são:
Abordagem baseada na decomposição de um problema a partir dos dados. Exemplos de tipos de modelos dessa classe:
Os tipos de modelos que representam essa classe são:
Segundo Roger Pressman, “Paradigmas são os modelos de processos que possibilitam:
Os paradigmas serão estudados no em outro capitulo.
Este texto apresenta algumas diretrizes para as entrevistas que você fará durante a fase de análise de sistemas do projeto de desenvolvimento de um sistema. Provavelmente entrevistará usuários, gerentes, auditores, programadores e auxiliares que utilizam sistemas já existentes (informatizados ou manuais) e também várias outras pessoas envolvidas.
Por que fazemos entrevistas durante a análise de sistemas? Porque:
A forma mais comum de entrevista é uma reunião pessoal e direta entre você (talvez acompanhado por até dois analistas auxiliares do projeto) e um ou mais interlocutores (entrevistados). Normalmente são efetuadas anotações por um dos entrevistadores; menos costumeiramente, a entrevista pode ser gravada ou um(a) secretário(a) tomará notas durante a entrevista.
Pode-se perceber que as informações obtidas em uma entrevista também podem ser obtidas por outros meios, por exemplo, solicitando-se que os entrevistados respondam por escrito a um questionário formal, ou solicitando que descrevam por escrito os requisitos do novo sistema. Também podemos aumentar as entrevistas pela presença de vários especialistas (que podem até conduzir a entrevista enquanto o analista de sistemas participa como assistente), como peritos em indústria/comercio, psicólogos comportamentais e negociadores. E, finalizando, deve-se lembrar que outros meios de obtenção de dados (ex.: videocassete, gravadores, etc...) podem ser utilizados para registrar uma entrevista.
Durante a década de 80, uma forma especializada de entrevista tornou-se popular em algumas empresas; conhecida como JAD (Joint Application Development) ou projeto acelerado, ou análise em equipe, e por vários outros nomes. Ela consiste em uma rápida entrevista e um processo acelerado de coleta de dados em que todos os principais usuários e o pessoal da análise de sistemas agrupam-se em uma única e intensiva reunião (que pode prolongar-se de um dia a uma semana) para documentar os requisitos do usuário. A reunião costuma ser supervisionada por um profissional experiente e bem treinado que atua como mediador para encorajar melhores comunicações entre os analistas de sistemas e os usuários. Freqüentemente, este supervisor é apoiado por algumas pessoas que se dedicam integralmente ao processo.
Embora todas essas variações tenham de fato sido utilizadas, elas são relativamente raras e não serão discutidas em maiores detalhes neste texto. A entrevista mais utilizada ainda é a reunião pessoal entre um analista de sistemas e um usuário final.
Inicialmente pode parecer que o processo de entrevistar um usuário seja uma questão simples e direta. Afinal, o analista e o usuário são pessoas inteligentes e capazes de expressarem. Os dois são pessoas racionais e ambos têm o mesmo objetivo: passar informações relativas a um novo sistema proposto da mente do usuário para a do analista. Qual é o problema?
Na realidade, existem muitos problemas que podem ocorrer. Em muitos projetos de alta tecnologia, tem-se observado que a maioria dos problemas difíceis não envolvem hardware nem software, mas sim o pleopleware. Os problemas de peopleware na análise de sistemas são muitas vezes encontrados nas entrevistas. Os problemas mais comuns a que você deve estar atento são:
O principal aspecto desta sugestão é que deve-se compreender que está tomando o tempo do usuário e que ele (ou o chefe dele) pode achar até que o analista esteja desperdiçando o tempo dele. Assim sendo, é importante o planejamento e preparação tão antecipadamente quanto possível para poder fazer uso eficiente da entrevista.
A primeira coisa a fazer é certificar-se de que o usuário conhece o assunto da entrevista. Em alguns casos isso pode ser feito por telefone; em outros, pode ser adequado preparar uma lista das perguntas que serão feitas, ou dos tópicos que serão abordados, ou dos DFD que necessita ser revisados, e remetê-la ao usuário com um dia ou dois de antecipação. Se não puder fazer isso, é um indício de que de fato o analista não está preparado para a entrevista. E se o usuário não tiver lido o material remetido, é sinal de que:
Se tiver preparado as perguntas antecipadamente, o analista deve ser capaz de realizar a entrevista em uma hora ou menos. Isso é importante; não só o usuário é geralmente incapaz de reservar mais do que uma hora de cada vez, mas também as pessoas normalmente não conseguem se concentrar intencionalmente (principalmente se estiverem examinando diagramas um tanto estranhos) por mais do que uma hora. Isso naturalmente significa que deve-se organizar a entrevista para abranger um escopo relativamente limitado, focalizando normalmente uma parte do sistema. Isso também pode significar que tenha de marcar algumas entrevistas com o mesmo usuário para abranger inteiramente a área em que ele está envolvido.
Finalizando, marcar uma reunião subseqüente para rever o material que foi coletado. Normalmente, após a entrevista, o analista irá para sua mesa com todas as informações colhidas na entrevista, e executará bastante trabalho com os dados brutos. Pode haver DFD a serem desenhados ou itens a serem criados no dicionário de dados; cálculos de custo/benefício podem precisar ser feitos; as informações provenientes da entrevista podem precisar ser correlacionados com dados de outras entrevistas, e assim por diante. Em qualquer caso, os dados dessa entrevista serão manipulados, documentados, analisados e convertidos em uma forma que o usuário pode nunca ter visto antes. Desse modo, pode ser necessário marcar uma entrevista posterior para verificar:
Durante a entrevista, pode-se achar conveniente utilizar ferramentas de prototipação, principalmente se o objetivo da entrevista for discutir a visão que o usuário tem da interface pessoa-máquina. De modo semelhante, se estiver revisando um diagrama de fluxo de dados e discutindo possíveis modificações, poderá achar prático usar uma ferramentas CASE.
Lembre-se, que o objetivo dessas ferramentas é facilitar as discussões e não complicá-las; elas devem permitir que o analista e o usuário examinem alternativas e modificações com rapidez e facilidade; elas podem ajudar a registrar o conhecimento de um requisito do usuário e corrigir imediatamente quaisquer erros que tenha sido cometido.
Se, a tecnologia introduzir-se no assunto, deve-se deixar fora da entrevista. Se o usuário tiver de aventurar-se além de seu ambiente normal de atividade (para outro prédio, na sala do computador) poderá encarar a ferramenta como um aborrecimento. Se o usuário não estiver familiarizado com a tecnologia de computadores e for solicitado a utilizar a ferramenta, poderá rejeitá-la. E se o analista não estiver familiarizado com a ferramenta (ou se a ferramenta for lenta, apresentar erros ou de emprego limitado) isso interferirá sensivelmente na entrevista. Em qualquer desses casos, talvez seja preferível usar a ferramenta off-line depois da entrevista; então, poderá mostrar ao usuário a saída da ferramenta sem causar quaisquer problemas desnecessários.
Se o analista tiver de desenvolver um modelo completo de sistema para alguma parte de um sistema, possivelmente necessitará determinar entradas, saídas, funções, características tempo-dependentes e a memória armazenada do sistema. Porém a ordem em que se obtém essas informações costumam não ter muita importância. Mas pode significar muito para o usuário, e deve deixá-lo começar a entrevista por onde ele preferir. Alguns usuários desejarão começar pelas saídas, isto é, pelos relatórios e valores de dados que eles querem que o sistema produza (na realidade, eles talvez nem saibam que entradas serão necessárias para produzir as saídas desejadas). Outros usuários poderão estar mais interessados nas entradas ou nos detalhes de uma transformação funcional. Outros ainda preferirão falar sobre os detalhes dos dados de um depósito de dados. Deve-se esforçar para enxergar os requisitos do sistema da perspectiva desses usuários, e conservar esta perspectiva em mente quando fizer as perguntas necessárias sua entrevista.
Como diz William Davis [Davis, 1983]: Sua atitude em relação à entrevista é importante na determinação de seu sucesso ou fracasso. Uma entrevista não é uma competição. Evite ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não uma tentativa de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nem indiretamente. Uma entrevista não é um julgamento. Faça perguntas detalhadas, mas não faça perguntas para confirmar outras respostas. Lembre-se que o entrevistado é o perito e que é você que precisa de respostas. Para concluir, de modo algum critique a credibilidade de outras pessoas.
As diretrizes acima alertaram sobre os inúmeros problemas políticos com que o analista pode se defrontar em uma entrevista e os muitos motivos pelos quais o usuário pode mostrar- se hostil. Mas ainda existem alguns problemas para os quais deve-se estar atento:
de ela estar associada a alguma coisa dentro dos limites do sistema ou fora deles. Desse modo, deve-se dar especial atenção ao desenvolvimento do modelo ambiental.
As entrevistas não são o único modo de coleta de informações sobre os requisitos de um sistema. Na realidade, quanto mais informações puder colher de outras fontes, mais produtivas poderão ser as entrevistas pessoais. Alternativas para as entrevistas:
