Engenharia de software

of 145/145
Engenharia de Software
  • date post

    19-May-2015
  • Category

    Documents

  • view

    23.023
  • download

    2

Embed Size (px)

description

Mais: www.portalgsti.com.br

Transcript of Engenharia de software

  • 1. Engenharia deSoftware

2. SUMRIOCaptulo 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS1. Introduo ...................................................................................................... 1.12. Principais Aspectos do Software .................................................................... 1.23. Paradigmas da Engenharia de Software ........................................................ 1.54. Viso geral da Engenharia de Software ....................................................... 1.11Captulo 2 QUALIDADE DE SOFTWARE1. Introduo ...................................................................................................... 2.12. Definio de Software de Qualidade .............................................................. 2.13. Metrologia da Qualidade de Software ............................................................ 2.44. Questes Importantes Qualidade de Software ............................................ 2.45. O Modelo CMM .............................................................................................. 2.6Captulo 3 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE1. Introduo ...................................................................................................... 3.12. Anlise de Riscos........................................................................................... 3.13. Definio de um Cronograma......................................................................... 3.44. Aquisio de Software.................................................................................... 3.85. Reengenharia................................................................................................. 3.96. Planejamento Organizacional......................................................................... 3.97. O Plano de Software .................................................................................... 3.10Captulo 4 ENGENHARIA DE SISTEMAS COMPUTACIONAIS1. Introduo ...................................................................................................... 4.12. Principais Aspectos da Engenharia de Sistemas............................................ 4.13. Anlise de Sistemas....................................................................................... 4.54. Arquitetura do Sistema................................................................................... 4.65. Especificao e Reviso ................................................................................ 4.8Captulo 5 ANLISE DE REQUISITOS1. Introduo ...................................................................................................... 5.12. As Atividades da Anlise de Requisitos.......................................................... 5.13. Processos de Comunicao........................................................................... 5.24. Princpios de Anlise ...................................................................................... 5.35. Prototipao de Software ............................................................................... 5.66. Especificao dos Requisitos de Software ..................................................... 5.77. Anlise Estruturada ........................................................................................ 5.88. Tcnicas de Anlise ..................................................................................... 5.14Captulo 6 PROJETO DE SOFTWARE 3. 1. Introduo ...................................................................................................... 6.12. O Processo de Projeto ................................................................................... 6.13. Aspectos Fundamentais do Projeto................................................................ 6.24. Classes de Projeto ......................................................................................... 6.55. Documentao ............................................................................................... 6.96. Projeto de Interfaces Homem-Mquina ........................................................ 6.11Captulo 7 LINGUAGENS DE PROGRAMAO1. Introduo ...................................................................................................... 7.12. A Traduo .................................................................................................... 7.13. Caractersticas das Linguagens de Programao .......................................... 7.24. Classes de Linguagens .................................................................................. 7.55. Estilo de Codificao...................................................................................... 7.76. Codificao e Eficincia ................................................................................. 7.8Captulo 8 TESTE DE SOFTWARE1. Introduo ...................................................................................................... 8.12. Fundamentos do Teste de Software .............................................................. 8.13. Modalidades de Teste .................................................................................... 8.24. Teste de Unidade........................................................................................... 8.45. Teste de Integrao ....................................................................................... 8.76. Teste de Validao....................................................................................... 8.107. Teste de Sistema ......................................................................................... 8.12Captulo 9 ANLISE E PROJETO ORIENTADOS A OBJETOS1. Introduo ...................................................................................................... 9.12. Orientao a objetos: Conceitos .................................................................... 9.13. Desenvolvimento Orientado a Objetos ........................................................... 9.34. Modelagem Orientada a Objetos.................................................................... 9.45. Anlise Orientada a Objetos......................................................................... 9.156. Projeto Orientado a Objetos......................................................................... 9.16BibliografiaAnexo 4. Engenharia deSoftware 1.1 5. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLACaptulo 1ENGENHARIA DE SOFTWARE CONCEITOS BSICOS1.INTRODUONos anos 40, quando se iniciou a evoluo dos sistemas computadorizados, grandeparte dos esforos, e conseqentes custos, era concentrada no desenvolvimento dohardware, em razo, principalmente das limitaes e dificuldades encontradas na poca. medida que a tecnologia de hardware foi sendo dominada, as preocupaes se voltaram, noincio dos anos 50, para o desenvolvimento dos sistemas operacionais, onde surgiram entoas primeiras realizaes destes sistemas, assim como das chamadas linguagens deprogramao de alto nvel, como FORTRAN e COBOL, e dos respectivos compiladores. Atendncia da poca foi de poupar cada vez mais o usurio de um computador de conhecerprofundamente as questes relacionadas ao funcionamento interno da mquina, permitindoque este pudesse concentrar seus esforos na resoluo dos problemas computacionaisem lugar de preocupar-se com os problemas relacionados ao funcionamento do hardware.J no incio dos anos 60, com o surgimento dos sistemas operacionais comcaractersticas de multiprogramao, a eficincia e utilidade dos sistemas computacionaistiveram um considervel crescimento, para o que contriburam tambm, de forma bastantesignificativa, as constantes quedas de preo do hardware.Uma conseqncia deste crescimento foi a necessidade, cada vez maior, dedesenvolver grandes sistemas de software em substituio aos pequenos programasaplicativos utilizados at ento. Desta necessidade, surgiu um problema nada trivial devido falta de experincia e no adequao dos mtodos de desenvolvimento existentes parapequenos programas, o que foi caracterizado, ainda na dcada de 60 como a "crise dosoftware", mas que, por outro lado, permitiu o nascimento do termo "Engenharia deSoftware".Atualmente, apesar da constante queda dos preos dos equipamentos, o custo dedesenvolvimento de software no obedece a esta mesma tendncia. Pelo contrrio,corresponde a uma percentagem cada vez maior no custo global de um sistemainformatizado. A principal razo para isto que a tecnologia de desenvolvimento desoftware implica, ainda, em grande carga de trabalho, os projetos de grandes sistemas desoftware envolvendo em regra geral um grande nmero de pessoas num prazorelativamente longo de desenvolvimento. O desenvolvimento destes sistemas realizado,na maior parte das vezes, de forma "ad-hoc", conduzindo a freqentes desrespeitos decronogramas e acrscimos de custos de desenvolvimento.O objetivo deste curso apresentar propostas de solues s questes relacionadasao desenvolvimento de software, atravs da transferncia dos principais conceitos relativos Engenharia de Software, particularmente no que diz respeito ao uso de tcnicas,metodologias e ferramentas de desenvolvimento de software. 1.2 6. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOSPROF. VITRIO BRUNO MAZZOLA2.PRINCIPAIS ASPECTOS DO SOFTWARE2.1.Software: definio e caractersticasPode-se definir o software, numa forma clssica, como sendo: "um conjunto deinstrues que, quando executadas, produzem a funo e o desempenho desejados,estruturas de dados que permitam que as informaes relativas ao problema a resolversejam manipuladas adequadamente e a documentao necessria para um melhorentendimento da sua operao e uso".Entretanto, no contexto da Engenharia de Software, o software deve ser visto comoum produto a ser "vendido". importante dar esta nfase, diferenciando os "programas"que so concebidos num contexto mais restrito, onde o usurio ou "cliente" o prprioautor. No caso destes programas, a documentao associada pequena ou (na maior partedas vezes) inexistente e a preocupao com a existncia de erros de execuo no umfator maior, considerando que o principal usurio o prprio autor do programa, este noter dificuldades, em princpio, na deteco e correo de um eventual "bug". Alm doaspecto da correo, outras boas caractersticas no so tambm objeto de preocupaocomo a portabilidade, a flexibilidade e a possibilidade de reutilizao.Um produto de software (ou software, como vamos chamar ao longo do curso), poroutro lado, sistematicamente destinado ao uso por pessoas outras que os seusprogramadores. Os eventuais usurios podem, ainda, ter formaes e experinciasdiferentes, o que significa que uma grande preocupao no que diz respeito aodesenvolvimento do produto deve ser a sua interface, reforada com uma documentaorica em informaes para que todos os recursos oferecidos possam ser explorados deforma eficiente. Ainda, os produtos de software devem passar normalmente por umaexaustiva bateria de testes, dado que os usurios no estaro interessados (e nem terocapacidade) de detectar e corrigir os eventuais erros de execuo.Resumindo, um programa desenvolvido para resolver um dado problema e umproduto de software destinado resoluo do mesmo problema so duas coisas totalmentediferentes. bvio que o esforo e o conseqente custo associado ao desenvolvimento deum produto sero muito superiores.Dentro desta tica, importante, para melhor caracterizar o significado de software, importante levantar algumas particularidades do software, quando comparadas a outrosprodutos, considerando que o software um elemento lgico e no fsico como a maioriados produtos: o software concebido e desenvolvido como resultado de um trabalho deengenharia e no manufaturado no sentido clssico; o software no se desgasta, ou seja, ao contrrio da maioria dos produtos, osoftware no se caracteriza por um aumento na possibilidade de falhas medidaque o tempo passa (como acontece com a maioria dos produtos manufaturados); a maioria dos produtos de software concebida inteiramente sob medida,sem a utilizao de componentes pr-existentes.Em funo destas caractersticas diferenciais, o processo de desenvolvimento desoftware pode desembocar um conjunto de problemas, os quais tero influncia direta naqualidade do produto.Tudo isto porque, desde os primrdios da computao, o desenvolvimento dosprogramas (ou, a programao) era visto como uma forma de arte, sem utilizao demetodologias formais e sem qualquer preocupao com a documentao, entre outrosfatores importantes. A experincia do programador era adquirida atravs de tentativa e erro.A verdade que esta tendncia ainda se verifica. Com o crescimento dos custos desoftware (em relao aos de hardware) no custo total de um sistema computacional, o 1.3 7. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLAprocesso de desenvolvimento de software tornou-se um item de fundamental importncia naproduo de tais sistemas. A nvel industrial, algumas questes que caracterizaram as preocupaes com oprocesso de desenvolvimento de software foram: por que o software demora tanto para ser concludo? por que os custos de produo tm sido to elevados? por que no possvel detectar todos os erros antes que o software sejaentregue ao cliente? por que to difcil medir o progresso durante o processo de desenvolvimento desoftware? Estas so algumas das questes que a Engenharia de Software pode ajudar aresolver. Enquanto no respondemos definitivamente a estas questes, podemos levantaralguns dos problemas que as originam: raramente, durante o desenvolvimento de um software, dedicado tempo paracoletar dados sobre o processo de desenvolvimento em s; devido poucaquantidade deste tipo de informao, as tentativas em estimar a durao/custo deproduo de um software tm conduzido a resultados bastante insatisfatrios;alm disso, a falta destas informaes impede uma avaliao eficiente dastcnicas e metodologias empregadas no desenvolvimento; a insatisfao do cliente com o sistema "concludo" ocorre freqentemente,devido, principalmente, ao fato de que os projetos de desenvolvimento sobaseados em informaes vagas sobre as necessidades e desejos do cliente(problema de comunicao entre cliente e fornecedor); a qualidade do software quase sempre suspeita, problema resultante da poucaateno que foi dada, historicamente, s tcnicas de teste de software (atporque o conceito de qualidade de software algo relativamente recente); o software existente normalmente muito difcil de manter em operao, o quesignifica que o custo do software acaba sendo incrementado significativamentedevido s atividades relacionadas manuteno; isto um reflexo da poucaimportncia dada manutenibilidade no momento da concepo dos sistemas.2.2.Software: Mitos e Realidade possvel apontar, como causas principais dos problemas levantados na seoanterior, trs principais pontos: a falta de experincia dos profissionais na conduo de projetos de software; a falta de treinamento no que diz respeito ao uso de tcnicas e mtodos formaispara o desenvolvimento de software; a cultura de programao que ainda difundida e facilmente aceita porestudantes e profissionais de Cincias da Computao; a incrvel "resistncia" s mudanas (particularmente, no que diz respeito ao usode novas tcnicas de desenvolvimento de software) que os profissionaisnormalmente apresentam. Entretanto, importante ressaltar e discutir os chamados "mitos e realidades" dosoftware, o que, de certo modo, explicam alguns dos problemas de desenvolvimento desoftware apresentados. 1.4 8. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA2.2.1. Mitos de GerenciamentoMito 1. "Se a equipe dispe de um manual repleto de padres e procedimentos dedesenvolvimento de software, ento a equipe est apta a encaminhar bem odesenvolvimento."Realidade 1. Isto verdadeiramente no o suficiente... preciso que a equipe apliqueefetivamente os conhecimentos apresentados no manual... necessrio que o que consteno dado manual reflita a moderna prtica de desenvolvimento de software e que este sejaexaustivo com relao a todos os problemas de desenvolvimento que podero aparecer nopercurso...Mito 2. "A equipe tem ferramentas de desenvolvimento de software de ltima gerao, umavez que eles dispem de computadores de ltima gerao."Realidade 2. Ter sua disposio o ltimo modelo de computador (seja ele um mainframe,estao de trabalho ou PC) pode ser bastante confortvel para o desenvolvedor dosoftware, mas no oferece nenhuma garantia quanto qualidade do software desenvolvido.Mais importante do que ter um hardware de ltima gerao ter ferramentas para aautomatizao do desenvolvimento de software (as ferramentas CASE)...Mito 3. "Se o desenvolvimento do software estiver atrasado, basta aumentar a equipe parahonrar o prazo de desenvolvimento."Realidade 3. Isto tambm dificilmente vai ocorrer na realidade... algum disse um dia que"... acrescentar pessoas em um projeto atrasado vai torn-lo ainda mais atrasado...". Defato, a introduo de novos profissionais numa equipe em fase de conduo de um projetovai requerer uma etapa de treinamento dos novos elementos da equipe; para isto, seroutilizados elementos que esto envolvidos diretamente no desenvolvimento, o que vai,conseqentemente, implicar em maiores atrasos no cronograma.2.2.2. Mitos do Cliente Mito 4. "Uma descrio breve e geral dos requisitos do software o suficiente para iniciar oseu projeto... maiores detalhes podem ser definidos posteriormente."Realidade 4. Este um dos problemas que podem conduzir um projeto ao fracasso, ocliente deve procurar definir o mais precisamente possvel todos os requisitos importantespara o software: funes, desempenho, interfaces, restries de projeto e critrios devalidao so alguns dos pontos determinantes do sucesso de um projeto. Mito 5. "Os requisitos de projeto mudam continuamente durante o seu desenvolvimento,mas isto no representa um problema, uma vez que o software flexvel e poder suportarfacilmente as alteraes."Realidade 5. verdade que o software flexvel (pelo menos mais flexvel do que a maioriados produtos manufaturados). Entretanto, no existe software, por mais flexvel que suportealteraes de requisitos significativas com adicional zero em relao ao custo dedesenvolvimento. O fator de multiplicao nos custos de desenvolvimento do softwaredevido a alteraes nos requisitos cresce em funo do estgio de evoluo do projeto,como mostra a figura 1.1. 1.5 9. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA 60 ~ 100 xCUSTO1.5 ~ 6 x 1x DEFINIODESENVOLVIMENTOMANUTENO Figura 1.1 - Influncia das alteraes de requisitos no custo de um sistema.2.2.2. Mitos do Profissional Mito 6. "Aps a edio do programa e a sua colocao em funcionamento, o trabalho estterminado."Realidade 6. O que ocorre na realidade completamente diferente disto. Segundo dadosobtidos a partir de experincias anteriores, 50 a 70% do esforo de desenvolvimento de umsoftware despendido aps a sua entrega ao cliente (manuteno).Mito 7. "Enquanto o programa no entrar em funcionamento, impossvel avaliar a suaqualidade."Realidade 7. Na realidade, a preocupao com a garantia do software deve fazer parte detodas as etapas do desenvolvimento, sendo que, ao fim de cada uma destas etapas, osdocumentos de projeto devem ser revisados observando critrios de qualidade.Mito 8. "O produto a ser entregue no final do projeto o programa funcionando."Realidade 8. O programa em funcionamento uma das componentes do software...almdo software, um bom projeto deve ser caracterizado pela produo de um conjuntoimportante de documentos, os quais podem ser identificados com auxlio da figura 1.2.3.PARADIGMAS DA ENGENHARIA DE SOFTWARE3.1 Definio de Engenharia de Software Os problemas apontados nas sees anteriores no sero, claro, resolvidos danoite para o dia, mas reconhecer a existncia dos problemas e defin-los da forma maisprecisa e eficaz so, sem dvida, um primeiro passo para a sua soluo. 1.6 10. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLAEstruturasde DadosPlano EspecificaoProjeto ListagemPrograma de Requisitos FuncionandoPlano deTestes Figura 1.2 - Componentes do software. Em primeiro lugar, preciso estar ciente tambm de que no existe uma abordagemmgica que seja a melhor para a soluo destes problemas, mas uma combinao demtodos que sejam abrangentes a todas as etapas do desenvolvimento de um software. Alm disto, importante e desejvel que estes mtodos sejam suportados por umconjunto de ferramentas que permita automatizar o desenrolar destas etapas, juntamentecom uma definio clara de critrios de qualidade e produtividade de software. So estesaspectos que caracterizam de maneira mais influente a disciplina de Engenharia deSoftware.Na literatura, pode-se encontrar diversas definies da Engenharia de Software: "O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais" [NAU 69]. A aplicao prtica do conhecimento cientfico para o projeto e a construode programas computacionais e a documentao necessria sua operaoe manuteno. [Boehm, 76] Abordagem sistemtica para o desenvolvimento, a operao e a manutenode software [Afnor, 83] Conjunto de mtodos, tcnicas e ferramentas necessrias produo desoftware de qualidade para todas as etapas do ciclo de vida do produto. [Krakowiak, 85]Num ponto de vista mais formal, a Engenharia de Software pode ser definida comosendo a aplicao da cincia e da matemtica atravs das quais os equipamentoscomputacionais so colocados disposio do homem por meio de programas,procedimentos e documentao associada. De modo mais objetivo, pode-se dizer que aEngenharia de Software busca prover a tecnologia necessria para produzir software de altaqualidade a um baixo custo. Os dois fatores motivadores so essencialmente a qualidade eo custo. A qualidade de um produto de software um parmetro cuja quantificao no trivial, apesar dos esforos desenvolvidos nesta direo. Por outro lado, o fator custo pode 1.7 11. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOSPROF. VITRIO BRUNO MAZZOLAser facilmente quantificado desde que os procedimentos de contabilidade tenham sidocorretamente efetuados.3.2.Modelos de Desenvolvimento de softwareO resultado de um esforo de desenvolvimento deve resultar normalmente numproduto. O processo de desenvolvimento corresponde ao conjunto de atividades e umordenamento destas de modo a que o produto desejado seja obtido.Um modelo de desenvolvimento corresponde a uma representao abstrata doprocesso de desenvolvimento que vai, em geral, definir como as etapas relativas aodesenvolvimento do software sero conduzidas e interrelacionadas para atingir o objetivo dodesenvolvimento que a obteno de um produto de software de alta qualidade a um custorelativamente baixo.As sees que seguem vo descrever alguns dos modelos conhecidos e utilizadosem desenvolvimento de software.3.2.1. O Modelo Queda dguaEste o modelo mais simples de desenvolvimento de software, estabelecendo umaordenao linear no que diz respeito realizao das diferentes etapas. Como mostra afigura 1.3, o ponto de partida do modelo uma etapa de Engenharia de Sistemas, onde oobjetivo ter uma viso global do sistema como um todo (incluindo hardware, software,equipamentos e as pessoas envolvidas) como forma de definir precisamente o papel dosoftware neste contexto. Em seguida, a etapa de Anlise de Requisitos vai permitir umaclara definio dos requisitos de software, sendo que o resultado ser utilizado comoreferncia para as etapas posteriores de Projeto, Codificao, Teste e Manuteno.Engenharia deSistemas Anlise de RequisitosProjeto Codificao Teste e IntegraoOperao eManutenoFigura 1.3 - Ilustrao do modelo Queda dgua. O modelo Queda dgua apresenta caractersticas interessantes, particularmente emrazo da definio de um ordenamento linear das etapas de desenvolvimento.Primeiramente, como forma de identificar precisamente o fim de uma etapa de o incio daseguinte, um mecanismo de certificao (ou reviso) implementado ao final de cada 1.8 12. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOSPROF. VITRIO BRUNO MAZZOLAetapa; isto feito normalmente atravs da aplicao de algum mtodo de validao ouverificao, cujo objetivo ser garantir de que a sada de uma dada etapa coerente com asua entrada (a qual j a sada da etapa precedente).Isto significa que ao final de cadaetapa realizada, deve existir um resultado (ou sada) a qual possa ser submetida atividadede certificao.Estas sadas, obtidas ao final de cada etapa, so vistas como produtosintermedirios e apresentam-se, normalmente, na forma de documentos (documento deespecificao de requisitos, documento de projeto do sistema, etc...).Outra caracterstica importante deste modelo que as sadas de uma etapa so asentradas da seguinte, o que significa que uma vez definidas, elas no devem, em hiptesealguma ser modificadas.Duas diretivas importantes que norteiam o desenvolvimento segundo o modeloQueda dgua, so: todas as etapas definidas no modelo devem ser realizadas, isto porque, emprojetos de grande complexidade, a realizao formal destas vai determinar osucesso ou no do desenvolvimento; a realizao informal e implcita de algumasdestas etapas poderia ser feita apenas no caso de projetos de pequeno porte; a ordenao das etapas na forma como foi apresentada deve ser rigorosamenterespeitada; apesar de que esta diretiva poderia ser questionada, a ordenaoproposta pelo modelo, por ser a forma mais simples de desenvolver, tem sidotambm a mais adotada a nvel de projetos de software. importante lembrar, tambm que os resultados de um processo dedesenvolvimento de software no devem ser exclusivamente o programa executvel e adocumentao associada. Existe uma quantidade importante de resultados (ou produtosintermedirios) os quais so importantes para o sucesso do desenvolvimento. Baseadosnas etapas apresentadas na figura 1.3, possvel listar os resultados mnimos esperadosde um processo de desenvolvimento baseado neste modelo: Documento de Especificaode Requisitos, Projeto do Sistema, Plano de Teste e Relatrio de Testes, Cdigo Final,Manuais de Utilizao, Relatrios de Revises. Apesar de ser um modelo bastante popular, pode-se apontar algumas limitaesapresentadas por este modelo: o modelo assume que os requisitos so inalterados ao longo do desenvolvimento;isto em boa parte dos casos no verdadeira, uma vez que nem todos osrequisitos so completamente definidos na etapa de anlise; muitas vezes, a definio dos requisitos pode conduzir definio do hardwaresobre o qual o sistema vai funcionar; dado que muitos projetos podem levardiversos anos para serem concludos, estabelecer os requisitos em termos dehardware um tanto temeroso, dadas as freqentes evolues no hardware; o modelo impe que todos os requisitos sejam completamente especificadosantes do prosseguimento das etapas seguintes; em alguns projetos, s vezesmais interessante poder especificar completamente somente parte do sistema,prosseguir com o desenvolvimento do sistema, e s ento encaminhar osrequisitos de outras partes; isto no previsto a nvel do modelo; as primeiras verses operacionais do software so obtidas nas etapas maistardias do processo, o que na maioria das vezes inquieta o cliente, uma vez queele quer ter acesso rpido ao seu produto. De todo modo, pode vir a ser mais interessante a utilizao deste modelo para odesenvolvimento de um dado sistema do que realizar um desenvolvimento de maneiratotalmente anrquica e informal. 1.9 13. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA3.2.2. Prototipao O objetivo da Prototipao um modelo de processo de desenvolvimento quebusca contornar algumas das limitaes existentes no modelo Queda dgua. A idia portrs deste modelo eliminar a poltica de "congelamento" dos requisitos antes do projeto dosistema ou da codificao.Isto feito atravs da obteno de um prottipo, com base no conhecimento dosrequisitos iniciais para o sistema. O desenvolvimento deste prottipo feito obedecendo realizao das diferentes etapas j mencionadas, a saber, a anlise de requisitos, o projeto,a codificao e os testes, sendo que no necessariamente estas etapas sejam realizadasde modo muito explcito ou formal.Este prottipo pode ser oferecido ao cliente em diferentes formas, a saber: prottipo em papel ou modelo executvel em PC retratando a interface homem-mquina capacitando o cliente a compreender a forma de interao com osoftware; um prottipo de trabalho que implemente um subconjunto dos requisitosindicados; um programa existente (pacote) que permita representar todas ou parte dasfunes desejadas para o software a construir.Colocado disposio do cliente, o prottipo vai ajud-lo a melhor compreender oque ser o sistema desenvolvido. Alm disso, atravs da manipulao deste prottipo, possvel validar ou reformular os requisitos para as etapas seguintes do sistema.Este modelo, ilustrado na figura 1.4, apresenta algumas caractersticasinteressantes, tais como: um modelo de desenvolvimento interessante para alguns sistemas de grandeporte os quais representem um certo grau de dificuldade para exprimirrigorosamente os requisitos; atravs da construo de um prottipo do sistema, possvel demonstrar arealizabilidade do mesmo; possvel obter uma verso, mesmo simplificada do que ser o sistema, com umpequeno investimento inicial.Anlise deRequisitosProjeto Projeto Codificao TesteCodificao TesteAnlise deRequisitos Figura 1.4 - Esquema de evoluo da prototipao. Os prottipos no so sistemas completos e deixam, normalmente, a desejar emalguns aspectos. Um destes aspectos normalmente a interface com o usurio. Osesforos de desenvolvimento so concentrados principalmente nos algoritmos queimplementem as principais funes associadas aos requisitos apresentados, a interface 1.10 14. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLAsendo, a este nvel parte suprflua do desenvolvimento, o que permite caracterizar estaetapa por um custo relativamente baixo.Por outro lado, a experincia adquirida no desenvolvimento do prottipo vai ser deextrema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindoreduzir certamente o seu custo, resultando tambm num sistema melhor concebido.3.2.3. Desenvolvimento IterativoEste modelo tambm foi concebido com base numa das limitaes do modeloQueda dgua e combinar as vantagens deste modelo com as do modelo Prototipao. Aidia principal deste modelo, ilustrada na figura 1.5, a de que um sistema deve serdesenvolvido de forma incremental, sendo que cada incremento vai adicionando ao sistemanovas capacidades funcionais, at a obteno do sistema final, sendo que, a cada passorealizado, modificaes podem ser introduzidas.Uma vantagem desta abordagem a facilidade em testar o sistema, uma vez que arealizao de testes em cada nvel de desenvolvimento , sem dvida, mais fcil do quetestar o sistema final. Alm disso, como na Prototipao, a obteno de um sistema, mesmoincompleto num dado nvel, pode oferecer ao cliente interessantes informaes que sirvamde subsdio para a melhor definio de futuros requisitos do sistema.No primeiro passo deste modelo uma implementao inicial do sistema obtida, naforma de um subconjunto da soluo do problema global. Este primeiro nvel de sistemadeve contemplar os principais aspectos que sejam facilmente identificveis no que dizrespeito ao problema a ser resolvido.Um aspecto importante deste modelo a criao de uma lista de controle deprojeto, a qual deve apresentar todos os passos a serem realizados para a obteno dosistema final. Ela vai servir tambm para se medir, num dado nvel, o quo distante se estda ltima iterao. Cada iterao do modelo de Desenvolvimento Iterativo consiste emretirar um passo da lista de controle de projeto atravs da realizao de trs etapas: oprojeto, a implementao e a anlise. O processo avana, sendo que a cada etapa deavaliao, um passo retirado da lista, at que a lista esteja completamente vazia. A listade controle de projeto gerencia todo o desenvolvimento, definindo quais tarefas devem serrealizadas a cada iterao, sendo que as tarefas na lista podem representar, inclusive,redefinies de componentes j implementados, em razo de erros ou problemasdetectados numa eventual etapa de anlise. 0 1N Projeto Projeto Projeto Implementao ImplementaoImplementao Anlise Anlise AnliseFigura 1.5 - O modelo Desenvolvimento Iterativo.3.2.4. O Modelo Espiral Este modelo, proposto em 1988, sugere uma organizao das atividades em espiral,a qual composta de diversos ciclos. Como mostrado na figura 1.6, a dimenso verticalrepresenta o custo acumulado na realizao das diversas etapas; a dimenso angularrepresenta o avano do desenvolvimento ao longo das etapas. 1.11 15. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLACada ciclo na espiral inicia com a identificao dos objetivos e as diferentesalternativas para se atingir aqueles objetivos assim como as restries impostas. O prximopasso no ciclo a avaliao das diferentes alternativas com base nos objetivos fixados, oque vai permitir tambm definir incertezas e riscos de cada alternativa. No passo seguinte, odesenvolvimento de estratgias permitindo resolver ou eliminar as incertezas levantadasanteriormente, o que pode envolver atividades de prototipao, simulao, avaliao dedesempenho, etc... Finalmente, o software desenvolvido e o planejamento dos prximospassos realizado.A continuidade do processo de desenvolvimento definida como funo dos riscosremanescentes, como por exemplo, a deciso se os riscos relacionados ao desempenho ou interface so mais importantes do que aqueles relacionados ao desenvolvimento doprograma. Com base nas decises tomadas, o prximo passo pode ser o desenvolvimentode um novo prottipo que elimine os riscos considerados.Por outro lado, caso os riscos de desenvolvimento de programa sejam consideradosos mais importantes e se o prottipo obtido no passo corrente j resolve boa parte dosriscos ligados a desempenho e interface, ento o prximo passo pode ser simplesmente aevoluo segundo o modelo Queda dgua.Como se pode ver, o elemento que conduz este processo essencialmente aconsiderao sobre os riscos, o que permite, de certo modo, a adequao a qualquerpoltica de desenvolvimento (baseada em especificao, baseada em simulao, baseadaem prottipo, etc...).CUSTO ACUMULADO AVANODetermina objetivosAvalia alternativas, alternativas e restriesidentifica e resolve Anliseriscos de RiscosAnlise de Riscos Anlise de Riscos Prot-AnliseProt- tipode RiscosProt- tipo 3 Opera-tipo 2 cional Reviso Prottipo 1Plano de Requisitos Simulaes, modelos, ...Plano de Ciclo Conceito dede Vida Operao Requisitosde Software Projeto Projeto do pro- Detalha- Plano deduto de doDesenvolvimento Validao dossoftware RequisitosCdigoPlano deTeste Integrao e TestesValidao e Veri- ficao do Pro- dePrximas etapas uni-do plano jeto Inte- dadeDesenvolve e verifica Teste grao Produto do PrximoImple- de acei- e testementa- taoNvelo Figura 1.7 - O modelo espiral.Uma caracterstica importante deste modelo o fato de que cada ciclo encerradopor uma atividade de reviso, onde todos os produtos do ciclo so avaliados, incluindo oplano para o prximo passo (ou ciclo). Numa aplicao tpica do modelo, pode-se imaginara realizao de um ciclo zero, onde se avalie a realizabilidade do projeto, o resultadodevendo ser a concluso de que ser possvel implementar ou no o projeto dedesenvolvimento. As alternativas consideradas neste caso so de muito alto nvel, como por 1.12 16. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOSPROF. VITRIO BRUNO MAZZOLAexemplo, se a organizao deve desenvolver o sistema ela prpria ou se deve contratar odesenvolvimento junto a uma empresa especializada.O modelo se adequa principalmente a sistemas que representem um alto risco deinvestimento para o cliente.4.VISO GERAL DA ENGENHARIA DE SOFTWAREAnalisando os modelos apresentados na seo precedente, possvel observar que,apesar de apresentar denominaes s vezes diferentes e de estarem associadas de modorelativamente distinto, as etapas apresentadas so caracterizadas por atividades similares.De um modo geral, pode-se organizar o processo de desenvolvimento de umsoftware a partir de trs grandes fases: a fase de definio, a fase de desenvolvimento ea fase de manuteno as quais sero discutidas nas sees abaixo.4.1.Fase de Definio A fase de definio est associada determinao do que vai ser feito. Nesta fase,o profissional encarregado do desenvolvimento do software deve identificar as informaesque devero ser manipuladas, as funes a serem processadas, qual o nvel dedesempenho desejado, que interfaces devem ser oferecidas, as restries do projeto e oscritrios de validao. Isto ter de ser feito no importando o modelo de desenvolvimentoadotado para o software e independente da tcnica utilizada pra faz-lo. Esta fase caracterizada pela realizao de trs etapas especficas: a Anlise (ou Definio) do Sistema, a qual vai permitir determinar o papel decada elemento (hardware, software, equipamentos, pessoas) no sistema, cujoobjetivo determinar, como resultado principal, as funes atribudas ao software; o Planejamento do Projeto de Software, no qual, a partir da definio doescopo do software, ser feita uma anlise de riscos e a definio dos recursos,custos e a programao do processo de desenvolvimento; a Anlise de Requisitos, que vai permitir determinar o conjunto das funes aserem realizadas assim como as principais estruturas de informao a seremprocessadas.4.2.Fase de Desenvolvimento Nesta fase, ser determinado como realizar as funes do software. Aspectos comoa arquitetura do software, as estruturas de dados, os procedimentos a seremimplementados, a forma como o projeto ser transformado em linguagem de programao,a gerao de cdigo e os procedimentos de teste devem ser encaminhados nesta fase. Normalmente, esta fase tambm organizada em trs principais etapas: o Projeto de Software, o qual traduz, num conjunto de representaes grficas,tabulares ou textuais, os requisitos do software definidos na fase anterior; estasrepresentaes (diversas tcnicas de representao podem ser adotadas nummesmo projeto) permitiro definir, com um alto grau de abstrao, aspectos dosoftware como a arquitetura, os dados, lgicas de comportamento (algoritmos) ecaractersticas da interface; a Codificao, onde as representaes realizadas na etapa de projeto seromapeadas numa ou em vrias linguagens de programao, a qual sercaracterizada por um conjunto de instrues executveis no computador; nestaetapa, considera-se tambm a gerao de cdigo de implementao, aqueleobtido a partir do uso de ferramentas (compiladores, linkers, etc...) e que serexecutado pelo hardware do sistema; 1.13 17. CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOSPROF. VITRIO BRUNO MAZZOLA os Testes de Software, onde o programa obtido ser submetido a uma bateriade testes para verificar (e corrigir) defeitos relativos s funes, lgica deexecuo, interfaces, etc...4.3.Fase de Manuteno A fase de manuteno, que se inicia a partir da entrega do software, caracterizadapela realizao de alteraes de naturezas as mais diversas, seja para corrigir errosresiduais da fase anterior, para incluir novas funes exigidas pelo cliente, ou para adaptaro software a novas configuraes de hardware. Sendo assim, pode-se caracterizar esta fase pelas seguintes atividades: a Correo ou Manuteno Corretiva, a qual consiste da atividade de correode erros observados durante a operao do sistema; a Adaptao ou Manuteno Adaptativa, a qual realiza alteraes no softwarepara que ele possa ser executado sobre um novo ambiente (CPU, arquitetura,novos dispositivos de hardware, novo sistema operacional, etc...); o Melhoramento Funcional ou Manuteno Perfectiva, onde so realizadasalteraes para melhorar alguns aspectos do software, como por exemplo, o seudesempenho, a sua interface, a introduo de novas funes, etc... A manuteno do software envolve, normalmente, etapas de anlise do sistemaexistente (entendimento do cdigo e dos documentos associados), teste das mudanas,teste das partes j existentes, o que a torna uma etapa complexa e de alto custo. Alm disso, considerando a atual situao industrial, foi criado, mais recentemente, oconceito de Engenharia Reversa, onde, atravs do uso das tcnicas e ferramentas daEngenharia de Software, o software existente sofre uma "reforma geral", cujo objetivo aumentar a sua qualidade e atualiz-lo com respeito s novas tecnologias de interface e dehardware. 1.14 18. Engenharia deSoftware 2.1 19. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLACaptulo 2QUALIDADE DE SOFTWARE1.INTRODUOComo foi mencionado no captulo anterior, o papel da Engenharia de Software ,principalmente, fornecer mtodos e ferramentas para o desenvolvimento do software dequalidade e a baixo custo.O fator qualidade um dos aspectos importantes que deve ser levado em contaquando do desenvolvimento do software. Para isto, necessrio que se tenha umadefinio precisa do que um software de qualidade ou, pelo menos, quais so aspropriedades que devem caracterizar um software desenvolvido segundo os princpios daEngenharia de Software.Um outro aspecto importante aquele relacionado avaliao e ao aprimoramentodo processo de desenvolvimento de software de uma organizao. Nesta linha, foidesenvolvido pelo SEI (Software Engineering Institute) um modelo que permite definirparmetros para a anlise desta questo nas corporaes, o modelo CMM (Capability andMaturity Model), cujas linhas gerais sero descritas na seo 5.2.DEFINIO DE SOFTWARE DE QUALIDADEPrimeiramente, importante discutir o conceito de software de qualidade. Segundo aAssociao Francesa de Normalizao, AFNOR, a qualidade definida como "a capacidadede um produto ou servio de satisfazer s necessidades dos seus usurios".Esta definio, de certa forma, coerente com as metas da Engenharia de Software,particularmente quando algumas definies so apresentadas. o caso das definies deVerificao e Validao introduzidas por Boehm, que associa a estas definies asseguintes questes: Verificao: "Ser que o produto foi construdo corretamente?" Validao: "Ser que este o produto que o cliente solicitou?"O problema que surge quando se reflete em termos de qualidade a dificuldade emse quantificar este fator.2.1.Fatores de Qualidade Externos e InternosAlgumas das propriedades que poderamos apontar de imediato so a correo, afacilidade de uso, o desempenho, a legibilidade, etc... Na verdade, analizando estaspropriedades, possvel organiz-las em dois grupos importantes de fatores, que vamosdenominar fatores externos e internos.Os fatores de qualidade externos, so aqueles que podem ser detectadosprincipalmente pelo cliente ou eventuais usurios. A partir da observao destes fatores, o 2.2 20. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLAcliente pode concluir sobre a qualidade do software, do seu ponto de vista. Enquadram-senesta classe fatores tais como: o desempenho, a facilidade de uso, a correo, aconfiabilidade, a extensibilidade, etc... J os fatores de qualidade internos so aqueles que esto mais relacionados viso de um programador, particularmente aquele que vai assumir as tarefas demanuteno do software. Nesta classe, encontram-se fatores como: modularidade,legibilidade, portabilidade, etc... No difcil verificar que, normalmente, os fatores mais considerados quando dodesenvolvimento do software so os externos. Isto porque, uma vez que o objetivo dodesenvolvimento do software satisfazer ao cliente, so estes fatores que vo assumir umpapel importante na avaliao do produto (da parte do cliente, claro!!!). No entanto, tambm no difcil concluir que so os fatores internos que vogarantir o alcance dos fatores externos.2.2. Fatores de Qualidade2.2.1. Correo a capacidade dos produtos de software de realizarem suas tarefas de formaprecisa, conforme definido nos requisitos e na especificao. um fator de sumaimportncia em qualquer categoria de software. Nenhum outro fator poder compensar aausncia de correo. No interessante produzir um software extremamente desenvolvidodo ponto de vista da interface homem-mquina, por exemplo, se as suas funes soexecutadas de forma incorreta. preciso dizer, porm, que a correo um fator maisfacilmente afirmado do que alcanado. O alcance de um nvel satisfatrio de correo vaidepender, principalmente, da formalizao dos requisitos do software e do uso de mtodosde desenvolvimento que explorem esta formalizao.2.2.2. Robustez A robustez a capacidade do sistema funcionar mesmo em condies anormais. um fator diferente da correo. Um sistema pode ser correto sem ser robusto, ou seja, oseu funcionamento vai ocorrer somente em determinadas condies. O aspecto maisimportante relacionado robustez a obteno de um nvel de funcionamento do sistemaque suporte mesmo situaes que no foram previstas na especificao dos requisitos. Napior das hipteses, importante garantir que o software no vai provocar conseqnciascatastrficas em situaes anormais. Resultados esperados so que, em tais situaes, osoftware apresente comportamentos tais como: a sinalizao da situao anormal, aterminao "ordenada", a continuidade do funcionamento "correto" mesmo de maneiradegradada, etc... Na literatura, estas caractersticas podem ser associadas tambm aoconceito de confiabilidade.2.2.3. Extensibilidade a facilidade com a qual se pode introduzir modificaes nos produtos de software.Todo software considerado, em princpio, "flexvel" e, portanto, passvel de modificaes.No entanto, este fator nem sempre muito bem entendido, principalmente quando se tratade pequenos programas. Por outro lado, para softwares de grande porte, este fator atingeuma importncia considervel, e pode ser atingido a partir de dois critrios importantes: a simplicidade de projeto, ou seja, quanto mais simples e clara a arquitetura do software, mais facilmente as modificaes podero ser realizadas; a descentralizao, que implica na maior autonomia dos diferentes componentes de software, de modo que a modificao ou a retirada de um componente no 2.3 21. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLAimplique numa reao em cadeia que altere todo o comportamento do sistema,podendo inclusive introduzir erros antes inexistentes.2.2.4. Reusabilidade a capacidade dos produtos de software serem reutilizados, totalmente ou emparte, para novas aplicaes. A necessidade vem da constatao de que muitoscomponentes de software obedecem a um padro comum, o que permite ento que estassimilaridades possam ser exploradas para a obteno de solues para outras classes deproblemas.Este fator permite, principalmente, atingir uma grande economia e um nvel dequalidade satisfatrios na produo de novos softwares, dado que menos programa precisaser escrito, o que significa menos esforo e menor risco de ocorrncia de erros. Istosignifica de fato que a reusabilidade pode influir em outros fatores de qualidade importantes,tais como a correo e a robustez.2.2.5. CompatibilidadeA compatibilidade corresponde facilidade com a qual produtos de software podemser combinados com outros. Este um fator relativamente importante, dado que um produtode software construdo (e adquirido) para trabalhar convivendo com outros softwares. Aimpossibilidade de interao com outros produtos pode ser, sem dvida, uma caractersticaque resultar na no escolha do software ou no abandono de sua utilizao. Os contra-exemplos de compatibilidade, infelizmente, so maiores que os exemplos, mas podemoscitar, nesta classe, principalmente, a definio de formatos de arquivos padronizados(ASCII, PostScript, ...), a padronizao de estruturas de dados, a padronizao deinterfaces homem-mquina (sistema do Macintosh, ambiente Windows, ...), etc...2.2.6. Eficincia A eficincia est relacionada com a utilizao racional dos recursos de hardware ede sistema operacional da plataforma onde o software ser instalado. Recursos tais comomemria, processador e co-processador, memria cache, recursos grficos, bibliotecas (porexemplo, primitivas de sistema operacional) devem ser explorados de forma adequada emespao e tempo.2.2.7. PortabilidadeA portabilidade consiste na capacidade de um software em ser instalado paradiversos ambientes de software e hardware. Esta nem sempre uma caractersticafacilmente atingida, devido principalmente s diversidades existentes nas diferentesplataformas em termos de processador, composio dos perifricos, sistema operacional,etc...Alguns softwares, por outro lado, so construdos em diversas verses, cada umadelas orientada para execuo num ambiente particular. Exemplos disto so algunsprogramas da Microsoft, como por exemplo o pacote Microsoft Office, que existe paraplataformas Macintosh e microcomputadores compatveis IBM.2.2.8. Facilidade de uso Este fator certamente um dos mais fortemente detectados pelos usurios dosoftware. Atualmente, com o grande desenvolvimento dos ambientes grficos comoWindows, X-Windows e o Sistema Macintosh, a obteno de softwares de fcil utilizaotornou-se mais freqente. A adoo de procedimentos de auxlio em linha (help on line) ,sem dvida, uma grande contribuio neste sentido. Dada a definio de software feita no 2.4 22. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLAincio do curso, porm, no se pode deixar de registrar a importncia de uma documentaoadequada (manual de usurio) capaz de orientar o usurio em sua navegao pelo softwareconsiderado.3.A METROLOGIA DA QUALIDADE DO SOFTWAREApresentados alguns fatores de qualidade de software, a dificuldade que seapresenta como medir a qualidade do software. Ao contrrio de outras disciplinas deengenharia, onde os produtos gerados apresentam caractersticas fsicas como o peso, aaltura, tenso de entrada, tolerncia a erros, etc..., a medida da qualidade do software algo relativamente novo e alguns dos critrios utilizados so questionveis.A possibilidade de estabelecer uma medida da qualidade um aspecto importantepara a garantia de um produto de software com algumas das caractersticas definidasanteriormente.O Metrologia do Software corresponde ao conjunto de teorias e prticasrelacionadas com as medidas, a qual permite estimar o desempenho e o custo do software,a comparao de projetos e a fixao dos critrios de qualidade a atingir.As medidas de um software podem ser as mais variadas, a escolha da medidadevendo obedecer a determinados critrios: a pertinncia da medida (interpretabilidade); ocusto da medida (percentual reduzido do custo do software); utilidade (possibilidade decomparao de medidas).As medidas de um software podem ser organizadas segundo duas grandescategorias:3.1.Medidas dinmicasSo as medidas obtidas mediante a execuo do software, como, por exemplo, ostestes, as medidas de desempenho em velocidade e ocupao de memria, os traos, etc...Estas medidas podem assumir um interesse relativamente grande pois elas permitemquantificar fatores que podem implicar em retorno econmico ou que representeminformaes sobre a correo do programa; por outro lado, estas medidas s podem serobtidas num momento relativamente tardio do ciclo de desenvolvimento de um software, ouseja, a partir da etapa de testes.3.2.Medidas estticasSo aquelas obtidas a partir do documento fonte do software, sem a necessidade deexecuo do software. Dentre as medidas estticas, podemos destacar: as medidas de complexidade textual, a qual baseada na computao do nmero de operadores e do nmero de operandos contidos no texto do software; a complexidade estrutural, a qual se baseia na anlise dos grafos de controle associadas a cada componente do software; as medidas baseadas no texto, como o tamanho do programa, a taxa de linhas de comentrios, etc...4.QUESTES IMPORTANTES QUALIDADE DE SOFTWAREUma vez que alguns parmetros relacionados qualidade foram detectados naseo 2.2, cabe aqui discutir alguns princpios que devem fazer parte das preocupaes deuma equipe de desenvolvimento de software... 2.5 23. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLA4.1.O princpio do uso: o software dever ser utilizado por outros Este princpio implica num cuidado em tornar o software acessvel no apenas parao usurio imediato, mas tambm para futuros programadores que iro trabalhar no cdigofonte, seja para eliminao de erros, seja para introduo ou aprimoramento de funes. Com base nestes princpios, o programador ou a equipe de programao deverprover a necessria flexibilidade e robustez ao programa desde o incio do desenvolvimentoe no inserir estes aspectos medida que os problemas vo surgindo. Um outro ponto importante que muitas vezes um programador julga quedeterminadas solues encontradas a nvel de um programa so to especficas que maisningum, incluindo o prprio autor, ir utilizar tal soluo novamente. As diversasexperincias mostram que isto podem ser um grave erro de avaliao, pois conduz, namaioria dos casos, gerao de cdigo incompreensvel, representando um grandeobstculo reutilizao. Algumas providncias no desenvolvimento de um software suportam o respeito aeste princpio: raciocinar, desde o incio do desenvolvimento, em termos de um software pblico; isto vai proporcionar uma economia relativamente grande no que diz respeito ao tempo necessrio para a depurao ou modificao de partes do cdigo; documentar suficientemente o programa, o que vai permitir uma economia em horas de explicao a outras pessoas de como funciona o programa ou como ele deve ser utilizado; projetar o software para que ele seja utilizvel por iniciantes; rotular todas as sadas, salvar ou documentar todas as entradas, o que pode facilitar o trabalho de interpretao de resultados obtidos durante a execuo do software.4.2.O princpio do abuso: o software ser utilizado de maneira indevidaEste princpio diz respeito s manipulaes incorretas que os usurios imprimem aoprograma, seja por desconhecimento do modo correto de utilizao, seja por simplescuriosidade. Exemplos destas manipulaes so a manipulao de arquivos de entrada deum programa nas mais diversas condies (arquivos vazios, arquivos binrios, arquivosmuito grandes, etc...) ou incorrees sintticas. Muitas vezes, entradas sintaticamentecorretas podem provocar erros de execuo (valores fora de faixa, erros de overflow,diviso por zero, etc...).Um outro problema a tentativa, por parte de usurios, de utilizao de um dadosoftware para uma outra finalidade que no aquela para a qual o software foi desenvolvido.Para levar em conta este princpio, os cuidados que o programador deve ter so osseguintes: garantir que o software oferea alguma sada satisfatria para qualquer tipo de entrada; evitar que o programa termine de forma anormal; chamar a ateno para entradas alteradas ou sadas incorretas.4.3.O princpio da evoluo: o software ser modificado Este outro aspecto de importncia no desenvolvimento de software, o qual estfortemente ligado com o aspecto da facilidade de manuteno (ou extensibilidade). fatoreconhecido que os softwares devero sofrer modificaes, estas pelas razes maisdiversas; seja devido deteo de um erro residual do desenvolvimento; seja por novosrequisitos surgidos aps a instalao do software. Isto torna evidente a necessidade de desenvolver o projeto e o cdigo de modo afacilitar as modificaes necessrias. A existncia de um cdigo bem estruturado edocumentado pelo menos 50% do trabalho resolvido. 2.6 24. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLADentro deste princpio, os cuidados a serem tomados devero ser: o desenvolvimento de programas com bom nvel de legibilidade; a estruturao em componentes de software facilmente modificveis; agrupar alteraes visveis ao usurio e eventuais correes em versesnumeradas; manter a documentao atualizada.4.4.O princpio da migrao: o software ser instalado em outras mquinas Este ltimo princpio leva em conta o fato de que a vida de muitos softwares deveultrapassar a vida da prpria mquina em que ele est executando. A velocidade com a qualas arquiteturas de computador tm evoluido nos ltimos anos acentua a importncia desteprincpio. Um problema relacionado a este princpio que s vezes os programas sodesenvolvidos explorando algumas particularidades das arquiteturas das mquinas para asquais eles esto sendo concebidos. Isto cria uma forte dependncia do hardware, o quedificulta a futura migrao para outras arquiteturas. Isto significa, na verdade, que para um programa apresentar um nvel satisfatrio deportabilidade, o programador deve evitar amarrar-se a detalhes de hardware da mquina aoinvs de "aproveit-los". Assim, podemos sintetizar as aes a serem preparadas com relao a esteprincpio: pensar os programas como meio para solucionar problemas e no para instruirdeterminado processador; utilizar as construes padronizadas das linguagens de programao ou sistemasoperacionais; isolar e comentar todos os aspectos do programa que envolvam a dependncia dohardware.5.O MODELO CMM A causa mais comum do insucesso dos projetos de desenvolvimento de software am utilizao ou a completa indiferena aos mtodos e ferramentas orientados concepo. possvel que, em empresas de desenvolvimento de software onde o uso demetodologias consistentes no seja prtica adotada, os projetos possam ter bonsresultados. Mas, em geral, estes bons resultados so muito mais uma conseqncia deesforos individuais do que propriamente causadas pela existncia de uma poltica e deuma infra-estrutura adequada produo de software. O modelo CMM Capability Maturity Model foi definido pelo SEI SoftwareEngineering Institute com o objetivo de estabelecer conceitos relacionados aos nveis dematuridade das empresas de desenvolvimento de software, com respeito ao grau deevoluo que estas se encontram nos seus processos de desenvolvimento. O modelo estabelece tambm que providncias as empresas podem tomar paraaumentarem, gradualmente o seu grau de maturidade, melhorando, por conseqncia, suaprodutividade e a qualidade do produto de software.5.1.Conceitos bsicos do CMMUm Processo de Desenvolvimento de Software corresponde ao conjunto deatividades, mtodos, prticas e transformaes que uma equipe utiliza para desenvolver emanter software e seus produtos associados (planos de projeto, documentos de projeto,cdigo, casos de teste e manuais de usurio). Uma empresa considerada num maior graude maturidade quanto mais evoludo for o seu processo de desenvolvimento de software. 2.7 25. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLA A Capabilidade de um processo de software est relacionada aos resultados quepodem ser obtidos pela sua utilizao num ou em vrios projetos. Esta definio permiteestabelecer uma estimao de resultados em futuros projetos. O Desempenho de um processo de software representa os resultados que socorrentemente obtidos pela sua utilizao. A diferena bsica entre estes dois conceitosest no fato de que, enquanto o primeiro, est relacionado aos resultados esperados, osegundo, relaciona-se aos resultados que foram efetivamente obtidos. A Maturidade de um processo de software estabelece os meios pelos quais ele definido, gerenciado, medido, controlado e efetivo, implicando num potencial de evoluo dacapabilidade. Numa empresa com alto grau de maturidade, o processo de desenvolvimentode software bem entendido por todo o staff tcnico, graas existncia de documentaoe polticas de treinamento, e que este continuamente monitorado e aperfeioado por seususurios. medida que uma organizao cresce em termos de maturidade, ela institucionalizaseu processo de desenvolvimento de software atravs de polticas, normas e estruturasorganizacionais, as quais geram uma infra-estrutura e uma cultura de suporte aos mtodose procedimentos de desenvolvimento.5.2. Nveis de maturidade no processo de desenvolvimento de softwareO modelo CMM define cinco nveis de maturidade no que diz respeito ao processode desenvolvimento de software adotado a nvel das empresas, estabelecendo uma escalaordinal que conduz as empresas ao longo de seu aperfeioamento.Um nvel de maturidade um patamar de evoluo de um processo dedesenvolvimento de software, correspondendo a um degrau na evoluo contnua de cadaorganizao. A cada nvel corresponde um conjunto de objetivos que, uma vez atingidos,estabilizam um componente fundamental do processo de desenvolvimento de software,tendo como conseqncia direta o aumento da capabilidade da empresa.A figura 2.1 apresenta os cinco nveis de maturidade propostos no modelo CMM, naqual se pode observar tambm o estabelecimento de um conjunto de aes que permitiroa uma empresa subir de um degrau para o outro nesta escala.5.2.1. Nvel Inicial No nvel inicial, o desenvolvimento de software realizado de forma totalmente adhoc, sem uma definio de processos. No caso de problemas que venham a ocorrerdurante a realizao de um projeto, a organizao tem uma tendncia a abandonartotalmente os procedimentos planejados e passa a um processo de codificao e testes,onde o produto obtido pode apresentar um nvel de qualidade suspeito. 2.8 26. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLAAperfeioamento contnuo Otimizado Processo previsvelGerenciado ProcessoDefinidopadronizadoProcesso disciplinado RepetvelInicial Figura 2.1 - Os nveis de maturidade de um processo de desenvolvimento de software.A capabilidade de uma empresa caracterizada como nvel 1 totalmenteimprevisvel, uma vez que o processo de desenvolvimento de software instvel, sujeito amudanas radicais freqentes, no apenas de um projeto a outro, mas tambm durante arealizao de um mesmo projeto.Neste nvel, estimao de custos, prazos e qualidade do produto algo totalmentefora do contexto e da poltica de desenvolvimento (que poltica?).Embora no se possa assegurar o fracasso de um projeto desenvolvido por umaempresa situada neste nvel, possvel dizer que o sucesso , geralmente, resultado deesforos individuais, variando com as habilidades naturais, o conhecimento e as motivaesdos profissionais envolvidos no projeto.5.2.2. Nvel Repetvel Neste nvel, polticas de desenvolvimento de software e tarefas de suporte a estaspolticas so estabelecidas, o planejamento de novos projetos sendo baseado naexperincia obtida com projetos anteriores. Para que uma empresa possa atingir este nvel, imprescindvel institucionalizar ogerenciamento efetivo dos seus projetos de software, de modo que o sucesso de projetosanteriores possam ser repetidos nos projetos em curso. Neste nvel, os requisitos do software e o trabalho a ser feito para satisfaz-los soplanejados e supervisionados ao longo da realizao do projeto. So definidos padres deprojeto, e a instituio deve garantir a sua efetiva implementao. A capabilidade de uma empresa situada neste nvel pode ser caracterizada comodisciplina, em razo dos esforos de gerenciamento e acompanhamento do projeto desoftware.5.2.3. Nvel DefinidoNo nvel definido, o processo de desenvolvimento de software consolidado tantodo ponto de vista do gerenciamento quanto das tarefas de engenharia a realizar; isto feitoatravs de documentao, padronizao e integrao no contexto da organizao, queadota esta verso para produzir e manter o software.Os processos definidos nas organizaes situadas neste nvel so utilizados comoreferncia para os gerentes de projeto e os membros do staff tcnico, sendo baseado emprticas propostas pela Engenharia de Software. 2.9 27. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLAProgramas de treinamento so promovidos ao nvel da organizao, como forma dedifundir e padronizar as prticas adotadas no processo definido.As caractersticas particulares de cada projeto podem influir no aprimoramento deum processo de desenvolvimento, sendo que para cada projeto em desenvolvimento, estepode ser instanciado.Um processo de desenvolvimento bem definido deve conter padres, procedimentospara o desenvolvimento das atividades envolvidas, mecanismos de validao e critrios deavaliao.A capabilidade de uma empresa no nvel 3 caracterizada pela padronizao econsistncia, uma vez que as polticas de gerenciamento e as prticas da Engenharia deSoftware so aplicadas de forma efetiva e repetida.5.2.4. Nvel GerenciadoNo nvel gerenciado, realizada a coleta de medidas do processo e do produtoobtido, o que vai permitir um controle sobre a produtividade (do processo) e a qualidade (doproduto). definida uma base de dados para coletar e analisar os dados disponveis dosprojetos de software. Medidas consistentes e bem definidas so, ento, uma caractersticadas organizaes situadas neste nvel, as quais estabelecem uma referncia para aavaliao dos processos de desenvolvimento e dos produtos.Os processos de desenvolvimento exercem um alto controle sobre os produtosobtidos; as variaes de desempenho do processo podem ser separadas das variaesocasionais (rudos), principalmente no contexto de linhas de produo definidas. Os riscosrelacionados ao aprendizado de novas tecnologias ou sobre um novo domnio de aplicaoso conhecidos e gerenciados cuidadosamente.A capabilidade de uma organizao situada este nvel caracterizada pelaprevisibilidade, uma vez que os processos so medidos e operam em limites conhecidos.5.2.5. Nvel Otimizado No nvel otimizado, a organizao promove contnuos aperfeioamentos noprocesso de desenvolvimento, utilizando para isto uma realimentao quantitativa doprocesso e aplicando novas idias e tecnologias. Os aperfeioamentos so definidos a partirda identificao dos pontos fracos e imperfeies do processo corrente e doestabelecimento das alteraes necessrias para evitar a ocorrncia de falhas. Anlises decusto/benefcio so efetuadas sobre o processo de desenvolvimento com base em dadosextrados de experincias passadas. Quando os problemas relacionados adoo de um dado processo dedesenvolvimento no podem ser totalmente eliminados, os projetos so cuidadosamenteacompanhados para evitar a ocorrncia de problemas inerentes do processo.5.3. Definio operacional do modelo CMMO modelo CMM, alm de definir os nveis de maturidade acima descritos, detalha, cada umdeles, com respeito aos objetivos essenciais de cada um e das tarefas chave a seremimplementadas para que estes objetivos sejam atingidos. Para isto, foi realizado, exceo do nvel 1, um detalhamento nos diferentes nveis,estabelecendo uma estrutura que permitisse caracterizar a maturidade e a capabilidade doprocesso de desenvolvimento de software. A figura 2.2 ilustra os componentes relacionadosa este detalhamento. 2.10 28. CAP. 2 QUALIDADE DE SOFTWAREPROF. VITRIO BRUNO MAZZOLANveis deMaturidade indicamcontm Capabilidadereas do Processo Chave atingemorganizados porFatores ObjetivosComunsvisam contm TarefasImplementao ou ChaveInstitucionalizao descrevem Infraestrutura ou Atividade Figura 2.2 - Estrutura dos nveis CMM.Como se pode notar na figura, cada nvel de maturidade composto por diversasreas Chave, as quais identificam um conjunto de atividades que, quando realizadasconjuntamente, permitem atingir os objetivos essenciais do nvel considerado, aumentandoa capabilidade do processo de desenvolvimento de software.A Tabela 2.1 apresenta as reas chave associadas a cada um dos nveis do CMM (exceo do nvel 1, como j foi explicado).Os Fatores Comuns indicam o grau de implementao ou institucionalizao deuma dada rea Chave. No modelo, os Fatores Comuns foram definidos em nmero decinco, como mostra a Tabela 2.2.As Tarefas Chave correspondem s atividades que, uma vez realizadas de modoconjunto, contribuiro para o alcance dos objetivos da rea chave. As tarefas chavedescrevem a infra-estrutura e as atividades que devero ser implementadas para a efetivaimplementao ou institucionalizao da rea chave. As tarefas chave correspondem a umasentena simples, seguida por uma descrio detalhada a qual pode incluir exemplos.A figura 2.3 apresenta um exemplo de estrutura de uma tarefa chave para a reaChave de Planejamento do Projeto de Software.5.4.Utilizao do modelo CMMO objetivo fundamental do estabelecimento deste modelo fornecer parmetrospara: de um lado, que as instituies que pretendam contratar fornecedores desoftware possam avaliar as capacidades destes fornecedores; por outro lado, para que as empresas de desenvolvimento de software possamidentificar quais os procedimentos a serem implementados ou institucionalizadosno mbito da organizao de modo a aumentar a capabilidade do seu processode software. 2.11 29. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLANvelreas Chave Gerenciamento de requisitos Repetvel (2) Planejamento do processo de desenvolvimento Acompanhamento do projeto Gerenciamento de subcontratao Garantia de qualidade Gerenciamento de configurao nfase ao processo na organizao Definio do processo na organizao Programa de treinamentoDefinido (3) Gerenciamento integrado Engenharia de software Coordenao intergrupo Atividades de revisoGerenciado (4) Gerenciamento da qualidade de software Gerenciamento quantitativo do processo Preveno de falhas Otimizado (5) Gerenciamento de mudana de tecnologia Gerenciamento de mudana do processo Tabela 2.1 - reas Chave por nvel de maturidade.Fator ComumObjetivos Passvel de Descreve as aes a realizar para definir e estabilizar umrealizao processo Capacidade de Define pr-condies necessrias no projeto ou organizaorealizao para implementar o processo de modo competente AtividadesDescreve os procedimentos necessrios para implementarrealizadas uma rea chaveMedidas eIndica a necessidade de realizao de atividades de medio anlisese anlise das medidasVerificao da Corresponde aos passos necessrios para assegurar que implementao todas as tarefas foram realizadas adequadamenteTabela 2.2 - Fatores comuns.Embora os dois objetivos sejam diferentes, definido no modelo um procedimentosimilar para a realizao dos dois tipos de anlise. As etapas deste procedimento, descritasa seguir, devero ser realizadas num esquema seqencial: seleo de uma equipe, cujos elementos sero treinados segundo os conceitosbsicos do modelo CMM, sendo que estes j devero ter conhecimentos deengenharia de software e gerenciamento de projetos; selecionar profissionais representantes da organizao, para os quais seraplicado um questionrio de maturidade; analisar as respostas obtidas do questionrio de maturidade, procurandoidentificar as reas chave; 2.12 30. CAP. 2 QUALIDADE DE SOFTWARE PROF. VITRIO BRUNO MAZZOLANvel 2: Repetvel indica contm Processo Planejamentodisciplinadodo Projetoatingeorganizado porEstimao para utilizao Atividadesno planejamento e Realizadasacompanhamento doprojeto visamcontmAtividade 9: Estimao parao software derivada deImplementao acordo com umprocedimento documentado descreveAtividadeFigura 2.3 - Exemplo de uma tarefa chave numa estrutura CMM. realizar uma visita (da equipe) organizao para a realizao de entrevistas erevises de documentao relacionadas ao processo de desenvolvimento; asentrevistas e revises devero ser conduzidas pelas reas chave do CMM e pelaanlise realizada sobre o questionrio de maturidade; ao fim da visita, a equipe elabora um relatrio enumerando os pontos fortes e ospontos fracos da organizao em termos de processo de desenvolvimento desoftware; finalmente, a equipe prepara um perfil de reas chave, que indica as reas ondea organizao atingiu/no atingiu os objetivos de cada rea. 2.13 31. Engenharia deSoftware 3.1 32. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAISPROF. VITRIO BRUNO MAZZOLACaptulo 3ENGENHARIA DE SISTEMAS COMPUTACIONAIS1.INTRODUOEmbora este curso tenha por objetivo a discusso dos aspectos mais importantesrelacionados ao desenvolvimento do software, importante reconhecer o fato bvio de queo software no consiste de um elemento autnomo. Para que suas funes possam serrealizadas, ele dever ser integrado a outros componentes, especialmente elementos dehardware, como processador, circuitos de memria e outros.Por esta razo, o software deve, antes de tudo, ser visto como um elemento de umsistema mais amplo, ao qual denominaremos um Sistema Computacional. No contextodeste curso, um Sistema Computacional dever ser entendido como o resultado da unio dediferentes componentes, entre os quais se enquadram o software, o hardware e elementosde outras naturezas como por exemplo o elemento humano, representado pelo usurio dosistema.A Engenharia de Sistemas Computacionais corresponde ao conjunto deatividades que devero ser realizadas para definir o sistema computacional como um todo.Dentre as atividades a serem conduzidas, pode-se citar a especificao, o projeto, aimplementao, a validao, a instalao e a manuteno.Cada uma das disciplinas componentes da Engenharia de Sistemas est relacionadaa uma tentativa de estabelecimento de uma ordem no desenvolvimento de sistemascomputacionais.Nestes sistemas, o software vem, h muitos anos, substituindo o hardware como oelemento de mais difcil concepo, com menor probabilidade de sucesso em termos deprazos e custo e de mais difcil administrao. Alm disso, a demanda por software cresce acada dia, at como conseqncia do grande desenvolvimento do hardware dos sistemascomputacionais.O objetivo deste captulo discutir as principais definies e aspectos relacionadoscom a Engenharia de Sistemas Computacionais, procurando definir o papel da Engenhariade Software neste contexto.2.ASPECTOS DA ENGENHARIA DE SISTEMAS COMPUTACIONAIS2.1.Sistema ComputacionalAntes de discutir os principais pontos relativos Engenharia de SistemasComputacionais, imprescindvel estabelecer uma definio do que um sistemacomputacional. Isto particularmente importante, uma vez que a palavra "sistema" umadas mais empregadas em qualquer rea da atividade humana (sistema poltico, sistemaeducacional, sistema de avaliao, etc...). 3.2 33. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF. VITRIO BRUNO MAZZOLADentro do contexto do que ser discutido aqui, pode-se definir um SistemaComputacional como sendo um conjunto de elementos interrelacionados que operamjuntos para o alcance de algum objetivo.Um sistema de processamento de texto, por exemplo, integra funes de entrada eedio de texto com funes de produo de documentos (software e hardware)manipuladas por um usurio (um elemento humano) para transformar um dado texto (umaentrada) num documento (a sada).Pode-se listar os elementos de um sistema computacional como sendo: software, no caso, programas de computador, estruturas de dados, e documentao associada que serve a efetivar os mtodos, procedimentos ou processo de controle lgico; hardware, que so os dispositivos eletrnicos que definem as capacidades de um computador e dispositivos eletromecnicos que oferecem funcionalidades ao ambiente externo; pessoal, usurios/operadores do hardware e do software; bancos de dados, uma coleo de informaes organizada sistematicamente, acessada atravs do software; documentao, manuais, formulrios e outros documentos que podem auxiliar no conhecimento do uso e operao do sistema; procedimentos, as regras que especificam o uso especfico de cada elemento do sistema computacional.As combinaes destes elementos podem ser as mais diversas para permitir atransformao das informaes. Um rob, por exemplo, um sistema computacional quetransforma um arquivo contendo instrues especficas num conjunto de movimentos eaes.2.2.Composio dos Sistemas Computacionais e as Propriedades Emergentes importante reconhecer o papel das atividades relacionadas Engenharia deSistemas Computacionais como determinantes para as tarefas que se desenvolveram combase em seus resultados. Embora tenhamos dito que um Sistema Computacional composto de diferentes elementos, no se deve negligenciar o fato de que a integraodestes diferentes elementos uma tarefa longe de ser trivial. O fato de se ter elementosconcebidos com exemplar nvel de qualidade no garante que a reunio destes v originarum sistema excepcional.Em tais sistemas, as dependncias de um elemento do sistema com relao aoutros podem se dar em muitos nveis. Por exemplo, o software s pode automatizar asoluo de um problema se o processador estiver funcionando de forma adequada. Poroutro lado, uma mquina de comando numrico s ir realizar corretamente o seu trabalhose o software de pilotagem tiver sido adequadamente concebido.Entender o papel da Engenharia de Sistemas Computacionais constatar que umsistema algo mais do que a simples unio de seus diversos elementos.Num sistema de grande porte, existe um conjunto de propriedades que soverificados somente a partir do momento em que os diferentes elementos do mesmo sointegrados. So as chamadas Propriedades Emergentes. Alguns exemplos destaspropriedades so: o peso global do sistema, um exemplo de propriedade que pode serpreviamente determinada a partir de propriedades individuais dos componentes; a confiabilidade do sistema, que est fortemente dependente da confiabilidadede cada elemento; 3.3 34. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF. VITRIO BRUNO MAZZOLA a facilidade de uso, que vai estar relacionada aos diferentes elementos dosistema como o hardware o software, mas tambm aos usurios do mesmo.2.3.Sistemas e Subsistemas Pode-se observar ainda que elementos de um determinado sistema podem operarde forma autnoma, constituindo-se num sistema independente. No entanto, ao seremincorporados ao sistema, suas funcionalidades vo estar dependendo de outros elementosdeste. Uma cmera de vdeo, por exemplo, pode ser vista como um sistema independente.Por outro lado, quando ela est embutida num sistema de segurana automatizado, a maiorparte de seus ajustes (enquadramento da imagem, foco, ativao e desativao) serocompletamente dependentes de outros componentes do sistema de segurana. Isto significa que, nos sistemas computacionais comum um dado sistema comporum outro sistema computacional de nvel hierrquico superior. Diz-se ento que o sistemaconsiderado um macroelemento ou subsistema do sistema de nvel superior. Um exemplo tpico desta situao aquela dos equipamentos de manufatura, comopor exemplo os robs, mquinas de comando numrico e controladores lgicosprogramveis, que so sistemas computacionais e ao mesmo tempo subsistemas de umsistema computacional de nvel hierrquico superior: a clula de manufatura. A clula demanufatura pode ser definida como um sistema computacional, uma vez que esta caracterizada por todos os elementos definidos acima. Se for feita uma anliseconsiderando outros nveis hierrquicos, possvel visualizar a clula como ummacroelemento de outro sistema computacional: o sistema de manufatura. A figura 3.1ilustra esta relao entre os diferentes sistemas computacionais descritos.2.4.Hierarquia e ambiente de um sistema Reconhecido o fato de que um sistema pode ser obtido a partir de outros sistemas,como o exemplo ilustrado figura 3.1, surge ento o conceito de hierarquia de sistemas,que vai permitir utilizar a definio de subsistema, introduzida anteriormente. Sistema de Automao da Fbrica Sistema deSistema de Sistema de Manufatura Estoques Informaes Sistema de ClulaTransporte de Flexvel de Material ManufaturaMquina deControlador ComandoRobLgico Numrico Programvel Figura 3.1 - Relao hierrquica entre sistemas computacionais. 3.4 35. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF. VITRIO BRUNO MAZZOLA Por esta razo, o ambiente de um sistema deve ser cuidadosamente estudado nestaetapa de concepo. A importncia do entendimento completo do ambiente de um sistema justificada pelos fatores seguintes: em grande parte das vezes, o sistema concebido para provocar alteraes noambiente; sendo assim, a compreenso dos principais aspectos defuncionamento do ambiente sero fundamentais para especificar de que forma osistema deve agir para provocar as alteraes de forma precisa; exemplos detais sistemas so um sistema de iluminao, um sistema de aquecimento (ourefrigerao) de ambiente; mesmo quando a funo do sistema no est relacionada a alteraes de seuambiente, importante se conhecer o quanto o ambiente pode influenciar nofuncionamento do sistema; por exemplo, numa rede de computadores a serinstalada numa unidade fabricao de uma empresa, o fato de naquela unidadeexistir um grande nmero de motores e inversores operando pode serdeterminante para decidir que tipos de protocolos e meios de transmissodevero ser empregados, devido alta incidncia de fontes de interferncia quepodem causar erros de comunicao.Um outro aspecto a ser considerado o conjunto de requisitos originado no prprioambiente. Os exemplos deste aspecto so os mais diversos, mas pode-se citar normas dequalidade ou segurana de produtos, requisitos de interface numa dada plataforma,requisitos de vedao, para um sistema computacional que ir operar num ambiente midoou sujeito a poeira.Por todas estas razes, fundamental que um sistema seja visto sempre como umcomponente de um sistema maior, o estudo aprofundado das caractersticas maisimportantes relativas ao ambiente e dos requisitos impostos por este sendo uma tarefaessencial.2.5.A Aquisio de SistemasNo desenvolvimento de sistemas, principalmente daqueles mais complexos, comum que determinados componentes sejam adquiridos em lugar de seremcompletamente desenvolvidos pela equipe ou empresa envolvida no projeto. Em algunscasos, o prprio sistema pode ser completamente adquirido num fabricante especfico e, emoutros, partes do sistema sero obtidas de um mesmo ou de diferentes fornecedores. Poroutro lado, pode haver sistemas onde todos os componentes podem ser completamentedesenvolvidos pela equipe.O processo de deciso sobre a compra ou o desenvolvimento de um sistema ou departe dele uma tarefa que requer um esforo e um tempo considervel, principalmente seo grau de complexidade do mesmo for elevado. Uma deciso baseada numa anlisesuperficial pode conduzir ao fracasso do projeto.Normalmente, para servir de referncia deciso, uma especificao do sistema eum projeto arquitetural devem ser conduzidos. Os resultados obtidos nesta tarefa soimportantes pelas seguintes razes: para que o processo de aquisio seja encaminhado com sucesso, necessriaa existncia de uma especificao e de uma viso arquitetural do sistema; o custo de aquisio de um sistema , na maioria dos casos, menor que dodesenvolvimento deste; por esta razo, o projeto arquitetural importante comoforma de decidir quais subsistemas sero adquiridos e quais serodesenvolvidos. 3.5 36. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAISPROF. VITRIO BRUNO MAZZOLA2.6.A Subcontratao As situaes em que uma empresa desenvolve completamente todos oscomponentes de um sistema so extremamente raras. Geralmente, a organizao "usuria"vai encomendar o sistema a uma organizao "fornecedora". A organizao fornecedora,eventualmente, vai "terceirizar" o desenvolvimento do sistema, contratando outras empresasfornecedoras dos diferentes subsistemas. A figura 3.2 ilustra este processo. Um aspecto interessante deste processo a otimizao, no que diz respeito aoscontatos, entre a organizao do usurio e as organizaes desenvolvedoras. Na realidade,o nico contato mantido pela organizao usuria com a principal contratante. Assubcontratantes vo projetar e construir os subsistemas cujos requisitos foramespecificados pela principal contratante que exerce o papel de aglutinadora de todas asempresas envolvidas no desenvolvimento.2.7.A Importncia do SoftwareNo desenvolvimento de sistemas computacionais, comum a utilizao decomponentes customizados (construdos sob medida) e componentes de "prateleira". Poresta razo, o componente de software assume um papel bastante importante nodesenvolvimento do sistema, isto porque este que pode assumir a funo de elo deligao entre os diferentes componentes, permitindo a adequao do funcionamento dosdiferentes componentes de hardware (principalmente aqueles de "prateleira") aos requisitosdo sistema.Um exemplo deste fato est num dos sistemas computacionais mais utilizados nosdias atuais os microcomputadores da linha PC. O PC da IBM, quando foi concebido, foitotalmente construdo a partir de componentes de hardware disponveis no mercado. Estadeciso foi tomada devido urgncia em ocupar o espao do mercado no setor decomputadores pessoais. Entretanto, a frmula mgica da IBM para fazer com que todosestes elementos funcionassem harmonicamente foi buscada no software, no caso o ROM-BIOS, que continha todas as rotinas de programao e acesso aos dispositivos de hardwareque compunham a arquitetura do PC.S a partir do momento em que as outras empresas conseguiram copiar o contedodo ROM-BIOS que surgiram os conhecidos "clones" do PC que difundiram a tecnologiapelo mundo todo.Usurio do Sistema PrincipalContratanteSubcontratante 1 Subcontratante 2Subcontratante 2 Figura 3.2 - Ilustrao do processo de aquisio de um sistema. 3.6 37. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF. VITRIO BRUNO MAZZOLA3.ENGENHARIA DE SISTEMAS COMPUTACIONAISO papel essencial da Engenharia de Sistemas Computacionais a resoluo deproblemas, onde a atividade de base a identificao, anlise e atribuio aos elementosconstituintes do sistema das funes desejadas para o sistema.A palavra que melhor define a Engenharia de Sistemas a interdisciplinaridade,uma vez que, na maior parte dos sistemas a serem concebidos, devem entrar em jogodiferentes competncias. Alm dos Engenheiros de Hardware e de Software, devem intervirnesta etapa especialistas como Engenheiros Eletricistas, Engenheiros Hidrulicos,Engenheiros de Telecomunicaes, Qumicos, Fsicos, Psiclogos, Mdicos, etc.O ponto de partida do trabalho do Engenheiro de Sistemas so os requisitos erestries formuladas pelo cliente, que vo permitir um primeiro delineamento das funes aserem executadas pelo sistema, de requisitos de desempenho, das interfaces a seremoferecidas, das restries de projeto e das estruturas de informao que sero processadaspor cada um dos elementos constituintes do sistema (software, hardware, pessoal, etc...).Neste trabalho, importante que se estabelea da forma mais precisa possvel asfunes a serem realizadas. Por exemplo, no caso do sistema de controle de um rob, no suficiente dizer que "ele deve reagir com rapidez se a bandeja de ferramentas estivervazia"... na realidade, importante especificar cuidadosamente os diferentes aspectosdeste requisito: o que vai indicar a bandeja vazia para o rob; os limites de tempo relacionados com a reao; de que forma deve ser esta reao. Uma vez identificados e analizadas todas as funes, requisitos e restries, passa-se fase de alocao, onde o objetivo atribuir, aos diferentes elementos que constituemo sistema, as funes analizadas anteriormente.Nesta tarefa, comum estabelecer alternativas de alocao para posterior definio.Consideremos, por exemplo, um sistema de tratamento grfico, onde uma das funesprincipais a transformao tridimensional de imagens. Deste exemplo, possvel imaginaralgumas opes de solues existentes:todas as transformaes sero resolvidas por software;as transformaes mais simples (redimensionamento e translao) serorealizadas em hardware e as mais complexas (rotao, perspectivas, etc...) emsoftware;todas as transformaes sero realizadas por um processador geomtricoimplementado em hardware.A escolha da soluo deve ser baseada num conjunto de critrios, onde entramfatores como custo, realizabilidade, desempenho, padronizao de interfaces, portabilidade,etc.Nas sees a seguir, sero descritas atividades encaminhadas no contexto daEngenharia de Sistemas Computacionais.3.1.Definio dos Requisitos O objetivo das tarefas a serem desenvolvidas nesta etapa identificar os requisitosdo Sistema Computacional a ser concebido. Considerando que grande parte dos sistemascomputacionais so construdos sob demanda, a forma usual de encaminhar esta etapa caracterizada por um conjunto de reunies estabelecidas entre a equipe dedesenvolvimento do sistema e os clientes ou usurios.Nesta etapa, pode-se considerar basicamente trs categorias de requisitos: 3.7 38. CAP. 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF. VITRIO BRUNO MAZZOLA os requisitos bsicos, que esto associados s funes a seremdesempenhadas pelo sistema; neste momento do desenvolvimento, estesrequisitos so definidos num nvel de abstrao relativamente elevado,uma vez que o detalhamento ser necessariamente realizado numa etapaposterior; as propriedades do sistema, que esto relacionadas s propriedadesemergentes do sistema; desempenho, segurana, disponibilidade, soalguns exemplos desta categoria de requisitos; as caractersticas indesejveis, que so propriedades que o sistemano deve possuir; to importante, muitas vezes, definir quecaractersticas no devem ser encontradas num dado sistema, quantodefinir aquelas que so consideradas essenciais; num sistema decomunicao de dados, por exemplo, algumas caractersticasindesejveis so os erros, as perdas e as duplicaes de mensagens.De forma geral, importante que sejam estabelecidos, da forma mais completapossvel, os objetivos e as funes a serem providas pelo sistema. Neste nvel, deve-seenfatizar o papel do sistema computacional no ambiente em que ele ser instalado,podendo-se deixar para etapas mais frente, a especificao dos aspectos funcionais domesmo.Observemos a distino atravs de um exemplo, onde so apresentadas duasverses de especificao dos requisitos de um sistema de segurana para um edifciocomercial:(a) O objetivo do sistema prover um sistema de proteo contra incndio eintruso que vai ativar um alarme interno e externo em caso de princpio deincndio ou invaso por pessoas no autorizadas;(b) O objetivo do sistema assegurar a continuidade do funcionamento normalconduzido no edifcio, mesmo na ocorrncia de eventos como o princpio deincndio ou intruso.Neste nvel do desenvolvimento do sistema, a segunda verso apresentada a maisadequada, uma vez que ela , por um lado, mais abrangente e, por outro, limitante emalguns aspectos. A forma como est estabelecido o objetivo do sistema est maiscompatvel com as necessidades do ambiente, e d uma maior abertura adoo detcnicas mais evoludas de preveno de incndio e intruso. Por outro lado, o fato deestabelecer como requisitos a garantia de continuidade das atividades realizadas noescritrio, elimina algumas solues como o uso de alarme interno ou irrigadores contraincndio.3.2.O projeto do sistemaOs principais passos envolvidos no projeto de um sistema computacional estoesquematizados na figura 3.3 e sero descritos nos pargrafos que seguem.Particionamento dos Requisitos. Uma vez estabelecidos os requisitos do sistema naetapa anterior, o objetivo deste primeiro passo de projeto partic