Home

Notas de Aula - Engenharia de Software -v2014

1. GFC Em um GFC blocos disjuntos de comandos s o considerados n s A execu o do primeiro comando do bloco acarreta a execu o de todos os outros comandos desse bloco na ordem dada Todos os comandos em um bloco t m um nico predecessor possivelmente com exce o do primeiro e um nico sucessor possivelmente com exce o do ltimo DELAMARO et al 2007 A representa o de um programa como um GFC estabelece uma correspond ncia entre n s e blocos de comandos e indica poss veis fluxos de controle entre blocos por meio de arcos Um GFC um grafo orientado com um nico n de entrada e um nico n de sa da Cada n representa um bloco indivis vel sequencial de comandos e cada arco representa um Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 82 poss vel desvio de um bloco para outro A partir de um GFC podem ser escolhidos os elementos que devem ser executados DELAMARO et al 2007 Seja o caso de uma fun o que retorna o en simo termo de uma s rie de S rie de Fibonacci A S rie de Fibonacci tem a seguinte forma 1 1 2 3 5 8 13 21 34 sendo o en simo termo calculado da seguinte forma sen 1 Fa 1 se n 2 Fa 1 se n gt 2 Fa Fn 1 Fio A Figura 5 2 mostra uma poss vel implementa o para esta fun o e seu correspondente GFC No Bloco de Comandos long fibonacci int n EAE 1
2. Manuten o ALUN m 11 13 14 15 19 19 19 21 22 24 25 36 45 48 48 50 51 59 61 70 70 71 74 T1 84 87 87 87 PARTE II Ger ncia de Software Cap tulo 7 Ger ncia da Qualidade 7 1 Documenta o de Software 7 2 Verifica o e Valida o de Software por meio de Revis es 7 3 Ger ncia de Configura o de Software 7 4 Medi o de Software Cap tulo 8 Ger ncia de Projetos 8 1 Projeto de Software e Ger ncia de Projetos 8 2 O Processo de Ger ncia de Projetos 8 3 Determina o do Escopo do Software 8 4 Defini o do Processo de Software do Projeto 8 5 Estimativas 8 6 Ger ncia de Riscos 8 7 Elabora o do Plano de Projeto Cap tulo 9 T picos Avan ados em Engenharia de Software 9 1 Normas e Modelos de Qualidade de Processo de Software 9 2 Processos Padr o 9 3 Processos geis 9 3 Apoio Automatizado ao Processo de Software Anexo A An lise de Pontos de Fun o 90 90 91 93 95 98 98 100 102 102 103 112 114 115 115 121 123 126 128 Engenharia de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 1 Cap tulo 1 Introdu o O desenvolvimento de software uma atividade de crescente import ncia na sociedade contempor nea A utiliza o de computadores nas mais diversas reas do conhe
3. UFES Universidade Federal do Esp rito Santo 103 Adicionalmente outros processos tipicamente de cunho gerencial devem ser definidos dentre eles processos de ger ncia de projetos e de garantia da qualidade 8 5 Estimativas Antes mesmo de serem iniciadas as atividades do processo de desenvolvimento o gerente e a equipe do projeto devem estimar o trabalho a ser realizado os recursos necess rios a dura o e por fim o custo do projeto Apesar das estimativas serem um pouco de arte e um pouco de ci ncia essa importante atividade n o deve ser conduzida de forma desordenada afinal as estimativas s o a base para todas as outras atividades do planejamento de projeto Para alcan ar boas estimativas de esfor o prazo e custo existem algumas op es PRESSMAN 2011 1 Postergar as estimativas at o mais tarde poss vel no projeto 2 Usar t cnicas de decomposi o 3 Usar um ou mais modelos emp ricos para estimativas de custo e esfor o 4 Basear as estimativas em projetos similares que j tenham sido conclu dos A primeira op o apesar de ser atraente n o pr tica pois estimativas devem ser providas logo no in cio do projeto planejamento do projeto No entanto deve se reconhecer que quanto mais tarde forem feitas as estimativas maior o conhecimento que se tem sobre o projeto e por conseguinte menores as chances de se cometer erros Assim fundamental revisar as estimativas na medida em que o pro
4. es de ajuste de desempenho e seguran a s o necess rias S o necess rias especifica es especiais de processador para um m dulo espec fico da aplica o Restri es operacionais requerem cuidados especiais no processador central ou no processador dedicado para executar a aplica o Al m das caracteristicas do item anterior h considera es especiais que exigem utiliza o de ferramentas de an lise de desempenho para a distribui o do sistema e seus componentes nas unidades processadoras 5 Volume de transa es Consiste na avalia o do n vel de influ ncia do volume de transa es no projeto desenvolvimento implanta o e manuten o do sistema 0 l Zi W N o est o previstos per odos de picos de volume de transa o Est o previstos picos de transa es mensalmente trimestralmente anualmente ou em certo per odo do ano S o previstos picos semanais S o previstos picos di rios Alto volume de transa es foi estabelecido pelo usu rio ou o tempo de resposta necess rio atinge n vel alto o suficiente para requerer an lise de desempenho na fase de projeto Al m do descrito no item anterior necess rio utilizar ferramentas de an lise de desempenho nas fases de projeto desenvolvimento e ou implanta o Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 137 6 Entrada de dados on li
5. es sobre um cliente tem significados diferentes quando passa pelos fluxos dados novo cliente e dados cliente No primeiro caso os dados ainda n o foram validados e portanto podem ser v lidos ou inv lidos enquanto no segundo fluxo esses mesmos dados j foram validados Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 39 dados novo Setor de cliente Cadastrar Pessoal cliente dados cliente clientes Figura 3 26 Mesmo conte do de dados em fluxos diferentes Fluxos de dados que transportam exatamente o mesmo conte do de para um dep sito de dados n o precisam ser nomeados No exemplo da Figura 3 26 se o fluxo dados cliente apresentar exatamente o mesmo conte do do dep sito clientes n o h necessidade de nome lo como mostra a Figura 3 27 dados novo Setor de cliente Cadastrar Pessoal cliente clientes Figura 3 27 Fluxo de dados n o nomeado Fluxos de erro ou exce o no exemplo dados cliente inv lidos s devem ser mostrados em um DFD se forem muito significativos para o seu entendimento Caso contr rio devem ser tratados apenas na descri o da l gica do processo E importante real ar que DFDs n o indicam a sequencia na qual fluxos de dados entram ou saem de um processo Essa sequencia descrita apenas na especifica o do processo
6. n o existe nenhum risco 100 prov vel ii perda se o risco se tornar realidade consequ ncias n o desejadas ou perdas acontecer o Desta forma de suma import ncia que riscos sejam identificados durante um projeto de software para que a es possam ser planejadas e utilizadas para evitar que um risco se torne real ou para minimizar seus impactos caso ele ocorra Esse o objetivo da Ger ncia de Riscos cujo processo envolve as seguintes atividades e Identifica o de riscos visa identificar poss veis amea as riscos para o projeto antecipando o que pode dar errado e An lise de riscos trata de analisar os riscos identificados estimando sua probabilidade e impacto grau de exposi o ao risco e Avalia o de riscos busca priorizar os riscos e estabelecer um ponto de corte indicando quais riscos ser o gerenciados e quais n o ser o e Planejamento de a es trata do planejamento das a es a serem tomadas para evitar a es de mitiga o que um risco ocorra ou para definir o que fazer quando um risco se tornar realidade a es de conting ncia e Elabora o do Plano de Riscos todos os aspectos envolvidos na ger ncia de riscos devem ser documentados em um plano de riscos indicando os riscos que comp em o perfil de riscos do projeto as avalia es dos riscos a defini o dos riscos a serem gerenciados e para esses as a es para evit los ou para minimizar seus impactos caso venham
7. o NPF segundo a seguinte express o 3 NPF F o NCi Cij j onde e NC n mero fun es do tipo i i variando de 1 a 5 segundo os tipos de fun o existentes ALI AIE EE SE e CE que foram classificados na complexidade j j variando de 1 a 3 segundo os valores de complexidade simples m dia e complexa e Cij valor da contribui o da complexidade j no c lculo dos pontos da fun o i dado pela tabela A 4 Tabela A 4 Contribui o das Fun es na Contagem de PFs N o Ajustados Fun o Complexidade ALI 7 10 15 AIE 5 7 10 EE 3 4 6 SE 4 5 7 CE 3 4 6 2 O total de pontos de fun o n o ajustados PFNA dado pelo somat rio dos pontos das tabelas de fun o 5 PFNA NPF i 1 sendo que i varia de 1 a 5 segundo os tipos de fun o existentes AIL AIE EE SE e CE Uma boa op o consiste em preencher a tabela mostrada na Figura A 3 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 133 Total de Pontos de Fun o N o Ajustados Figura A 3 Tabela para C lculo de Pontos de Fun o N o Ajustados Determina o do Fator de Ajuste O fator de ajuste influencia os pontos de fun o n o ajustados em 35 obtendo se o n mero de PFs ajustados Para se calcular o fator de ajuste s o usadas 14 caracter sticas gerais dos sistemas a saber Engenh
8. Cause 7 22 Decision Management System Architectural Sotware Architectural Sotware Qudity Process Design Process Design Process Assurance Process Oase 6 33 Clause 643 Clause 713 Oas 7 23 Organizational y Software Detailed Desi Sotware Verification Project Enabling Risk Managemert implementation Process Process a Process Processes Process Cause 634 Cause 644 Clause 714 Clause 7 2 4 Life Cycle Model Corti guration System htegration Software Construction Software Validation Maragerent Process Management Process Process Process Process Cause 621 Oase 6 35 Cause 645 Cause 715 Cause 7 25 Hfrastructure Hfomatico Management System Qua fication Software htegation Management Process Process Testing Process Process Clause 622 Classe 6 36 Clause 646 Clause 7146 Software Review Process Clause 7 26 Project Porfolio Software Installation Software Qualification Measurement Process h Sotware Audt Process Maragement Process Process Testing Process Cause 622 Cause 6 3 7 Cause 647 Clause 717 Clause 7 2 7 Human Resource Sotware Acceptance Software Problem Maragement Process Support Process Resolution Process Cause 624 Cause 648 Clause 7 28 Quality Management Software Operation Process Process Clause 625 Cause 649 Software Reuse Processes Software Maintenance Domain Engineering Reuse Program Process Process Management Process Clause 64140 Cause 7341 Cause 7 33 Software D
9. UFES Universidade Federal do Esp rito Santo 5 m todos e t cnicas utilizados nesta fase com destaque para a Modelagem de Casos de Uso e a Modelagem de Entidades e Relacionamentos e Cap tulo 4 Projeto de Software aborda os conceitos b sicos de projeto de sistemas de software tratando da arquitetura do sistema a ser desenvolvido e do projeto de seus componentes Tamb m s o discutidos o projeto de dados e o projeto de interface com o usu rio e Cap tulo 5 Implementa o e Testes de Software s o enfocadas as atividades de implementa o e testes sendo esta ltima tratada em diferentes n veis a saber teste de unidade teste de integra o e teste de sistema e Cap tulo 6 Entrega e Manuten o discute as quest es relacionadas entrega do sistema para o cliente tais como o treinamento e a documenta o de entrega e o processo de manuten o de software PARTE II Ger ncia de Software e Cap tulo 7 Ger ncia da Qualidade s o abordadas t cnicas para revis o de software bem como processos importantes para a garantia da qualidade a saber documenta o ger ncia de configura o de software e medi o de software e Cap tulo 8 Ger ncia de Projetos s o abordadas as principais atividades do processo de ger ncia de projetos a saber planejamento acompanhamento e encerramento de projetos e Cap tulo 9 T picos Avan ados em Engenharia de Software discute alguns aspectos adi
10. Universidade Federal do Esp rito Santo 124 projeto design necess rio antes de podem come ar a implementa o projeto e implementa o devem ser feitos em paralelo S o caracter sticas necess rias das pessoas e da equipe gil em si e Compet ncia habilidades espec ficas de desenvolvimento de software e conhecimento do processo a ser usado e Foco comum todos devem ter o mesmo foco entregar ao cliente a pr xima vers o incremento do sistema no prazo prometido e Colabora o deve haver colabora o entre membros da equipe e com o cliente e Autonomia para tomar decis es t cnicas e de planejamento e Versatilidade aceitar o fato de que o problema sendo resolvido hoje pode mudar amanh e Respeito e confian a m tuas a equipe mais do que a soma das partes e Auto organiza o o time se auto gerencia em rela o ao trabalho a ser feito s adapta es ao processo e ao cronograma de trabalho A motiva o para os processos geis tentar combater as fraquezas dos processos convencionais de Engenharia de Software Contudo processos geis n o s o uma ant tese dos processos tradicionais De fato princ pios de agilidade podem ser aplicados a quaisquer processos de software Dentre os m todos geis de desenvolvimento de software destacam se o eXtreme Programming XP e o Scrum 9 3 1 eXtreme Programming XP Ainda que as ideias subjacentes ao XP existissem desde o final da d cada de 1
11. importante considerar tamb m requisitos de dom nio Requisitos de dom nio ou regras de neg cio s o provenientes do dom nio de aplica o do sistema e refletem caracter sticas e restri es desse dom nio Eles s o derivados do neg cio que o sistema se prop e a apoiar e podem restringir requisitos funcionais existentes ou estabelecer como c lculos espec ficos devem ser realizados refletindo fundamentos do dom nio de aplica o SOMMERVILLE 2011 Por exemplo em um sistema de matr cula de uma universidade uma importante regra de neg cio diz que um aluno s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pr requisitos 3 2 Engenharia de Requisitos Dada a import ncia de requisitos para o sucesso de um projeto eles devem ser cuidadosamente identificados analisados documentados e avaliados Al m disso altera es em requisitos devem ser gerenciadas para garantir que est o sendo adequadamente tratadas Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 20 Ao conjunto de atividades relacionadas aos requisitos d se o nome de Engenharia de Requisitos De maneira geral o processo de Engenharia de Requisitos envolve as seguintes atividades KOTONYA SOMMERVILLE 1998 como ilustra a Figura 3 1 Ger ncia de Requisitos problemas nos requisitos V amp V de Requisit
12. Atividades Requisitos An lise Projeto Implementa o Testes Iter sede z i j 2 itera es EE ss Figura 2 9 O Modelo de Processo do RUP As atividades do processo de desenvolvimento s o distribu das ao longo de uma itera o em fun o do foco da fase correspondente Por exemplo em uma itera o que ocorra no final da fase de elabora o tipicamente s o realizadas atividades de especifica o de requisitos an lise projeto implementa o e testes J em uma itera o t pica da fase de concep o essencialmente s o realizadas atividades de levantamento de requisitos com algum trabalho de modelagem an lise Eventualmente se um prot tipo for desenvolvido pode haver algum trabalho de implementa o e testes Leitura Complementar Os livros de Pressman 2011 Sommerville 2011 e Pfleeger 2004 s o excelentes refer ncia na rea de Engenharia de Software e contemplam os aspectos tratados neste cap tulo e muito mais Modelos de processo s o discutidos em PRESSMAN 2011 no Cap tulo 2 Modelos de Processo em SOMMERVILLE 2011 no Cap tulo 2 Processos de Software e em PFLEEGER 2004 no Cap tulo 2 Modelagem do Processo e Ciclo de Vida Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 18 Refer ncias do Cap tulo CHRISTENSEN M J THAYER R H
13. e possibilitar a discuss o de corre es e modifica es com o usu rio e formar a documenta o do sistema Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 23 Mapa Pol tico Mapa Tur stico Figura 3 3 Modelos como Abstra es da Realidade Um modelo enfatiza um conjunto de caracter sticas da realidade que corresponde perspectiva do modelo No desenvolvimento de sistemas h duas perspectivas principais Estrutural tem por objetivo descrever as informa es que o sistema deve representar e gerenciar Comportamental visa especificar as a es funcionalidades servi os que o sistema deve prover bem como o comportamento de certas entidades do modelo estrutural em rela o a essas a es Al m da perspectiva que um modelo enfatiza modelos de sistemas podem ser constru dos em diferentes n veis de abstra o foco no problema ou na solu o Geralmente no desenvolvimento de sistemas s o considerados tr s n veis Modelo conceitual considera caracter sticas do sistema independentes do ambiente computacional hardware e software no qual o sistema ser implementado Modelos conceituais s o constru dos na atividade de an lise de requisitos Modelo l gico trata caracter sticas dependentes de um determinado tipo de plataforma computacional Essas caracter sticas s o contudo independentes de
14. es nos itens as ltimas vers es dos mesmos e identificadores de libera o e Gerenciamento de Libera o e Entrega diz respeito constru o do produto de software ou de partes dele produzindo itens de configura o ICs derivados a partir de ICs fonte libera o identificando as vers es particulares de cada IC que ser o disponibilizadas e entrega implantando os produtos de software no ambiente final de execu o 7 3 1 O Processo de GCS O primeiro passo do processo de GCS a confec o de um plano de ger ncia de configura o que inicia com a identifica o dos itens que ser o colocados sob ger ncia de configura o chamados itens de configura o ICs Os itens mais relevantes para serem submetidos ger ncia de configura o s o aqueles mais usados durante o ciclo de vida os mais importantes para seguran a os projetados para reutiliza o e os que podem ser modificados por v rios desenvolvedores ao mesmo tempo SANCHES 2001b Os itens n o colocados sob ger ncia de configura o podem ser alterados livremente Ap s a sele o dos itens deve se descrever como eles se relacionam Isso muito importante para as futuras manuten es pois permite identificar de maneira eficaz os itens afetados em decorr ncia de uma altera o Al m disso deve se criar um esquema de identifica o dos itens de configura o com atribui o de nomes exclusivos para que seja poss vel estabelecer a evol
15. estados v rios casos de uso s o testados para exercitar estados e transi es em um diagrama de estados Uma vez integrados todos os m dulos do sistema parte se para os testes de sistema Os testes de sistema incluem diversos tipos de teste realizados geralmente na seguinte ordem PFLEEGER 2004 e Teste funcional de sistema verifica se o sistema integrado realiza as fun es especificadas nos requisitos e Teste n o funcional de sistema verifica se o sistema integrado atende os requisitos n o funcionais do sistema efici ncia seguran a confiabilidade etc e Teste de aceita o os testes funcionais e n o funcionais citados anteriormente s o realizados por testadores ou eventualmente por desenvolvedores ainda que desaconselh vel tomando por base a especifica o do sistema e portanto s o testes de verifica o Entretanto necess rio que o sistema seja testado tamb m pelos clientes e usu rios testes de valida o No teste de aceita o clientes e usu rios testam o sistema a fim de garantir que o mesmo satisfaz suas necessidades Vale destacar que o que foi especificado pelos desenvolvedores pode ser diferente do que o cliente queria Assim o teste de aceita o assegura que o sistema solicitado o que foi constru do e Teste de instala o algumas vezes o teste de aceita o feito no ambiente real de funcionamento outras n o Quando o teste de aceita o for feito em um ambiente de test
16. ii testes feitos por testadores independentes iii Compartilhamento de responsabilidades entre desenvolvedores e testadores independentes Contudo delegar toda a atividade de testes para desenvolvedores perigoso tendo em vista que o c digo resultado de seu trabalho Logo procurar defeitos de certo modo a destrui o do mesmo e o pr prio desenvolvedor n o tem motiva o psicol gica para projetar casos de teste que demonstrem que seu produto tem defeitos disson ncia cognitiva Assim dificilmente o desenvolvedor consegue criar casos de teste que rompam com a l gica de funcionamento de seu pr prio c digo KOSCIANSKI SOARES 2006 Testadores independentes s o mais indicados uma vez que s o capazes de assumir uma perspectiva de testes Contudo se testadores independentes forem respons veis por todos os testes em todas as fases isso pode tornar o processo lento e pouco produtivo Assim compartilhar responsabilidades pode ser uma op o conciliat ria A divis o pode ser feita por 1 fases na qual desenvolvedores testam unidades muitas vezes em paralelo com a implementa o das mesmas Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 85 enquanto testadores independentes realizam testes de integra o e de sistema ou ii por atividades do processo de teste em que testadores independentes s o respons veis pelo
17. indica que a transi o ocorrer t o logo a condi o torne se verdadeira Quando uma transi o n o possuir uma condi o associada ent o ela ocorrer sempre que o evento ocorrer 3 10 An lise de Requisitos segundo o Paradigma Estruturado Podemos notar que DFDs e Modelos de Casos de Uso t m alguns aspectos em comum e Ambos os modelos mostram as fronteiras do sistema delimitando o que est fora do sistema atores nos modelos de casos de uso e entidades externas nos DFDs e o que responsabilidade do sistema casos de uso nos modelos de casos de uso e processos nos DFDs e Ambos os modelos mostram quem atores nos modelos de casos de uso e entidades externas nos DFDs pode realizar alguma funcionalidade do sistema casos de uso nos modelos de casos de uso e processos nos DFDs Entretanto h diferen as significativas e Nos DFDs elementos internos ao sistema dep sitos de dados e fluxos de dados s o mostrados Isso n o ocorre nos modelos de casos de uso que buscam modelar as funcionalidades do sistema a partir de uma perspectiva externa e As associa es entre atores e casos de uso n o estabelecem que informa o est trafegando enquanto nos DFDs essa informa o definida pelos fluxos de dados Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 49 Para a maior parte das situa es modelos de caso
18. ncia de modelos produzidos na fase de projeto contra os correspondentes modelos de an lise p ex consist ncia entre um modelo de entidades e relacionamentos e o modelo relacional dele derivado no projeto de dados Nas revis es processos documentos e outros artefatos s o revisados por um grupo de pessoas com o objetivo de avaliar se os mesmos est o em conformidade com os padr es organizacionais estabelecidos e se o prop sito de cada um deles est sendo atingido incluindo o atendimento a requisitos do cliente e dos usu rios Assim o objetivo de uma revis o detectar erros e inconsist ncias em artefatos e processos sejam eles relacionados forma sejam eles relacionados ao conte do e apont los aos respons veis pela sua elabora o Uma revis o dita uma revis o t cnica formal quando segue um processo bem definido O processo de revis o come a com o planejamento da revis o quando uma equipe Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 93 de revis o formada tendo frente um l der A equipe de revis o deve incluir os membros da equipe que possam ser efetivamente teis para atingir o objetivo da revis o Muitas vezes a pessoa respons vel pela elabora o do artefato a ser revisado integra a equipe de revis o O prop sito da revis o deve ser previamente informado e o material a ser revisado deve
19. nica entrega feita como mostra a Figura 2 5 Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 13 Equipe 1 Equipe 2 Sistema Equipe n Figura 2 5 O Modelo RAD Assim como o modelo incremental o modelo RAD permite varia es Em todos os casos no entanto os requisitos t m de ser bem definidos o escopo do projeto tem de ser restrito e o sistema modular Se o projeto for grande por exemplo o n mero de equipes crescer demais e a atividade de integra o tornar se por demais complexa Obviamente para adotar esse modelo uma organiza o tem de ter recursos humanos suficientes para acomodar as v rias equipes 2 3 Modelos de Processo Evolutivos Sistemas de software como quaisquer sistemas complexos evoluem ao longo do tempo Seus requisitos muitas vezes s o dif ceis de serem estabelecidos ou mudam com frequ ncia ao longo do desenvolvimento PRESSMAN 2011 Assim importante ter como op o modelos de ciclo de vida que lidem com incertezas e acomodem melhor as cont nuas mudan as Alguns modelos incrementais dado que preconizam um desenvolvimento iterativo podem ser aplicados a esses casos mas a grande maioria deles toma por pressuposto que os requisitos s o bem definidos Modelos evolucion rios ou evolutivos buscam preencher essa lacuna Enquanto modelos increment
20. o apenas uma simples recupera o de dados Uma SE pode tamb m manter um ALI ou alterar o comportamento do sistema Por fim uma Consulta Externa CE assim como uma SE um processo elementar que envia dados ou informa es de controle para fora da fronteira da aplica o mas sem a realiza o de nenhum c lculo nem a cria o de dados derivados Seu objetivo apresentar informa o para o usu rio por meio apenas de recupera o de informa es Nenhum ALI mantido durante sua realiza o nem o comportamento do sistema alterado Calcular os pontos de fun o n o ajustados Para calcular os pontos de fun o n o ajustados preciso identificar a complexidade e a contribui o em pontos por fun o de cada uma das fun es contadas Para tal s o utilizadas tabelas de complexidade espec ficas para cada tipo de fun o ver Anexo A Determinar o valor do fator de ajuste o fator de ajuste baseado em 14 caracter sticas gerais de sistemas que avaliam a funcionalidade geral da aplica o que est sendo contada e seus n veis de influ ncia O n vel de influ ncia de uma caracter stica determinado com base em uma escala de O nenhuma influ ncia a 5 forte influ ncia Assim o fator de ajuste visa ajustar os pontos de fun o n o ajustados em 35 Esse passo tornou se opcional em 2002 para que o m todo da APF passasse a ser um padr o internacional de medi o funcional ISO IEC 20926 As princ
21. o de revis es Uma Revis o de Software visa assegurar que um artefato produzido em uma fase possui qualidade suficiente para ser usado em uma fase subsequente Revis es s o tipicamente realizadas em documentos produzidos ao longo do processo de software tais como documentos de requisitos modelos diversos especifica es de projeto etc Quando realizadas por clientes e usu rios revis es visam valida o Documentos de requisitos t m de ser submetidos avalia o de clientes e usu rios pois do contr rio h grande risco do sistema de software resultante n o atender s suas reais necessidades Quando uma revis o realizada por um membro da organiza o de desenvolvimento a revis o dita uma revis o por pares e o foco a verifica o Assim revis es por pares visam checar basicamente i se padr es organizacionais de documenta o est o sendo corretamente aplicados e 11 se h consist ncia entre diferentes artefatos produzidos para representar a mesma coisa Neste ltimo caso o foco pode ser a verifica o da consist ncia de artefatos produzidos em uma mesma fase tal como diferentes modelos conceituais detalhando requisitos previamente especificados p ex consist ncia entre o modelo de entidade e relacionamento o modelo de casos de uso e diagramas de estados produzidos para um mesmo sistema ou a verifica o da consist ncia de artefatos produzidos em fases diferentes tal como verificar a consist
22. o modelo em cascata a partir do qual diversos outros modelos foram propostos inclusive a maioria dos modelos incrementais e evolutivos 2 1 1 O Modelo em Cascata Tamb m chamado de modelo de ciclo de vida cl ssico o modelo em cascata organiza as atividades do processo de desenvolvimento de forma sequencial como mostra a Figura 2 1 Cada fase envolve a elabora o de um ou mais documentos que devem ser aprovados antes de se iniciar a fase seguinte Assim uma fase s deve ser iniciada ap s a conclus o daquela que a precede Uma vez que na pr tica essas fases se sobrep em de alguma forma geralmente permite se um retorno fase anterior para a corre o de erros encontrados A entrega do sistema completo ocorre em um nico marco ao final da fase de Entrega e Implanta o Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 9 Figura 2 1 O Modelo em Cascata O uso de revis es ao fim de cada fase permite o envolvimento do usu rio Al m disso cada fase serve como uma base aprovada e documentada para o passo seguinte facilitando bastante a ger ncia do projeto O modelo em cascata o modelo de ciclo de vida mais antigo e mais amplamente usado Entretanto cr ticas t m levado ao questionamento de sua efici ncia Dentre os problemas algumas vezes encontrados na sua aplica o destacam se PRE
23. para entidades e relacionamentos em um modelo ER Entretanto em um DFD n o h uma representa o expl cita dos relacionamentos entre as entidades Para indicar que o relacionamento entre entidades existe a representa o dos acessos dos processos aos dep sitos de dados deve obedecer seguinte regra geral ao criar ou excluir um relacionamento ou uma entidade que participa de um relacionamento mostre o acesso aos dep sitos de dados que correspondem ao relacionamento e s entidades que participam do relacionamento A Figura 3 31 mostra a representa o gr fica desses acessos a El E2 Modelo de Dados Gen rico Processo Processo El RI E2 El E2 Criar ou excluir uma ocorr ncia de R1 Criar ou excluir uma ocorr ncia de R2 Figura 3 31 Acessos a dep sitos de dados Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 42 No caso do relacionamento R1 como esse relacionamento tem um atributo a ele representado em um DFD como sendo um dep sito de dados Assim para criar ou excluir uma ocorr ncia de R1 representam se acessos a R1 El e E2 J o relacionamento R2 como esse n o possui atributos n o d origem a um dep sito de dados Para criar ou excluir uma ocorr ncia de R2 s o representados acessos a El e E2 3 7 2 Construindo DFDs Uma boa op o para o uso de DFDs consiste em elaborar um DFD para cada funcion
24. todo de medi o e portanto seu uso da forma como proposta para a realiza o de estimativas de tamanho uma adapta o Tendo em vista isso foram propostas algumas varia es mais simples do m todo voltadas para a realiza o de estimativas e que apresentam resultados satisfat rios dentre elas a Contagem Indicativa o uso de Complexidades M dias e a Contagem Estimativa Todas consideram apenas PFs n o ajustados VAZQUEZ SIM ES ALBERT 2005 Na Contagem Indicativa necess ria apenas a identifica o das fun es de dados ALIs e AIEs Considera se ent o 35 PFs para cada ALI e 15 PFs para cada AIE identificados ou seja o n mero de PFs n o ajustados dado por nPFNA 35 nALI 15 nAIE Nos casos de Complexidades M dias e Contagem Estimativa necess rio identificar todas as fun es de dados ALIs e AIEs e transacionais EEs CEs e SEs mas n o necess rio usar as tabelas de complexidade No caso das Complexidades M dias do ISBSG Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 109 Benchmark considera se 7 4 PFs para cada ALI 5 5 PFs para cada AIE 4 3 PFs para cada EE 5 4 PFs para cada SE e 3 8 PFs para cada CE Assim o n mero de PFs n o ajustados dado por nPFNA 7 4 nALI 5 5 nATE 4 3 nEE 5 4 nSE 3 8 nCE No caso da Contagem Estimativa da NESMA os pesos s o um pouco difere
25. ulica e el trica ou mesmo c lculos estruturais Um bom pedreiro capaz de resolver o problema a contento Talvez n o seja dada a melhor solu o mas o produto resultante pode atender aos requisitos pr estabelecidos Essa abordagem contudo n o vi vel para a constru o de um edif cio Nesse caso necess rio realizar um estudo aprofundado incluindo an lises do solo c lculos estruturais etc seguido de um planejamento da execu o da obra e desenvolvimento de modelos maquetes e plantas de diversas naturezas at a realiza o da obra que deve ocorrer por etapas tais como funda o alvenaria e acabamento Ao longo da realiza o do trabalho deve se realizar um acompanhamento para verificar prazos custos e a qualidade do que se est construindo Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento surgiu a Engenharia de Software A Engenharia de Software a rea da Ci ncia da Computa o voltada especifica o desenvolvimento e manuten o de sistemas de software com aplica o de tecnologias e pr ticas de ger ncia de projetos e outras disciplinas visando organiza o produtividade e qualidade no processo de software A Engenharia de Software trata de aspectos relacionados ao estabelecimento de processos m todos t cnicas ferramentas e ambientes de suporte ao desenvolvimento de software Assim como em outras reas em uma abordagem de en
26. 4 mostra as principais possibilidades Na parte a da Figura 2 4 inicialmente durante a fase de planejamento um levantamento preliminar dos requisitos realizado Com esse esbo o dos requisitos planejam se os incrementos e se desenvolve a primeira vers o do sistema Concluido o primeiro ciclo todas as atividades s o novamente realizadas para o segundo ciclo inclusive o planejamento quando a atribui o de requisitos aos incrementos pode ser revista Este procedimento repetido sucessivamente at que se chegue ao produto final Outras duas varia es do modelo incremental bastante utilizadas s o apresentadas nas partes b e c da Figura 2 4 Na parte b dessa figura os requisitos s o especificados para o sistema como um todo e as itera es ocorrem a partir da fase de an lise Na Figura 2 4 c o sistema tem seus requisitos especificados e analisados a arquitetura do sistema definida e apenas o projeto detalhado a implementa o e os testes s o realizados em v rios ciclos Uma vez que nessas duas varia es os requisitos s o especificados para o sistema como um todo sua ado o requer que os requisitos sejam est veis e bem definidos O modelo incremental particularmente til quando n o h pessoal suficiente para realizar o desenvolvimento dentro dos prazos estabelecidos ou para lidar com riscos t cnicos tal como a ado o de uma nova tecnologia PRESSMAN 2011 Engenharia de Software Notas de Aula C
27. Aplica o com entrada de dados on line e suporta mais de um tipo de protocolo de comunica o 2 Processamento de Dados Distribu do Esta caracter stica refere se a sistemas que utilizam dados ou processamento distribu do valendo se de diversas CPUs 0 Aplica o n o auxilia na transfer ncia de dados ou fun es entre os processadores da empresa Aplica o prepara dados para o usu rio final utilizar em outro processador do usu rio final tal como planilhas Aplica o prepara dados para transfer ncia transfere os para serem processados em outro equipamento da empresa n o pelo usu rio final Processamento distribu do e a transfer ncia de dados on line e apenas em uma dire o Processamento distribu do e a transfer ncia de dados on line e em ambas as dire es As fun es de processamento s o dinamicamente executadas no equipamento CPU mais apropriada 2 E z x o Protocolo um conjunto de informa es que reconhecem e traduzem para um determinado padr o informa es entre dois sistemas ou perif ricos permitindo interc mbio das informa es Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 136 3 Desempenho Trata se de par metros estabelecidos pelo usu rio como aceit veis relativos a tempo de resposta 0 l 2 Nenhum requisito especial de desempenho foi solicitado pel
28. Arquitetura do Software visa a definir os grandes componentes estruturais do software e seus relacionamentos e Projeto de Dados tem por objetivo projetar a estrutura de armazenamento de dados necess ria para implementar o software e Projeto de Interfaces descreve como o software dever se comunicar dentro dele mesmo interfaces internas com outros sistemas interfaces externas e com pessoas que o utilizam interface com o usu rio e Projeto Detalhado tem por objetivo refinar e detalhar a descri o dos componentes estruturais da arquitetura do software A seguir cada uma dessas subatividades do projeto de software discutida luz do paradigma estruturado 4 1 Projeto de Dados Um aspecto fundamental da fase de projeto consiste em estabelecer de que forma ser o armazenados os dados do sistema Em fun o da plataforma de implementa o diferentes solu es de projeto devem ser adotadas Isto se o software tiver de ser implementado em um banco de dados relacional por exemplo um modelo relacional deve ser produzido adequando a modelagem de entidades e relacionamentos a essa plataforma de implementa o Atualmente a plataforma mais utilizada para armazenamento de grandes volumes de dados s o os Bancos de Dados Relacionais e portanto neste texto discutiremos apenas o projeto l gico de bancos de dados relacionais 4 1 1 O Modelo Relacional Em um modelo de dados relacional os conjuntos de dados s o
29. O Produto Na ger ncia de projetos um gerente se depara logo no in cio com um s rio problema s o necess rias estimativas quantitativas de tempo e custo e um plano organizado do trabalho a ser feito Entretanto n o h informa o suficiente para tal Assim a primeira coisa a fazer definir o escopo do software realizando um levantamento preliminar de requisitos Neste contexto ganha for a a ideia de decompor o problema em uma abordagem dividir para conquistar Inicialmente o sistema deve ser decomposto em subsistemas que s o por sua vez decompostos em m dulos Os m dulos podem ainda ser recursivamente decompostos em subm dulos ou fun es at que se tenha uma vis o geral das funcionalidades a serem tratadas no projeto Caracter sticas especiais relacionadas a essas fun es devem ser apontadas tais como requisitos de desempenho 8 1 3 O Processo Para poder ser gerenciado um projeto tem de ser planejado em termos das atividades a serem realizadas definindo dentre outros os respons veis pela sua realiza o e os produtos de trabalho a serem produzidos Os modelos de processo discutidos no Cap tulo 2 podem estabelecer uma base para a defini o do processo de projeto mas h de se levar em conta que cada projeto tem caracter sticas nicas e que portanto al m de selecionar o modelo de processo mais indicado para o projeto em quest o o gerente de projeto precisa ainda adapt lo para as reais
30. S o v rios os problemas enfrentados nesta fase tais como dificuldades para se estabelecer o escopo do sistema o que deve ser tratado no desenvolvimento e o que n o ser tratado problemas de comunica o entre pessoas e falta de entendimento acerca do assuntos Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 22 que cercam o desenvolvimento do sistema volatilidade dos requisitos requisitos mudando muito rapidamente e falta de envolvimento dos principais interessados especialistas de dom nio clientes e usu rios Assim para tentar minimizar essas dificuldades estabelecer uma rela o de confian a com clientes e usu rios e melhor aproveitar os esfor os v rias t cnicas de levantamento de requisitos s o normalmente empregadas pelos engenheiros de requisitos ou analistas de sistemas dentre elas entrevistas question rios prototipa o investiga o de documentos observa o din micas de grupo etc Uma caracter stica fundamental da atividade de levantamento de requisitos o seu enfoque em uma vis o do cliente usu rio Em outras palavras est se olhando para o sistema a ser desenvolvido por uma perspectiva externa Ainda n o se est procurando definir a estrutura interna do sistema mas sim procurando saber que funcionalidades o sistema deve oferecer ao usu rio e que restri es o sistema devem satisfazer ou
31. Uso De fato outros elementos de modelo podem ser usados em diagramas de casos de uso tais como associa es de depend ncia entre casos de uso rela es de generaliza o entre casos de uso e entre atores mas fogem ao escopo deste texto Maiores informa es podem ser encontradas em BOOCH RUMBAUGH JACOBSON 2006 3 8 2 Descri o de Casos de Uso Um caso de uso deve descrever o que um sistema faz Geralmente um diagrama de casos de uso insuficiente para esse prop sito Assim deve se especificar o comportamento de um caso de uso pela descri o textual de seu fluxo de eventos de modo que algu m de fora possa compreend lo Ao escrever o fluxo de eventos deve se incluir como e quando o caso de uso inicia e termina quando o caso de uso interage com os atores e quais s o as informa es transferidas e o fluxo b sico e os fluxos alternativos do comportamento BOOCH RUMBAUGH JACOBSON 2006 Uma vez que o conjunto inicial de casos de uso estiver estabilizado cada um deles deve ser descrito em mais detalhes Primeiro deve se descrever o fluxo de eventos principal ou curso b sico isto o curso de eventos mais importante que normalmente ocorre Variantes do curso b sico de eventos e erros que possam vir a ocorrer devem ser descritos em cursos alternativos Normalmente para cada curso b sico de um caso de uso h diversos cursos alternativos As t cnicas de especifica o de processos descritas na Se o 3 7 po
32. a atua o de cada elemento do conjunto de entidades no relacionamento e portanto importante atribuir pap is Assim no caso do auto relacionamento pr requisito para da Figura 3 8 estamos dizendo que pr requisitos c dl d2 dl d2 e Disciplina e papel d1 pr requisito e papel d2 p s requisito At o momento tratamos apenas de relacionamentos bin rios Entretanto relacionamentos n rios s o tamb m poss veis ainda que bem menos corriqueiros Um relacionamento tern rio por exemplo s se caracteriza pelo terno como mostra a Figura 3 9 Os relacionamentos tern rios normalmente s o dif ceis de se dar um nome e por isso usual represent los pelas iniciais das tr s entidades envolvidas como mostra o exemplo da Figura 3 10 Neste exemplo estamos dizendo que lojas compram materiais de fornecedores sendo que uma loja pode comprar v rios materiais diferentes de fornecedores diferentes J um fornecedor pode vender v rios materiais para diferentes lojas Por fim um material pode ser adquirido por v rias lojas a partir de v rios fornecedores A oa C Ref abo aeA beB ceC Figura 3 9 Relacionamento Tern rio Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 29 Figura 3 10 Exemplo de Relacionamento Tern rio Alguns relacionamentos s o t o importantes que assumem o status de e
33. a ocorrer e Monitoramento de riscos medida que o projeto progride os riscos t m de ser monitorados para se verificar se os mesmos est o se tornando realidade ou n o Novos riscos podem ser identificados o grau de exposi o de um risco pode mudar e a es podem ter de ser tomadas Essa atividade realizada durante o acompanhamento do progresso do projeto Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 113 Na identifica o de riscos trabalhar com uma s rie de riscos aleat rios pode ser um fator complicador principalmente em grandes projetos em que o n mero de riscos relativamente grande Assim a classifica o de riscos em categorias de risco definindo tipos b sicos de riscos importante para guiar a realiza o dessa atividade Cada organiza o deve ter seu pr prio conjunto de categorias de riscos Para efeito de exemplo podem ser consideradas categorias tais como tecnologia pessoal legal organizacional de neg cio etc Uma vez identificados os riscos deve ser feita uma an lise dos mesmos luz de suas duas principais vari veis a probabilidade do risco se tornar real e o impacto do mesmo caso ocorra Na an lise de riscos o gerente de projeto deve executar quatro atividades b sicas PRESSMAN 2011 1 estabelecer uma escala que reflita a probabilidade de um risco ii avaliar as consequ ncias d
34. alto n vel executada quando o sistema estiver operacional visando a descobrir erros nos requisitos PRESSMAN 2011 PFLEEGER 2004 No teste de unidade faz se necess rio construir pequenos componentes para permitir testar os m dulos individualmente os ditos drivers e stubs Um driver um programa respons vel pela ativa o e coordena o do teste de uma unidade Ele respons vel por receber os dados de teste fornecidos pelo testador passar esses dados para a unidade sendo testada obter os resultados produzidos por essa unidade e apresent los ao testador Um stub Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 75 uma unidade que substitui na hora do teste uma outra unidade chamada pela unidade que est sendo testada Em geral um stub simula o comportamento da unidade chamada com o m nimo de computa o ou manipula o de dados MALDONADO FABBRI 2001 Pode n o ser pr tico e vi vel testar todas as unidades individualmente para depois integr las dada a necessidade de uma grande quantidade de drivers e stubs a ser constru da poss vel adotar estrat gias de teste de integra o que diminuam a quantidade de drivers e stubs necess rios Sejam as seguintes abordagens Integra o ascendente ou bottom up Nessa abordagem primeiramente cada m dulo no n vel inferior da hierarquia do sistema testado indi
35. aumentar a produtividade H diversos tipos de ferramentas de teste Contudo ainda assim muito trabalho humano necess rio para criar os casos de teste adequados aos crit rios utilizados DELAMARO et al 2007 Refer ncias do Cap tulo DELAMARO M E MALDONADO J C JINO M Introdu o ao Teste de Software S rie Campus SBC Editora Campus 2007 KOSCIANSKI A SOARES M S Qualidade de Software Editora Novatec 2006 MALDONADO J C FABBRI S C P F Teste de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 MCGREGOR J D SYKES D A 4 Practical Guide to Testing Object Oriented Software Addison Wesley 2001 MYERS G J The Art of Software Testing 2nd edition John Wiley amp Sons 2004 PFLEEGER S L Engenharia de Software Teoria e Pr tica 2 Edi o S o Paulo Prentice Hall 2004 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 Engenharia de Software Cap tulo 6 Entrega e Manuten o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 87 Cap tulo 6 Entrega e Manuten o Uma vez que o sistema aceito e instalado estamos chegando ao fim do processo de desenvolvimento de software A entrega a ltima etapa desse processo Uma vez entregue o sistema passa a estar em opera o e requisi es de mudan as sejam de car ter corret
36. cada a o A Figura 3 32 mostra um exemplo de rvore de Decis o Se for necess rio descrever a l gica de um processo como um conjunto de instru es combinando decis es e a es intermedi rias a rvore de decis o pode ser combinada com portugu s estruturado Sem atraso de Tratamento pagamento nt 8 registrado Priorit rio A ep Priorit rio neg cios gt trabalho gt R 1 milh o Com atraso O anos de pagamento registrado Tempo de trabalho lt Normal Volume de 20 anos neg cios lt Norma R 1 milh o Figura 3 32 Exemplo de rvore de Decis o Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 45 3 8 Modelagem de Casos de Uso Uma t cnica alternativa para a modelagem funcional amplamente utilizada nos dias de hoje a Modelagem de Casos de Uso A modelagem de casos de uso foi originalmente proposta no contexto de um m todo de an lise orientada a objetos o m todo OOSE JACOBSON 1992 mas percebeu se que na verdade essa uma t cnica independente de paradigma dado que n o descreve a estrutura interna de um sistema mas apenas prov uma forma de estruturar uma vis o externa do mesmo O modelo de casos de uso um modelo bastante simples voltado para a comunica o com clientes e usu rios e portanto bastante dependente de descri es textuais De fato como um modelo voltado
37. com as atividades de garantia da qualidade de software Dentre as principais fun es da GCS destacam se e Identifica o da Configura o refere se identifica o dos itens de software e suas vers es a serem controladas estabelecendo linhas b sicas Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 94 e Controle de Vers o combina procedimentos e ferramentas para administrar diferentes vers es dos itens de configura o criados durante o processo de software e Controle de Modifica o combina procedimentos humanos e ferramentas automatizadas para controlar as altera es feitas em itens de software Para tal o seguinte processo normalmente realizado solicita o de mudan a aprova o ou rejei o da solicita o registro de retirada para altera o check out an lise avalia o e realiza o das altera es revis o e registro da realiza o das altera es check in e Auditoria de Configura o visa avaliar um item de configura o quanto a caracter sticas n o consideradas nas revis es tal como se os itens relacionados aos solicitados foram devidamente atualizados e Relato da Situa o da Configura o refere se prepara o de relat rios que mostrem a situa o e o hist rico dos itens de software controlados Tais relat rios podem incluir dentre outros o n mero de altera
38. conseguinte custos de altera es As atividades que se preocupam com essa quest o s o coletivamente denominadas atividades de garantia da qualidade de software e devem ser realizadas ao longo de todo o processo de desenvolvimento de software MALDONADO FABBRI 2001 Conforme discutido no Cap tulo 5 as atividades de controle e garantia da qualidade podem ser de dois tipos principais Verifica o e Valida o V amp V O objetivo da verifica o assegurar que o software esteja sendo constru do de forma correta Deve se verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padr es organizacionais foram consistentemente aplicados Por outro lado o objetivo da valida o assegurar que o software que est sendo desenvolvido o software correto ou seja se os requisitos e o software dele derivado satisfazem s necessidades dos clientes e usu rios As atividades de V amp V podem ser de dois tipos est ticas e din micas Testes s o an lises din micas uma vez que envolvem a execu o de c digo Contudo a execu o do c digo requer obviamente que c digo fonte tenha sido produzido Assim a avalia o de um produto de software apenas por meio de testes normalmente insuficiente Conforme dito na introdu o deste cap tulo a qualidade do produto de software tem de ser constru da ao longo do processo Assim fundamental realizar atividades de V amp V est ticas o que envolve a realiza
39. da rela o destino com um subscrito t como ilustra a Figura 4 5 Colunas que n o s o chaves prim rias ou estrangeiras n o s o representadas nos diagramas mas sim em um dicion rio de dados do modelo relacional 4 1 2 Construindo um Modelo Relacional a partir de um Modelo ER Para se realizar o mapeamento de um modelo de entidades e relacionamentos em um modelo relacional pode se utilizar como ponto de partida as seguintes diretrizes e Entidades e entidades associativas devem dar origem a tabelas e Uma inst ncia de uma entidade deve ser representada como uma linha da tabela correspondente e Um atributo de uma entidade deve ser tratado como uma coluna da tabela correspondente e Toda tabela tem de ter uma chave prim ria que pode ser um atributo determinante do conjunto de entidades correspondente ou uma nova coluna criada exclusivamente para este fim e Relacionamentos devem ser mapeados atrav s da transposi o da chave prim ria de uma tabela para a outra Ainda que esse mapeamento seja amplamente aplic vel sempre necess rio avaliar requisitos n o funcionais para se chegar ao melhor projeto para uma dada situa o Al m disso os relacionamentos requerem um cuidado maior e por isso s o tratados a seguir com mais detalhes Relacionamentos 1 1 No caso de relacionamentos um para um 1 1 para decidir qual chave transpor deve se considerar alguns aspectos Seja um relacionamento um para um R en
40. dados presente nos DFDs e Descri o da l gica dos processos simples que n o mere am ser decompostos em outros Um DFD mostra as fronteiras do sistema aquilo que n o for uma Entidade Externa ser interno ao sistema delimitando assim a fronteira do sistema Al m disso mostra todas as rela es entre dados armazenados e que fluem no sistema e os processos que manipulam e transformam esses dados encarnando totalmente a filosofia do paradigma estruturado Processos Representam as transforma es e manipula es feitas sobre os dados em um sistema e correspondem a procedimentos ou fun es que um sistema tem de prover A ocorr ncia de um evento de um dos seguintes tipos deve ser representada como um processo em um DFD e transforma es do conte do de um fluxo de dados de entrada no conte do de um fluxo de dados de sa da sem armazenamento interno no sistema Figura 3 23 entrada sa da Figura 3 23 Transforma es de dados e inser es ou modifica es do conte do de dados armazenados a partir do conte do possivelmente transformado de dados de entrada como mostra a Figura 3 24 entrada sa da Figura 3 24 Armazenamento de dados e transforma es de dados previamente armazenados no conte do de um fluxo de dados de sa da como mostra a Figura 3 25 Do entrada sa da Figura 3 25 Gera o de dados de sa da a partir de dados armazenados Um processo representado por um c rculo c
41. de qualidade Mas o que um processo de software Um processo de software pode ser visto como o conjunto de atividades m todos e pr ticas que guiam os profissionais na produ o de software Um processo eficaz deve claramente considerar as rela es entre as atividades os artefatos produzidos no desenvolvimento as ferramentas e os procedimentos necess rios e a habilidade o treinamento e a motiva o do pessoal envolvido De maneira geral os processos de software s o decompostos em processos menores ditos subprocessos tais como processo de desenvolvimento processo de garantia da qualidade processo de ger ncia de projetos etc Esses processos por sua vez s o compostos de atividades que tamb m podem ser decompostas Para cada atividade de um processo importante saber quais as suas subatividades as atividades que devem preced las pr atividades os artefatos de entrada insumos e de sa da produtos os recursos necess rios humanos hardware software etc e os procedimentos m todos t cnicas roteiros modelos de documento etc a serem utilizados na sua realiza o A Figura 1 1 mostra os elementos que comp em um processo de forma esquem tica Processo de Software Processos Atividades Pr atrvidades Subatmidades Artefatos Insumos Produtos Recursos Recursos Humanos Ferramentas de Software Hardware Procedimentos M todos T cnicas Roteiros Figura 1 1 Elementos que comp em um Pr
42. de Fun es Dados Transacionais Determinar o Calcular PFs Fator de N o Ajuste Ajustados Calcular PFs Ajustados Figura 8 2 Passos do M todo de An lise de Pontos de Fun o e Determinar o tipo de contagem de pontos de fun o este o primeiro passo no processo de contagem Existem tr s tipos de contagem contagem de PF de projeto de desenvolvimento de aplica es instaladas e de projetos de manuten o e Identificar o escopo de contagem e a fronteira da aplica o neste passo definem se as funcionalidades que ser o inclu das em uma contagem de PFs espec fica A fronteira da aplica o definida estabelecendo um limite l gico entre a aplica o que est sendo medida os usu rios e outras aplica es O escopo de contagem define a parte do sistema funcionalidades a ser contada Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 107 Determinar a contagem de pontos de fun o n o ajustados os pontos de fun o n o ajustados PFNA refletem as funcionalidades fornecidas pelo sistema para o usu rio Essa contagem leva em conta dois tipos de fun es fun es de dados e fun es transacionais bem como sua complexidade simples m dia ou complexa Contar as fun es de dados as fun es de dados representam as necessidades de dados internos e externos aplica o sendo considerados arquivos l
43. demonstra es para dar feedback Cada demo cont m as fun es at o ltimo sprint 9 4 Apoio Automatizado ao Processo de Software Com o aumento da complexidade dos processos de software passou a ser imprescind vel o uso de ferramentas e ambientes de apoio realiza o de suas atividades visando sobretudo atingir n veis mais altos de qualidade e produtividade Ferramentas CASE Computer Aided Software Engineering passaram ent o a ser utilizadas para apoiar a realiza o de atividades espec ficas tais como planejamento e an lise e especifica o de requisitos Por exemplo para apoiar atividades da ger ncia de projetos h diversas ferramentas dispon veis tais como Microsoft Project ou dotProject sendo esta ltima uma ferramenta livre de c digo aberto Apesar dos benef cios do uso de ferramentas CASE individuais atualmente o n mero e a variedade de ferramentas t m crescido a tal ponto que levou os engenheiros de software a pensarem n o apenas em apoiar seus processos mas sim em trabalhar com diversas ferramentas que interajam entre si e forne am suporte a todo ciclo de vida do desenvolvimento dando origem ao Ambientes de Desenvolvimento de Software ADSs ADSs buscam combinar t cnicas m todos e ferramentas para apoiar o engenheiro de software na constru o de produtos de software abrangendo todas as atividades inerentes ao processo ger ncia desenvolvimento e controle da qualidade Refer ncias d
44. designar tanto relacionamentos entre entidades espec ficas como para referenciar o conjunto de relacionamentos que existe entre conjuntos de entidades Opcionalmente usaremos o termo inst ncia tanto de entidades quanto de relacionamentos para referenciar um elemento do tipo de entidades e de relacionamentos respectivamente Departamento Funcion rio lota lota c d f d e Departamento e fe Funcion rios Figura 3 5 Representa o gr fica para relacionamentos E importante notar que todos os relacionamentos bin rios possuem uma leitura inversa Se um departamento lota funcion rios ent o funcion rios est o lotados em departamentos Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 27 Conforme anteriormente mencionado um conjunto de relacionamentos um subconjunto do produto cartesiano das entidades envolvidas necess rio portanto descrever de forma mais apurada qual esse subconjunto Isto feito via defini o de cardinalidades Uma cardinalidade indica os n meros m nimo cardinalidade m nima e m ximo cardinalidade m xima de associa es poss veis em um relacionamento Seja o seguinte caso Um professor tem que estar lotado em um e somente um departamento enquanto um departamento deve ter no m nimo 13 professores e no m ximo um n mero arbitr rio N Essa restri o imposta pelo mundo real deve
45. diferentes poss vel a partir de uma estimativa de tamanho chegar a estimativas de esfor o e custo Dada a import ncia da estimativa de tamanho nessa abordagem ela geralmente a primeira estimativa a ser realizada 8 5 2 Estimativa de Tamanho Ainda que anteriormente o tamanho tenha sido basicamente utilizado para normalizar indicadores de produtividade custo e qualidade mesmo isoladamente pode ser uma medida importante como por exemplo na contrata o de servi os de desenvolvimento e manuten o de software Dois modelos de contrata o s o bastante difundidos atualmente VAZQUEZ SIM ES ALBERT 2005 pre o global fixo e por pre o unit rio por homem hora No primeiro um pre o total fixo estabelecido por um produto ou servi o bem definido O grande problema desse modelo que normalmente alta a probabilidade de haver um aumento do escopo inicialmente previsto A quest o passa a ser incorporar ou n o novos requisitos ao produto Se a decis o for por incorporar novos requisitos quem vai pagar a conta Afinal aumento do escopo implica em aumento no trabalho a ser realizado Renegociar contratos nem sempre f cil Al m disso as altera es nos requisitos podem ser muitas e s vezes pequenas sendo invi vel a realiza o de tantas renegocia es Se a decis o for por n o incorporar novos requisitos o resultado final pode ser ainda mais desastroso a insatisfa o do cliente No modelo basea
46. disso podem ser aplicados em todas as fases de teste e s o independentes de paradigma pois n o levam em considera o a implementa o O crit rio de particionamento de equival ncia divide o dom nio de entrada de um m dulo em classes de equival ncia a partir das quais casos de teste s o derivados Uma classe de equival ncia representa um conjunto de estados v lidos ou inv lidos das condi es de entrada A meta minimizar o n mero de casos de teste ficando apenas com um caso de teste para cada classe de equival ncia uma vez que em principio todos os elementos de uma mesma classe devem se comportar de maneira equivalente Quando o crit rio de particionamento de equival ncia aplicado inicialmente deve se repartir o dominio de entrada de um m dulo ou programa em classes ou parti es de equival ncia Caso as classes de equival ncia se sobreponham ou os elementos de uma mesma classe n o se comportem da mesma maneira elas devem ser revistas a fim de torn las distintas DELAMARO et al 2007 Uma vez identificadas as classes de equival ncia devem se definir os casos de teste escolhendo um elemento de cada classe Qualquer elemento da classe pode ser considerado um representante desta e portanto basta ter definir um caso de teste por classe de equival ncia DELAMARO et al 2007 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal
47. do Esp rito Santo 78 Seja o caso de uma fun o para calcular o imposto de renda devido de um valor informado cuja interface a seguinte calcularIR valor float float A especifica o desta fun o dada pela Tabela 5 1 levando em conta ainda as seguintes considera es e Entrada v lida Valor monet rio maior ou igual a zero e Sa das poss veis incluindo erros decorrentes de entradas inv lidas o Valor monet rio referente ao imposto de renda devido o Mensagem informando que o valor informado n o um valor monet rio o Mensagem de erro informando que o valor informado menor do que zero Tabela 5 1 Tabela de Imposto de Renda IR OOo Anoa o De 2 563 92 at 3 418 59 320 60 De 3 418 60 at 4 271 59 577 00 Acima de 4 271 59 790 58 Tomando por base a especifica o acima apresentada a Tabela 5 2 apresenta o conjunto de classes de equival ncia correspondentes e a Tabela 5 3 mostra casos de teste representativos de cada uma dessas classes Tabela 5 2 Classes de Equival ncia Entrada Classes de Equival ncia Tipo de Classe de Equival ncia valor valor um valor monet rio entre 0 00 e 1 710 78 V lida valor um valor monet rio entre 1 710 79 e 2 563 91 V lida valor um valor monet rio entre 2 563 92 e 3 418 59 V lida valor um valor monet rio entre 3 418 59 e 4 271 59 V lida valor um valor monet rio maior do que 4 271 59 V lida valor n o
48. do problema e os requisitos podem ser claramente estabelecidos esse modelo indicado uma vez que f cil de ser gerenciado Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 10 2 1 2 O Modelo em V O modelo em V uma varia o do modelo em cascata que procura enfatizar a estreita rela o entre as atividades de teste teste de unidade teste de integra o teste de sistema e teste de aceita o e as demais fases do processo de desenvolvimento PFLEEGER 2004 como mostra a Figura 2 2 presas Testes de Unidade e Integra o Figura 2 2 O Modelo em V O modelo em V sugere que os testes de unidade s o utilizados basicamente para verificar a implementa o e o projeto detalhado Uma vez que os testes de integra o est o focados na integra o das unidades que comp em o software eles tamb m s o usados para avaliar o projeto detalhado Assim testes de unidade e integra o devem garantir que todos os aspectos do projeto do sistema foram implementados corretamente no c digo Quando os testes de integra o atingem o n vel do sistema como um todo teste de sistema o projeto da arquitetura passa a ser o foco Neste momento busca se verificar se o sistema atende aos requisitos definidos na especifica o Finalmente os testes de aceita o conduzidos tipicamente pelos usu rios e cliente
49. em m ltiplos locais al m disso os itens 1 ou 2 caracterizam a aplica o Plano de documenta o e manuten o foram providos e testados para suportar a aplica o em m ltiplos locais al m disso o item 3 caracteriza a aplica o Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 141 14 Facilidade de mudan as focaliza a preocupa o com a influ ncia da manuten o no desenvolvimento do sistema Esta influ ncia deve ser quantificada baseando na observa o de atributos tais como disponibilidade de facilidades como consultas e relat rios flex veis para atender necessidades simples conte como 1 item disponibilidade de facilidades como consultas e relat rios flex veis para atender necessidades de complexidade m dia conte como 2 itens disponibilidade de facilidades como consultas e relat rios flex veis para atender necessidades complexas conte 3 itens se os dados de controle s o armazenados em tabelas que s o mantidas pelo usu rio atrav s de processos on line mas mudan as t m efeitos somente no dia seguinte se os dados de controle s o armazenados em tabelas que s o mantidas pelo usu rio atrav s de processos on line as mudan as t m efeito imediatamente conte como 2 itens Pontua o 0 Nenhum dos itens descritos 1 Um dos itens descritos 2 Dois dos itens descritos 3 Tr s dos itens descritos 4
50. ent o s o v lidas Atributos de relacionamentos s o atributos que n o s o de nenhuma das duas entidades mas sim do relacionamento entre elas e em geral est o relacionados com protocolos e datas ou s o resultantes de avalia es tal como no exemplo da Figura 3 16 Fornecedor Produto raz o cnpj c digo descri o social Figura 3 16 Atributo de relacionamento Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 32 H um teste que pode ser aplicado para se deduzir se um atributo de um dos dois tipos de entidades ou se do relacionamento Seja o exemplo da Figura 3 17 0 N L N fornece Figura 3 17 Relacionamento com atributos 1 Fixa se um produto p ex Impressora XPY e variam se os fornecedores desse produto Evidentemente o valor do atributo pode mudar Por exemplo a Casa do Analista vende a Impressora XPY por R 350 enquanto a loja Compute vende a mesma impressora por R 310 Se o valor do atributo mudar ao variarmos o elemento do outro conjunto de entidades porque este n o atributo do primeiro conjunto de entidades no caso Produto 2 Procedimento an logo deve ser feito agora para a outra entidade Fixando se um fornecedor e variando se os produtos temos A Casa do Analista vende a impressora XPY por R 350 e um notebook AWS por R 1 700 Como o valor do atributo variou p
51. gicos internos e os arquivos de interface externa Ambos s o grupos de dados logicamente relacionados ou informa es de controle que foram identificados pelo usu rio A diferen a est no fato de um Arquivo L gico Interno ALI ser mantido dentro da fronteira da aplica o isto armazenar os dados mantidos atrav s de um ou mais processos elementares da aplica o enquanto um Arquivo de Interface Externa AIE apenas referenciado pela aplica o ou seja ele mantido dentro da fronteira de outra aplica o Assim o objetivo de um AIE armazenar os dados referenciados por um ou mais processos elementares da aplica o sendo contada mas que s o mantidos por outras aplica es Contar as fun es transacionais as fun es transacionais representam as funcionalidades efetivamente fornecidas para o usu rio sendo categorizadas em tr s tipos entradas externas sa das externas e consultas externas As Entradas Externas EEs s o processos elementares que processam dados ou informa es de controle que entram pela fronteira da aplica o O objetivo principal de uma EE manter um ou mais ALIs ou alterar o comportamento do sistema As Sa das Externas SEs s o processos elementares que enviam dados ou informa es de controle para fora da fronteira da aplica o Seu objetivo mostrar informa es recuperadas atrav s de um processamento l gico isto que envolva c lculos ou cria o de dados derivados e n
52. importante real ar a diferen a entre ator e usu rio Um usu rio uma pessoa que utiliza o sistema enquanto um ator representa um papel espec fico que um usu rio pode desempenhar V rios usu rios em uma organiza o podem interagir com o sistema da mesma forma e portanto desempenham o mesmo papel Um ator representa exatamente um certo papel que diversos usu rios podem desempenhar Assim atores podem ser pensados como classes de usu rios isto descri es de um comportamento enquanto usu rios podem desempenhar diversos pap is e assim servir como inst ncias de diferentes classes de atores Ao lidar com atores importante pensar em termos de pap is ao inv s de usu rios Um bom ponto de partida para a identifica o de atores verificar a raz o pela qual o sistema deve ser desenvolvido procurando observar que atores o sistema se prop e a ajudar Quando um ator interage com o sistema normalmente ele realiza uma sequ ncia comportamentalmente relacionada de a es em um di logo com o sistema Tal sequ ncia compreende um caso de uso Um caso de uso de fato uma maneira espec fica de se utilizar o sistema atrav s da execu o de alguma parte de sua funcionalidade Cada caso de uso constitui um curso completo de passos com um ator e especifica a intera o que acontece entre o ator e o sistema O conjunto de todas as descri es de casos de uso especifica todas as maneiras de se usar o sistema e consequentement
53. in cio do projeto elas t m de ser realizadas para produzir uma primeira vis o gerencial sobre o projeto quando s o conjuntamente denominadas de planejamento do projeto medida que o projeto avan a contudo o plano do projeto deve ser revisto uma vez que problemas podem surgir ou porque se ganha um maior entendimento sobre o problema Essas revis es do plano de projeto s o ditas atividades de acompanhamento do projeto e tipicamente s o realizadas nos marcos do projeto Os marcos de um projeto s o estabelecidos durante a defini o do processo e tipicamente correspondem ao t rmino de atividades importantes do processo de desenvolvimento tais como An lise e Especifica o de Requisitos Projeto e Implementa o O prop sito de um marco garantir que os interessados tenham uma vis o do andamento do projeto e concordem com os rumos a serem tomados Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 102 Em uma atividade de acompanhamento do projeto o escopo pode ser revisto altera es no processo podem ser necess rias bem como devem ser monitorados os riscos e revisadas as estimativas de tamanho esfor o dura o e custo Na sequ ncia cada uma das atividades inerentes ao planejamento e acompanhamento de projetos discutida 8 3 Determina o do Escopo do Software A primeira atividade de ger ncia em um pro
54. int i 2 3 long b 1 Ka Ga to 4 if n gt 1 4 6 long temp b q b b a 8 a temp 9 i i 1 10 11 12 return b Figura 5 2 Fun o que retorna o en simo termo da S rie de Fibonacci Dentre os principais crit rios de teste estrutural podem ser citados os crit rios baseados na complexidade e os crit rios baseados no fluxo de controle Os crit rios baseados na complexidade utilizam informa es sobre a complexidade do programa para derivar casos de teste O Crit rio de McCabe ou Teste de Caminho B sico o crit rio baseado em complexidade mais conhecido Caminhos linearmente independentes i e que introduzam pelo menos um novo conjunto de instru es ou uma nova condi o estabelecem um conjunto b sico para o GFC Se os casos de teste puderem ser projetados de modo a for ar a execu o dos caminhos do conjunto b sico ent o cada instru o ter sido executada pelo menos uma vez e cada condi o ter sido executada com V e F O conjunto b sico n o nico De fato diferentes conjuntos b sicos podem ser derivados para um GFC O tamanho do conjunto b sico dado pela medida da complexidade ciclom tica que pode ser calculada dentre outros da seguinte forma n arcos n n s 2 DELAMARO et al 2007 No exemplo do GFC da Figura 5 2 o tamanho do conjunto b sico 3 5 4 2 Ou seja 3 casos de teste s o suficientes para testar os caminhos linearmente independent
55. multivalorado Atributos multivalorados s o representados com um asterisco associado Por exemplo o atributo telefone da entidade Funcion rio multivalorado j que um mesmo funcion rio pode ter mais de um telefone Atributos podem ter um valor vazio associado Isso acontece quando para uma inst ncia n o existe um valor para aquele atributo ou ele ainda n o conhecido P ex o atributo telefone da entidade Funcion rio pode receber um valor vazio j que um funcion rio espec fico pode n o ter nenhum telefone ou em um dado momento ele n o ser conhecido Uma vez que estamos falando de conjuntos de entidades e relacionamentos muitas vezes til apontar que atributos s o capazes de identificar univocamente um elemento de um conjunto O conjunto de um ou mais atributos que identificam uma entidade do conjunto dito ser determinante Atributos determinantes s o sublinhados como forma de destaque A Figura 3 15 mostra uma representa o gr fica para atributos Ainda que essa nota o possa ser empregada de maneira geral atributos s o representados apenas no dicion rio de dados para evitar modelos complexos e de dif cil leitura endere o nome Funcion rio telefone matr cula Figura 3 15 Representa o gr fica para atributos Vale destacar que atributos tamb m s o usados para descrever caracter sticas de relacionamentos atributos de relacionamentos e que todas as considera es feitas at
56. na reorganiza o interna do c digo fonte sem altera o no seu comportamento externo A refatora o permite melhorias no projeto depois que a implementa o j iniciou o Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 125 que importante em XP uma vez que projeto e implementa o ocorrem em paralelo Contudo importante ressaltar que o esfor o necess rio para refatora o cresce medida que o tamanho da aplica o aumenta A implementa o come a com a cria o de testes de unidade para cada hist ria inclu da no incremento A ideia subjacente a esta abordagem que desenvolver com o teste pronto mais f cil como estudar para uma prova j sabendo as quest es Nada extra deve ser desenvolvido S o que est inclu do no teste Assim que o c digo produzido os testes podem ser efetuados em seguida feedback instant neo Outro conceito chave em XP a programa o em pares duas pessoas trabalham juntas na mesma m quina durante a implementa o Com isso tem se um mecanismo de resolu o de problemas em tempo real duas cabe as pensam melhor do que uma e garantia da qualidade A inten o manter os programadores focados na tarefa sendo que cada programador assume um papel ligeiramente diferente A integra o feita pelos programadores pares ou por uma equipe de integra o diariam
57. necessidades do projeto Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 100 A decomposi o do processo de software em subprocessos e a decomposi o destes em diferentes n veis de atividade a base para a defini o do processo 8 1 4 Estrutura Anal tica do Projeto Uma boa ger ncia de projetos precisa fundir as vis es de produto e processo Cada fun o ou m dulo a ser desenvolvido pela equipe do projeto deve passar pelas v rias atividades definidas no processo de software Essa pode ser uma base bastante efetiva para a elabora o de estimativas incluindo a aloca o de recursos j que sempre mais f cil estimar por es menores de trabalho Assim til elaborar uma Estrutura Anal tica do Projeto EAP Work Breakdown Structure WBS considerando essa duas dimens es produto e processo como ilustra a Tabela 8 1 Tabela 8 1 Estrutura de Divis o do Trabalho considerando a fus o das vis es de produto e processo Atividades do processo M dulos An lise e Projeto Implementa o Testes Fun es Especifica o de Requisitos M dulo 1 M dulo 2 Uma EAP fornece um esquema para identifica o e organiza o das unidades l gicas de trabalho a serem gerenciadas que s o chamadas de pacotes de trabalho work packages 8 2 O Processo de Ger ncia d
58. normalmente s o realizadas ao longo de todo o ciclo de vida sempre que necess rio ou em pontos pr estabelecidos durante o planejamento ditos marcos ou pontos de controle A Figura 1 2 mostra a rela o entre os v rios tipos de processos Processo de Ger ncia de Projetos E g Processo de Desenvolvimento de Software Produto de Software Pot T T if Processos de Apoio Figura 1 2 Decomposi o do Processo de Software 1 3 A Organiza o deste Texto Neste texto procura se oferecer uma vis o geral da Engenharia de Software discutindo seus principais processos e atividades e como realiz los Este texto est dividido em tr s partes na Parte I s o abordados os processos de desenvolvimento e manuten o de software na Parte II s o abordados o processo de ger ncia de projetos e os processos de apoio Essas partes est o organizadas nos seguintes cap tulos PARTE I Desenvolvimento e Manuten o de Software e Cap tulo 2 Vis o Geral do Processo de Desenvolvimento procura dar uma vis o geral das atividades que comp em o processo de desenvolvimento de software bem como apresenta os principais modelos de ciclo de vida que organizam essas atividades e Cap tulo 3 Requisitos de Software aborda requisitos e tipos de requisitos e procura dar uma vis o geral da Engenharia de Requisitos discutindo alguns dos Engenharia de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo
59. objetivos da APF s o e Medir as funcionalidades do sistema requisitadas e recebidas pelo usu rio e Medir projetos de desenvolvimento e manuten o de software sem se preocupar com a tecnologia que ser utilizada na implementa o O processo para contagem de PFs compreende sete passos mostrados na figura A 1 Determinar o Tipo de Contagem Identificar o Escopo de Contagem e Fronteira da Aplica o Contar as Contar as Fun es de Fun es Dados Transacionais Determinar o Determinar Fator de os PFs N o Ajuste Ajustados Calcular os PFs Ajustados Figura A 1 O Processo de Contagem de Pontos de Fun o Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 129 e Determinar o tipo de contagem de pontos de fun o este o primeiro passo no processo de contagem sendo que existem tr s tipos de contagem contagem de PF de projeto de desenvolvimento de aplica es instaladas e de projetos de manuten o e Identificar o escopo de contagem e a fronteira da aplica o neste passo definem se as funcionalidades que ser o inclu das em uma contagem de PFs espec fica A fronteira da aplica o definida estabelecendo um limite l gico entre a aplica o que est sendo medida o usu rio e outras aplica es O escopo de contagem define a parte do sistema funcionalidades a ser contada e Determinar a contagem de pon
60. os testes Logo em geral teste exaustivo n o vi vel e por conseguinte testes podem mostrar apenas a presen a de defeitos mas n o a aus ncia deles Para se testar um programa P devem ser selecionados alguns pontos espec ficos de D P para executar DELAMARO et al 2007 Um aspecto crucial para o sucesso na atividade de teste a escolha correta dos casos de teste Um teste bem sucedido identifica defeitos que ainda n o foram detectados Um bom caso de teste aquele que tem alta probabilidade de encontrar um defeito ainda n o descoberto A escolha de casos de teste passa pela identifica o de subdom nios de teste Um subdom nio de teste um subconjunto de D P que cont m dados de teste semelhantes ou seja que se comportam do mesmo modo por isso basta executar P com apenas um deles Fazendo se isso com todos os subdom nios de D P consegue se um conjunto de teste T bastante reduzido em rela o a D P mas que de certa maneira representa cada um de seus elementos DELAMARO et al 2007 Existem duas maneiras de se selecionar elementos de cada um dos subdom nios de teste DELAMARO et al 2007 e Teste Aleat rio um grande n mero de casos de teste selecionado aleatoriamente de modo que probabilisticamente se tenha uma boa chance de ter todos os subdom nios representados em T e Teste de Subdom nios ou Teste de Parti o procura se estabelecer quais s o os subdom nios a serem utilizados e ent o s
61. planejamento e projeto de casos de teste e os desenvolvedores s o respons veis pela constru o e execu o dos casos de teste e O que testar Que partes do sistema devem ser mais cuidadosamente testadas Esta resposta obtida definindo se os requisitos de teste O Princ pio de Pareto adaptado ao teste aponta que 20 dos componentes de software concentram 80 dos defeitos Esse princ pio sugere que os esfor os devem ser concentrados nas partes mais importantes e ou fr geis Um bom teste ao mesmo tempo econ mico e encontra o m ximo de defeitos XOSCIANSKI SOARES 2006 Por exemplo ser que necess rio testar todas as unidades inclusive unidades reutilizadas de outros projetos McGregor e Sykes 2001 sugerem que pode n o ser necess rio testar unidades reutilizadas de outros projetos ou de bibliotecas Al m disso algumas unidades n o s o f ceis de serem testadas individualmente requerendo drivers e ou stubs complexos Assim esses autores sugerem concentrar esfor os em usos prov veis e Quanto teste necess rio Conforme discutido anteriormente imposs vel testar tudo Testes podem somente mostrar a presen a de erros mas n o a sua aus ncia Assim o importante ter uma boa cobertura nos testes A cobertura de teste pode ser medida dentre outras de duas maneiras MCGREGOR SYKES 2001 1 Em rela o a requisitos quanto dos requisitos especificados foi testado Considerar requisitos funcionais e n o f
62. prim ria de uma tabela transposta como uma coluna na outra tabela onde considerada uma chave estrangeira A Figura 4 3 ilustra um relacionamento 1 N entre as entidades Departamento e Funcion rio indicando que um departamento pode lotar v rios funcion rios enquanto um funcion rio tem de estar lotado em um departamento Essa figura mostra ainda o mapeamento para as correspondentes tabelas indicando a chave transposta 1 1 0 N lota Departamento Funcion rio Cod Depto 0158 5295 1712 Chave Estrangeira Figura 4 3 Exemplo de liga o entre tabelas por meio de chave estrangeira e Tabelas Associativas usadas para representar relacionamentos muitos para muitos Seja o exemplo da Figura 4 4 no qual uma pessoa pode ter interesse em v rios assuntos enquanto um assunto pode ser de interesse de v rias pessoas A tabela Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 53 Interesse uma tabela associativa sendo suas duas colunas chaves transpostas de outras tabelas 0 N 0 N tem interesse em Pessoa Interesse Assunto CPF Pessoa C digo Assunto 96100199 Jos 96100199 COMP 83467187 Maria 96100199 02765140 02765140 MUS COMP Computa o ENG MUS M sica Figura 4 4 Exemplo de Tabela Associativa O modelo relacional tem diversas propriedades que precisam ser
63. process areas PAs As caracter sticas de cada n vel s o apresentadas a seguir N vel 1 Inicial O processo de software caracterizado como ad hoc e eventualmente ca tico Poucos processos s o definidos e o sucesso depende de esfor os individuais Neste n vel a organiza o tipicamente opera sem formalizar procedimentos sem realizar estimativas de custo e sem ter planos de projeto Ferramentas n o s o bem integradas ao processo ou n o s o uniformemente aplicadas O controle de altera es superficial e h pouco entendimento sobre os problemas N vel 2 Gerenciado Os processos b sicos de ger ncia s o estabelecidos para acompanhar custo cronograma e funcionalidade Os sucessos em projetos anteriores com aplica es similares podem ser repetidos N vel 3 Definido A organiza o possui um processo padr o definido que usado como base para todos os projetos As atividades de engenharia e ger ncia de software s o est veis e h um entendimento comum e amplo das atividades pap is e responsabilidades no processo N vel 4 Gerenciado Quantitativamente A organiza o fixa metas quantitativas de qualidade para produtos e processos e fornece instrumentos para medi es consistentes e bem definidas Tanto o processo de software como os produtos s o quantitativamente entendidos e controlados poss vel que a organiza o preveja tend ncias na qualidade do processo e dos produtos dentro de front
64. produtos espec ficos Tais modelos s o t picos da fase de projeto Modelo f sico leva em considera o caracter sticas dependentes de uma plataforma computacional espec fica isto uma linguagem e um compilador espec ficos um sistema gerenciador de bancos de dados espec fico o hardware de um determinado fabricante etc Tais modelos podem ser constru dos tanto na fase de projeto detalhado quanto na fase de implementa o Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 24 Conforme apontado anteriormente nas primeiras etapas do processo de desenvolvimento levantamento de requisitos e an lise o engenheiro de software representa o sistema atrav s de modelos conceituais Em etapas posteriores projeto e implementa o as caracter sticas l gicas e f sicas s o representadas em outros modelos Para a realiza o da atividade de an lise uma escolha deve ser feita o paradigma de desenvolvimento Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e portanto definem as caracter sticas b sicas dos modelos a serem constru dos Por exemplo o paradigma orientado a objetos parte do pressuposto que o mundo povoado por objetos ou seja a abstra o b sica para se representar as coisas do mundo s o os objetos os quais s o classificados em classes J o paradigma estruturado adota uma vis o de desenvol
65. representados por tabelas de valores Cada tabela denominada rela o bidimensional sendo organizada em linhas e colunas Esse modelo est fortemente baseado na teoria matem tica sobre rela es da o nome relacional Os principais conceitos do modelo relacional s o os seguintes Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 52 e Tabela tabela de valores bidimensional organizada em linhas e colunas A Figura 4 2 mostra um exemplo de uma tabela Funcion rio derivada de uma entidade Funcion rio que tem como atributos matr cula nome CPF e data de nascimento 0111 17345687691 11 04 66 0208 56935101129 21 02 64 0789 81176628911 01 11 70 1589 91125769120 20 10 80 Figura 4 2 Tabela Funcion rio e Linha representa uma entidade de um conjunto de entidades Ex A funcion ria M nica do conjunto de funcion rios e Coluna representa um atributo de uma entidade Ex Matr cula Nome CPF Dt Nasc e C lula Item de dado da linha i coluna j Ex Rita linha 2 coluna 2 e Chave Prim ria coluna ou combina o de colunas que possui a propriedade de identificar de forma nica uma linha da tabela e que utilizada para estabelecer associa es entre entidades via transposi o de chave Ex Matr cula CPF e Chave Estrangeira ou Transposta a forma utilizada para associar linhas de tabelas distintas A chave
66. respeitadas a saber Cada tabela possui um nome o qual deve ser distinto do nome de qualquer outra tabela da base de dados Nenhum campo parte de uma chave prim ria pode ser nulo Cada c lula de uma rela o pode ser vazia exceto os campos de chaves prim rias ou ao contr rio pode conter no m ximo um nico valor N o h duas linhas iguais A ordem das linhas irrelevante Cada coluna tem um nome o qual deve ser distinto dos demais nomes das colunas de uma mesma tabela Usando se os nomes para se fazer refer ncia s colunas a ordem destas torna se irrelevante Um campo que seja chave estrangeira s pode assumir valor nulo ou um valor para o qual exista um registro na tabela onde ele chave prim ria Muitas vezes durante o projeto de bancos de dados relacionais til representar graficamente as tabelas e as liga es entre elas Para tal um Diagrama Relacional pode ser desenvolvido representando as liga es entre tabelas de um modelo relacional A Figura 4 5 mostra um exemplo de um fragmento de um diagrama relacional e suas tabelas correspondentes Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 54 Diagrama Relacional HDep FunChefe Fun Departamento HO Funcion rio Tabelas do Modelo Relacional Departamentos C digo Matr cula Chefe Funcion rios 13888 00877 06001 00877 MAT 06001 QUI
67. rito Santo 70 Cap tulo 5 Implementa o e Teste de Software Uma vez projetado o sistema necess rio escrever os programas que implementem esse projeto e test los Os testes devem ser feitos em diversos n veis come ando pelos m dulos isolados teste de unidade passando a integr los teste de integra o at atingir os testes do sistema como um todo teste de sistema Diversas t cnicas podem ser empregadas para este fim De fato dada sua import ncia testes n o devem ser tratados apenas como uma atividade no ciclo de vida de software mas sim como um processo O processo de teste deve ocorrer em paralelo com outras atividades do processo de desenvolvimento de software an lise de requisitos projeto de software e implementa o e envolve tamb m atividades de planejamento Este cap tulo aborda brevemente na Se o 5 1 a atividade de implementa o A Se o 5 2 discute princ pios gerais de teste de software A Se o 5 3 trata de n veis de teste enquanto a Se o 5 4 trata de t cnicas de teste Por fim a Se o 5 5 aborda o processo de teste 5 1 Implementa o Ainda que um projeto bem elaborado facilite sobremaneira a implementa o essa tarefa n o necessariamente f cil Muitas vezes os projetistas n o conhecem em detalhes a plataforma de implementa o e portanto n o s o capazes de ou n o desejam chegar a um projeto algor tmico pass vel de implementa o direta Al m disso
68. s o muito importantes N o poss vel controlar o que n o se pode medir e principalmente s poss vel chegar a boas estimativas com base em dados hist ricos se dados forem coletados criteriosamente Assim as medidas d o visibilidade ao estado do projeto permitindo tanto saber para onde ir no in cio do projeto quanto verificar se o rumo est correto tomando a es corretivas quando necess rio VAZQUEZ SIM ES ALBERT 2005 Mas n o basta coletar dados aleatoriamente Conforme discutido no Cap tulo 7 para que possam ser usados eficientemente dados t m de ser arranjados de modo a prover indicadores Por exemplo o que se pode dizer a respeito da qualidade de um produto de software que tenha apresentado cinco defeitos depois de implantado boa N o Isoladamente esse dado pouco diz Neste caso combinar dados em medidas obtendo medidas derivadas uma boa op o No exemplo anterior se combin ssemos a medida de n mero de defeitos com uma medida de tamanho tal como linhas de c digo LOC ter amos a medida derivada n mero de defeitos por linha de c digo capaz de nos dizer bem mais do que os dados isolados Se agora os cinco defeitos medidos fossem em um software de 10 000 linha de c digo chegar se ia ao valor de 0 5 defeito KLOC A partir dessa medida comparando a com indicadores da organiza o a sim poder se ia chegar a alguma conclus o sobre a qualidade do produto Em uma abordagem desta nature
69. s o uma importante base para a defini o dos processos padr o das organiza es Assim usando essas normas e modelos de qualidade em uma abordagem de defini o de processos em n veis poss vel definir processos para projetos espec ficos que levem em considera o as particularidades de cada projeto sem no entanto desconsiderar aspectos importantes para se atingir a qualidade do processo Normas e Modelos de Cultura Organizacional Processo Padr o pode Sonae ESSO Dom nio do Problema Especializa o Paradigma e Tecnologia de Desenvolvimento Processo Especializado 1 Processo Especializado n Instanciac o Processo de Projeto 1 Processo de Projeto m Figura 9 3 Modelo para Defini o de Processos em N veis Particularidades do Projeto Modelo de Ciclo de Vida ou Modelo de Processo Sob o ponto de vista do conhecimento do processo essencial que os processos padr o da organiza o ou especializados estejam internalizados nas pessoas ou seja os desenvolvedores devem execut los naturalmente Al m disso o processo padr o organizacional deve estar institucionalizado isto toda a organiza o deve execut lo Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 123 9 3 Processos geis Um dos principais desafios no desenvolvimento de software lidar com mudan as Divers
70. ser entregue com anteced ncia para que cada membro da equipe de revis o possa avali lo Uma vez que todos estejam preparados uma reuni o convocada pelo l der Essa reuni o dever ser relativamente breve duas horas no m ximo uma vez que todos j est o preparados para a mesma Durante a reuni o o l der orientar o processo de revis o passando por todos os aspectos relevantes a serem revistos Todas as considera es dos demais membros da equipe de revis o devem ser discutidas e as decis es registradas dando origem a uma ata de reuni o de revis o contendo uma lista de defeitos encontrados Os artefatos que comp em a documenta o do projeto s o as entradas insumos para as atividades de garantia da qualidade quando os mesmos s o verificados quanto consist ncia e ader ncia em rela o aos padr es de documenta o da organiza o e validados em rela o aos seus prop sitos e aos requisitos que se prop em a atender Assim o resultado das atividades de garantia da qualidade fortemente dependente da documenta o produzida 7 3 Ger ncia de Configura o de Software Durante o processo de desenvolvimento de software v rios artefatos s o produzidos e alterados constantemente evoluindo at que seus prop sitos fundamentais sejam atendidos Ferramentas de software tais como compiladores e editores de texto tamb m podem ser substitu dos por vers es mais recentes ou mesmo por outras ferramentas P
71. t cnicas como a Modelagem de Entidades e Relacionamentos CHEN 1990 e a Modelagem de Estados foram incorporadas an lise estruturada dando origem An lise Estruturada Moderna YOURDON 1990 Por fim a An lise Essencial de Sistemas MCMENAMIN PALMER 1991 uma evolu o da An lise Estruturada Moderna que passou a endere ar algumas das principais dificuldades que os analistas enfrentavam com a aplica o da An lise Estruturada Moderna a dificuldade de capturar requisitos nos est gios iniciais do desenvolvimento a capacidade de distinguir entre requisitos verdadeiros e falsos e uma abordagem mais eficiente para dividir o sistema em partes independentes de modo a facilitar o processo de an lise O m todo da An lise Essencial de Sistemas preconiza que de uma forma geral um sistema deve ser modelado atrav s de tr s dimens es POMPILHO 1995 e dados diz respeito aos aspectos est ticos e estruturais do sistema e controle leva em conta aspectos temporais e comportamentais do sistema Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 25 e fun es considera a transforma o de valores Durante muito tempo no paradigma estruturado houve grandes debates entre os profissionais de desenvolvimento de sistemas sobre por qual perspectiva se deveria come ar a especifica o de um sistema pelos dados ou pelas fu
72. tampouco seus procedimentos internos para podermos utiliz la Sistemas compostos por caixas pretas s o facilmente constru dos testados corrigidos entendidos e modificados Desse modo o primeiro passo no controle da complexidade no projeto estruturado consiste em dividir um sistema em m dulos de modo a atingir as seguintes metas cada m dulo deve resolver uma parte bem definida do problema a fun o de cada m dulo deve ser facilmente compreendida conex es entre m dulos devem refletir apenas conex es entre partes do problema as conex es devem ser t o simples e independentes quanto poss vel Os m dulos devem ser dispostos em uma hierarquia de modo a por um lado n o provocar sobrecarga de processamento e de outro n o criar m dulos apenas intermedi rios sem desempenhar nenhuma fun o H v rios tipos de diagramas hier rquicos para o projeto de programas MARTIN MCCLURE 1991 Neste texto ser o explorados dois deles o Diagrama Hier rquico de Fun es DHF usado principalmente para o projeto arquitetural e o Diagrama de Estrutura Modular DEM usado para o projeto detalhado de m dulos A diferen a b sica entre eles que o DHF n o representa o fluxo de dados e controles entre m dulos nem aspectos relacionados com detalhes l gicos de um m dulo tais como estruturas de repeti o la os e condi es Essas informa es s o capturadas em um DEM e por isso mesmo o DEM empregado
73. um processo de melhoria da qualidade PRESSMAN 2011 Refer ncias do Cap tulo MALDONADO J C FABBRI S C P F Verifica o e Valida o de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 SANCHES R Documenta o de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001a SANCHES R Ger ncia de Configura o de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001b Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 98 Cap tulo 8 Ger ncia de Projetos Antes de contratar o desenvolvimento de um software geralmente um cliente quer saber se seu fornecedor capaz de realizar esse trabalho quanto o projeto custar e qual ser a sua dura o Para responder a essas perguntas necess rio definir o escopo do projeto atrav s de um levantamento preliminar de requisitos realizar estimativas levantar riscos alocar recursos e definir cronograma de execu o e or amento Todas essas informa es s o registradas em um documento chamado Plano de Projeto que deve ser sistematicamente revisado ao l
74. um valor monet rio Inv lida valor um valor monet rio menor do que 0 Inv lida Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 79 Tabela 5 3 Casos de Teste Entrada Sa da Esperada 1 320 50 0 00 2 000 00 21 69 3 410 00 190 90 3 912 55 303 32 8 475 29 1 540 12 2 000 00 Erro valor deve ser maior ou igual a 0 Axt89 Erro Entre com um valor monet rio O crit rio de particionamento de equival ncia possibilita uma boa redu o do tamanho do dom nio de entrada sendo especialmente adequado para aplica es em que as vari veis de entrada podem ser facilmente identificadas e assumem valores espec ficos Contudo n o t o facilmente aplic vel mesmo quando o dom nio de entrada simples se o processamento do m dulo for complexo Nestes casos a especifica o pode sugerir que um grupo de dados seja processado de forma id ntica mas isso pode n o ocorrer na pr tica DELAMARO et al 2007 A pr tica mostra que um grande n mero de erros tende a ocorrer nas fronteiras do dom nio de entrada de um m dulo Tendo isso em mente o crit rio de an lise de valor limite tem por premissa que casos de teste que exploram condi es limites t m maior probabilidade de encontrar defeitos Tais condi es est o exatamente sobre ou imediatamente acima ou abaixo dos limitante
75. 006 Nenhum sistema computacional existe isoladamente Todo sistema interage com atores humanos ou outros sistemas que utilizam esse sistema para algum prop sito e esperam que o sistema se comporte de acordo com as maneiras previstas Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e uma descri o de um conjunto de sequ ncias de a es realizadas pelo sistema para produzir um resultado de valor observ vel por um ator BOOCH RUMBAUGH JACOBSON 2006 Em ess ncia um caso de uso uma intera o t pica entre um ator usu rio humano outro sistema computacional ou um dispositivo e um sistema que captura alguma fun o vis vel ao ator e em especial busca atingir uma meta do cliente Um ator modela qualquer coisa que precise interagir com o sistema tais como usu rios e outros sistemas que se comunicam com o sistema em quest o Atores s o externos ao sistema os casos de uso comportam os elementos de modelo que residem dentro do sistema Assim ao se definir fronteiras entre atores e casos de uso est se delimitando o escopo do sistema Por estarem fora do sistema atores est o fora do controle do sistema e n o precisam ser descritos em detalhes Atores representam tudo que tem necessidade de trocar informa o com o sistema Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 46
76. 13888 Figura 4 5 Exemplo de Diagrama Relacional e as respectivas tabelas Nesse exemplo a coluna Matr cula foi considerada a chave prim ria da tabela Funcion rio e foi transposta para a tabela Departamento O contr rio tamb m poderia ser feito isto transpor a chave prim ria de Departamento para Funcion rio A primeira op o mais indicada porque h poucos funcion rios que s o chefes enquanto todos os departamentos t m chefes Assim a coluna Matr cula Chefe n o ter valores vazios e portanto ela mais densa do que seria a coluna resultante da transposi o da chave prim ria de Departamento para a tabela Funcion rio Em um Diagrama Relacional s o representados os seguintes elementos e Tabelas s o representadas por ret ngulos com uma refer ncia chave prim ria em cima da tabela Fun Funcion rio Figura 4 6 Nota o para Tabelas em um Diagrama Relacional e Relacionamentos s o representadas por linhas cont nuas associadas aos s mbolos abaixo Cardinalidade Relacionamento 0 1 o 1 1 0 N 0 L N K Figura 4 7 Nota o para Relacionamentos em um Diagrama Relacional Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 55 e Chaves estrangeiras quando uma chave transposta n o fizer parte da chave prim ria da rela o destino a mesma representada em cima do ret ngulo
77. 3 N veis de Teste Conforme apontado anteriormente o teste de software envolve v rios est gios ou n veis Basicamente h tr s grandes fases de teste MALDONADO FABBRI 2001 DELAMARO et al 2007 e Teste de Unidade tem por objetivo testar a menor unidade do projeto procurando identificar erros de l gica e de implementa o em cada m dulo separadamente No paradigma estruturado procedimentos e fun es s o exemplos de unidades e Teste de Integra o visa a descobrir erros associados s interfaces dos m dulos quando esses s o integrados para formar a estrutura do produto de software e Teste de Sistema tem por objetivo identificar erros de fun es requisitos funcionais e outras caracter sticas requisitos n o funcional que n o estejam de acordo com as especifica es Tomando por base essas fases o processo de teste pode ser estruturado de modo que em cada fase diferentes tipos de erros e aspectos do software sejam considerados MALDONADO FABBRI 2001 Tipicamente os primeiros testes focalizam componentes individuais Os testes de unidade podem ser realizados medida que ocorre a implementa o das unidades e podem ser realizados pelos pr prios desenvolvedores DELAMARO et al 2007 Ap s os componentes individuais terem sido testados eles precisam ser integrados at se obter o sistema por inteiro Na integra o o foco o projeto e a arquitetura do sistema Finalmente uma s rie de testes de
78. 6 A ISO 9001 de car ter geral ou seja n o se destina especificamente ind stria de software e estabelece requisitos m nimos da garantia da qualidade que devem ser atendidos pelos fornecedores de produtos ou servi os Ela uma norma certificadora Essa certifica o mundialmente reconhecida feita por organismos certificadores em geral credenciados por organismos nacionais de acredita o no caso do Brasil o INMETRO Assim a conquista da certifica o ISO 9001 por uma empresa significa que a mesma alcan ou um padr o internacional de qualidade em seus processos ROCHA MALDONADO WEBER 2001 O principal problema para se adotar essa norma precisamente o fato dela ser geral Assim quando aplicada ao contexto da ind stria de software muitos problemas surgem pela falta de diretrizes mais focadas nas caracter sticas de processos de software Assim de maneira geral outras normas e modelos de qualidade s o usadas por organiza es de software para apoiar uma certifica o ISO 9001 com destaque para a norma ISO IEC 12207 A norma ISO IEC 12207 Systems and software engineering Software life cycle processes Engenharia de Software e de Sistemas Processos de Ciclo de Vida de Software ISO IEC 2008 estabelece uma estrutura comum para os processos de ciclo de vida de software com terminologia bem definida que pode ser referenciada pela ind stria de software A estrutura cont m processos atividades e tarefas que
79. 96 avalia o No entanto poss vel perceber tamb m aspectos comuns dentre eles a forte rela o com a medi o Inicialmente necess rio definir as entidades que ser o avaliadas e quais de suas caracter sticas ser o usadas na avalia o Segundo preciso definir quais medidas ser o usadas para quantificar essas caracter sticas Uma vez planejada a medi o pode se passar efetivamente sua execu o o que envolve a aplica o de procedimentos de medi o para se obter um valor para uma medida da entidade em quest o Uma vez realizada a medi o devem se analisar seus resultados para avaliar as entidades gerando observa es tais como problemas e n o conformidades detectados Essas observa es devem dar origem a a es para tratar os problemas detectados Uma medida fornece uma indica o quantitativa da extens o quantidade dimens o capacidade ou tamanho de um atributo de um produto ou de um processo Uma medida dita uma medida base quando ela funcionalmente independente de outras medidas p ex quantidade de erros descobertos em uma revis o Uma medida dita uma medida derivada quando ela definida como uma fun o de duas ou mais medidas p ex n mero de erros encontrados por linha de c digo Medidas derivadas procuram relacionar medidas base com o objetivo de se prover uma ideia da efic cia do processo projeto ou produto sendo medido Diz que uma medida um indicador quando ela us
80. 980 sua concep o foi formalizada em 1999 com o livro Extreme Programming Explained Embrace Change de Kent Beck O processo de software preconizado pelo XP possui quatro atividades principais PRESSMAN 2011 planejamento design implementa o e testes Estas atividades s o organizadas de maneira incremental em diversos ciclos sendo que a cada ciclo uma vers o operacional ou incremento produzida e entregue ao cliente No planejamento hist rias de usu rio user stories s o escritas e priorizadas atribui o de valor pelo cliente e membros da equipe estimam uma dura o em semanas de desenvolvimento para cada uma delas Se a dura o de uma hist ria for maior do que 3 semanas pedido ao cliente que divida a hist ria Clientes e desenvolvedores decidem juntos quais hist rias entrar o na pr xima vers o do sistema No lan amento da primeira vers o a velocidade do projeto quantidade de hist rias implementadas calculada A velocidade do projeto usada para estimar datas de entrega futuras medida que o trabalho progride o cliente pode adicionar alterar excluir ou dividir hist rias O time XP aceita as mudan as e se replaneja Na fase de projeto design parte se do princ pio que um modelo simples sempre prefer vel a um modelo complexo e que n o se deve projetar funcionalidade extra assumindo que ela ser necess ria no futuro XP recomenda o uso de refatora o refactoring que consiste
81. Dep sitos de Dados Dep sitos de dados s o pontos de reten o permanente ou tempor ria de dados que permitem a integra o entre processos ass ncronos isto processos realizados em tempos distintos Representam um local de armazenamento de dados entre processos Um dep sito de dados representado por um ret ngulo sem a linha lateral direita com um nome e um identificador opcional em seu interior s vezes para evitar o cruzamento de linhas de fluxos de dados ou para impedir que longas linhas de fluxos de dados saiam de um lado para outro do diagrama um mesmo dep sito de dados pode ser representado mais de uma vez no diagrama Nessa situa o adicionamos uma linha vertical na lateral esquerda do ret ngulo como mostra a Figura 3 28 clientes DI clientes Figura 3 28 Nota o para dep sitos de dados Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 40 Um dep sito de dados n o se altera quando um pacote de informa o sai dele atrav s de um fluxo de dados Por outro lado um fluxo para um dep sito representa uma das seguintes a es e uma inclus o isto um ou mais novos pacotes de informa o est o sendo introduzidos no dep sito e uma atualiza o ou seja um ou mais pacotes est o sendo modificados sendo que isso pode envolver a altera o de todo um pacote ou apenas de parte dele e um
82. Em sistemas maiores o uso da fiss o pode se tornar invi vel sendo recomendado ent o o uso da explos o Recomenda es para a Constru o de DFDs 1 Escolha nomes significativos para todos os elementos de um DFD Utilize termos empregados pelos usu rios no dom nio da aplica o 2 Evite desenhar DFDs complexos Cuidado com os processos sem fluxos de dados de entrada ou de sa da 4 Cuidado com os dep sitos de dados que s possuem fluxos de dados de entrada ou de sa da 5 Dep sitos de dados permanentes devem manter estreita rela o com os conjuntos de entidades e de relacionamentos do modelo ER 6 Fique atento ao princ pio de conserva o de dados isto dados que saem de um dep sito devem ter sido previamente l colocados e dados produzidos por um processo t m de ser pass veis de serem gerados por esse processo Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 43 7 Quando do uso de explos o os fluxos de dados que entram e saem em um diagrama de n vel superior devem entrar e sair no n vel inferior que o detalha 8 N o represente no DFD fluxos de controle ou de material Como o nome indica DFDs representam fluxos de dados 9 S especifique a l gica de processos primitivos ou seja aqueles que n o s o detalhados em outros diagramas 3 7 3 T cnicas de Especifica o de Processos Quand
83. F As funcionalidades controladas por esse execut vel devem ser tratadas como m dulos filhos do m dulo inicial do diagrama Fun es menores que comp em uma macro fun o podem ser representadas como m dulos filhos do m dulo correspondente Para sistemas de m dio a grande porte contudo representar todas as funcionalidades em um nico diagrama pode torn lo muito complexo Assim novos DHFs podem ser elaborados para agrupar certas funcionalidades Tomemos como exemplo um sistema de entrega em domic lio de lanches cujo escopo o seguinte e Subsistema Controle de Card pio envolvendo macro fun es para Cadastrar Lanches e Bebidas Cada uma dessas macro fun es teria fun es para incluir excluir alterar e consultar esses diferentes tipos de itens de card pio e Subsistema Atendimento a Clientes envolvendo macro fun es para Cadastrar Cliente Controlar Pedido e Consultar Card pio Assim como os demais cadastros o cadastro de clientes teria fun es para incluir um novo cliente alterar dados de cliente consultar e excluir clientes J o controle de pedidos envolveria fun es para efetuar um novo pedido alterar dados de pedido cancelar pedido definir entregador e registrar atendimento de pedido Por fim a consulta ao card pio teria fun es para consultar lanches e bebidas Com base nesse escopo e considerando que cada subsistema deve ser implementado como uma aplica o execut vel poder amos construir o DH
84. F mostrado na Figura 4 19 Nesse diagrama optou se por n o representar os m dulos filhos do m dulo Controlar Pedido uma vez que ele bastante complexo com v rios sub m dulos o que traria uma complexidade indesejada para o DHF Assim al m do diagrama da Figura 4 19 um outro cujo m dulo inicial seria Controlar Pedido deveria ser elaborado Vale ressaltar que um DHF pode ser usado como um guia para o projeto das interfaces com o usu rio apoiando a defini o de janelas estruturas de menu etc Assim o projeto de IU deve ocorrer em paralelo com o projeto modular de programas Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 64 Aplica o Atendimento a Cliente Controlar Pedido Cadastrar Cliente Incluir Novo Alterar Dados Consultar Excluir Cliente Cliente Cliente Cliente Consultar Card pio Consultar Consultar Lanches Bebidas Figura 4 19 Exemplo de DHF 4 3 2 Diagrama de Estrutura Modular Em um Diagrama de Estrutura Modular DEM um programa representado como um conjunto de m dulos organizados hierarquicamente de modo que os m dulos que executam tarefas de alto n vel no programa s o colocados nos n veis superiores da hierarquia enquanto os m dulos que executam tarefas detalhadas de n vel mais baixo aparecem nos n veis inferiores Observando a hierarquia os m dulos a cada n vel sucessivo cont m taref
85. Quatro dos itens descritos 5 Todos os cinco itens descritos Refer ncia R Dias An lise por Pontos de Fun o Uma T cnica para Dimensionamento de Sistemas de Informa o on line Disponivel em www presidentekennedy br resi edicao03 artigo02 pdf Ultimo acesso 13 05 2004
86. SSMAN 2011 e Projetos reais muitas vezes n o seguem o fluxo sequencial que o modelo prop e e Os requisitos devem ser estabelecidos de maneira completa correta e clara logo no in cio de um projeto A aplica o deve portanto ser entendida pelo desenvolvedor desde o in cio do projeto Entretanto frequentemente dif cil para o usu rio colocar todos os requisitos explicitamente O modelo em cascata requer isto e tem dificuldade de acomodar a incerteza natural que existe no in cio de muitos projetos e O usu rio precisa ser paciente Uma vers o operacional do software n o estar dispon vel at o final do projeto e A introdu o de certos membros da equipe tais como projetistas e programadores frequentemente adiada desnecessariamente A natureza linear do ciclo de vida cl ssico leva a estados de bloqueio nos quais alguns membros da equipe do projeto precisam esperar que outros membros da equipe completem tarefas dependentes Cada um desses problemas real Entretanto o modelo de ciclo de vida cl ssico tem um lugar definitivo e importante na Engenharia de Software Muitos outros modelos mais complexos s o na realidade varia es do modelo cascata incorporando la os de realimenta o PFLEEGER 2004 Embora tenha fraquezas ele significativamente melhor do que uma abordagem casual para o desenvolvimento de software De fato para problemas pequenos e bem definidos onde os desenvolvedores conhecem bem o dom nio
87. The Project Manager s Guide to Software Engineering Best Practices Wiley IEEE Computer Society Press 2002 KROLL P KRUCHTEN P The Rational Unified Process Made Easy A Practitioner s Guide to the RUP Addison Wesley 2003 KRUCHTEN P The Rational Unified Process An Introduction 3 Edition Addison Wesley 2003 PFLEEGER S L Engenharia de Software Teoria e Pr tica 2 Edi o S o Paulo Prentice Hall 2004 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 SOMMERVILLE I Engenharia de Software 9 Edi o S o Paulo Pearson Prentice Hall 2011 Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 19 Cap tulo 3 Requisitos de Software Em um desenvolvimento de software a primeira coisa a ser feita capturar os requisitos que o sistema a ser desenvolvido tem de tratar Um entendimento dos requisitos do software essencial para o sucesso de um projeto de desenvolvimento de software Os requisitos devem ser inicialmente levantados e descritos de maneira sucinta para permitir definir o escopo do sistema Depois os requisitos devem ser refinados em detalhes as fun es e o desempenho do software devem ser especificados e as interfaces e restri es que o software deve atender devem ser estabelecidas Modelos dos dados e do comportamento do sistema devem ser
88. UFES Universidade Federal do Esp rito Santo Engenharia de Software Notas de Aula Ricardo de Almeida Falbo falbo winf ufes br 2014 Sum rio Cap tulo 1 Introdu o 1 1 Qualidade de Software 1 2 Processo de Software 1 3 A Organiza o deste Texto PARTE I Desenvolvimento e Manuten o de Software Cap tulo 2 Vis o Geral do Processo de Desenvolvimento 2 1 Modelos de Processo Sequenciais 2 2 Modelos de Processo Incrementais 2 3 Modelos de Processo Evolutivos 2 4 Prototipa o 2 4 Processo Unificado Cap tulo 3 Requisitos de Software 3 1 Requisitos e Tipos de Requisitos 3 2 Engenharia de Requisitos 3 3 Levantamento de Requisitos 3 4 An lise de Requisitos 3 5 M todos de An lise de Requisitos no Paradigma Estruturado 3 6 Modelagem de Entidades e Relacionamentos 3 7 Modelagem de Fluxos de Dados 3 8 Modelagem de Casos de Uso 3 9 Modelagem de Estados 3 10 An lise de Requisitos segundo o Paradigma Estruturado Cap tulo 4 Projeto de Software 4 1 Projeto de Dados 4 2 Projeto de Interface com o Usu rio 4 3 Projeto Modular de Programas Cap tulo 5 Implementa o e Teste de Software 5 1 Implementa o 5 2 Princ pios Gerais de Teste de Software 5 3 N veis de Teste 5 4 T cnicas de Teste 5 5 Processo de Teste Cap tulo 6 Entrega e Manuten o 6 1 Entrega 6 2
89. a exclus o isto pacotes de informa o est o sendo removidos do dep sito A sem ntica dos acessos aos dep sitos de dados mostrada na Figura 3 29 Leitura n o destrutiva do conte do do dep sito de dados Inclus o exclus o ou altera o do conte do do dep sito de dados Leitura e modifica o do conte do do dep sito de dados Figura 3 29 Sem ntica dos acessos a dep sitos de dados em um DFD importante observar a integridade de um dep sito de dados segundo dois prismas e Observar se todos os elementos de dados que fazem parte do dep sito t m como efetivamente chegar l isto fazem parte de pelo menos um fluxo de dados que chega ao dep sito e Observar se todos os elementos de dados que fazem parte do dep sito s o em algum momento solicitados por um processo isto fazem parte de pelo menos um fluxo de dados que sai do dep sito Entidades Externas Entidades externas s o fontes ou destinos de dados do sistema Representam os elementos do ambiente com os quais o sistema se comunica Tipicamente uma entidade externa uma pessoa p ex um usu rio um grupo de pessoas p ex um departamento da empresa ou outras institui es ou um outro sistema que interaja com o sistema em quest o Uma entidade externa deve ser identificada por um nome e representada por um ret ngulo Assim como no caso dos dep sitos de dados em diagramas complexos podemos desenhar uma mesma entidade externa mai
90. a implementa o 2 Requisitos de convers o e implanta o foram estabelecidos pelo usu rio e roteiro de convers o e implanta o foram providos e testados O impacto da convers o no projeto n o considerado importante 3 Requisitos de convers o e implanta o foram estabelecidos pelo usu rio e roteiro de convers o e implanta o foram providos e testados O impacto da convers o no projeto considerado importante 4 Al m do item 2 convers o autom tica e ferramentas de implanta o foram providas e testadas 5 Al m do item 3 convers o autom tica e ferramentas de implanta o foram providas e testadas Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 140 12 Facilidade operacional a an lise desta caracter stica permite quantificar o n vel de influ ncia na aplica o com rela o a procedimentos operacionais autom ticos que reduzem os procedimentos manuais bem como mecanismos de inicializa o salvamento e recupera o verificados durante os testes do sistema 0 Nenhuma considera o especial de opera o al m do processo normal de salvamento foi estabelecida pelo usu rio 1 4 Verifique quais das seguintes afirmativas podem ser identificadas na aplica o Selecione as que forem aplicadas Cada item vale um ponto exceto se definido explicitamente e Foram desenvolvidos processos de inicializa
91. a sua documenta o De maneira geral o processo de desenvolvimento de software envolve as seguintes atividades An lise e Especifica o de Requisitos Projeto Implementa o Testes Entrega e Implanta o do Sistema Na An lise e Especifica o de Requisitos o foco est no levantamento compreens o e especifica o dos requisitos que o produto de software deve ser capaz de satisfazer Para entender a natureza do software a ser constru do o engenheiro de software tem de compreender o dom nio do problema bem como a funcionalidade e o comportamento esperados para o sistema Uma vez capturados os requisitos do sistema estes devem ser modelados avaliados e documentados Uma parte vital desta fase a constru o de modelos descrevendo o qu o software tem de fazer e n o como faz lo ditos modelos conceituais A fase de Projeto respons vel por incorporar requisitos tecnol gicos aos requisitos essenciais do sistema e portanto requer que a plataforma de implementa o seja conhecida Basicamente envolve duas grandes etapas projeto da arquitetura do sistema e o projeto detalhado O objetivo da primeira etapa definir a arquitetura geral do software tendo por base o modelo constru do na fase de an lise de requisitos Essa arquitetura deve descrever a estrutura de n vel mais alto da aplica o e identificar seus principais componentes O prop sito do projeto detalhado detalhar o projeto do software para cada componen
92. ada para se ter uma compreens o do processo produto ou projeto sendo medido Medi o o ato de medir isto de determinar um valor para uma medida Seja o seguinte exemplo deseja se saber se uma pessoa est com seu peso ideal ou n o Para tal duas medidas base s o importantes altura H e peso P Ao medir essas dimens es est se efetuando uma medi o A medida derivada ndice de massa corporal IMC calculada segundo a seguinte f rmula IMC P H2 A partir dessa medida a Organiza o Mundial de Sa de estabeleceu indicadores que apontam se um adulto est acima do peso se est obeso ou abaixo do peso ideal considerado saud vel conforme a seguir Se IMC lt 18 5 ent o o indiv duo est abaixo do peso ideal considerado saud vel Se 18 5 lt IMC lt 25 ent o o indiv duo est com o peso normal Se 25 lt IMC lt 30 ent o o indiv duo est acima do peso Se IMC gt 30 ent o o indiv duo est obeso Realizando medi es uma pessoa pode obter seus valores de peso e altura A partir desses valores ela pode calcular a medida derivada IMC e ter um indicador se est abaixo do peso no peso ideal acima do peso ou obeso Conhecendo esse indicador a pessoa pode ajustar seu modo de vida alimenta o pr tica de exerc cios f sicos etc visando a melhorias reais para sua sa de Uma vez que a medi o de software se preocupa em obter valores num ricos para alguns atributos de um produt
93. ais t m por base a entrega de vers es operacionais desde o primeiro ciclo os modelos evolutivos n o t m essa preocupa o Muito pelo contr rio na maioria das vezes os primeiros ciclos produzem prot tipos ou at mesmo apenas modelos medida que o desenvolvimento avan a e os requisitos v o ficando mais claros e est veis prot tipos v o dando lugar a vers es operacionais at que o sistema completo seja constru do Assim quando o problema n o bem definido e ele n o pode ser totalmente especificado no in cio do desenvolvimento melhor optar por um modelo evolutivo A avalia o ou o uso do prot tipo sistema pode aumentar o conhecimento sobre o produto e melhorar o entendimento que se tem acerca dos requisitos Entretanto a ger ncia do projeto e a ger ncia de configura o precisam ser bem estabelecidas e conduzidas Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 14 2 3 1 O Modelo em Espiral O modelo espiral mostrado na Figura 2 6 um dos modelos evolutivos mais difundidos An lise Especifica o de Requisitos Projeto Entrega e Implementa o Implanta o Testes Figura 2 6 O Modelo Espiral Ao se adotar o modelo espiral o sistema desenvolvido em ciclos sendo que nos primeiros ciclos nem sempre todas as atividades s o realizadas Por exempl
94. al Guia Pr tico de An lise de Sistemas IBPI Press Editora Infobook Rio de Janeiro 1995 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 SETZER W Bancos de Dados 2 Edi o Editora Edgard Blucher 1987 SOMMERVILLE I Engenharia de Software 9 Edi o S o Paulo Pearson Prentice Hall 2011 YOURDON E An lise Estruturada Moderna Editora Campus 1990 Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 50 Cap tulo 4 Projeto de Software O projeto ou design de software encontra se no n cleo t cnico do processo de desenvolvimento de software e aplicado independentemente do modelo de ciclo de vida e paradigma adotados iniciado assim que os requisitos do software tiverem sido pelo menos parcialmente modelados e especificados correspondendo primeira dentre as tr s atividades do dom nio da solu o computacional projeto implementa o e testes requeridas para se construir um sistema de software PRESSMAN 2011 Enquanto a atividade de an lise concentra se no problema a ser resolvido de forma independente da tecnologia a ser adotada na sua solu o a atividade de projeto envolve a modelagem de como o sistema ser implementado com a adi o dos requisitos n o funcionais aos modelos constru dos na an lise como ilustra a Figura 4 1 Assim o objetivo d
95. alidade identificada no levantamento de requisitos As funcionalidades podem ser classificadas em fundamentais aquelas que visam apoiar diretamente os principais processos de neg cio da organiza o e custodiais aquelas necess rias para prover as informa es necess rias para a realiza o das funcionalidades fundamentais p ex cadastros Se um processo oriundo de uma funcionalidade for complexo demais ele pode ser decomposto em outros processos de modo a manter um certo n vel de complexidade nos processos representados em um DFD Esse n vel de complexidade pode ser estabelecido pelo tamanho da especifica o da l gica do processo Se tal n vel de complexidade for superado devemos utilizar uma das seguintes t cnicas para decompor o DFD e Fiss o o processo complexo substitu do no pr prio DFD por um n mero de processos mais simples e Explos o o processo original permanece no diagrama sendo criado um novo DFD de n vel inferior consistindo de processos menos complexos Assim um projeto n o representado por um nico DFD mas sim por um conjunto de DFDs em v rios n veis de decomposi o funcional Recomenda se o uso da fiss o quando a leitura do diagrama n o ficar prejudicada pelo aparecimento de mais alguns processos em um DFD A fiss o possui a vantagem de representar todo o sistema em um nico DFD n o sendo necess rio recorrer a outros diagramas para se obter um entendimento completo de suas fun es
96. anuten o O projeto de programas um processo iterativo e de refinamento que pode ser descrito em duas etapas principais o projeto da arquitetura do sistema e o projeto detalhado dos m dulos Em ambos os casos t cnicas de Projeto Modular de Programas s o empregadas Apesar de usar diferentes varia es para o projeto arquitetural e para o projeto detalhado basicamente dois conceitos s o centrais para o projeto estruturado de sistemas M dulo Conjunto de instru es que desempenha uma fun o espec fica dentro de um programa E definido por entrada sa da fun o l gica e dados internos Conex o entre M dulos Indica a forma como os m dulos interagem entre si O bloco b sico de constru o de um programa estruturado portanto um m dulo Assim os modelos do projeto estruturado de programas s o organizados como uma hierarquia de m dulos A ideia b sica estruturar os programas em termos de m dulos e conex es entre esses m dulos O Projeto Modular de Programas considera ainda alguns aspectos importantes para o projeto de programas Procura solucionar sistemas complexos atrav s da divis o do sistema em caixas pretas os m dulos e pela organiza o dessas caixas pretas em uma hierarquia conveniente para uma implementa o Utiliza ferramentas gr ficas o que tornam mais f cil a compreens o Oferece um conjunto de estrat gias para desenvolver o projeto de solu o a par
97. ap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 12 Vers o la Operacional lb Vers o Operacional k Vers o Operacional Figura 2 4 Varia es do Modelo Incremental Dentre as vantagens do modelo incremental podem ser citadas CHRISTENSEN THAYER 2002 e Menor custo e menos tempo s o necess rios para se entregar a primeira vers o e Os riscos associados ao desenvolvimento de um incremento s o menores devido ao seu tamanho reduzido e O n mero de mudan as nos requisitos pode diminuir devido ao curto tempo de desenvolvimento de um incremento Como desvantagens podemos citar CHRISTENSEN THAYER 2002 e Se os requisitos n o s o t o est veis ou completos quanto se esperava alguns incrementos podem ter de ser bastante alterados e A ger ncia do projeto mais complexa sobretudo quando a divis o em subsistemas inicialmente feita n o se mostrar boa 2 2 2 O Modelo RAD O modelo RAD Rapid Application Development ou modelo de desenvolvimento r pido de aplica es um tipo de modelo incremental que prima por um ciclo de desenvolvimento curto tipicamente de at 90 dias PRESSMAN 2011 Assim como no modelo incremental o sistema subdividido em subsistemas e incrementos s o realizados A diferen a marcante que os incrementos s o desenvolvidos em paralelo por equipes distintas e apenas uma
98. apoiando o uso do sistema gerado p ex manual do usu rio ajuda tutoriais Uma documenta o de qualidade propicia uma maior organiza o durante o desenvolvimento de um sistema facilitando modifica es e futuras manuten es no mesmo Al m disso reduz o impacto da perda de membros da equipe reduz o tempo de desenvolvimento de fases posteriores reduz o tempo de manuten o e contribui para redu o de erros aumentando assim a qualidade do processo e do produto gerado Dessa forma a Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 91 cria o da documenta o t o importante quanto a cria o do software em si SANCHES 2001a Assim importante planejar a documenta o de um projeto definindo dentre outros os documentos que ser o gerados por cada atividade do processo modelos de documentos a serem adotados e crit rios de an lise aprova o ou reprova o Algumas dessas atividades est o estreitamente relacionadas com o controle e a garantia da qualidade de software outras com a ger ncia da configura o do software conforme discutido na Se o 7 3 Uma eficaz maneira de se melhorar a qualidade da documenta o produzida em um projeto e por conseguinte do sistema de software resultante consiste em se definir padr es a serem aplicados na elabora o dos documentos Os padr es aplicam se aos artef
99. ara a mesma entidade sinal de que ele n o atributo de Fornecedor 3 Se o atributo pre o n o nem de Produto nem de Fornecedor ent o um atributo do relacionamento entre os dois tipos de entidades como mostra a Figura 3 18 0 N LN T fornece Figura 3 18 Atributo do Relacionamento pre o Uma outra quest o a ser considerada relacionada a atributos a informa o que se deseja modelar deve ser tratada como atributo de uma entidade ou como uma segunda entidade relacionada primeira Analisemos o seguinte exemplo Ser que departamento que oferece uma disciplina deve ser modelado como atributo da entidade Disciplina ou merece ser uma nova entidade relacionada a ela De forma geral conv m tratar um elemento de informa o como uma segunda entidade se e O elemento em quest o tem atributos pr prios e A segunda entidade resultante relevante para o sistema e O elemento em quest o de fato identifica a segunda entidade e A segunda entidade pode ser relacionada a diversas ocorr ncias da entidade 1 1 N e A segunda entidade relaciona se a outras entidades que n o a entidade 1 Podemos notar que no exemplo todos os crit rios anteriormente enumerados foram satisfeitos e portanto departamento deve ser tratado como uma nova entidade como mostra a Figura 3 19 Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal d
100. ara ajudar Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 15 engenheiros de software e clientes a entender o que est sendo constru do quando os requisitos n o est o claros Ainda que tenha sido citada anteriormente no contexto do modelo espiral ela pode ser aplicada no contexto de qualquer modelo de processo A Figura 2 7 por exemplo ilustra um modelo em cascata com prototipa o PFLEEGER 2004 a ammanamananana maninho K LEICITETTETEEEETETTETET TILLID 2 Prototipa o Figura 2 7 O Modelo em Cascata com Prototipa o 2 5 O Processo Unificado O Modelo do Processo Unificado muitas vezes referenciado como RUP Rational Unified Process um modelo de processo bastante elaborado que procura incorporar elementos de v rios dos modelos de processo anteriormente apresentados em uma tentativa de incorporar as melhores pr ticas de desenvolvimento de software dentre elas a prototipa o e a entrega incremental SOMMERVILLE 2011 Ainda que apresentado neste texto isoladamente em uma se o o modelo de processo do RUP um modelo evolutivo como ilustra a Figura 2 8 na medida em que preconiza o desenvolvimento em ciclos de modo a permitir uma melhor compreens o dos requisitos De fato a op o por apresent lo em uma se o separada que o RUP n o apenas um model
101. aria de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 134 1 Comunica o de Dados 2 Processamento de Dados Distribu do 3 Desempenho 4 Utiliza o do Equipamento Restri es de Recursos Computacionais 5 Volume de Transa es 6 Entrada de Dados On line 7 Efici ncia do Usu rio Final Usabilidade 8 Atualiza o On line 9 Processamento Complexo 10 Reusabilidade 11 Facilidade de Implanta o 12 Facilidade Operacional Processos Operacionais tais como Inicializa o C pia de Seguran a Recupera o etc 13 M ltiplos Locais e Organiza es do Usu rio 14 Facilidade de Mudan as Manutenibilidade Para cada uma dessas 14 caracter sticas deve se atribuir um valor de O nenhuma influ ncia a 5 forte influ ncia dito grau ou n vel de influ ncia que indica o quanto determinada caracter stica tem influ ncia no sistema Os 14 graus de influ ncia GIs informados s o somados resultando no n vel de influ ncia total NTT 14 NIT Gl Finalmente o valor do fator de ajuste VFA determinado ent o pela f rmula VFA NIT 0 01 0 65 C lculo dos Pontos de Fun o Ajustados Uma vez calculados os PF n o ajustados e o fator de ajuste poss vel calcular os PFs ajustados Esse c lculo feito de formas diferentes para cada tipo de contagem projeto de desenvolvimento projeto de manuten o ou aplica
102. as que definem as tarefas realizadas no n vel precedente MARTIN MCCLURE 1991 Um m dulo definido como uma cole o de instru es de programa com quatro atributos b sicos entradas e sa das fun o l gica e dados internos Entradas e sa das s o respectivamente as informa es que um m dulo necessita e fornece A fun o de um m dulo o que ele faz para produzir a partir da informa o de entrada os resultados da sa da Entradas sa das e fun o fornecem a vis o externa do m dulo e portanto apenas esses aspectos s o representados em um Diagrama de Estrutura Modular A l gica de um m dulo a descri o dos algoritmos que executam a fun o Dados internos s o aqueles referenciados apenas dentro do m dulo L gica e dados internos representam a vis o interna do m dulo e s o descritos por uma t cnica de especifica o de Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 65 programas tal como portugu s estruturado tabelas de decis o e rvores de decis o discutidos no Cap tulo 3 Assim sendo um DEM mostra A divis o de um programa em m dulos A hierarquia e a organiza o dos m dulos As interfaces de comunica o entre m dulos entrada sa da As fun es dos m dulos dadas por seus nomes Estruturas de controle entre m dulos tais como condi o de execu o de um m dulo la os de
103. atos produzidos ao longo do processo de software e podem ser dentre outros modelos de documentos roteiros normas e padr es de nomes dependendo do artefato a que se aplicam Tipicamente para documentos modelos de documentos e roteiros s o providos Um modelo de documento define a estrutura se es subse es informa es de cabe alho e rodap de p gina etc o estilo tamanho e tipos de fonte cores etc e o conte do esperado para documentos de um tipo espec fico Documentos tais como Plano de Projeto Documento de Especifica o de Requisitos e Documento de Especifica o de Projeto devem ter modelos de documentos espec ficos associados Documentos padronizados s o importantes pois facilitam a leitura e a compreens o uma vez que os profissionais envolvidos est o familiarizados com seu formato Quando n o poss vel ou desej vel estabelecer uma estrutura r gida como um modelo de documento roteiros dando diretrizes gerais para a elabora o de um artefato devem ser providos Em situa es em que n o poss vel definir uma estrutura tal como no c digo fonte normas e padr es de nomea o devem ser providos Assim tomando o exemplo do c digo fonte extremamente pertinente a defini o de um padr o de codifica o indicando nomes de vari veis v lidos estilos de identa o regras para coment rios etc Padr es organizacionais s o muito importantes pois eles fornecem um meio de capturar as melhore
104. bela 5 4 Casos de Teste Adicionais An lise de Valor Limite Entrada Sa da Esperada 0 01 Erro valor deve ser maior ou igual a 0 0 00 0 00 0 01 0 00 1 710 97 0 00 1 710 98 0 00 1 710 99 0 00 2 563 90 63 98 2 563 91 63 98 2 563 92 63 98 3 418 58 192 18 3 418 59 192 18 3 418 60 192 18 4 271 58 384 10 4 271 59 384 10 4 271 60 384 11 O crit rio de an lise de valor limite complementa o crit rio de particionamento de equival ncia aumentando a cobertura a situa es lim trofes muito sujeitas a erros Assim como o crit rio de particionamento de equival ncia a an lise de valor limite especialmente adequado para aplica es em que as vari veis de entrada podem ser facilmente identificadas e assumem valores espec ficos Contudo n o t o facilmente aplic vel mesmo quando o dom nio de entrada simples se o processamento do m dulo for complexo A t cnica de teste funcional sistem tico combina as diretrizes do particionamento de equival ncia e da an lise de valor limite e define diretrizes adicionais Primeiramente requer ao menos dois casos de teste de cada parti o para minimizar o problema de defeitos coincidentes que mascaram falhas Al m disso define outras diretrizes dentre elas e Seo dom nio de entrada aceita valores num ricos e esses valores s o discretos ou seja se fazem parte de um conjunto enumer vel ent o se devem de
105. cessos de An lise de Requisitos de Software Projeto da Arquitetura de Software Projeto Detalhado de Software Constru o de Software Integra o de Software e Teste de Qualifica o de Software correspondem s atividades do processo de desenvolvimento de software estudadas na Parte I destas notas de aula e Grupo de Processos de Suporte de Software Os processos de Ger ncia de Documenta o de Software Ger ncia de Configura o de Software Garantia da Qualidade Verifica o Valida o e Revis o de Software foram abordados no Cap tulo 7 Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 117 Al m de atividades e tarefas cada processo tem um prop sito e um resultado associados Os prop sitos e resultados dos processos de ciclo de vida constituem um Modelo de Refer ncia de Processos System Context Processes Software Specific Processes Agreement Project Technical SW Imp lement SW Support Processes Processes Process es ation Processes Processes Acquisition Process Project Planning Process Fequi eds e a ad td rota Preso Cause 611 Oase 6 31 Process Cause 6 41 Cause 7141 Cause 7 21 SupplyProcess Project Assessment and System Requirements Software Requirements Software Configuration a y 612 Contral Process Analysis Process Analysis Process Management Process Cause 612 Cause 6 32 Cause 642 Clause 742
106. cidade de reutiliza o O ideal que tenhamos apenas coes o funcional isto que todos os elementos de um m dulo estejam contribuindo para a execu o de uma e somente uma fun o do sistema Vale a pena ressaltar que coes o e acoplamento s o interdependentes e portanto uma boa coes o deve nos levar a um pequeno acoplamento A Figura 4 26 procura ilustrar este fato Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo Baixa Coes o F brica de Refrigerantes Tate Vila Velha Conjunto Habitacional da CST Alta Coes o F brica de Refrigerantes Tate Vila Velha F brica de Garrafas Pl sticas Alto Acoplamento Tr fego Intenso Baixo Acoplamento Pouco Tr fego Cap tulo 4 Projeto de Software 69 Baixa Coes o F brica de Garrafas Pl sticas Alta Coes o Conjunto Habitacional da CST Figura 4 26 Coes o e Acomplamento Refer ncias do Cap tulo PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 MARTIN J MCCLURE C T cnicas Estruturadas e CASE Makron Books S o Paulo 1991 XAVIER C M S PORTILHO C Projetando com Qualidade a Tecnologia de Sistemas de Informa o Livros T cnicos e Cient ficos Editora 1995 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp
107. cimento humano tem gerado uma crescente demanda por solu es computadorizadas Para os iniciantes na Ci ncia de Computa o desenvolver software muitas vezes confundido com programa o Essa confus o inicial pode ser atribu da parcialmente pela forma como as pessoas s o introduzidas nesta rea de conhecimento come ando por desenvolver habilidades de racioc nio l gico atrav s de programa o e estruturas de dados Ali s nada h de errado nessa estrat gia Come amos resolvendo pequenos problemas que gradativamente v o aumentando de complexidade requerendo maiores conhecimentos e habilidades Entretanto chega se a um ponto em que dado o tamanho ou a complexidade do problema que se pretende resolver essa abordagem individual centrada na programa o n o mais indicada De fato ela s aplic vel para resolver pequenos problemas tais como calcular m dias ordenar conjuntos de dados etc envolvendo basicamente o projeto de um algoritmo Contudo insuficiente para problemas grandes e complexos tais como aqueles tratados na automa o banc ria na informatiza o de portos ou na gest o empresarial Em tais situa es uma abordagem de engenharia necess ria Observando outras reas tal como a Engenharia Civil podemos verificar que situa es an logas ocorrem Por exemplo para se construir uma casinha de cachorro n o necess rio elaborar um projeto de engenharia civil com plantas baixa hidr
108. cionais da Engenharia de Software a saber normas e modelos de qualidade do processo de software processos padr o processos geis e apoio automatizado ao processo de software O desenvolvimento de um produto de software norteado pela escolha de um paradigma de desenvolvimento Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e portanto definem as caracter sticas b sicas dos modelos a serem constru dos Por exemplo o paradigma orientado a objetos parte do pressuposto que o mundo povoado por objetos ou seja a abstra o b sica para se representar as coisas do mundo s o os objetos J o paradigma estruturado adota uma vis o de desenvolvimento baseada em um modelo entrada processamento sa da No paradigma estruturado os dados s o considerados separadamente das fun es que os transformam e a decomposi o funcional usada intensamente Neste texto discutimos as atividades do processo de desenvolvimento de software luz do paradigma estruturado PARTE I Desenvolvimento e Manuten o de Software Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 7 Cap tulo 2 Vis o Geral do Processo de Desenvolvimento O processo de desenvolvimento de software engloba as atividades que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente incluindo
109. co enfatiza a sele o de mais de um caso de teste por parti o ou limite aumentando assim a chance de revelar defeitos Contudo por ser baseado nos crit rios de particionamento de equival ncia e an lise de valor limite apresenta as mesmas limita es desses crit rios DELAMARO et al 2007 Em rela o s t cnicas de teste funcional de maneira geral vale ressaltar que como os crit rios funcionais se baseiam apenas na especifica o n o podem assegurar que partes cr ticas e essenciais do c digo tenham sido cobertas Assim importante que outras t cnicas sejam aplicadas em conjunto para que o software seja explorado por diferentes pontos de vista DELAMARO et al 2007 Os testes estruturais s o uma boa op o para este fim 5 4 2 Testes Estruturais Os testes estruturais ou de caixa branca estabelecem os objetivos do teste com base em uma dada implementa o verificando detalhes do c digo Baseia se no conhecimento da estrutura interna de um m dulo ou programa Caminhos l gicos internos s o testados estabelecendo casos de teste que p em prova condi es la os defini es e usos de vari veis DELAMARO et al 2007 PRESSMAN 2011 H diversas t cnicas de testes caixa branca cada uma delas procurando apoiar o projeto de casos de teste focando em algum ou v rios aspectos da implementa o Em geral a maioria dos crit rios estruturais utiliza uma representa o de Grafo de Fluxo de Controle
110. coplamento diz respeito ao grau de interdepend ncia entre dois m dulos O objetivo minimizar o acoplamento isto tornar os m dulos t o independentes quanto poss vel Podemos citar como raz es para minimizar o acoplamento Quanto menos conex es houver entre dois m dulos menor ser a chance de um problema ocorrido em um deles se refletir em outros Uma altera o deve afetar o menor n mero de m dulos poss vel isto uma altera o em um m dulo n o deve implicar em altera es em outros m dulos Ao dar manuten o em um m dulo n o devemos nos preocupar com detalhes de codifica o de outros m dulos O acoplamento envolve tr s aspectos principais tipo da conex o tamanho da conex o e o que comunicado atrav s da conex o O tipo da conex o diz respeito forma como uma conex o estabelecida O ideal que a comunica o se d atrav s de chamadas a m dulos cada um deles fazendo uso apenas de vari veis locais Qualquer informa o externa Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 68 necess ria deve ser passada como par metro Assim cada m dulo deve possuir seu escopo pr prio de vari veis evitando se utilizar uma vari vel definida em outro m dulo Com rela o ao tamanho da conex o quanto menor o n mero de informa es trafegando de um m dulo para outro menor ser o acoplamento Entre
111. correta de acordo com padr es previamente definidos sem conter requisitos amb guos incompletos ou ainda requisitos incoerentes ou imposs veis de serem testados J a valida o diz respeito a avaliar se os requisitos do sistema est o corretos ou seja se os requisitos e modelos documentados atendem s reais necessidades de usu rios e clientes e Ger ncia de Requisitos se preocupa em gerenciar as mudan as nos requisitos j acordados manter uma trilha dessas mudan as e gerenciar os relacionamentos entre os requisitos e as depend ncias entre requisitos e outros artefatos produzidos no processo de software de forma a garantir que mudan as nos requisitos sejam feitas de maneira controlada e documentada Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 21 Em rela o ao processo de software das cinco atividades do processo de Engenharia de Requisitos anteriormente listadas apenas as tr s primeiras fazem parte do processo de desenvolvimento Levantamento An lise e Documenta o de Requisitos As duas ltimas s o na realidade atividades de ger ncia envolvendo requisitos A atividade de Verifica o e Valida o de Requisitos uma importante atividade do processo de Ger ncia da Qualidade e um instrumento fundamental para a garantia do projeto como um todo tendo em vista que os requisitos s o a base para o sucesso de u
112. cos e tomar a es corretivas Deste modo as atividades realizadas sumarizadas na Figura 8 1 no planejamento s o novamente consideradas no acompanhamento do projeto que tipicamente se d nos marcos definidos no projeto e Encerramento terminado o projeto a ger ncia ainda tem um importante trabalho a fazer fazer uma an lise cr tica do que deu certo e o que n o funcionou procurando registrar li es aprendidas de sucesso e oportunidades de melhoria Compara es entre valores estimados e realizados identifica o de problemas que ocorreram e causas dos desvios devem ser discutidas com os membros da equipe procurando fazer com que haja um aprendizado n o s da equipe mas da organiza o como um todo Uma t cnica bastante empregada neste contexto a an lise post mortem Levantamento preliminar de requisitos marco Planejamento Encerramento Determina o do Escopo do Software Defini o do Processo de Sotware do Projeto Realiza o de Estimativas Estimativa de Tamanho Estimativa de Esfor o Estimativa e Aloca o de Recursos Estimativa de Tempo Elabor a o de Cronograma do Projeto Estimativa de Custos Elaler a o de Or amento do Projete Identifica o de Riscos a Planajamanto de Respostas aos Riscos Figura 8 1 O Processo de Ger ncia de Projetos de Software As atividades relacionadas no quadro na parte inferior na Figura 8 1 s o realizadas diversas vezes ao longo do projeto Tipicamente no
113. cos s o subconjuntos de dados dentro de um ALI AIE que foram reconhecidos pelo usu rio Se o usu rio n o reconhecer subconjuntos de dados em um ALTAIE ent o se deve contar o ALI AIE como um registro l gico Um Item de Dados por sua vez um campo reconhecido pelo usu rio como nico e n o repetido Vale destacar que s devem ser contados os itens de dados utilizados pela aplica o em contagem Contando se os registros l gicos e os itens de dados de um ALI AIE pode se chegar sua complexidade utilizando a tabela A 1 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 131 Tabela A 1 Tabela de Identifica o da Complexidade das Fun es de Dados N mero de Registros N mero de Itens de Dados Referenciados L gicos Dela 19 De 20 a 50 Apenas 1 Simples Simples M dia De2as Simples M dia Complexa 6 ou mais M dia Complexa Complexa Contagem das Fun es Transacionais De maneira an loga contagem das fun es de dados a contagem das fun es transacionais envolve a identifica o de fun es transacionais entradas externas sa das externas e consultas externas e sua classifica o de acordo com a complexidade funcional envolvida simples m dia ou complexa A defini o da complexidade funcional feita com base no n mero de arquivos referenciados e dos itens de dados manipulados pela fu
114. dades levantamento de requisitos an lise projeto evolu o e entrega As tarefas de cada atividade s o feitas dentro de um padr o de processo chamado sprint Uma lista priorizada de requisitos dita backlog mantida Requisitos podem ser adicionados removidos e alterados a qualquer momento bem como as prioridades podem ser alteradas Um sprint uma unidade de trabalho com tempo pr determinado tipicamente de 30 dias Durante um sprint s o escolhidos alguns requisitos do backlog e estes s o Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 126 considerados congelados i e n o sujeitos a mudan as Assim a equipe pode trabalhar em um ambiente est vel por um curto per odo de tempo Pequenas reuni es de aproximadamente 15 minutos s o feitas diariamente pela equipe com o Scrum Master uma esp cie de l der do projeto na qual tr s perguntas chave s o feitas para cada membro da equipe O que voc fez desde a ltima reuni o Que obst culos voc tem encontrado O que voc planeja fazer at a pr xima reuni o Os objetivos dessas reuni es scrum s o descobrir potenciais problemas cedo socializar o conhecimento e promover a auto organiza o da equipe O produto resultante de um sprint um demo Demos s o incrementos de software entregues ao cliente como demonstra es O cliente avalia as
115. de com o MPS BR Define tamb m os n veis de maturidade e de capacidade de processos e os processos em si e M todo de Avalia o MA MPS cont m o processo de avalia o os requisitos para os avaliadores e os requisitos para averigua o da conformidade ao modelo MR MPS Est descrito de forma detalhada no Guia de Avalia o e foi baseado na norma ISO IEC 15504 e Modelo de Neg cio MN MPS cont m uma descri o das regras para a implementa o do MR MPS pelas empresas de consultoria de software e de avalia o O MR MPS define sete n veis de maturidade A Em Otimiza o B Gerenciado Quantitativamente C Definido D Largamente Definido E Parcialmente Definido F Gerenciado e G Parcialmente Gerenciado A escala de maturidade se inicia no n vel G e progride at o n vel A Para cada um desses sete n veis de maturidade foi atribu do um perfil de processos e de capacidade de processos que indicam onde a organiza o tem que colocar esfor os para melhoria de forma a atender os objetivos de neg cio A Tabela 9 2 mostra os n veis de maturidade do MPS BR e seus processos A Tabela 9 3 mostra um comparativo dos n veis e processos do MR MPS SW n veis G a D com seus correspondentes no modelo CMMI DEV vers o 1 3 n veis 2 e 3 Tabela 9 2 N veis de Maturidade e Processos do MPS BR N vel Processos A B Ger ncia de Projetos evolu o C Ger ncia de Decis es GDE Desenvolvimento pa
116. de sele o s o expressas como uma combina o se ent o sen o conforme abaixo se lt condi o gt ent o grupo de a es 1 sen o grupo de a es 2 fim se Quando existirem v rias a es dependentes de uma mesma condi o que sejam mutuamente exclusivas podemos utilizar uma estrutura do tipo caso conforme abaixo Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 44 caso lt condi o gt valor 1 grupo de a es 1 valor 2 grupo de a es 2 valor n grupo de a es N fim caso e Instru es de Repeti o Aplicadas quando devemos executar uma instru o ou um grupo de instru es repetidas vezes A estrutura de repeti o pode ser usada de tr s formas distintas 1 para cada X fa a grupo de a es fim para 2 enquanto lt condi o for verdadeira gt fa a grupo de a es fim enquanto 3 repita grupo de a es at que lt condi o seja verdadeira gt Arvores de Decis o rvores de Decis o s o excelentes para mostrar a estrutura de decis o de um processo Os ramos da rvore correspondem a cada uma das possibilidades l gicas uma excelente ferramenta para esquematizar a estrutura l gica e para obter do usu rio a confirma o de que a l gica expressa est correta De forma clara e objetiva permite a leitura da combina o das circunst ncias que levam a
117. dem ser aplicadas na descri o de casos de uso Contudo h muitas outras maneiras que podem ser usadas para a descri o de casos de uso ainda que n o abordadas neste texto Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 48 3 9 Modelagem de Estados Diagramas de Estados s o utilizados para descrever o comportamento de uma entidade com o objetivo de mostrar o comportamento da mesmo ao longo do seu tempo de vida Diagramas de Estado descrevem todos os poss veis estados pelos quais uma entidade pode passar e as transi es dos estados como resultado de eventos est mulos que atingem a mesmo A Figura 3 34 mostra a nota o b sica para diagramas de estado segundo a UML Estado Estado Inicial Final evento condi o Estado 1 Estado 2 O Figura 5 27 Nota o B sica para Diagramas de Estados Estados s o representados por ret ngulos com os cantos arredondados e transi es por setas sendo que ambos podem ser rotulados O r tulo de um estado cont m tipicamente o seu nome J o r tulo de uma transi o tem duas partes principais ambas opcionais Evento condi o Basicamente a sem ntica de um diagrama de estados a seguinte quando um evento ocorre se a condi o verdadeira a transi o ocorre A entidade passa ent o para um novo estado O fato de uma transi o n o possuir um evento associado
118. devem ser aplicados na aquisi o fornecimento desenvolvimento opera o e manuten o de produtos de software Esse conjunto de processos atividades e tarefas foi projetado para ser adaptado de acordo com as caracter sticas de cada projeto de software o que pode envolver o detalhamento a adi o e a supress o de processos atividades e tarefas n o aplic veis ao mesmo A ISO IEC 12207 abrange tanto a Engenharia de Software quanto a Engenharia de Sistemas Ela agrupa os processos do ciclo de vida em sete grupos de processo a saber Processos de Acordo Processos Organizacionais Habilitadores de Projetos Processos de Projeto Processos T cnicos Processos de Implementa o de Software Processos de Suporte de Software Processos de Reutiliza o de Software sendo os quatro primeiros processos de contexto de sistema e os tr s ltimos processos espec ficos de software A Figura 9 1 mostra os grupos de processo da ISO IEC 12207 e seus processos de ciclo de vida Dentre os processos mostrados destacam se os seguintes abordados anteriormente nestas notas de aula e Grupo de Processos de Projeto Os processos de Planejamento de Projetos Avalia o e Controle de Projetos e Ger ncia de Riscos correspondem ao Processo de Ger ncia de Projetos estudado no Cap tulo 8 O processo de Medi o est relacionado medi o tema abordado tanto no Cap tulo 7 quanto no Cap tulo 8 e Grupo de Processos de Implementa o de Software Os pro
119. do M dulo Chamado Figura 4 21 Conex o entre m dulos Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 66 Comunica o entre m dulos M dulos conectados est o se comunicando logo existem informa es trafegando entre eles Estas informa es podem ser dados ou controles descrevem uma situa o ocorrida durante a execu o do m dulo A Figura 4 22 mostra a conven o utilizada para se determinar se a informa o que est sendo passada entre m dulos um dado ou um controle juntamente com um exemplo Obter dados cliente O Sa Liga o de Dados cpf O O dados cliente o x cliente inexistente A a Liga o de Controle Pesquisar cliente por cpf Figura 4 22 Comunica o entre m dulos Chamadas Condicionais Em muitos casos um m dulo s ser ativado se uma condi o for satisfeita Nestes casos temos chamadas condicionais cuja nota o mostrada na Figura 4 23 No exemplo esquerda o m dulo 4 pode ou n o chamar o m dulo B No exemplo direita o m dulo 4 pode chamar um dos m dulos B ou C Se Figura 4 23 Chamada Condicional Chamadas Iterativas Algumas vezes nos deparamos com situa es nas quais um m dulo ou um conjunto de m dulos chamado v rias vezes caracterizando chamadas iterativas ou repetidas cuja nota o mostrada na Figura 4 24 No exem
120. do em homem hora o risco passa a ser outro Se a organiza o respons vel pelo fornecimento do produto ou servi o pouco produtiva ela n o penalizada Muito pelo contr rio Ela recebe ainda mais para fazer o mesmo servi o VAZQUEZ SIM ES ALBERT 2005 Uma forma alternativa para contrata o consiste em uma varia o do segundo modelo na qual o pre o unit rio pago n o mais por homem hora uma unidade de esfor o mas por uma unidade de tamanho Assim poss vel acomodar mudan as no esfor o mas sem os desvios observados na modalidade por homem hora A quest o passa a ser ent o que medida usar para medir tamanho Entre as v rias formas de se medir tamanho de um software uma das mais simples direta e intuitiva a contagem do n mero de linhas de c digo Lines Of Code LOC dos programas fonte Existem alguns estudos que demonstram a alta correla o entre essa medida e o tempo necess rio para se desenvolver um sistema Entretanto o uso de LOCSs apresenta v rias desvantagens Primeiro verifica se que ela fortemente ligada tecnologia empregada sobretudo a linguagem de programa o e ao estilo do c digo escrito Segundo pode ser dif cil estimar essa grandeza no in cio do desenvolvimento sobretudo se n o houver dados hist ricos relacionados com a linguagem de programa o utilizada no projeto Por fim essa medida pouco significativa para o cliente Visando possibilitar a realiza o de estima
121. dos em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 115 Cap tulo 9 T picos Avan ados em Engenharia de Software Estudos mostram que a qualidade do produto de software depende diretamente da qualidade dos processos adotados no seu desenvolvimento FUGGETTA 2000 Assim cada vez mais as organiza es t m despendido esfor os significativos na melhoria cont nua de seus processos de software Este cap tulo discute os seguintes aspectos relacionados melhoria de processos de software normas e modelos de qualidade de processo processos de software padr o processos geis e apoio automatizado ao processo de software 9 1 Normas e Modelos de Qualidade de Processo de Software Os modelos de ciclo de vida se at m apenas s atividades b sicas do processo de desenvolvimento e suas inter rela es Eles s o um importante ponto de partida para a defini o de processos mas n o s o suficientes Afinal um processo de software na verdade um conjunto de processos dentre eles o processo de desenvolvimento Mas h outros tais como os processos de ger ncia de projetos e de garantia da qualidade Para o sucesso na defini o e melhoria dos processos de software fundamental que v rios aspectos sejam considerados V rios modelos e normas de qualidade de processo t m surgido com o objetivo de apoiar a busca por processos de maior qualidade apontando os principais aspectos
122. dos os projetos da organiza o contenham as informa es consideradas relevantes Tipicamente um plano de projeto composto de outros artefatos dentre eles processo do projeto estrutura anal tica do projeto estimativas cronograma or amento e plano de riscos Refer ncias do Cap tulo HAZAN C Medi o da Qualidade e Produtividade em Software In Qualidade e Produtividade em Software 4 edi o K C Weber A R C Rocha C J Nascimento organizadores Makron Books p 25 41 2001 JALOTE P CMM in Practice Processes For Executing Software Projects At Infosys Addison Wesley Publishing Company 1999 MARTINS J C C Gerenciando Projetos de Desenvolvimento de Software com PMI RUP e UML 2 edi o revisada Rio de Janeiro Brasport 2005 PFLEEGER S L Engenharia de Software Teoria e Pr tica 2 Edi o S o Paulo Prentice Hall 2004 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 SOMMERVILLE I Engenharia de Software 9 Edi o S o Paulo Pearson Prentice Hall 2011 VAZQUEZ C E SIM ES G S ALBERT R M An lise de Pontos de Fun o Medi o Estimativas e Gerenciamento de Projetos de Software 3 edi o S o Paulo Editora rica 2005 VIEIRA M F Gerenciamento de Projetos de Tecnologia da Informa o Rio de Janeiro Editora Elsevier Campus 2003 Engenharia de Software Cap tulo 9 T picos Avan a
123. duto e questionar a sua validade Um testador deve abordar um software com a atitude de questionar tudo sobre ele A perspectiva de teste requer que um fragmento de software demonstre n o apenas que ele executa de acordo com o especificado mas que executa apenas o especificado Assim bons testadores necessitam de um conjunto especial de habilidades dentre elas querer prova de qualidade n o fazer suposi es n o deixar passar reas importantes e procurar ser reproduz vel MCGREGOR SYKES 2001 Em um teste de software executa se um programa utilizando algumas entradas em particular e verificar se se seu comportamento est de acordo com o esperado Caso a execu o apresente algum resultado n o especificado um defeito foi identificado Os dados da execu o podem servir como fonte para a localiza o e corre o de defeitos mas teste n o depura o DELAMARO et al 2007 Seja P um programa a ser testado O dom nio de entrada de P denominado D P o conjunto de todos os valores poss veis que podem ser utilizados para executar P Um dado de teste para P um elemento de D P O dominio de saida de P o conjunto de todos os poss veis resultados produzidos por P Um caso de teste de P um par formado por um dado de teste mais o resultado esperado para a execu o de P com aquele dado de teste Ao conjunto de todos os casos de teste usados durante uma determinada atividade de teste d se o nome de conjunto de casos de
124. e a sua funcionalidade completa Um bom caso de uso compreende uma sequ ncia de transa es realizadas pelo sistema que produz um resultado de valor observ vel para um particular ator Por produzir um resultado de valor observ vel queremos dizer que um caso de uso tem de garantir que um ator realiza uma tarefa que tem um valor identific vel Isso importante para se obter casos de uso que n o sejam muito pequenos Por outro lado a identifica o de um particular ator importante na obten o de casos de uso que n o sejam muito grandes Os casos de uso fornecem uma maneira para os engenheiros de software chegarem a uma compreens o comum acerca das funcionalidades do sistema com os usu rios finais do sistema e com os especialistas do dom nio Al m disso servem para ajudar a validar e verificar o sistema medida que ele evolui durante seu desenvolvimento Assim os casos de uso n o apenas representam o comportamento desejado do sistema mas tamb m podem ser utilizados como base para a elabora o de casos de teste principalmente nos testes de integra o e de sistema BOOCH RUMBAUGH JACOBSON 2006 Usualmente em primeiro lugar casos de uso s o listados e discutidos para s ent o se realizar alguma modelagem conceitual estrutural Entretanto em alguns casos a modelagem conceitual estrutural Modelo de Entidades e Relacionamentos ajuda a descobrir casos de uso raz o pela qual essas atividades s o conduzidas com alt
125. e Projetos de Software Como ilustra a Figura 8 1 tipicamente um processo de ger ncia de projetos envolve quatro atividades principais e Inicia o quando realizada a autoriza o formal para que o projeto seja iniciado e Planejamento um plano organizado de como o projeto ser conduzido deve ser elaborado O planejamento do projeto deve tratar da defini o do escopo do software da defini o do processo de software do projeto da realiza o de estimativas da elabora o de cronograma e or amento e da identifica o e tratamento dos riscos associados ao projeto e Acompanhamento conforme anteriormente apontado no in cio do projeto h pouca informa o dispon vel o que pode comprometer a precis o do escopo identificado das estimativas realizadas e por conseguinte do cronograma e do or amento elaborados medida que o trabalho avan a execu o do projeto maior conhecimento se tem e portanto poss vel refinar e ajustar esses elementos Al m disso projetos s o din micos e portanto est o sujeitos s mudan as que ocorrem no contexto em que o produto ser inserido Sendo assim Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 101 fundamental acompanhar o progresso do trabalho refinar escopo e estimativas alterar o processo do projeto o cronograma e o or amento al m de monitorar ris
126. e diferente do local em que ser instalado necess rio realizar testes de instala o Al m dos testes de unidade integra o e sistema outros tipos de teste s o realizados ao longo do ciclo de vida de um sistema Os testes de regress o por exemplo s o realizados por ocasi o da ocorr ncia de mudan as A cada novo m dulo adicionado ou a cada altera o o software se modifica Essas modifica es podem introduzir defeitos inclusive em fun es que antes funcionavam corretamente Assim necess rio verificar se as altera es efetuadas est o corretas reexecutando algum subconjunto dos testes para garantir que as modifica es n o est o propagando efeitos colaterais indesejados PRESSMAN 2011 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 77 5 4 T cnicas de Teste Diversas t cnicas de teste t m sido propostas visando apoiar o projeto de casos de teste Essas t cnicas podem ser classificadas segundo os crit rios utilizados para estabelecer os objetivos de teste em testes funcionais estruturais baseados em modelos baseados em defeitos dentre outros Neste texto s o discutidas apenas algumas t cnicas funcionais e estruturais Para maiores detalhes vide DELAMARO et al 2007 5 4 1 Testes Funcionais Os testes funcionais ou de caixa preta utilizam as especifica es de requisitos an lise
127. e projeto para definir os objetivos do teste e portanto para guiar o projeto de casos de teste Os testes s o conduzidos na interface do software e o programa ou sistema considerado uma caixa preta Para testar um m dulo programa ou sistema s o fornecidas entradas e avaliadas as sa das geradas para verificar se est o em conformidade com a correspondente especifica o Detalhes de implementa o n o s o levados em conta Deste modo o software avaliado segundo o ponto de vista do usu rio DELAMARO et al 2007 Os testes caixa preta s o empregados para demonstrar que as fun es do software est o operacionais que a entrada adequadamente aceita e a sa da corretamente produzida e que a integridade da informa o externa uma base de dados por exemplo mantida PRESSMAN 2011 As t cnicas de teste funcional estabelecem crit rios para particionar o dom nio de entrada em subdom nios a partir dos quais ser o definidos os casos de teste DELAMARO et al 2007 Cada t cnica estabelece um crit rio de particionamento Dentre as diversas t cnicas de teste caixa preta podem ser citadas DELAMARO et al 2007 PRESSMAN 2011 particionamento de equival ncia an lise de valor limite e teste funcional sistem tico Todos os crit rios das t cnicas funcionais baseiam se apenas na especifica o do produto testado e portanto o teste funcional depende fortemente da qualidade da especifica o sendo testada Al m
128. e relacionamentos N N deve se criar uma terceira tabela transpondo as chaves prim rias das duas tabelas que participam do relacionamento N N como mostra a Figura 4 11 Se existirem atributos do relacionamento esses dever o ser colocados na nova tabela Caso seja necess rio algum desses atributos pode ser designado para compor a chave prim ria da tabela associativa como ilustra o exemplo da Figura 4 12 Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 57 Diagrama E R Diagrama Relacional Figura 4 11 Relacionamentos N N no Diagrama Relacional cursou Diagrama E R 0 N 0 N m Jem HAI Al Dis HPer odo Dis Diagrama Relacional Disciplina Figura 4 12 Exemplo de relacionamento N N Auto Relacionamentos Os auto relacionamentos devem seguir as mesmas regras de tradu o de relacionamentos como ilustram os exemplos das figuras 4 13 e 4 14 0 N Diagrama E R est l subordinada Unidade a Organizacional UO UO Superior Diagrama Relacional O Unidade Organizacional D Figura 4 13 Exemplo de Auto relacionamento 1 N Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 58 Diagrama E R pr requisito l Dis Dis Pr Req Dis Diagrama Relacional P Figura 4 14 Exemplo de um Auto relacionamento N N Re
129. e tem de ser f cil de manter sendo o produto de software observado por uma perspectiva interna J para um cliente o produto de software deve agregar valor a seu neg cio qualidade em uso Em ltima inst ncia podemos perceber que a qualidade um conceito com m ltiplas facetas perspectivas de usu rio desenvolvedor e cliente e que envolve diferentes caracter sticas por exemplo usabilidade confiabilidade efici ncia manutenibilidade portabilidade seguran a produtividade que devem ser alcan adas em n veis diferentes dependendo do prop sito do software Por exemplo um sistema de tr fego a reo tem de ser muito mais eficiente e confi vel do que um editor de textos Por outro lado um software educacional a ser usado por crian as deve primar muito mais pela usabilidade do que um sistema de venda de passagens a reas a ser operado por agentes de turismo especializados O que h de comum nas v rias perspectivas discutidas acima que todas elas est o focadas no produto de software Ou seja estamos falando de qualidade do produto Entretanto como garantir que o produto final de software apresenta essas caracter sticas Apenas avaliar se o produto final as apresenta uma abordagem indesej vel para o pessoal de desenvolvimento de software tendo em vista que a constata o a posteriori de que o software n o apresenta a qualidade desejada pode implicar na necessidade de refazer grande parte do trabalho necess rio po
130. e teste das atividades de teste das estimativas dos recursos necess rios para realiz las dos objetivos estrat gias e t cnicas de teste a serem adotadas e dos crit rios para determinar quando uma atividade de teste est completa Projeto de Casos de Testes a atividade chave para um teste bem sucedido ou seja para se descobrir a maior quantidade de defeitos com o menor esfor o poss vel A seguir os casos de teste devem ser cuidadosamente projetados e avaliados para tentar se obter um conjunto de casos de teste que seja representativo e envolva as v rias possibilidades de exerc cio das fun es do software cobertura dos testes Existe uma grande quantidade de t cnicas de teste para apoiar os testadores a projetar casos de teste oferecendo uma abordagem sistem tica para o teste de software Uma vez definidos os casos de teste eles devem ser implementados Execu o dos testes consiste na execu o dos casos de teste e registro de seus resultados Avalia o dos resultados detectadas falhas os defeitos dever o ser procurados depura o N o detectadas falhas deve se fazer uma avalia o final da qualidade dos casos de teste e definir pelo encerramento ou n o da atividade de teste Em rela o ao planejamento de teste as seguintes quest es devem ser respondidas Quem deve realizar os testes Para tratar esta quest o tr s abordagens podem ser utilizadas 1 testes feitos pelos pr prios desenvolvedores
131. efatos produzidos a partir dela Uma coisa fato qualidade do produto de software n o se atinge de forma espont nea Ela tem de ser constru da ao longo do processo de software Assim qualidade do produto de software est intimamente relacionada a diversos processos relacionados dentre eles Documenta o Verifica o amp Valida o Ger ncia de Configura o de Software e Medi o Este cap tulo aborda o tema Ger ncia da Qualidade de Software e est estruturado da seguinte forma a Se o 7 1 trata da documenta o produzida ao longo de processo de desenvolvimento de software a Se o 7 2 retoma o tema Verifica o amp Valida o V amp V parcialmente abordado no Cap tulo 5 o qual trata de Teste de Software para discutir t cnicas complementares de revis o as quais se aplicam a documentos a Se o 7 3 discute o processo de Ger ncia de Configura o de Software finalmente a Se o 7 4 trata de Medi o aplicada garantia da qualidade 7 1 Documenta o de Software A documenta o produzida em um projeto de software de suma import ncia para se gerenciar a qualidade tanto do produto sendo produzido quanto do processo usado para seu desenvolvimento No desenvolvimento de software s o produzidos diversos documentos dentre eles documentos descrevendo processos p ex plano de projeto registrando requisitos e modelos do sistema p ex documentos de especifica o de requisitos e de projeto e
132. egrada Treinamento Organizacional Desenvolvimento de Requisitos Solu o T cnica Integra o do Produto Verifica o Valida o Ger ncia de Riscos An lise e Tomada de Decis es 4 Desempenho do Processo Organizacional Ger ncia de Projetos Quantitativa 5 An lise e Resolu o de Causas Ger ncia do Desempenho Organizacional 9 1 3 O Modelo de Refer ncia Brasileiro MPS BR O MPS BR Melhoria de Processo do Software Brasileiro SOFTEX 2011 tem como objetivo definir um modelo de melhoria e avalia o de processo de software adequado preferencialmente s micro pequenas e m dias empresas brasileiras de forma a atender as suas necessidades de neg cio e a ser reconhecido nacional e internacionalmente como um modelo aplic vel ind stria de software Por este motivo est aderente a modelos e normas internacionais A base t cnica utilizada para a constru o do MPS BR composta pelas normas ISO IEC 12207 e ISO IEC 15504 estando totalmente aderente a essas normas Al m disso o MPS BR tamb m cobre o conte do do CMMI Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 120 O MPS BR est dividido em tr s componentes e Modelo de Refer ncia MR MPS cont m os requisitos que as organiza es dever o atender para estar em conformida
133. eiras quantificadas N vel 5 Em Otimiza o A organiza o possui uma base para melhoria cont nua e otimiza o do processo Dados sobre a efici ncia de um processo s o usados para efetuar an lises custo benef cio de novas tecnologias e para propor mudan as no processo A Figura 9 2 mostra os n veis de maturidade do CMMI e em seguida na Tabela 9 1 s o apresentadas as reas de processo de cada n vel Desempenho do processo controlado estatisticamente Gerenciado Quantitativamente Foco na melhoria cont nua do processo Em Otimiza o Processo caracterizado para a organiza o e pr ativo muitas vezes reativo Processo caracterizado para projetos e E Processo imprevis vel fracamente controlado e reativo Figura 9 2 Os n veis de maturidade do CMMI Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 119 Tabela 9 1 As reas de processo dos n veis de maturidade do CMMI N vel Area de Processo 2 Planejamento de Projeto Monitora o e Controle de Projeto Ger ncia de Requisitos Ger ncia de Acordo com Fornecedor Ger ncia de Configura o Medi o e An lise Garantia da Qualidade de Produto e de Processo 3 Defini o do Processo Organizacional Foco no Processo Organizacional Ger ncia de Projetos Int
134. elaborados e os principais artefatos produzidos devem ser submetidos avalia o da qualidade Os requisitos s o o objeto de estudo deste cap tulo 3 1 Requisitos e Tipos de Requisitos Uma das principais medidas do sucesso de um sistema de software o grau no qual ele atende aos requisitos para os quais foi constru do Os requisitos de um sistema de software incluem descri es das fun es que o sistema deve prover e das restri es que devem ser satisfeitas Em outras palavras os requisitos definem o que o sistema deve fazer e as circunst ncias sob as quais deve operar SOMMERVILLE 2011 Requisitos s o normalmente classificados em requisitos funcionais e n o funcionais Requisitos funcionais como o pr prio nome indica apontam as fun es que o sistema deve prover J os requisitos n o funcionais descrevem restri es sobre as fun es oferecidas tais como restri es de tempo de uso de recursos etc De maneira geral requisitos n o funcionais de produtos de software referem se a atributos de qualidade que o sistema deve apresentar tais como confiabilidade usabilidade efici ncia portabilidade manutenibilidade e seguran a Vale a pena mencionar que alguns requisitos n o funcionais dizem respeito ao sistema como um todo e n o a uma funcionalidade espec fica Por exemplo pode ser um requisito de todo um sistema de software ser de f cil manuten o Al m das classes de requisitos funcionais e n o funcionais
135. elecionam se os casos de teste em cada subdominio A identifica o dos subdom nios feita com base em crit rios de teste Dependendo dos crit rios estabelecidos s o obtidos subdom nios diferentes DELAMARO et al 2007 Diferentes t cnicas de teste utilizam diferentes crit rios e por conseguinte levam a parti es diferentes Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 74 Em ess ncia s o importantes princ pios de testes a serem observados PRESSMAN 2011 PFLEEGER 2004 e Teste completo n o poss vel ou seja mesmo para sistemas de tamanho moderado pode ser imposs vel executar todas as combina es de caminhos durante o teste e Teste envolve v rios est gios Geralmente primeiro cada m dulo testado isoladamente dos demais m dulos do sistema teste de unidade medida que os testes progridem o foco se desloca para a integra o dos m dulos teste de integra o at se chegar ao sistema como um todo teste de sistema e Teste deve ser conduzido pelo menos parcialmente por terceiros Os testes conduzidos por outras pessoas que n o aquelas que produziram o c digo t m maior probabilidade de encontrar defeitos O desenvolvedor que produziu o c digo pode estar muito envolvido com ele para poder detectar defeitos mais sutis e Testes devem ser planejados bem antes de serem realizados 5
136. em 35 Esse passo tornou se opcional em 2002 para que o m todo da APF passasse a ser um padr o internacional de medi o funcional ISO IEC 20926 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 130 As principais cr ticas s o a grande varia o na interpreta o das 14 caracter sticas gerais de sistemas e a constata o que algumas delas est o desatualizadas e Calcular os pontos de fun o ajustados finalmente os PFs ajustados s o calculados considerando se o tipo de contagem definido no primeiro passo A figura A 2 apresenta uma vis o geral dos tipos de fun o que s o considerados na contagem da APF Usu rio Externo Entrada Sa da Consulta Externa Externa Externa Entrada Externa Sa da Externa Arquivo L gico Consulta Externa Arquivo de Interface Intemo C Externa Aplica o sendo contada Outras aplica es Figura A 2 Vis o Geral das Fun es de uma Aplica o segundo a APF Contagem das Fun es de Dados Conforme discutido anteriormente o primeiro passo para a contagem das fun es de dados consiste em identificar arquivos l gicos internos ALIs e arquivos de interface externa AIEs Cada uma dessas fun es de dados deve ser classificada segundo sua complexidade funcional Essa complexidade definida com base em dois conceitos registros l gicos e itens de dados Registros L gi
137. ema a ser desenvolvido impossibilita a ado o de um modelo sequencial sobretudo pela necessidade de disponibilizar rapidamente uma vers o para o usu rio Nesses casos um modelo incremental indicado PRESSMAN 2011 No desenvolvimento incremental o sistema dividido em subsistemas ou m dulos tomando por base a funcionalidade Os incrementos ou vers es s o definidos come ando com um pequeno subsistema funcional que a cada ciclo acrescido de novas funcionalidades Al m de acrescentar novas funcionalidades nos novos ciclos as funcionalidades providas anteriormente podem ser modificadas para melhor satisfazer s necessidades dos clientes usu rios 2 2 1 O Modelo de Processo Incremental O modelo incremental pode ser visto como uma filosofia b sica que comporta diversas varia es O princ pio fundamental que a cada ciclo ou itera o uma vers o operacional do sistema produzida e entregue para uso ou avalia o detalhada do cliente Para tal requisitos t m de ser minimamente levantados e h de se constatar que o sistema modular de modo que se possa planejar o desenvolvimento em incrementos O primeiro incremento tipicamente cont m funcionalidades centrais tratando dos requisitos b sicos Outras caracter sticas s o tratadas em ciclos subsequentes Dependendo do tempo estabelecido para a libera o dos incrementos algumas atividades podem ser feitas para o sistema como um todo ou n o A Figura 2
138. ema usando apenas uma t cnica recomend vel utilizar v rias t cnicas diferentes sobretudo dependendo da fase Testes estruturais que utilizam o conhecimento da implementa o s o mais adequados para testes de unidade ainda que possam ser usados em alguns casos de integra o Testes funcionais que utilizam o conhecimento da especifica o Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 86 podem ser utilizados em quaisquer n veis sendo a principal op o para testes de integra o e de sistema Um plano de testes deve ser utilizado para guiar todas as atividades de teste e deve incluir objetivos do teste abordando cada tipo unidade integra o e sistema como ser o executados e quais crit rios a serem utilizados para determinar quando o teste est completo Uma vez que os testes est o relacionados aos requisitos dos clientes e usu rios o planejamento dos testes pode come ar t o logo a especifica o de requisitos tenha sido elaborada medida que o processo de desenvolvimento avan a an lise projeto e implementa o novos testes v o sendo planejados e incorporados ao plano de testes A automatiza o do processo de teste um importante fator para o sucesso no teste de software O processo de teste tende a ser extremamente dispendioso e muito importante utilizar ferramentas de apoio ao teste para buscar
139. ente Conforme anteriormente citado os testes de unidade s o constru dos durante a implementa o Para tal XP preconiza que deve ser usado um framework de automatiza o de testes de modo que uma estrat gia de testes de regress o possa ser adotada A premissa de XP que consertar problemas pequenos a cada duas ou tr s horas gasta menos tempo do que consertar problemas enormes perto da data de entrega Testes de aceita o s o especificados pelo cliente com base nas hist rias de usu rio 9 3 2 Scrum Scrum tem como premissa a exist ncia do caos O nome deste m todo vem de uma atividade que ocorre em partidas de Rugby Os principais princ pios de Scrum s o PRESSMAN 2011 e Equipes pequenas s o organizadas para maximizar a comunica o minimizar o overhead e compartilhar conhecimento t cito e informal e O processo deve ser adapt vel a mudan as t cnicas e de neg cio e H incrementos frequentes e regulares de software que podem ser inspecionados ajustados testados documentados e expandidos e O trabalho e os membros da equipe s o divididos em parti es de baixo acoplamento e Documenta o e testes constantes s o feitos medida que o produto constru do e O processo tem a capacidade de declarar o produto como pronto a qualquer momento por qualquer motivo a concorr ncia saiu na frente o usu rio precisa do sistema acabou o prazo etc O processo de Scrum envolve as seguintes ativi
140. ente cpf nome endere o telefone comercial telefone residencial telefone comercial telefone residencial 3 7 Modelagem de Fluxos de Dados Uma perspectiva igualmente importante para a an lise dos requisitos de um sistema aquela que considera as fun es que o sistema dever executar para atender s necessidades de seus usu rios A Modelagem de Fluxos de Dados a t cnica mais empregada para este fim pelos m todos de an lise segundo o paradigma estruturado Diagramas de Fluxos de Dados DFDs s o a parte gr fica de um Modelo de Fluxos de Dados DFDs permitem representar um sistema como uma rede de processos interligados entre si por fluxos de dados e dep sitos de dados DFDs utilizam se de quatro s mbolos gr ficos visando representar os seguintes componentes Processos Fluxos de Dados Dep sitos de Dados e Entidades Externas A Figura 3 22 mostra a nota o usada por Yourdon 1990 que ser a adotada neste texto Processos e Fluxos de Dados Entidades Externas Dep sitos de Dados Figura 3 22 Nota o b sica para constru o de DFDs Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 37 Al m dos Diagramas de Fluxos de Dados s o necess rios para uma completa modelagem das fun es e Dicion rio de Dados adicionar no dicion rio produzido para o Modelo ER um entrada para cada fluxo de
141. es a saber 1 1 4 n 1 ii 1 2 4 n 2 e iii 1 2 3 2 4 n gt 2 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 83 Os crit rios baseados no fluxo de controle como o pr prio nome diz utilizam apenas caracter sticas de controle da execu o do programa comandos condi es e la os para derivar casos de teste Os principais crit rios baseados no fluxo de controle s o e Todos os n s requer que cada n do grafo e por conseguinte cada comando do programa seja executado pelo menos uma vez Isso o m nimo esperado de uma boa atividade de teste e Todos os arcos requer que cada arco do grafo cada desvio de fluxo de controle seja exercitado pelo menos uma vez e Todos os caminhos requer que todos os caminhos poss veis no programa sejam exercitados o que muitas vezes impratic vel No exemplo do GFC da Figura 5 2 se for adotado o crit rio todos os n s basta um nico caso de teste com n gt 2 Se for adotado o crit rio todos os arcos s o necess rios pelo menos dois casos de teste n 1 arco 1 4 en gt 2 demais arcos J o crit rio todos os caminhos requer infinitos casos de teste O teste estrutural apresenta uma importante limita o se um programa n o implementa uma fun o n o existir um caminho que corresponda a ela e nenhum dado de te
142. es instaladas Para projetos de desenvolvimento o c lculo dado por PF PENA VFA onde PFNA N mero de PFs n o ajustados e VFA valor do fator de ajuste Refer ncia C Hazan Medi o da Qualidade e Produtividade em Software In Qualidade e Produtividade em Software 4 edi o K C Weber A R C Rocha C J Nascimento organizadores Makron Books 2001 p 25 41 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 135 As 14 Caracter sticas Gerais e seus Graus de Influ ncia Dias 2004 Grau Descri o 0 Nenhuma influ ncia 1 Influ ncia minima 2 Influ ncia moderada 3 Influ ncia m dia 4 Influ ncia significante 5 Influ ncia forte 1 Comunica o de dados os aspectos relacionados aos recursos utilizados para a comunica o de dados do sistema dever o ser descritos de forma global Descrever se a aplica o utiliza protocolos diferentes para recebimento envio das informa es do sistema PDS Aplica o batch ou funciona stand alone Aplica o batch mas utiliza entrada de dados ou impress o remota Aplica o batch mas utiliza entrada de dados e impress o remota Aplica o com entrada de dados on line para alimentar processamento batch ou sistema de consulta Aplica o com entrada de dados on line mas suporta apenas um tipo de protocolo de comunica o
143. finir casos de teste para testar todos os valores e Seo dom nio de entrada aceita valores num ricos dentro de um certo intervalo ent o se devem definir casos de teste para testar os extremos e um valor no interior do intervalo e Se o dom nio de sa da de valores num ricos discretos ent o se devem definir casos de teste gerando todos os valores Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 81 e Seo dom nio de sa da de valores num ricos dentro de um certo intervalo ent o se devem definir casos de teste para gerar os extremos e pelo menos um valor no interior do intervalo e Para testar valores de entrada ilegais devem ser inclu dos casos de teste para verificar se o software os rejeita Neste caso diretrizes do crit rio de an lise de valor limite devem ser empregadas e Definir casos de teste para explorar tipos ilegais que podem ser interpretados como valores v lidos p ex valor real para um campo inteiro e Definir casos de teste para explorar entradas v lidas mas que podem ser interpretadas como tipos ilegais p ex n meros em campos que requerem caracteres e Definir casos de teste para explorar limites da representa o bin ria dos dados p ex para campos inteiros de 16 bits selecionar os valores 32768 e 32767 Para tratar o problema da corre o coincidente o teste funcional sistem ti
144. ganiza o estrutura da equipe e coordena o Al m disso h diversos fatores que afetam a forma o de equipes relacionamentos interpessoais tipo do projeto criatividade etc No que se refere organiza o estrutura das equipes h diversas formas de se estruturar equipes A maneira mais tradicional consiste em estabelecer uma hierarquia de autoridade na qual o projeto possui um l der o qual respons vel por atribuir as tarefas e acompanhar o andamento do projeto Nesta estrutura a comunica o entre o l der e os demais membros da equipe vertical Esta estrutura pode se tornar mais flex vel mantendo a figura do l der de projeto mas estabelecendo uma comunica o mais horizontal na qual os membros da equipe t m mais liberdade e poder de decis o Uma maneira bem mais flex vel consiste em n o haver um l der permanente e as decis es serem tomadas por consenso do grupo A comunica o entre os membros da equipe horizontal Geralmente projetos de inova o s o organizados desta maneira ltima maneira pois ela estimula a criatividade a colabora o e a participa o engajada no projeto Na forma o de equipes deve se levar em conta o tamanho da equipe Quanto maior o n mero de membros da equipe maior a quantidade de caminhos poss veis de comunica o o que pode ser um problema uma vez que o n mero de pessoas que podem se comunicar com outras pode afetar a qualidade do produto resultante 8 1 2
145. ganizacional Defini o do Processo Organizacional Defini o do Processo Organizacional Ger ncia de Projetos evolu o Ger ncia de Projetos Integrada Ger ncia de Recursos Humanos Treinamento Organizacional Ger ncia de Reutiliza o D Desenvolvimento de Requisitos Desenvolvimento de Requisitos Integra o do Produto Integra o do Produto Projeto e Constru o do Produto Solu o T cnica Verifica o Verifica o Valida o Valida o C Desenvolvimento para Reutiliza o Ger ncia de Decis es An lise e Tomada de Decis es Ger ncia de Riscos Ger ncia de Riscos 9 2 Processos Padr o V rios dos modelos e normas de qualidade de processo discutidos anteriormente p ex processo Defini o do Processo Organizacional do MR MPS preconizam que embora diferentes projetos requeiram processos com caracter sticas espec ficas para atender s suas particularidades poss vel estabelecer um conjunto de ativos de processo subprocessos atividades subatividades artefatos recursos e procedimentos a ser utilizado na defini o de processos de software de uma organiza o Essas cole es de ativos de processo de software constituem os chamados processos de software padr o Processos para projetos especificos Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do E
146. garantir Os resultados do levantamento de requisitos devem ser documentados em um documento de requisitos Normalmente este documento tem um formato pr definido pela organiza o contendo dentre outros listas de requisitos funcionais n o funcionais e regras de neg cio descritos em linguagem natural 3 4 An lise de Requisitos A an lise de requisitos muitas vezes chamada an lise de sistemas por outro lado enfoca o que o sistema tem de ter para tratar adequadamente os requisitos levantados Assim sendo a an lise de requisitos em ltima inst ncia uma atividade de constru o de modelos Um modelo uma representa o de alguma coisa do mundo real uma abstra o da realidade e portanto representa uma sele o de caracter sticas do mundo real relevantes para o prop sito do sistema em quest o Um bom exemplo de modelos s o os mapas Como ilustra a Figura 3 3 h mapas por exemplo que focalizam a estrutura pol tica de um estado enquanto outros podem enfocar aspectos relacionados a turismo neste mesmo estado No exemplo da Figura 3 3 a entidade sendo representada a mesma o estado do Esp rito Santo contudo as perspectivas de aten o s o diferentes Modelos s o fundamentais no desenvolvimento de sistemas Tipicamente eles s o constru dos para e possibilitar o estudo do comportamento do sistema e facilitar a comunica o entre membros da equipe de desenvolvimento e clientes e usu rios
147. genharia de software inicialmente o problema a ser tratado deve ser analisado e decomposto em partes menores Para cada uma dessas partes uma solu o deve ser elaborada Solucionados os subproblemas isoladamente necess rio integrar as solu es Para tal uma arquitetura deve ser Engenharia de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 2 estabelecida Para apoiar a resolu o de problemas procedimentos m todos t cnicas roteiros etc devem ser utilizados bem como ferramentas para automatizar pelo menos parcialmente o trabalho Neste cen rio raramente poss vel conduzir o desenvolvimento de um produto de software de maneira individual Pessoas t m de trabalhar em equipes o esfor o tem de ser planejado coordenado e acompanhado bem como a qualidade do que se est produzindo tem de ser sistematicamente avaliada 1 1 Qualidade de Software Uma vez que um dos objetivos da Engenharia de Software melhorar a qualidade dos produtos de software desenvolvidos uma quest o deve ser analisada O que qualidade de software Se perguntarmos a um usu rio provavelmente ele dir que um produto de software de boa qualidade se ele satisfizer suas necessidades sendo f cil de usar eficiente e confi vel Essa uma perspectiva externa de observa o pelo uso do produto Por outro lado para um desenvolvedor um produto de boa qualidad
148. gnificado imprescind vel bem como o uso adequado de recuo e espa amento entre linhas de c digo que ajudam a visualizar a estrutura de controle do programa PFLEEGER 2004 Al m da documenta o interna escrita no pr prio c digo importante que o c digo de um sistema possua tamb m uma documenta o externa incluindo uma vis o geral dos componentes do sistema grupos de componentes e da inter rela o entre eles PFLEEGER 2004 Ainda que padr es sejam muito importantes deve se ressaltar que a correspond ncia entre os componentes do projeto e o c digo fundamental caracterizando se como a mais importante quest o a ser tratada O projeto o guia para a implementa o ainda que o programador tenha certa flexibilidade para implement lo como c digo PFLEEGER 2004 Como resultado de uma implementa o bem sucedida as unidades de software devem ser codificadas e crit rios de verifica o das mesmas devem ser definidos 5 2 Princ pios Gerais de Teste de Software O desenvolvimento de software est sujeito a diversos tipos de problemas os quais acabam resultando na obten o de um produto diferente daquele que se esperava Muitos fatores podem ser identificados como causas de tais problemas mas a maioria deles tem como origem o erro humano DELAMARO et al 2007 Para avaliar a qualidade de um produto de software h dois tipos principais de atividades e Verifica o visa assegurar que o software
149. gue contar como 6 itens Pontua o 0 Nenhum dos itens descritos 1 De um a tr s itens descritos 2 De quatro a cinco dos itens descritos 3 Mais de cinco dos itens descritos mas n o h requisitos espec ficos do usu rio quanto usabilidade do sistema Mais de cinco dos itens descritos e foram estabelecidos requisitos quanto usabilidade fortes o suficiente para gerarem atividades espec ficas envolvendo fatores tais como minimiza o da digita o para mostrar inicialmente os valores utilizados com mais frequ ncia 5 Mais de cinco dos itens descritos e foram estabelecidos requisitos quanto usabilidade fortes o suficiente para requerer ferramentas e processos especiais para demonstrar antecipadamente que os objetivos foram alcan ados a Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 138 8 Atualiza es on line Mede a influ ncia no desenvolvimento do sistema face utiliza o de recursos que visem a atualiza o dos Arquivos L gicos Internos no modo on line 0 l 2 W Nenhuma Atualiza o on line de um a tr s arquivos l gicos internos O volume de atualiza o baixo e a recupera o de dados simples Atualiza o on line de mais de tr s arquivos l gicos internos O volume de atualiza o baixo e a recupera o dos dados simples Atualiza o on line da maioria dos arq
150. ina p s requisito cursou Figura 3 20 Exemplo de ocorr ncia de restri es de integridade Nesse exemplo gostariamos de dizer dentre outras coisas que um aluno n o pode se matricular duas vezes na mesma turma ainda que ele possa se matricular em v rias turmas Al m disso um aluno s pode se matricular em uma turma de uma disciplina se j tiver cursado todos os pr requisitos daquela disciplina Essas duas restri es sobre poss veis relacionamentos n o s o pass veis de serem capturadas pela nota o dos Diagramas ER e devem ser ent o escritas em linguagem natural como parte do Modelo ER mais precisamente no dicion rio de dados do projeto O primeiro tipo de restri o apontado no exemplo anterior dito uma restri o de integridade de repeti o e indica quantas vezes os mesmos dois elementos das entidades podem ser relacionados O segundo tipo dito uma restri o de integridade de depend ncia apontando que um relacionamento pode ser restringido por outro relacionamento ou depender de seus relacionamentos anteriores Restri es de Integridade sobre o Dom nio dos Atributos Ainda visando manter a integridade do modelo de dados devemos descrever no dicion rio de dados restri es de integridade que regem os valores dos atributos isto o conjunto de valores que um atributo pode assumir Esta tarefa deve ser feita utilizando se dos seguintes recursos e enumera o lista expl cita de valo
151. ior ou menor dependendo do tipo de manuten o a ser realizada Pfleeger 2004 aponta os seguintes tipos de manuten o Manuten o corretiva trata de problemas decorrentes de defeitos medida que falhas ocorrem elas s o relatadas equipe de manuten o que se encarrega de encontrar o defeito que causou a falha e faz as corre es nos requisitos an lise projeto ou implementa o conforme o necess rio Esse reparo inicial pode ser tempor rio visando manter o sistema funcionando Quando esse for o caso mudan as mais complexas podem ser implementadas posteriormente Manuten o adaptativa s vezes uma mudan a no ambiente do sistema incluindo hardware e software de apoio pode implicar em uma necessidade de adapta o Manuten o perfectiva consiste em realizar mudan as para melhorar algum aspecto do sistema mesmo quando nenhuma das mudan as for consequ ncia de defeitos Isso inclui a adi o de novas capacidades bem como amplia es gerais Manuten o preventiva consiste em realizar mudan as a fim de prevenir falhas Geralmente ocorre quando um mantenedor descobre um defeito que ainda n o causou falha e decide corrigi lo antes que ele gere uma falha Refer ncias do Cap tulo PFLEEGER S L Engenharia de Software Teoria e Pr tica 2 Edi o S o Paulo Prentice Hall 2004 SANCHES R Processo de Manuten o In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Ma
152. ipais cr ticas s o a grande varia o na interpreta o das 14 caracter sticas gerais de sistemas e a constata o que algumas delas est o desatualizadas Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 108 e Calcular os pontos de fun o ajustados finalmente os PFs ajustados s o calculados considerando se o tipo de contagem definido no primeiro passo e o fator de ajuste A Figura 8 3 apresenta uma vis o esquem tica dos tipos de fun o que s o considerados na contagem da APF J Usu rio Externo Entrada Sa da Consulta Externa Externa Externa Entrada Externa Sa da Externa Arquivo L gico Consulta Externa Arquivo de Interface emo DARE Externa Aplica o sendo contada Outras aplica es Figura 8 3 Vis o Esquem tica das Fun es de uma Aplica o segundo a APF Ainda que a obten o dos pontos de fun o seja dependente unicamente do conhecimento das funcionalidades requeridas e n o da tecnologia a ser empregada o maior problema da APF que os dados necess rios para essa an lise s o bastante imprecisos no in cio de um projeto e portanto gerentes de projeto s o muitas vezes obrigados a produzir estimativas antes de um estudo mais aprofundado Assim pode ser dif cil utilizar o m todo da APF integralmente para realizar as primeiras estimativas A APF antes de mais nada um m
153. is que a qualidade seja incorporada ao produto ao longo de seu processo de desenvolvimento De fato a qualidade dos produtos de software depende fortemente da qualidade dos processos usados para desenvolv los e mant los Seguindo uma tend ncia de outros setores a qualidade do processo de software tem sido apontada como fundamental para a obten o da qualidade do produto Abordagens de qualidade de processo tal como a s rie de padr es ISO 9000 sugerem que melhorando a qualidade do processo de software poss vel melhorar a qualidade dos produtos resultantes A premissa por detr s dessa afirmativa a de que processos bem estabelecidos que incorporam mecanismos sistem ticos para acompanhar o desenvolvimento e avaliar a qualidade no geral conduzem a produtos de qualidade Por exemplo quando se diz que um fabricante de eletrodom sticos uma empresa certificada ISO 9001 uma das normas da s rie ISO 9000 n o se est garantindo que todos os eletrodom sticos por ele produzidos s o Engenharia de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 3 produtos de qualidade Mas sim que ele tem um bom processo produtivo o que deve levar a produtos de qualidade 1 2 Processo de Software r Uma vez que a qualidade do processo de software o caminho para se obter a qualidade dos produtos de software importante estabelecer um processo de software
154. isposal Reuse A sset Process Maragement Process Clause 6411 Cause 732 Figura 9 1 Processos de Ciclo de Vida da ISO IEC 12207 Por fim a norma ISO IEC 15504 Information Technology Process Assessment Tecnologia da Informa o Avalia o de Processos ISO IEC 2004 um padr o para avalia o de processos de software Juntas as normas ISO IEC 12207 e ISO IEC 15504 estabelecem um framework com terminologias bem definidas e boas pr ticas para a defini o e avalia o de processos de software 9 1 2 O Modelo CMMI O Modelo de Maturidade e Capacidade Integrado Capability Maturity Model Integration CMMN SEI 2010 foi desenvolvido no Instituto de Engenharia de Software Software Engineering Institute SED da Universidade de Carnegie Mellon com o intuito de quantificar a capacidade de uma organiza o produzir produtos de software de alta qualidade de forma previs vel e consistente Sua motiva o inicial foi apontar as necessidades de melhoria nos projetos de desenvolvimento de software do Departamento de Defesa dos EUA O CMMI estruturado em cinco n veis de maturidade de 1 a 5 onde o n vel 1 o menos maduro e o n vel 5 o mais maduro Cada n vel de maturidade com exce o do n vel Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 118 1 composto de v rias reas de processo
155. ivo sejam de car ter evolutivo certamente ocorrer o De fato como o mundo din mico ocorrendo mudan as de pessoas de regras e processos de neg cio da estrat gia das organiza es e de tecnologia dentre outros fundamental que os sistemas evoluam para acompanhar essas mudan as de modo a continuamente satisfazer as necessidades de clientes e usu rios 6 1 Entrega A entrega n o meramente uma formalidade No momento em que o sistema ou uma vers o dele instalado no local de opera o e devidamente aceito necess rio ainda ajudar os usu rios a entenderem e a se sentirem mais familiarizados com o sistema Neste momento duas quest es s o cruciais para uma transfer ncia bem sucedida treinamento e documenta o PFLEEGER 2004 A opera o do sistema extremamente dependente de pessoal com conhecimento e qualifica o Portanto essencial que o treinamento de pessoal seja realizado para que os usu rios e operadores possam operar o sistema adequadamente A documenta o que acompanha o sistema tamb m tem papel crucial na entrega afinal ela ser utilizada como material de refer ncia para a solu o de problemas ou como informa es adicionais Essa documenta o inclui dentre outros manuais do usu rio e do operador guia geral do sistema tutoriais e ajuda help preferencialmente on line PFLEEGER 2004 6 2 Manuten o O desenvolvimento de um sistema termina quando o produto ent
156. iza o consiste em aplicar inicialmente crit rios mais fracos e talvez menos eficazes por m menos custosos Em fun o da disponibilidade de or amento e de tempo da criticidade de um programa e da maturidade da organiza o poder se iam aplicar crit rios mais fortes e eventualmente mais eficazes por m mais caros Todas as t cnicas de teste se aplicam ao teste de unidade sendo que os testes estruturais tem foco neste n vel Todas as t cnicas de teste se aplicam ao teste de integra o com destaque para o teste funcional Por fim para testes de sistema tipicamente aplicam se t cnicas de teste funcional Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 84 5 5 Processo de Teste O processo de teste pode ser definido como um processo separado mas intimamente ligado ao processo de desenvolvimento Isso porque eles t m metas e medidas de sucesso diferentes Por exemplo quanto menor a taxa de defeitos raz o entre o n de casos de teste que falham pelo total de casos de teste mais bem sucedido considerado o processo de desenvolvimento Por outro lado quanto maior a taxa de defeitos considera se mais bem sucedido o processo de teste MCGREGOR SYKES 2001 O processo de teste envolve quatro atividades principais PFLEEGER 2004 MALDONADO FABBRI 2001 Planejamento de Testes trata da defini o dos requisitos d
157. jeto em quest o produto ou processo 2 Para cada caracter stica de qualidade selecionada definir subcaracter sticas de qualidade relevantes que tenham influ ncia sobre a mesma estabelecendo um modelo ou f rmula de computar a caracter stica a partir das subcaracter sticas F rmulas baseadas em peso s o bastante utilizadas cq p scqy Pn scqn 3 Usar procedimento an logo ao anterior para as subcaracter sticas n o pass veis de mensura o direta 4 Para as subcaracter sticas diretamente mensur veis selecionar medidas coletar dados e computar as medidas segundo a f rmula ou modelo estabelecido 5 Fazer o caminho inverso agora computando subcaracter sticas n o diretamente mensur veis at se chegar a um valor para a caracter stica de qualidade Conclu do o processo de medi o deve se comparar os valores obtidos com padr es estabelecidos para a organiza o de modo a se obter os indicadores da qualidade A partir dos indicadores a es devem ser tomadas visando melhoria da qualidade Vale destacar que especialmente no caso da avalia o da qualidade de software medidas relacionadas a defeitos s o bastante teis tal como n mero de erros por linhas de c digo O nico modo racional de melhorar um produto ou processo medir atributos espec ficos obter um conjunto de medidas significativas baseadas nesses atributos e usar os valores medidos para fornecer indicadores que conduzir o
158. jeto avan a acompanhamento do projeto T cnicas de decomposi o a segunda op o usam a abordagem dividir para conquistar na realiza o de estimativas Atrav s da decomposi o do projeto em m dulos fun es decomposi o do produto e atividades mais importantes decomposi o do processo estimativas s o geradas para por es do projeto ditos pacotes de trabalho Assim a Estrutura Anal tica do Projeto como a mostrada na Tabela 8 1 pode ser utilizada para estimar por exemplo tamanho ou esfor o Modelos emp ricos tipicamente usam f rmulas matem ticas derivadas em experimentos para prever esfor o como uma fun o de tamanho linhas de c digo pontos de fun o dentre outras medidas Entretanto deve se observar que os dados emp ricos que suportam a maioria desses modelos s o derivados de um conjunto limitado de projetos Al m disso fatores culturais da organiza o n o s o considerados no uso de modelos emp ricos pois os projetos que constituem a base de dados do modelo s o externos organiza o Apesar de suas limita es modelos emp ricos s o teis e podem ser usados em conjunto com informa es hist ricas da organiza o para estabelecer suas pr prias correla es Finalmente na ltima op o dados de projetos anteriores armazenados em um reposit rio de experi ncias da organiza o podem prover uma perspectiva hist rica importante e ser uma boa fonte para estimativas At
159. jeto de software consiste na determina o do escopo do produto de software a ser desenvolvido PRESSMAN 2011 Basicamente o escopo do produto composto pela especifica o de um conjunto de funcionalidades requisitos funcionais associada a outras caracter sticas desejadas requisitos n o funcionais tais como desempenho confiabilidade etc Para que o escopo do software seja determinado um levantamento preliminar de requisitos deve ser realizado O escopo pode ser documentado de v rias formas sempre contendo uma breve descri o das fun es do sistema requisitos n o funcionais importantes e o contexto e objetivos do sistema 8 4 Defini o do Processo de Software do Projeto O objetivo de se definir um processo de software favorecer a produ o de sistemas de alta qualidade atingindo as necessidades dos usu rios finais dentro de um cronograma e um or amento previs veis O processo de software n o pode ser definido de forma universal Para ser eficaz e conduzir constru o de produtos de boa qualidade o processo deve ser adequado s especificidades do projeto em quest o Deste modo processos devem ser definidos caso a caso considerando se as caracter sticas da aplica o dom nio do problema tamanho complexidade etc a tecnologia a ser adotada na sua constru o paradigma de desenvolvimento linguagem de programa o mecanismo de persist ncia etc a organiza o onde o produto ser desenvolvid
160. l do Esp rito Santo 60 s o apenas algumas das muitas quest es que devem ser levantadas durante o projeto da interface com o usu rio PRESSMAN 2011 De maneira geral o projeto de interfaces com o usu rio segue o seguinte processo global como mostra a Figura 4 18 1 Delinear as tarefas necess rias para obter a funcionalidade do sistema este passo visa capturar as tarefas que as pessoas fazem normalmente no contexto do sistema e mape las em um conjunto similar mas n o necessariamente id ntico de tarefas a serem implementadas no contexto da interface homem m quina Estabelecer o perfil dos usu rios A interface do sistema deve ser adequada ao n vel de habilidade dos seus futuros usu rios Assim necess rio estabelecer o perfil dos potenciais usu rios e classific los segundo aspectos como n vel de habilidade n vel na organiza o e membros em diferentes grupos Considerar aspectos gerais de projeto de interface tais como tempo de resposta facilidades de ajuda mensagens de erro tipos de comandos entre outros Construir prot tipos e em ltima inst ncia implementar as interfaces do sistema usando ferramentas apropriadas A prototipagem abre espa o para uma abordagem iterativa de projeto de interface com o usu rio Para tal imprescind vel o suporte de ferramentas para a constru o de interfaces provendo facilidades para manipula o de janelas menus bot es comandos etc Avaliar o
161. lacionamento Tern rio No caso de relacionamentos tern rios deve se criar uma nova tabela contendo as chaves das tr s entidades envolvidas como mostra a Figura 4 15 Assim como no caso dos relacionamentos bin rios N N se existirem atributos do relacionamento esses dever o ser colocados na nova tabela Caso seja necess rio algum desses atributos pode ser designado para compor a chave prim ria da nova tabela Diagrama E R Diagrama Relacional Figura 4 15 Relacionamentos Tern rios no Diagrama Relacional Particionamento No caso de particionamento de conjuntos de entidades deve se criar uma tabela para o super tipo e tantas tabelas quantos forem os sub tipos todos com a mesma chave como Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 59 mostra a Figura 4 16 Caso n o haja no modelo conceitual um atributo determinante no super tipo uma chave prim ria deve ser criada para fazer a amarra o com os sub tipos HST Sub tipol Sub tipoN Q ST Sub tipo1 Sub tipoN Figura 4 16 Tradu o de Particionamento Atributos Multivalorados Segundo a propriedade do modelo relacional que nos diz que cada c lula de uma tabela pode conter no m ximo um nico valor n o podemos representar atributos multivalorados como uma nica coluna da tabela H algumas solu es poss veis para este problema tal como criar tantas co
162. las De maneira geral um modelo de processo descreve uma filosofia de organiza o de atividades estruturando as atividades do processo em fases e definindo como essas fases est o relacionadas Entretanto ele n o descreve um curso de a es preciso recursos procedimentos e restri es Ou seja ele um importante ponto de partida para definir como o projeto ser conduzido mas a sua ado o n o o suficiente para guiar e controlar um projeto de software na pr tica Os modelos de ciclo de vida de maneira geral contemplam apenas as fases do processo de desenvolvimento An lise e Especifica o de Requisitos Projeto Implementa o Testes e Entrega e Implanta o A escolha de um modelo de processo fortemente dependente das caracter sticas do projeto dentre elas tipo de software a ser desenvolvido p ex sistema de informa o sistema de tempo real etc paradigma de desenvolvimento estruturado orientado a objetos etc tamanho e complexidade do sistema estabilidade dos requisitos e caracter sticas da equipe Assim importante conhecer alguns modelos e em que situa es s o aplic veis Os principais modelos de processo podem ser agrupados em tr s categorias principais modelos sequenciais modelos incrementais e modelos evolutivos 2 1 Modelos de Processo Sequenciais Como o nome indica os modelos sequenciais organizam o processo em uma sequ ncia linear de atividades O principal modelo desta categoria
163. ldonado K Weber Prentice Hall 2001 Parte II Ger ncia de Software Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 90 Cap tulo 7 Ger ncia da Qualidade Uma das principais metas da Engenharia de Software a produ o de software de qualidade Entretanto que caracter sticas um determinado produto precisa apresentar para considerarmos que o mesmo tem qualidade Seja o exemplo de autom veis Para se definir o conceito de qualidade de um autom vel diversos fatores s o levados em conta Fatores como conforto seguran a desempenho beleza e custo t m estreita rela o com a qualidade No caso de produtos de software caracter sticas como adequa o funcional desempenho confiabilidade usabilidade portabilidade e manutenibilidade est o diretamente relacionados qualidade mas o grau em que cada uma delas precisa ser atendida pode variar de sistema para sistema Assim por estes exemplos podemos perceber que qualidade um conceito relativo Ainda que qualidade seja um conceito relativo poss vel estabelecer duas diretrizes b sicas a saber e Qualidade est fortemente relacionada conformidade com os requisitos e Qualidade diz respeito satisfa o do cliente Problemas no produto de software resultante podem decorrer de problemas na especifica o dos seus requisitos ou na deriva o dos diversos art
164. lunas quantas necess rias para representar o atributo Essa solu o contudo pode em muitos casos n o ser eficiente ou mesmo poss vel Uma solu o mais geral para este problema criar uma tabela em separado como mostra a Figura 4 17 HCl Cli Num telefone Figura 4 17 Mapeamento Geral de Atributos Multivalorados 4 2 Projeto de Interface com o Usu rio A maioria dos sistemas atuais desenvolvida para ser utilizada por pessoas Assim um aspecto fundamental no projeto de sistemas a interface com o usu rio IU Nessa etapa do projeto s o definidos os formatos de janelas e relat rios entre outros sendo a prototipagem bastante utilizada buscando auxiliar o desenvolvimento e a sele o dos mecanismos reais de intera o A IU respons vel por definir como um usu rio comandar o sistema e como o sistema apresentar as informa es a ele O princ pio b sico para o projeto de interfaces com o usu rio o seguinte Conhe a o usu rio e as tarefas O projeto de interface com o usu rio envolve n o apenas aspectos de tecnologia facilidades para interfaces gr ficas multim dia etc mas principalmente o estudo das pessoas Quem o usu rio Como ele aprende a interagir com um novo sistema Como ele interpreta uma informa o produzida pelo sistema O que ele espera do sistema Essas Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federa
165. m projeto de software A atividade de Ger ncia de Requisitos pode ser vista como a Ger ncia de Configura o aplicada a requisitos A Figura 3 2 procura ilustrar o posicionamento das atividades da Engenharia de Requisitos no processo de software Ger ncia de Configura o Ger ncia da Qualidade Figura 3 2 As Atividades da Engenharia de Requisitos no Processo de Software Uma vez que o foco desta primeira parte das notas de aula o processo de desenvolvimento as atividades de levantamento e an lise de requisitos s o estudadas com maiores detalhes As demais atividades s o discutidas na Parte II destas notas de aula 3 3 Levantamento de Requisitos O levantamento de requisitos uma atividade de descoberta de informa es Para poder capturar os requisitos de um sistema necess rio compreender dentre outros o dom nio de aplica o os processos de neg cio a serem apoiados pelo sistema os problemas que se pretende resolver e necessidades e restri es dos envolvidos Para se ganhar este entendimento diversas fontes podem ser pesquisadas dentre elas material bibliogr fico manuais de funcionamento da organiza o documentos da organiza o e as pessoas envolvidas dentre elas especialistas do dom nio clientes e usu rios O levantamento de requisitos uma atividade complexa que n o se resume somente a perguntar s pessoas o que elas desejam e tamb m n o uma simples transfer ncia de conhecimento
166. n es Os argumentos igualmente v lidos exploravam considera es como e Dados s o mais est veis que fun es e Sem um entendimento das fun es a serem desempenhadas pelo sistema como definir o escopo e os dados necess rios A An lise Essencial procurou estabelecer um novo ponto de partida para a especifica o de um sistema a identifica o dos eventos que o afetam POMPILHO 1995 De fato com essa abordagem a an lise essencial passava a abranger tamb m o levantamento de requisitos uma vez que a An lise Estruturada Moderna focava somente na an lise de requisitos A identifica o de eventos passou a ser usada tamb m para a decomposi o funcional dos sistemas Atualmente praticamente nenhum desses m todos aplicado integralmente na pr tica Contudo as t cnicas por eles empregadas s o ainda bastante usadas muitas vezes combinadas com outras t cnicas mais modernas de especifica o de sistemas como a Modelagem de Casos de Uso Assim neste texto s o abordadas algumas das principais t cnicas de modelagem de sistemas aplicadas no desenvolvimento de sistemas segundo o paradigma estruturado a saber Modelagem de Entidades e Relacionamentos Modelagem de Casos de Uso Modelagem de Fluxos de Dados e Modelagem de Estados 3 6 Modelagem de Entidades e Relacionamentos A Modelagem de Entidades e Relacionamentos uma t cnica utilizada para representar os dados a serem armazenados em um sistema tendo sido de
167. n o utilizando as tabelas A 2 para entradas externas e A 3 para sa das e consultas externas Nessas tabelas um arquivo referenciado pode ser um ALI lido ou mantido pela fun o transacional ou um ATE lido pela fun o transacional J o n mero de itens de dados referenciados calculado considerando apenas os itens de dados efetivamente referenciados pela fun o transacional em quest o Tabela A 2 Tabela de Identifica o da Complexidade de Entradas Externas N mero de Arquivos N mero de Itens de Dados Referenciados Referenciados De 5a 15 00ul Simples Simples M dia 2 Simples M dia Complexa 3 ou mais M dia Complexa Complexa Tabela A 3 Tabela de Identifica o da Complexidade de Sa das e Consultas Externas N mero de Arquivos N mero de Itens de Dados Referenciados Referenciados De 6 a 19 00ul Simples Simples M dia 20u3 Simples M dia Complexa 4 ou mais M dia Complexa Complexa C lculo dos Pontos de Fun o N o Ajustados Uma vez contadas as fun es de dados e as fun es transacionais poss vel calcular os PFs n o ajustados de uma aplica o Esse c lculo feito da seguinte forma Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 132 1 Para cada um dos cinco tipos de fun o ALI AIE EE SE e CE s o computados os totais de pontos de fun
168. ne A an lise desta caracter stica permite quantificar o n vel de influ ncia exercida pela utiliza o de entrada de dados no modo on line no sistema Todas as transa es s o processadas em modo batch De 1 a 7 das transa es s o entradas de dados on line De 8 a 15 das transa es s o entradas de dados on line De 16 a 23 das transa es s o entradas de dados on line De 24 a 30 das transa es s o entradas de dados on line Mais de 30 das transa es s o entradas de dados on line pon df A o 7 Usabilidade a an lise desta caracter stica permite quantificar o grau de influ ncia relativo aos recursos implementados com vista a tornar o sistema amig vel permitindo incrementos na efici ncia e satisfa o do usu rio final tais como e Aux lio navega o teclas de fun o acesso direto e menus din micos Menus Documenta o e help on line Movimento autom tico do cursor Movimento horizontal e vertical de tela Impress o remota via transa es on line Teclas de fun o preestabelecidas Processos batch submetidos a partir de transa es on line Utiliza o intensa de campos com v deo reverso intensificados sublinhados coloridos e outros indicadores Impress o da documenta o das transa es on line atrav s de hard copy Utiliza o de mouse Menus pop up O menor n mero poss vel de telas para executar as fun es de neg cio Suporte bilingue contar como 4 itens Suporte multil n
169. no projeto detalhado de m dulos enquanto o DHF usado para o projeto da arquitetura do sistema Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 63 4 3 1 Diagrama Hier rquico de Fun es Um Diagrama Hier rquico de Fun es DHF define a arquitetura global de um programa ou sistema mostrando m dulos e suas inter rela es MARTIN MCCLURE 1991 Cada m dulo pode representar um subsistema programa ou m dulo de programa Sua finalidade mostrar os componentes funcionais gerais arquitetura do sistema e fazer refer ncia a diagramas detalhados tipicamente Diagramas de Estrutura Modular Um DHF n o mostra o fluxo de dados entre componentes funcionais ou qualquer informa o de estruturas de controle tais como la os loops ou condi es A estrutura de um DHF tem como ponto de partida um m dulo inicial localizado no topo da hierarquia que det m o controle sobre os demais m dulos do diagrama ditos seus m dulos filhos Um m dulo filho por sua vez pode ser pai de outros m dulos indicando que ele det m o controle sobre esses m dulos A constru o de um DHF deve procurar espelhar a estrutura do neg cio que o sistema est tratando A descri o do escopo com sua subdivis o em subsistemas e os casos de uso e descri es associadas devem ser a base para a constru o dos DHF s Cada execut vel deve dar origem a um DH
170. ntes sendo o n mero de PFs n o ajustados dado por nPFNA 7 nALI 5 nAIE 4 nEE 5 nSE 4 nCE Obviamente a contagem detalhada de pontos de fun o mais precisa que os demais tipos de contagem Entretanto requer um tempo maior para ser realizado e depende de especifica es mais detalhadas que na grande maioria das vezes n o existem no in cio de um projeto Vale destacar que estudos realizados pela NESMA com mais de 100 projetos apontam que a contagem estimativa tem menor dispers o em rela o contagem detalhada do que a contagem indicativa Assim uma boa op o iniciar as estimativas com uma t cnica simplificada tal como a Contagem Estimativa da NESMA e medida que um maior entendimento dos requisitos obtido passar contagem detalhada Al m disso os pontos de fun o devem ser recontados ao longo do processo nas atividades de acompanhamento de projetos para que ajustes de previs es possam ser realizados e controlados fornecendo feedback para situa es futuras 8 5 3 Estimativas de Esfor o Para a realiza o de estimativas de tempo cronol gico dura o e custo fundamental estimar antes o esfor o necess rio para completar o projeto ou cada uma de suas atividades Estimativas de esfor o podem ser obtidas diretamente pelo julgamento de especialistas usando t cnicas de decomposi o ou podem ser computadas a partir de dados de tamanho ou de dados hist ricos Quando as estimati
171. ntidades No modelo ER esses relacionamentos s o chamados de entidades associativas ou agregados Assim uma entidade associativa uma abstra o atrav s da qual um tipo de relacionamentos entre duas entidades tratado como um tipo de entidades em um n vel mais alto Essa nova entidade a entidade associativa pode ent o relacionar se com outras entidades do modelo como mostra a Figura 3 11 RIc y xeX yeY R2c x y x y e RI ze Zy Figura 3 11 Entidade Associativa A Figura 3 12 mostra um exemplo de entidade associativa Nesse exemplo o tipo de relacionamento Consulta assume o status de um tipo de entidade Uma consulta pode ser paga ent o por um Plano de Sa de Consulta Plano de Sa de Figura 3 12 Exemplo de Entidade Associativa Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 30 E importante observar que entidades associativas muitas vezes capturam eventos que ocorrem no mundo real e que precisam ser registrados no sistema Assim uma op o at mais clara representar esse evento como um tipo de entidades relacionado aos demais como ilustra a Figura 3 13 paga Plano de Sa de Figura 3 13 Evento representado como um Tipo de Entidade Particionamento de Entidades Muitas vezes inst ncias de entidades do mundo real se subdividem em categorias com atributos e
172. o No que se refere s atividades do processo de desenvolvimento o foco o levantamento de requisitos ainda que atividades de modelagem conceitual an lise e para a elabora o de um esbo o bastante inicial da arquitetura do sistema projeto possam ser realizadas Prot tipos podem ser constru dos para apoiar a comunica o com o cliente Elabora o os objetivos desta fase s o analisar o dom nio do problema estabelecer a arquitetura do sistema refinar o plano do projeto e identificar seus maiores riscos KRUCHTEN 2003 Assim em termos do processo de desenvolvimento o foco s o as atividades de an lise e projeto Constru o envolve o projeto detalhado de componentes sua implementa o e testes Nesta fase os componentes do sistema s o desenvolvidos integrados e testados Transi o como o pr prio nome indica o prop sito desta fase fazer a transi o do sistema do ambiente de desenvolvimento para o ambiente de produ o S o feitos testes de sistema e de aceita o e a entrega do sistema aos seus usu rios Cada fase por sua vez pode envolver um n mero arbitr rio de itera es dependendo das caracter sticas do projeto Al m disso todo o conjunto de fases tamb m pode ser realizado de maneira incremental em ciclos Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 17 Fases
173. o de processo de desenvolvimento Ele muito mais do que isso Ele uma abordagem completa para o desenvolvimento de software incluindo al m de um modelo de processo de software a defini o detalhada de responsabilidades pap is atividades artefatos e fluxos de trabalho dentre outros O modelo de processo do RUP tem como diferencial principal a sua organiza o em duas dimens es como ilustra a Figura 2 9 Na dimens o horizontal representada a estrutura do modelo em rela o ao tempo a qual organizada em fases e itera es Na dimens o vertical s o mostradas as atividades chamadas de disciplinas no RUP Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 16 Requisitos Modelagem An lise amp Projeto do Neg cio Planejamento Ger ncia de Implementa o Configura o Planejamento Ambiente Testes Inicial Avalia o Entrega Figura 2 8 Desenvolvimento Iterativo no RUP adaptado de KROLL KRUCHTEN 2003 No que se refere s fases o RUP considera quatro fases no desenvolvimento de software Concep o visa estabelecer um bom entendimento do escopo do projeto obtendo um entendimento de alto n vel dos requisitos a serem tratados KROLL KRUCHTEN 2003 Nesta fase o foco est na comunica o com o cliente para a identifica o de requisitos e nas atividades de planejament
174. o o produto resultante do primeiro ciclo pode ser uma especifica o do produto ou um estudo de viabilidade As passadas subsequentes ao longo da espiral podem ser usadas para desenvolver prot tipos chegando progressivamente a vers es operacionais do software at se obter o produto completo At mesmo ciclos de manuten o podem ser acomodados nesta filosofia fazendo com que o modelo espiral contemple todo o ciclo de vida do software PRESSMAN 2011 importante ressaltar que a cada ciclo o planejamento deve ser revisto com base no feedback do cliente ajustando inclusive o n mero de itera es planejadas De fato este o maior problema do ciclo de vida espiral ou de maneira geral dos modelos evolucion rios a ger ncia de projetos Pode ser dif cil convencer clientes especialmente em situa es envolvendo contrato que a abordagem evolutiva gerenci vel PRESSMAN 2011 2 4 Prototipa o Muitas vezes clientes t m em mente um conjunto geral de objetivos para um sistema de software mas n o s o capazes de identificar claramente as funcionalidades ou informa es requisitos que o sistema ter de prover ou tratar Modelos podem ser teis para ajudar a levantar e validar requisitos mas pode ocorrer dos clientes e usu rios s terem uma verdadeira dimens o do que est sendo constru do se forem colocados diante do sistema Nestes casos o uso da prototipa o fundamental A prototipa o uma t cnica p
175. o salvamento e recupera o mas a interven o do operador necess ria e Foram estabelecidos processos de inicializa o salvamento e recupera o e nenhuma interven o do operador necess ria conte como dois itens e A aplica o minimiza a necessidade de montar fitas magn ticas e A aplica o minimiza a necessidade de manuseio de papel 5 A aplica o foi desenhada para trabalhar sem operador nenhuma interven o do operador necess ria para operar o sistema al m de executar e encerrar a aplica o A aplica o possui rotinas autom ticas para recupera o em caso de erro 13 M ltiplos Locais e Organiza es do Usu rio consiste na an lise da arquitetura do projeto observando se a necessidade de instala o do sistema em diversos lugares 0 Os requisitos do usu rio n o consideraram a necessidade de instala o em mais de um local A necessidade de m ltiplos locais foi considerada no projeto e a aplica o foi desenhada para operar apenas em ambientes de software e hardware id nticos A necessidade de m ltiplos locais foi considerada no projeto e a aplica o est preparada para trabalhar apenas em ambientes similares de software e hardware A necessidade de m ltiplos locais foi considerada no projeto e a aplica o est preparada para trabalhar em diferentes ambientes de hardware e ou software Plano de documenta o e manuten o foram providos e testados para suportar a aplica o
176. o Cap tulo FUGGETTA A Software Process A Roadmap In Proceedings of The Future of Software Engineering ICSE 2000 Limerick Ireland 2000 ISO ZSO 9000 Quality management systems Fundamentals and vocabulary 2005 ISO IEC ISO IEC 12207 Systems and software engineering Software life cycle processes 2008 ISO IEC ISO EC 15504 Information technology Process assessment Part 1 Concepts and vocabulary 2004 PRESSMAN R S Engenharia de Software Uma Abordagem Profissional 7 Edi o McGraw Hill 2011 Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 127 ROCHA A R C MALDONADO J C WEBER K C Qualidade de Software Teoria e Pr tica S o Paulo Prentice Hall 2001 SEI CMMI for Development Version 1 3 Technical Report ESC TR 2010 33 2010 SOFTEX MPS BR Melhoria de Processo do Software Brasileiro Guia Geral 2011 Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 128 Anexo A An lise de Pontos de Fun o A An lise de Pontos de Fun o APF um m todo padr o para a medi o do desenvolvimento de software visando estabelecer uma medida de tamanho do software em Pontos de Fun o PFs com base na funcionalidade a ser implementada sob o ponto de vista do usu rio Os
177. o Esp rito Santo 33 Departamento Professor Disciplina Figura 3 19 Departamento como Nova Entidade 3 6 2 Restri es de Integridade Muitas vezes n o somos capazes de modelar toda a estrutura de informa o necess ria com um Diagrama ER sobretudo no que diz respeito a restri es Para suprir essa defici ncia de representa o dos Diagramas ER devemos adicionar ao modelo descri es textuais na forma de restri es de integridade isto restri es do mundo real que devem ser descritas para manter a integridade do modelo H dois tipos b sicos de restri es de integridade restri es sobre os poss veis relacionamentos e restri es sobre os valores dos atributos Restri es de Integridade em Relacionamentos Alguns relacionamentos s podem ocorrer se determinada restri o for satisfeita Um exemplo de restri o de integridade s o as cardinalidades Por exemplo se um funcion rio s pode estar lotado em um nico departamento ent o n o poss vel relacionar um funcion rio j lotado a um novo departamento A cardinalidade uma das poucas restri es de integridade que s o expressas no pr prio Diagrama ER Entretanto h outras situa es em que n o conseguimos capturar tais restri es Seja o exemplo da Figura 3 20 Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 34 Discipl
178. o chegamos a um n vel de especifica o em que os processos n o s o mais decompon veis precisamos complementar essa especifica o com descri es das l gicas dos processos A especifica o de processos deve ser feita de forma que possa ser validada por analistas e usu rios Entretanto encontramos muitos problemas na descri o de forma narrativa entre os quais podemos citar 1 uso de express es do tipo mas todavia a menos que ii uso de comparativos maior que menor que mais de menos de iii ambiguidades inerentes a frases concatenadas com e ou iv uso de adjetivos indefinidos p ex bom mau Para administrar os problemas oriundos da narrativa s o utilizadas t cnicas de especifica o de processos entre as quais podemos citar Portugu s Estruturado e Arvores de Decis o Portugu s Estruturado O Portugu s Estruturado um subconjunto do Portugu s cujas senten as s o organizadas segundo as tr s estruturas de controle introduzidas pela Programa o Estruturada sequ ncia sele o e repeti o e Instru es de Sequ ncia grupo de instru es a serem executadas que n o tenham repeti o e n o sejam oriundas de processos de decis o S o escritas na forma imperativa como no exemplo abaixo obter atribuir armazenar e Instru es de Sele o quando uma decis o deve ser tomada para que uma a o seja executada utilizamos uma instru o de sele o As instru es
179. o e a equipe de desenvolvimento H v rios aspectos a serem considerados na defini o de um processo de software No centro da arquitetura de um processo de desenvolvimento est o as suas atividades chave an lise de requisitos projeto implementa o e testes que s o a base sobre a qual o processo de desenvolvimento deve ser constru do Entretanto a defini o de um processo envolve a escolha de um modelo de ciclo de vida ou modelo de processo o detalhamento decomposi o de suas macro atividades a escolha de m todos t cnicas e roteiros procedimentos para a sua realiza o e a defini o de recursos p ex hardware e software pap is respons veis p ex analista programador e artefatos requeridos e produzidos A escolha de um modelo de ciclo de vida ou modelo de processo o ponto de partida para a defini o do processo de desenvolvimento Conforme discutido no Cap tulo 2 um modelo de processo organiza as macro atividades b sicas do processo de desenvolvimento estabelecendo preced ncia e depend ncia entre as mesmas Para a defini o completa do processo de desenvolvimento cada atividade descrita no modelo de processo deve ser decomposta e para suas subatividades devem ser associados m todos t cnicas ferramentas e crit rios de qualidade entre outros formando uma base s lida para o desenvolvimento Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo
180. o grau de paralelismo Um caso de uso pode ser capturado atrav s de conversas com usu rios t picos e clientes discutindo as v rias coisas que eles querem fazer com o sistema Cada uma dessas intera es discretas constitui um caso de uso D a ela um nome e escreva uma pequena descri o textual n o mais do que uns poucos par grafos N o tente capturar todos os detalhes de um caso de uso logo no in cio Os objetivos do usu rio podem ser o ponto de partida para a elabora o dos casos de uso Proponha um caso de uso para satisfazer cada um dos objetivos do usu rio A partir deles estude as poss veis intera es do usu rio com o sistema e refine o modelo de casos de uso Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 47 3 8 1 Diagramas de Casos de Uso Diagramas de casos de uso especificam as funcionalidades que um sistema tem de oferecer segundo diferentes perspectivas dos usu rios Em sua forma mais simples um diagrama de casos de uso apresenta os dois elementos b sicos atores e casos de uso A Figura 3 33 mostra a nota o b sica da Linguagem de Modelagem Unificada Unified Modeling Language UML BOOCH RUMBAUGH JACOBSON 2006 para diagramas de casos de uso Ator a de Uso 1 ns E E E Caso de Uso Caso de Uso 3 Ator 2 Caso de Uso 2 Figura 3 33 Nota o B sica da UML para Diagramas de Casos de
181. o ou de um processo uma quest o importante passa a ser Que atributos medir O modelo de qualidade definido na norma ISO IEC 9126 1 trata dessa quest o Esse modelo de qualidade subdividido em dois modelos i o modelo de qualidade para caracter sticas externas e internas e 11 o modelo de qualidade para qualidade em uso O primeiro classifica os atributos de qualidade de software em seis caracter sticas funcionalidade confiabilidade usabilidade efici ncia manutenibilidade e portabilidade que s o por sua vez desdobradas em subcaracter sticas As subcaracter sticas podem ser desdobradas em mais n veis at se ter subcaracter sticas diretamente mensur veis para as Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 97 quais medidas s o aplicadas As normas ISO IEC 9126 2 e 9126 3 apresentam respectivamente medidas externas e internas Esse modelo de qualidade preconiza a an lise de caracter sticas de qualidade a partir de suas subcaracter sticas de forma recursiva at que se tenham medidas para as quais seja poss vel coletar dados Esse modelo aplic vel n o somente a produtos de software mas tamb m para avaliar a qualidade de processos de software Assim de maneira geral na avalia o quantitativa da qualidade necess rio 1 Definir caracter sticas de qualidade relevantes para avaliar a qualidade do ob
182. o para um membro da equipe do projeto 8 5 6 Estimativa de Custo De posse das demais estimativas poss vel estimar os custos do projeto De maneira geral os seguintes itens devem ser considerados nas estimativas de custos e Custos relativos ao esfor o empregado pelos membros da equipe no projeto e Custos de hardware e software incluindo manuten o e Outros custos relacionados ao projeto tais como custos de viagens e treinamentos realizados no mbito do projeto e Despesas gerais incluindo gastos com gua luz telefone pessoal de apoio administrativo pessoal de suporte etc Para a maioria dos projetos o custo dominante o que se refere ao esfor o empregado juntamente com as despesas gerais Sommerville 2011 sugere que de modo geral os custos relacionados com as despesas gerais correspondem a um valor equivalente aos custos relativos ao esfor o empregado pelos membros da equipe no projeto Assim para efeitos de estimativas de custos pode se considerar esses dois itens como sendo um nico item computado em dobro Custos de hardware e software ainda que menos influentes n o devem ser desconsiderados sob pena de provocarem preju zos para o projeto Uma forma de tratar esses custos considerar a deprecia o com base na vida til do equipamento ou da vers o do software utilizada Quando o custo do projeto estiver sendo calculado como parte de uma proposta para o cliente ent o ser preciso definir
183. o pre o cotado Uma abordagem para defini o do pre o pode ser consider lo como o custo total do projeto mais o lucro Entretanto a rela o entre o Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 112 custo do projeto e o pre o cotado para o cliente normalmente n o t o simples assim SOMMERVILLE 2011 Estimativas de custo podem ser derivadas de estimativas de tamanho ou esfor o Por exemplo muitas organiza es que trabalham com pontos de fun o t m valores pr definidos da rela o R PF a serem utilizados na elabora o de estimativas de custo e na cota o de pre os para clientes Uma vez definido o custo de um projeto deve se elaborar um or amento ou cronograma financeiro do projeto indicando o momento e o valor de cada desembolso e de cada entrada de recursos do projeto 8 6 Ger ncia de Riscos Uma importante tarefa da ger ncia de projetos prever os riscos que podem prejudicar o bom andamento do projeto e definir a es a serem tomadas para evitar sua ocorr ncia ou quando n o for poss vel evitar a ocorr ncia para diminuir seus impactos Um risco qualquer condi o evento ou problema cuja ocorr ncia n o certa mas que pode afetar negativamente o projeto caso ocorra Assim os riscos envolvem duas caracter sticas principais 1 incerteza um risco pode ou n o acontecer isto
184. o projeto incorporar a tecnologia aos requisitos essenciais do usu rio projetando o que ser constru do na implementa o Para tal necess rio conhecer a tecnologia dispon vel e as facilidades do ambiente de software no qual o sistema ser implementado Dom nio do An lise e Mundo Real Especifica o bd de Requisitos o qu Projeto como Dom nio da Solu o Implementa o Computacional Figura 4 1 Vis o Geral da Atividade de Projeto O projeto de software um processo de refinamento Inicialmente o projeto representado em um n vel alto de abstra o A medida que o trabalho avan a os refinamentos conduzem a representa es de menores n veis de abstra o Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 51 Uma especifica o de projeto deve e Contemplar todos os requisitos especificados nos documentos de requisitos e Ser um guia compreens vel para aqueles que v o codificar testar e manter o software e Prover um quadro completo do software tratando aspectos funcionais comportamentais e de dados segundo uma perspectiva de implementa o Na fase de projeto modelos de projeto s o gerados a partir dos modelos de an lise com o objetivo de representar o que dever ser codificado na fase de implementa o Independentemente do paradigma adotado o projeto deve produzir e Projeto da
185. o usu rio Requisitos de desempenho foram estabelecidos e revistos mas nenhuma a o especial foi requerida Tempo de resposta e volume de processamento s o itens cr ticos durante hor rios de pico de processamento Nenhuma determina o especial para a utiliza o do processador foi estabelecida A data limite para a disponibilidade de processamento sempre o pr ximo dia til Tempo de resposta e volume de processamento s o itens cr ticos durante todo o hor rio comercial Nenhuma determina o especial para a utiliza o do processador foi estabelecida A data limite necess ria para a comunica o com outros sistemas limitante Os requisitos de desempenho estabelecidos requerem tarefas de an lise de desempenho na fase de planejamento e an lise da aplica o Al m do descrito no item anterior ferramentas de an lise de desempenho foram usadas nas fases de planejamento desenvolvimento e ou implementa o para atingir os requisitos de desempenho estabelecidos pelos usu rios 4 Utiliza o do Equipamento Trata se de observa es quanto ao n vel de utiliza o de equipamentos requerido para a execu o do sistema Este aspecto observado com vista a planejamento de capacidades e custos 0 l 2 0S Nenhuma restri o operacional explicita ou mesmo impl cita foi incluida Existem restri es operacionais leves N o necess rio esfor o especial para atender s restri es Algumas considera
186. ocessam dados ou informa es de controle que entram pela fronteira da aplica o O objetivo principal de uma EE manter um ou mais ALIs ou alterar o comportamento do sistema As Sa das Externas SEs s o processos elementares que enviam dados ou informa es de controle para fora da fronteira da aplica o Seu objetivo mostrar informa es recuperadas atrav s de um processamento l gico isto que envolva c lculos ou cria o de dados derivados e n o apenas uma simples recupera o de dados Uma SE pode tamb m manter um ALI ou alterar o comportamento do sistema Por fim uma Consulta Externa CE assim como uma SE um processo elementar que envia dados ou informa es de controle para fora da fronteira da aplica o mas sem realiza o de nenhum c lculo nem a cria o de dados derivados Seu objetivo apresentar informa o para o usu rio por meio apenas de uma recupera o das informa es Nenhum ALI mantido durante sua realiza o nem o comportamento do sistema alterado e Determinar o valor do fator de ajuste o fator de ajuste baseado em 14 caracter sticas gerais de sistemas que avaliam a funcionalidade geral da aplica o que est sendo contada e seus n veis de influ ncia O n vel de influ ncia de uma caracter stica determinado com base em uma escala de 0 nenhuma influ ncia a 5 forte influ ncia Assim o fator de ajuste visa a ajustar os pontos de fun o n o ajustados
187. ocesso de Software O processo de desenvolvimento de software como o pr prio nome indica a espinha dorsal do desenvolvimento de software e envolve as atividades que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente S o exemplos de Engenharia de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 4 atividades do processo de desenvolvimento especifica o e an lise de requisitos projeto e implementa o Paralelamente ao processo de software diversos processos de apoio e de ger ncia s o realizados O processo de ger ncia de projetos envolve atividades relacionadas ao planejamento e ao acompanhamento gerencial do projeto tais como realiza o de estimativas elabora o de cronogramas an lise dos riscos do projeto etc Os processos de apoio por sua vez visam apoiar provendo informa es ou servi os as atividades dos demais processos incluindo al m dos processos de desenvolvimento e de ger ncia de projetos os pr prios processos de apoio Dentre os processos de apoio h os processos de medi o ger ncia de configura o de software garantia da qualidade verifica o e valida o As atividades dos processos de ger ncia de projetos e de apoio n o est o ligadas diretamente constru o do produto final o software a ser entregue para o cliente incluindo toda a documenta o necess ria e
188. om o reaproveitamento de parte dos programas de uma aplica o em outras aplica es implica em cuidados com padroniza o O grau de influ ncia no dimensionamento do sistema quantificado observando se os seguintes aspectos Nenhuma preocupa o com reutiliza o de c digo C digo reutilizado foi usado somente dentro da aplica o 2 Menos de 10 da aplica o foi projetada prevendo utiliza o posterior do c digo por outra aplica o 3 10 ou mais da aplica o foi projetada prevendo utiliza o posterior do c digo por outra aplica o 4 A aplica o foi especificamente projetada e ou documentada para ter seu c digo reutilizado por outra aplica o e a aplica o customizada pelo usu rio em n vel de c digo fonte 5 A aplica o foi especificamente projetada e ou documentada para ter seu c digo facilmente reutilizado por outra aplica o e a aplica o customizada para uso atrav s de par metros que podem ser alterados pelo usu rio jp 11 Facilidade de implanta o a quantifica o do grau de influ ncia desta caracter stica feita observando se o plano de convers o e implanta o e ou ferramentas utilizadas durante a fase de testes do sistema 0 Nenhuma considera o especial foi estabelecida pelo usu rio e nenhum procedimento especial requerido na implanta o 1 Nenhuma considera o especial foi estabelecida pelo usu rio mas procedimentos especiais s o necess rios n
189. om uma senten a simples verbo objetos em seu interior e opcionalmente um identificador n mero A senten a deve tentar Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 38 descrever o melhor poss vel a fun o a ser desempenhada sem ambiguidades Devem ser evitados nomes muito f sicos p ex gravar imprimir etc ou muito t cnicos p ex apagar fazer backup etc Toda transforma o de dados deve ser representada e deste modo n o se admite liga o direta entre entidades externas e dep sitos de dados Como j mencionado anteriormente para uma completa modelagem das fun es s o necess rios al m dos DFDs um Dicion rio de Dados e as Especifica es das L gicas dos processos Deste modo s teremos um entendimento completo de um processo ap s descrevermos sua l gica As especifica es das l gicas dos processos s devem ser feitas para processos simples Processos complexos devem ser decompostos em outros processos at se atingir um n vel de reduzida complexidade Uma heur stica para se definir se um processo merece ou n o ser representado em um DFD dada em fun o da descri o de sua l gica Quando essa descri o utilizar aproximadamente uma ou duas p ginas ent o o processo parece estar adequado Processos descritos em tr s ou quatro linhas s o simples demais para serem tratados como p
190. onal com frequ ncia de semanas a meses de prefer ncia no menor espa o de tempo 4 Interessados stakeholders e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto 5 Desenvolver projetos em torno de indiv duos motivados D a eles o ambiente e o apoio que precisam e confie que eles far o o trabalho 6 O m todo mais eficiente e efetivo para troca de informa o internamente a conversa cara a cara 7 Software funcionando a principal medida de progresso 8 Desenvolvimento sustent vel manter um ritmo constante do desenvolvimento indefinidamente 9 Aten o cont nua excel ncia t cnica e ao bom projeto promovem agilidade 10 Simplicidade a arte de maximizar a quantidade de trabalho n o efetuado essencial 11 As melhores arquiteturas requisitos e projetos emergem de equipes auto organizadas 12 Em intervalos regulares a equipe deve refletir sobre como se tornar mais efetiva e ajustar seu comportamento As premissas para o uso de processos geis s o PRESSMAN 2011 i dif cil predizer quais requisitos ser o mantidos e quais v o mudar assim como quais prioridades mudar o ou n o ii An lise projeto constru o e teste n o s o t o previs veis do ponto de vista de planejamento como gostariamos iii Uma vez que dif cil prever o quanto de Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES
191. ongo do projeto de modo a permitir acompanhar o progresso e tomar a es corretivas no caso de se detectar desvios em rela o ao inicialmente planejado Esse conjunto de atividades faz parte da Ger ncia de Projetos de software 8 1 Projeto de Software e Ger ncia de Projetos Projeto como definido pelo PMBOK um empreendimento tempor rio com o objetivo de criar um produto ou servi o nico VIEIRA 2003 um trabalho que visa cria o de um produto ou execu o de um servi o espec fico tempor rio n o repetitivo e que envolve um certo grau de incerteza na sua realiza o MARTINS 2005 Normalmente caracterizado por uma sequ ncia de atividades o processo do projeto sendo executada por pessoas dentro de limita es de tempo recursos no caso de projetos de software sobretudo recursos humanos e custos Assim sendo a Ger ncia de Projetos de Software envolve dentre outros o planejamento e o acompanhamento das pessoas envolvidas no projeto do produto sendo desenvolvido e do processo seguido para evoluir o software de um conceito preliminar at uma implementa o concreta e operacional PRESSMAN 2011 8 1 1 As Pessoas Em um projeto de software h v rias pessoas envolvidas exercendo diferentes pap is tais como Gerente de Projeto Desenvolvedor Analistas Projetistas Programadores Testadores Gerente da Qualidade Clientes Usu rios O n mero de pap is e suas denomina es podem se
192. or m caso essas mudan as n o sejam devidamente documentadas e comunicadas poder o acarretar diversos problemas tais como dois ou mais desenvolvedores podem estar alterando um mesmo artefato ao mesmo tempo n o se saber qual a vers o mais atual de um artefato n o se repercutir altera es nos artefatos impactados por um artefato em altera o Esses problemas podem gerar v rios transtornos como incompatibilidade entre os grupos de desenvolvimento inconsist ncias retrabalho atraso na entrega e insatisfa o do cliente Assim para que esses transtornos sejam evitados de suma import ncia o acompanhamento e o controle de artefatos processos e ferramentas atrav s de um processo de ger ncia de configura o de software durante todo o ciclo de vida do software A Ger ncia de Configura o de Software GCS visa estabelecer e manter a integridade dos itens de software ao longo de todo o ciclo de vida do software garantindo a completeza a consist ncia e a corre o de tais itens e controlando o armazenamento a manipula o e a distribui o dos mesmos Para tal tem de identificar e documentar os produtos de trabalho que podem ser modificados estabelecer as rela es entre eles e os mecanismos para administrar suas diferentes vers es controlar modifica es e permitir auditoria e a elabora o de relat rios sobre o estado de configura o Pelos objetivos da GCS pode se notar que ela est diretamente relacionada
193. os Levantamento de An lise de Requisitos Requisitos Documenta o de Requisitos Figura 3 1 O Processo da Engenharia de Requisitos e Levantamento de Requisitos Nesta fase os usu rios clientes e especialistas de dom nio s o identificados e trabalham junto com os engenheiros de requisitos para entender a organiza o o dom nio da aplica o os processos de neg cio a serem apoiados as necessidades que o software deve atender e os problemas e defici ncias dos sistemas atuais Os diferentes pontos de vista dos participantes do processo bem como as oportunidades de melhoria restri es existentes e problemas a serem resolvidos devem ser levantados e An lise de Requisitos visa estabelecer um conjunto acordado de requisitos consistentes e sem ambiguidades que possa ser usado como base para as atividades subsequentes do processo de software Para tal diversos tipos de modelos s o constru dos Assim a an lise de requisitos essencialmente uma atividade de modelagem A an lise de requisitos pode incluir ainda negocia o entre usu rios para resolver conflitos detectados e Documenta o de Requisitos a atividade de representar os resultados da Engenharia de Requisitos em um documento ou conjunto de documentos contendo os requisitos do software e os modelos que os especificam e Verifica o e Valida o de Requisitos A verifica o de requisitos avalia se os requisitos est o sendo tratados de forma
194. os procedimentos padr es regulamenta es ou guias foram devidamente aplicados no processo e no produto SANCHES 2001b Enfim o ltimo passo do processo de GCS a prepara o de relat rios que uma tarefa que tem como objetivo relatar a todas as pessoas envolvidas no desenvolvimento e manuten o do software as seguintes quest es 1 O que aconteceu ii Quem fez iii Quando aconteceu iv O que mais foi afetado O acesso r pido s informa es agiliza o processo de desenvolvimento e melhora a comunica o entre as pessoas evitando assim muitos problemas de altera es do mesmo item de configura o com inten es diferentes e s vezes conflitantes SANCHES 2001b 7 4 Medi o de Software Para poder controlar a qualidade medir muito importante Se n o poss vel medir expressando em n meros apenas uma an lise qualitativa e portanto subjetiva pode ser feita o que na maioria das vezes insuficiente Com medi es as tend ncias boas ou m s podem ser detectadas melhores estimativas podem ser feitas e melhorias reais podem ser conseguidas PRESSMAN 2011 Avalia es da qualidade assumem particularidades que come am pelo tipo de entidade que se est avaliando e v o at diferentes caracter sticas a serem avaliadas e m todos de Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo
195. os desenvolvedores apontam que uma abordagem tradicional de desenvolvimento centrada no planejamento e na execu o de processos inapropriada para o desenvolvimento de sistemas muito sujeitos a mudan as Uma alternativa para esses casos seria a agilidade De maneira bem geral agilidade pode ser vista como a capacidade de adapta o das organiza es face s mudan as ocorridas no ambiente de neg cios SANTANA J NIOR 2012 Uma equipe gil aquela que consegue responder rapidamente a mudan as d valor s caracter sticas e habilidades de cada membro e reconhece que a colabora o a chave para o sucesso do projeto PRESSMAN 2011 As bases para o desenvolvimento gil foram definidas por Kent Beck e outros 16 desenvolvedores por meio do Manifesto para Desenvolvimento gil de Software PRESSMAN 2011 Esse manifesto diz que devem ser valorizados i indiv duos e intera es ao inv s de processos e ferramentas ii software funcional ao inv s de documenta o iii colabora o ao inv s de negocia o iv responder s mudan as ao inv s de seguir um plano S o 12 os princ pios geis a Satisfazer o cliente a prioridade m xima por meio de entrega cont nua de software de valor 2 Mudan as em requisitos devem ser bem recebidas mesmo em fases mais avan adas do desenvolvimento Os processos geis direcionam as mudan as para obter vantagens competitivas para o cliente 3 Entregar software funci
196. os mesmos Uma tabela ordenada pelo grau de exposi o pode ser montada e uma linha de corte nessa tabela estabelecida indicando quais riscos ser o tratados e quais ser o desprezados Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 114 Para os riscos a serem gerenciados devem ser definidos planos de a o estabelecendo a es a serem adotadas para em primeiro lugar evitar que os riscos ocorram a es de mitiga o ou caso isso n o seja poss vel a es para tratar e minimizar seus impactos a es de conting ncia Esse o prop sito da atividade de planejamento das a es Ao longo de todo o processo da ger ncia de riscos as decis es envolvidas devem ser documentadas em um plano de riscos Esse plano servir de base para a atividade de monitoramento dos riscos quando os riscos ser o monitorados para se verificar se os mesmos est o se tornando realidade ou n o Caso estejam se tornando ou j sejam uma realidade deve se informar que a es foram tomadas No caso do risco se concretizar deve se informar tamb m quais as consequ ncias da sua ocorr ncia 8 7 Elabora o do Plano de Projeto Todas as atividades realizadas no contexto da ger ncia de projeto devem ser documentadas em um Plano de Projeto Cada organiza o deve estabelecer um modelo ou padr o para a elabora o desse documento de modo que to
197. os riscos iii estimar o impacto do risco no projeto e no produto e iv calcular o grau de exposi o do risco que uma medida casando probabilidade e impacto De maneira geral escalas para probabilidades e impactos s o definidas de forma qualitativa tais como probabilidade alta m dia ou baixa e impacto baixo m dio alto ou muito alto Isso facilita a an lise dos riscos mas por outro lado pode dificultar a avalia o Assim a defini o de medidas quantitativas para o risco pode ser importante pois tende a diminuir a subjetividade na avalia o Jalote 1999 prop e os valores quantitativos mostrados nas tabelas 8 3 e 8 4 para as escalas acima Tabela 8 3 Categorias de Probabilidade JALOTE 1999 Probabilidade Faixa de Valores Baixa at 30 M dia 30 a 70 Alta acima de 70 Tabela 8 4 Categorias de Impacto JALOTE 1999 Impacto Faixa de Valores Baixo de0a3 M dio de3a7 Alto de 7a 9 Muito Alto de9a 10 Usando valores quantitativos para expressar probabilidade e impacto poss vel obter um valor num rico para o grau de exposi o ao risco dado por E r P r I r onde E r o grau de exposi o associado ao risco r e P r e I r correspondem respectivamente aos valores num ricos de probabilidade e impacto do risco r De posse do grau de exposi o de cada um dos riscos que comp em o perfil de riscos do projeto pode se passar avalia o d
198. os stubs para E F e G Por fim o sistema inteiro seria testado Muitas outras abordagens algumas usando as apresentadas anteriormente podem ser adotadas tal como a integra o sandu che PFLEEGER 2004 que considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e descendente respectivamente para as camadas localizadas abaixo e acima da camada alvo Outra possibilidade testar individualmente cada m dulo e depois integrar todos de uma vez teste big bang Neste caso Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 76 tanto drivers quanto stubs t m de ser constru dos para cada m dulo o que leva a muito mais codifica o e problemas em potencial PFLEEGER 2004 Outras abordagens de integra o fazem uso dos modelos constru dos na fase de an lise para testar a integra o dos m dulos Na estrat gia de integra o baseada em casos de uso a integra o dos m dulos testada no contexto da realiza o de um caso de uso Uma vez testados casos de uso individualmente outras estrat gias podem ser usadas para testar v rios casos de uso integrados A estrat gia de integra o baseada no ciclo de vida do dom nio por exemplo consiste em realizar os processos de neg cio atrav s dos correspondentes casos de uso como eles tipicamente acontecem Na estrat gia de integra o baseada em m quina de
199. ou determinada fun o do mesmo est sendo desenvolvido corretamente o que inclui verificar se os m todos e processos est o sendo aplicados adequadamente e Valida o visa garantir que o software que est sendo desenvolvido o software correto As atividades de Verifica o e Valida o V amp V podem ser divididas em est ticas e din micas A an lise est tica n o envolve a execu o do produto e portanto ela pode ser aplicada em qualquer artefato intermedi rio J a an lise din mica envolve a execu o do produto Revis es t cnicas e inspe o de c digo s o exemplos de t cnicas que podem ser aplicadas para analisar estaticamente um produto de software ou partes dele T cnicas para revis o de software s o abordadas no Cap tulo 7 destas notas de aula Neste cap tulo s o abordadas apenas atividades de V amp V din micas os testes de software Teste de software o processo de executar um programa com o objetivo de encontrar defeitos MYERS 2004 Teste uma atividade de verifica o e valida o do software e consiste na an lise din mica do mesmo isto na execu o do produto de software com o objetivo de verificar a presen a de defeitos no produto e aumentar a confian a de que o mesmo est correto MALDONADO FABBRI 2001 Entretanto vale ressaltar que mesmo se um teste n o detectar defeitos isso n o quer dizer necessariamente que o produto um produto de boa qualidade Teste s capa
200. para o levantamento de requisitos sua principal finalidade gerenciar a complexidade do dom nio do problema dividindo as funcionalidades do sistema em casos de uso permitindo assim que as discuss es e as correspondentes descri es textuais sejam feitas em contextos menores mais espec ficos Um modelo de casos de uso composto por um conjunto de Diagramas de Casos de Uso geralmente um diagrama de casos de uso para cada subsistema e de descri es para cada ator e para cada caso de uso identificado As descri es de atores podem ser bastante simples j que esses s o externos ao sistema enquanto as descri es de casos de uso s o mais detalhadas uma vez que representam funcionalidades que o sistema deve oferecer Como poss vel deduzir pela vis o geral dos modelos de casos de uso dada acima os principais conceitos desse tipo de modelo s o atores e casos de uso De forma sucinta um ator um papel que um usu rio outro sistema ou dispositivo desempenha com respeito ao sistema Casos de uso representam funcionalidades requeridas externamente Uma associa o entre um ator e um caso de uso significa que est mulos podem ser enviados entre atores e casos de uso Os atores s o conectados aos casos de uso somente por meio de associa es A associa o entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si cada um com a possibilidade de enviar e receber mensagens BOOCH RUMBAUGH JACOBSON 2
201. plo os m dulos B e C s o chamados repetidas vezes pelo m dulo 4 as PE Figura 4 24 Chamada Iterativa Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 67 Conectores Algumas vezes um mesmo m dulo chamado por mais de um m dulo s vezes em diagramas diferentes Outras o diagrama est complexo demais e deseja se continu lo em outra p gina Nestas situa es conectores podem ser utilizados como ilustra a Figura 4 25 Cadastrar cliente cp cpf ji l cpf v lido Validar cpf sai v lido Figura 4 25 Conectores T cnicas de Desenho Para elaborar um diagrama de estrutura modular devemos observar as seguintes orienta es Os m dulos devem ser desenhados na ordem de execu o da esquerda para a direita Idealmente cada m dulo s deveria aparecer uma nica vez no diagrama Para se evitar cruzamento de linhas podem se usar conectores N o segmentar demais Crit rios de Qualidade de Diagramas de Estrutura Modular O objetivo maior do projeto modular de programas permitir que um sistema complexo seja dividido em m dulos simples No entanto vital que essa parti o seja feita de tal forma que os m dulos sejam t o independentes quanto poss vel e que cada um deles execute uma nica fun o Crit rios que tratam desses aspectos s o respectivamente acoplamento e coes o A
202. projeto tomando por base o tamanho do mesmo em KLOC E 5 5 0 73 KLOC Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 110 Outros modelos s o apresentados em PRESSMAN 2011 PFLEEGER 2004 e SOMMERVILLE 2011 Contudo deve se observar que modelos emp ricos diferentes conduzem a resultados muito diferentes o que indica que esses modelos devem ser adaptados para as condi es da organiza o Uma forma de se fazer essa adapta o consiste em experimentar o modelo usando resultados de projetos j finalizados comparar os valores obtidos com os dados reais e analisar a efic cia do modelo Se a concord ncia dos resultados n o for boa as constantes do modelo devem ser recalculadas usando dados organizacionais PRESSMAN 2011 8 5 4 Aloca o de Recursos Estimar os recursos necess rios para o desenvolvimento de um produto de software outra importante tarefa Quando falamos em recursos estamos englobando pessoas hardware e software dentre outros No caso de software devemos pensar em ferramentas de software tais como ferramentas CASE ou software de infraestrutura p ex um sistema gerenciador de banco de dados bem como componentes de software a serem reutilizados no desenvolvimento tais como bibliotecas de interface ou uma camada de persist ncia de dados Em todos os casos recursos humanos de hardware e de sof
203. que um processo de qualidade deve considerar Dentre essas normas e modelos destacam se as normas ISO 9000 ISO 2005 ISO IEC 12207 ISO IEC 2008 ISO IEC 15504 ISO IEC 2004 e os modelos CMMI SEI 2010 e MPS BR SOFTEX 2011 9 1 1 Normas ISO As normas da fam lia ISO 9000 ISO 2005 foram desenvolvidas para apoiar organiza es de todos os tipos e tamanhos na implementa o e opera o de sistemas eficazes de gest o da qualidade As normas que comp em a s rie ISO 9000 s o e ISO 9000 descreve os fundamentos de sistemas de gest o da qualidade e estabelece a terminologia para esses sistemas e ISO 9001 especifica os requisitos para um sistema de gest o da qualidade com enfoque na satisfa o do cliente Para uma organiza o ser certificada ISO 9001 ela precisa demonstrar sua capacidade para fornecer produtos que atendam aos requisitos do cliente expl citos e impl citos e os requisitos regulamentares aplic veis e ISO 9004 fornece diretrizes que consideram tanto a efic cia como a efici ncia do sistema de gest o da qualidade Seu objetivo melhorar o desempenho da organiza o e a satisfa o dos clientes e das demais partes interessadas e ISO 19011 fornece diretrizes sobre auditoria internas e externas de sistemas de gest o da qualidade Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 11
204. quest es relacionadas legibilidade alterabilidade e reutiliza o t m de ser levadas em conta Deve se considerar ainda que programadores geralmente trabalham em equipe necessitando integrar testar e alterar c digo produzido por outros Assim muito importante que haja padr es organizacionais para a fase de implementa o Esses padr es devem ser seguidos por todos os programadores e devem estabelecer dentre outros padr es de nomes de vari veis formato de cabe alhos de programas e formato de coment rios recuos e espa amento de modo que o c digo e a documenta o a ele associada sejam claros para quaisquer membros da organiza o Padr es para cabe alho por exemplo podem informar o que o c digo programa m dulo ou componente faz quem o escreveu como ele se encaixa no projeto geral do sistema quando foi escrito e revisado apoios para teste entrada e sa da esperadas etc Essas informa es s o de grande valia para a integra o testes manuten o e reutiliza o PFLEEGER 2004 Al m dos coment rios feitos no cabe alho dos programas coment rios adicionais ao longo do c digo s o tamb m importantes ajudando a compreender como o componente implementado Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 71 Por fim o uso de nomes significativos para vari veis indicando sua utiliza o e si
205. r bastante diferentes dependendo da organiza o e at mesmo do projeto As pessoas trabalhando em um projeto s o organizadas em equipes Assim o conceito de equipe pode ser visto como um conjunto de pessoas trabalhando em diferentes tarefas mas objetivando uma meta comum Essa n o uma caracter stica do desenvolvimento de software mas da organiza o de pessoas em qualquer atividade humana Assim a defini o O PMBOK Project Management Body of Knowledge Corpo de Conhecimento em Ger ncia de Projetos um guia de orienta o do conhecimento envolvido na ger ncia de projetos cujo objetivo identificar e descrever conceitos e pr ticas da ger ncia de projetos em geral padronizando a terminologia e os processos adotados nesta rea de estudo Esse documento foi produzido e periodicamente atualizado pelo PMI Project Management Institute Instituto de Ger ncia de Projetos uma entidade internacional sem fins lucrativos que congrega profissionais atuando na rea de ger ncia de projetos MARTINS 2005 Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 99 de equipes importante para uma ampla variedade de situa es tal como uma forma o de uma equipe de futebol Para a boa forma o de equipes devem ser definidos os pap is necess rios e devem ser considerados aspectos fundamentais a saber lideran a or
206. ra Reutiliza o DRU Ger ncia de Riscos GRI D Desenvolvimento de Requisitos DRE Projeto e Constru o do Produto PCP Integra o do Produto ITP Verifica o VER Valida o VAL E Avalia o e Melhoria de Processo Organizacional AMP Defini o do Processo Organizacional DFP Ger ncia de Recursos Humanos GRH Ger ncia de Reutiliza o GRU Ger ncia de Projetos evolu o F Medi o MED Ger ncia de Configura o GCO Aquisi o AQU Garantia da Qualidade GQA Ger ncia de Portf lio de Projetos GPP G Ger ncia de Requisitos GRE Ger ncia de Projetos GPR Engenharia de Software Cap tulo 9 T picos Avan ados em Engenharia de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 121 Tabela 9 3 Processos do MR MPS SW e reas de Processos do CMMI DEV MR MPS SW CMMI DEV N vel Processo N vel rea de Processo G Ger ncia de Projetos 2 Planejamento de Projeto Monitora o e Controle de Projeto Ger ncia de Requisitos Ger ncia de Requisitos F Aquisi o Ger ncia de Acordo com Fornecedor Ger ncia de Configura o Ger ncia de Configura o Garantia da Qualidade Garantia da Qualidade de Produto e de Processo Ger ncia de Portf lio de Projetos Medi o Medi o e An lise E Avalia o e Melhoria do Processo 3 Foco no Processo Organizacional Or
207. rav s de mecanismos de busca poss vel recuperar projetos similares suas estimativas e li es aprendidas que podem ajudar a elaborar estimativas mais precisas Nesta abordagem os fatores culturais s o considerados pois os projetos foram desenvolvidos na pr pria organiza o Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 104 Vale frisar que essas abordagens n o s o excludentes muito pelo contr rio O objetivo ter v rias formas para realizar estimativas e usar seus resultados para se chegar a estimativas mais precisas Quando se fala em estimativas est se tratando na realidade de diversos tipos de estimativas tamanho esfor o recursos tempo e custos Geralmente a realiza o de estimativas come a pelas estimativas de tamanho A partir delas estima se o esfor o necess rio e na sequ ncia alocam se os recursos necess rios elabora se o cronograma do projeto estimativa de dura o e por fim estima se o custo do projeto e define se o seu or amento cronograma de desembolso 8 5 1 Ger ncia de Projetos e Medi o muito importante observar a estreita rela o entre ger ncia de projetos e medi o Para acompanhar o andamento do projeto preciso medir o progresso e comparar com o estimado Mesmo no planejamento sobretudo quando se pretende utilizar dados de projetos anteriores dados de medidas
208. regue para o cliente e entra em opera o A partir da deve se garantir que o sistema continuar a ser til e atendendo s necessidades do usu rio o que pode demandar altera es no mesmo Come a ent o a fase de manuten o ou evolu o SANCHES 2001 H muitas causas para a manuten o dentre elas SANCHES 2001 falhas no processamento devido a erros no software falhas de desempenho e outros requisitos n o funcionais altera es no ambiente de produ o mudan as nos processos de neg cio levando necessidade de modifica es em fun es existentes necessidade de inclus o de novas capacidades no sistema Engenharia de Software Cap tulo 6 Entrega e Manuten o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 88 Ao contr rio do que podemos pensar a manuten o n o uma tarefa trivial nem de pouca relev ncia Ela uma atividade important ssima e de intensa necessidade de conhecimento O mantenedor precisa conhecer o sistema o dom nio de aplica o os requisitos do sistema a organiza o que utiliza o mesmo pr ticas de engenharia de software passadas e atuais a arquitetura do sistema algoritmos usados etc O processo de manuten o semelhante mas n o igual ao processo de desenvolvimento e pode envolver atividades de levantamento de requisitos an lise projeto implementa o e testes agora no contexto de um software existente Essa semelhan a pode ser ma
209. relacionamentos parcialmente distintos Passa a ser interessante ent o representar os atributos e relacionamentos comuns em um supertipo e os atributos e relacionamentos espec ficos em subtipos Essa distin o pode ser feita por meio de e Generaliza o uma entidade de um n vel mais alto criada para capturar as caracter sticas comuns de entidades de n vel mais baixo e Especializa o uma entidade de n vel mais alto de abstra o desmembrada em v rias entidades de n vel mais baixo A Figura 3 14 mostra um exemplo de particionamento 1 1 AN lota Engenheiro Secret ria crea l ngua matr cula habilita o Projeto participa de Figura 3 14 Particionamento de um Conjunto de Entidades Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 31 Atributos Os atributos s o utilizados para descrever caracter sticas ou propriedades relevantes de entidades e de relacionamentos Quando um atributo pode assumir apenas um nico valor ele dito um atributo monovalorado Por exemplo os atributos nome e data de nascimento de uma entidade Funcion rio s o monovalorados tendo em vista que uma inst ncia de Funcion rio por exemplo Jo o possui apenas um nome e uma data de nascimento Por outro lado quando um atributo pode assumir v rios valores para uma mesma inst ncia ele dito
210. repeti o de m dulos itera o dentre outras Um DEM n o mostra a l gica e os dados internos dos m dulos e por isso deve ser acompanhado de uma descri o dos m dulos mostrando os detalhes internos dos procedimentos das caixas pretas Nota o Utilizada na Elabora o de DEMs A seguir s o apresentadas as principais nota es utilizadas para elaborar Diagramas de Estrutura Modular XAVIER PORTILHO 1995 M dulo Em um DEM um m dulo representado por um ret ngulo dentro do qual est contido seu nome como mostra a Figura 4 20 Um m dulo pr definido aquele que j existe em uma biblioteca de m dulos e portanto n o precisa ser descrito ou detalhado verbo objeto qualificador M dulo Pr definido Figura 4 20 Simbologia para M dulos em um DEM Nome do M dulo Conex o entre m dulos Um sistema um conjunto de m dulos organizados dentro de uma hierarquia cooperando e se comunicando para realizar um trabalho A hierarquia mostra quem chama quem Portanto m dulos devem estar conectados No exemplo da Figura 4 21 o m dulo 4 chama o m dulo B passando como par metros os dados X e Y O m dulo B executa ent o sua fun o e retorna o controle para 4 no ponto imediatamente ap s a chamada de B passando como resultado o dado Z A ordem de chamada sempre de cima para baixo da esquerda para a direita Par metros X Y o M dulo Chamador O Z Resulta
211. representa todos os livros de uma biblioteca Para estabelecermos uma padroniza o neste texto usaremos nomes de tipos de entidades sempre no singular e escritos com a primeira letra em mai sculo No entanto isto n o representa efetivamente uma regra Al m disso usaremos o termo entidade para referenciar tanto entidades quanto tipos de entidades de maneira indistinta ainda que sejam conceitos diferentes Essa uma pr tica bastante comum e o contexto ser suficiente para que o leitor perceba se estamos tratando de um tipo de entidade ou de uma entidade espec fica Relacionamentos Um relacionamento uma abstra o de uma associa o entre duas ou mais entidades Por exemplo podemos querer registrar que o funcion rio Jo o uma entidade do tipo Funcion rio est lotado um relacionamento no departamento de Vendas uma entidade do tipo Departamento Um relacionamento bin rio como o citado no exemplo anterior uma representa o abstrata da associa o entre duas entidades Da mesma forma que as entidades estamos mais interessados em modelar tipos de relacionamentos Um tipo ou conjunto de relacionamentos um subconjunto do produto cartesiano dos conjuntos de entidades envolvidos sendo representado por um losango com um verbo para indicar a a o e uma seta para informar o sentido de leitura como mostra a Figura 3 5 Al m disso assim como fizemos com entidades usaremos indistintamente o termo relacionamento para
212. res Ex Estado Civil solteiro casado desquitado divorciado e vi vo e normas de aceita o regras para se identificar se o valor v lido ou n o Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 35 Ex Nome qualquer conjunto de caracteres alfanum ricos come ado por uma letra e intervalo descri o de um subconjunto de um intervalo conhecido Ex M s de 1 at 12 Uma vez estabelecido o dom nio interessante determinar valores poss veis e prov veis isto alguns valores apesar de poderem ocorrer pouco prov vel que ocorram dependendo do contexto Por exemplo com rela o ao atributo idade de um empregado o valor 81 um valor poss vel mas ser que ele um valor prov vel considerando que a aposentadoria ocorre de maneira compuls ria aos 70 anos Outros aspectos que devem ser considerados na descri o dos atributos s o e obrigatoriedade estabelecer se um determinado atributo pode ter um valor nulo a ele associado Ex Telefone opcional Nome obrigat rio e depend ncia Os valores que um atributo pode assumir muitas vezes s o dependentes dos valores de outros atributos Neste caso importante relacionar no dicion rio de projeto como se d esta depend ncia Ex O valor do atributo dia depende fundamentalmente do valor do atributo m s a data de demiss o de um funcion rio
213. resultado Coletar dados qualitativos e quantitativos question rios distribu dos aos usu rios do prot tipo Projeto Preliminar Constru o do Constru o do 1 Prot tipo n Prot tipo Avalia o do Modifica es do Projeto Usu rio de Interface Estudo da Avalia o pelo Projetista Projeto de Interface Conclu do Figura 4 18 Abordagem Iterativa para o Projeto de Interface com o Usu rio Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 61 4 3 Projeto Modular de Programas A tarefa de constru o de sistemas computadorizados requer uma organiza o das ideias de modo a se conseguir desenvolver produtos com qualidade Programas escritos sem qualquer subdivis o s o invi veis do ponto de vista administrativo e n o permitem reaproveitamento de trabalhos anteriormente executados O Projeto Modular de Programas oferece uma cole o de orienta es t cnicas estrat gicas e heur sticas que visam a conduzir a bons programas a serem desenvolvidos segundo o paradigma estruturado O objetivo desenvolver programas com menor complexidade usando o princ pio dividir para conquistar Como resultado de um bom projeto de programas espera se obter Facilidade na leitura de programas maior legibilidade Maior rapidez na depura o de programas na fase de testes Facilidade de modifica o de programas na fase de m
214. rocessos em um DFD Por outro lado se a descri o da l gica do processo necessitar de tr s ou mais p ginas ent o esse processo est muito abrangente e n o deve ser tratado como um nico processo mas sim deve ser decomposto em processos de menor complexidade Para situa es desta natureza duas t cnicas s o utilizadas fiss o ou explos o como estudaremos mais frente Fluxos de Dados Fluxos de dados s o utilizados para representar a movimenta o de dados atrav s do sistema S o simbolizados por setas que identificam a dire o do fluxo e devem ter associado um nome o mais significativo poss vel de modo a facilitar a valida o do diagrama com os usu rios Esse nome deve ser um substantivo que facilite a identifica o do pacote de dados transportado Um fluxo de dado em um DFD pode ser considerado como um caminho atrav s do qual poder o passar uma ou mais estruturas de dados em tempo n o especificado Note que em um DFD n o se representam elementos de natureza n o informacional isto dinheiro pessoas materiais etc Devemos observar se um fluxo de dados entra e sai de um processo sem modifica o Isso representa uma falha haja visto que um processo transforma dados Embora possa parecer um tanto bvio bom lembrar que um mesmo conte do pode ter diferentes significados em pontos distintos do sistema e portanto os fluxos devem ter nomes diferentes No DFD da Figura 3 26 um mesmo conjunto de informa
215. rtantes atividades do processo de GCS o controle de altera es O controle de altera es combina procedimentos humanos e ferramentas automatizadas para controlar altera es realizadas em ICs PRESSMAN 2011 Assim que uma altera o solicitada o impacto em outros itens e o custo para a modifica o devem ser avaliados Um respons vel deve decidir se a altera o dever ou n o ser realizada Caso a altera o seja liberada pessoas s o indicadas para sua execu o Assim que n o houver ningu m utilizando os ICs envolvidos c pias deles s o retiradas do reposit rio central e colocadas em uma rea de trabalho do desenvolvedor atrav s de um procedimento denominado check out A partir deste momento nenhum outro desenvolvedor poder alterar esses itens Os desenvolvedores designados fazem as altera es necess rias e assim que essas forem conclu das os itens s o submetidos a uma revis o Se as altera es forem aprovadas os itens s o devolvidos ao reposit rio central estabelecendo uma nova linha base em um procedimento chamado check in PRESSMAN 2011 SANCHES 2001b Por m mesmo com uma aplica o bem sucedida dos mecanismos de controle n o poss vel garantir que as modifica es foram corretamente implementadas Assim revis es e auditorias de configura o de software s o necess rias PRESSMAN 2011 Essas atividades de garantia da qualidade tentam descobrir omiss es ou erros na configura o e se
216. s buscam validar os requisitos confirmando que os requisitos corretos foram implementados no sistema teste de valida o A conex o entre os lados direito e esquerdo do modelo em V implica que caso sejam encontrados problemas em uma atividade de teste a correspondente fase do lado esquerdo e suas fases subsequentes podem ter de ser executadas novamente para corrigir ou melhorar esses problemas Os modelos sequenciais pressup em que o sistema entregue completo ap s a realiza o de todas as atividades do desenvolvimento Entretanto nos dias de hoje os clientes n o est o mais dispostos a esperar o tempo necess rio para tal sobretudo quando se trata de grandes sistemas PFLEEGER 2004 Dependendo do porte do sistema podem se passar anos at que o sistema fique pronto sendo invi vel esperar Assim outros modelos foram propostos visando a dentre outros reduzir o tempo de desenvolvimento A entrega por partes possibilitando ao usu rio dispor de algumas funcionalidades do sistema enquanto outras est o sendo ainda desenvolvidas um dos principais mecanismos utilizados por esses modelos como discutido a seguir Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 11 2 2 Modelos de Processo Incrementais H muitas situa es em que os requisitos s o razoavelmente bem definidos mas o tamanho do sist
217. s das classes de equival ncia Assim este crit rio usado em conjunto com o particionamento de equival ncia e leva sele o de casos de teste que exercitem valores lim trofes DELAMARO et al 2007 As recomenda es do crit rio de an lise de valor limite s o as seguintes e Se a condi o de entrada especificar um intervalo de valores de entrada ent o se devem definir casos de teste para os limites desse intervalo e para valores imediatamente subsequentes acima e abaixo que explorem as classes vizinhas e Se a condi o de entrada especificar uma quantidade de valores de entrada n ent o se devem definir casos de teste com nenhum valor de entrada somente um valor de entrada com a quantidade m xima de valores de entrada n e com a quantidade m xima de valores 1 n 7 e Aplicar as recomenda es acima para condi es de sa da quando couber e Sea entrada ou a sa da for um conjunto ordenado deve ser dada aten o especial aos primeiro e ltimo elementos desse conjunto Seja o exemplo da fun o para calcular o imposto de renda Neste caso a entrada especifica 5 intervalos de valor e portanto aplicando se a primeira das recomenda es acima listadas s o necess rios mais 15 casos de teste 3 para cada limite de valor como mostra a Tabela 5 4 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 80 Ta
218. s de uma vez para se evitar o cruzamento de linhas de fluxos de dados ou para impedir que longas linhas de fluxos de dados saiam de um lado a outro do diagrama Nesse caso convenciona se utilizar um tra o diagonal no canto inferior direito do s mbolo da entidade externa como mostra a Figura 3 30 Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 41 Clientes Clientes Z Figura 3 30 Nota es para representar entidades externas Ao identificarmos alguma coisa ou sistema como uma entidade externa estamos afirmando que essa entidade est fora dos limites do sistema em quest o e portanto fora do controle do sistema que est sendo modelado Assim qualquer relacionamento existente entre entidades externas n o deve ser mostrado em um DFD Se em algum momento descrevemos algo que ocorre dentro de uma entidade externa ou relacionamentos entre entidades externas necess rio reconhecer que a fronteira do sistema na realidade mais ampla do que foi estabelecido inicialmente e portanto deve ser revista Uma vez que as entidades externas como o pr prio nome indica s o externas ao sistema os fluxos de dados que as interligam aos diversos processos representam a interface entre o sistema e o mundo externo 3 7 1 Rela es entre DFDs e DERs Conforme discutido anteriormente dep sitos de dados s o representa es em um DFD
219. s de uso s o suficientes para representar a perspectiva funcional de um sistema De fato h muita cr tica aos DFDs exatamente por misturarem perspectivas interna pelo uso de dep sitos de dados e externa bem como pelo n vel de detalhe a que se prop em chegar Assim quando for elaborado um modelo de casos de uso DFDs passam a ser desnecess rios Neste caso o modelo de an lise pode conter apenas a Diagramas de Casos de Uso Descri es de Atores e Casos de Uso Diagramas de Entidades e Relacionamentos Dicion rio de Dados D DOD O0 O Diagramas de Estados Refer ncias do Cap tulo BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 CHEN P Gerenciando Banco de Dados A Abordagem Entidade Relacionamento para Projeto L gico McGraw Hill 1990 DE MARCO T An lise Estruturada e Especifica o de Sistemas Editora Campus 1983 GANE C SARSON T An lise Estruturada de Sistemas Livros T cnicos e Cient ficos Editora 1983 JACOBSON I Object Oriented Software Engineering A Use Case Driven Approach Addison Wesley 1992 KOTONYA G SOMMERVILLE I Requirements engineering processes and techniques Chichester England John Wiley 1998 MCMENAMIN S M PALMER J F An lise Essencial de Sistemas McGraw Hill 1991 PFLEEGER S L Engenharia de Software Teoria e Pr tica 2 Edi o S o Paulo Prentice Hall 2004 POMPILHO S An lise Essenci
220. s pr ticas de uma organiza o e facilitam a realiza o de atividades de avalia o da qualidade que podem ser dirigidas pela avalia o da conformidade em rela o ao padr o Al m disso sendo organizacionais todos os membros da organiza o tendem a estar familiarizados com os mesmos facilitando a manuten o dos artefatos ou a substitui o de pessoas no decorrer do projeto Para aqueles artefatos tidos como os mais importantes no planejamento da documenta o saud vel que haja um padr o organizacional associado Dada a import ncia de padr es organizacionais eles devem ser elaborados com bastante cuidado Uma boa pr tica consiste em usar como base padr es gerais propostos por institui es nacionais ou internacionais voltadas para a rea de qualidade de software tal como a ISO 7 2 Verifica o e Valida o de Software por meio de Revis es Durante o processo de desenvolvimento de software ocorrem enganos interpreta es err neas e outras falhas principalmente provocados por problemas na comunica o e na transforma o da informa o que podem resultar em mau funcionamento do sistema resultante Assim muito importante detectar defeitos o quanto antes preferencialmente na Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 92 atividade em que foram cometidos como forma de diminuir retrabalho e por
221. senvolvida originalmente para dar suporte ao projeto de bancos de dados CHEN 1990 SETZER 1987 Tipicamente um Modelo de Entidades e Relacionamentos MER composto por um conjunto de Diagramas de Entidades e Relacionamentos e um Dicion rio de Dados 3 6 1 Diagrama de Entidades e Relacionamentos Basicamente um Diagrama ER representa as entidades do mundo real e os relacionamentos entre elas que um sistema de informa o precisa simular internamente Al m disso entidades e relacionamentos podem ter atributos Entidades Uma entidade uma representa o abstrata de alguma coisa do mundo real que temos interesse em monitorar o comportamento Pode ser a representa o de um ser um objeto um organismo social etc Assim o funcion rio Jo o uma entidade Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 26 Entretanto desejamos representar de fato tipos de entidades isto grupos de entidades que t m caracter sticas semelhantes No modelo ER tipos ou conjuntos de entidades s o representados graficamente por ret ngulos como mostra a Figura 3 4 Livro Cliente Funcion rio Figura 3 4 Representa o Gr fica de Conjuntos de Entidades Um conjunto de entidades representa todos os elementos do mundo real referidos pelo conjunto Por exemplo em um sistema de uma biblioteca o conjunto de entidades Livro
222. ser considerada no modelo ER e ela registrada usando se cardinalidades como mostra a Figura 3 6 1 1 Departamento Professor lota Figura 3 6 Representa o de cardinalidades em relacionamentos Vale destacar que a cardinalidade m nima aponta a quantidade de inst ncias m nima necess ria para que a associa o seja estabelecida considerando o momento em que uma inst ncia de uma entidade criada Assim no exemplo anterior quando um novo professor for ser registrado no sistema ele ter obrigatoriamente de estar lotado em um departamento Por outro lado ao se criar um novo departamento ter se de informar pelo menos 13 professores que nele ser o lotados E importante frisar que entre duas entidades podem existir v rios tipos de relacionamentos diferentes como mostra o exemplo da Figura 3 7 Departamento Funcion rio chefia Figura 5 7 Dois relacionamentos diferentes entre as mesmas entidades Al m disso uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo inclusive com ela mesma auto relacionamento como mostra a Figura 3 8 Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 28 1 1 13 N Disciplina pr requisito para p s requisito Figura 3 8 Exemplo de auto relacionamento No caso de auto relacionamentos til distinguir qual
223. sp rito Santo 122 podem ent o ser definidos a partir da instancia o do processo de software padr o da organiza o levando em considera o suas caracter sticas particulares Esses processos instanciados s o ditos processos de projeto De fato o modelo de defini o de processos baseado em processos padr o pode ser estendido para comportar v rios n veis Primeiro pode se definir um processo padr o da organiza o contendo os ativos de processo que devem fazer parte de todos os processos de projeto da organiza o Esse processo padr o pode ser especializado para agregar novos ativos de processo considerando aspectos tais como tipos de software paradigmas ou dom nios de aplica o Assim obt m se processos mais completos que consideram caracter sticas da especializa o desejada Por fim a partir de um processo padr o ou de um processo padr o especializado poss vel instanciar um processo de projeto que ser o processo a ser utilizado em um projeto de software espec fico Para definir esse processo devem ser consideradas as particularidades de cada projeto A Figura 9 3 ilustra essa abordagem de defini o de processos de software em n veis ROCHA MALDONADO WEBER 2001 Uma vez que objetivo das normas e modelos de qualidade apontar caracter sticas que um bom processo de software tem de apresentar deixando a organiza o livre para estruturar essas caracter sticas segundo sua pr pria cultura elas
224. ste ser requerido para exercit la Assim essa t cnica deve ser empregada de modo complementar a outras t cnicas p ex t cnicas funcionais Al m disso alguns elementos requeridos p ex uma certa combina o de arcos podem n o ser execut veis sendo imposs vel derivar casos de teste para eles 5 4 3 Aplicando T cnicas de Teste importante ressaltar que t cnicas de teste devem ser utilizadas de forma complementar j que elas t m prop sitos distintos e detectam categorias de erros distintas MALDONADO FABBRI 2001 primeira vista pode parecer que realizando testes de caixa branca rigorosos poder amos chegar a programas corretos Contudo isso pode n o ser pr tico uma vez que todas as combina es poss veis de caminhos e valores de vari veis teriam de ser exercitados o que geralmente imposs vel Al m disso se um programa n o implementa uma fun o definida em uma especifica o n o existir um caminho que corresponda a ela e nenhum dado de teste ser requerido para exercit la Assim se existir um problema a aus ncia da fun o ele n o ser detectado Isso n o quer dizer entretanto que os testes caixa branca n o s o teis Testes caixa branca podem ser usados por exemplo para garantir que todos os caminhos independentes de um m dulo tenham sido exercitados pelo menos uma vez PRESSMAN 2011 Uma boa abordagem para a introdu o de pr ticas mais sistem ticas de teste em uma organ
225. tanto vale a pena ressaltar que importante manter se a clareza da conex o N o devemos mascarar as informa es que fluem Finalmente no que tange ao que comunicado entre m dulos o ideal que se busque acoplamento apenas de dados Entretanto quando se fizer necess ria a comunica o de fluxos de controle devemos faz la sem m scaras As seguintes orienta es podem ajudar a minimizar o acoplamento entre m dulos O m dulo que chama n o deve nunca enviar um controle ao m dulo chamado isso significa que o m dulo que chama est dizendo o que o m dulo chamado deve fazer caracterizando portanto que o m dulo chamado n o trata de uma nica fun o S utilizar fluxos de controle de baixo para cima O m dulo chamado avisa que n o conseguiu executar sua fun o mas n o deve dizer ao chamador o que fazer Evitar o uso de vari veis globais Sempre que poss vel utilizar vari veis locais E inadmiss vel que um m dulo se refira a uma parte interna de outro e Ter pontos nicos de entrada e sa da em um m dulo Coes o define como as atividades de um m dulo est o relacionadas umas com as outras No projeto modular de programas os m dulos devem ter alta coes o isto seus elementos internos devem estar fortemente relacionados uns com os outros O grau de coes o de um m dulo tem um impacto direto na qualidade do software produzido sobretudo no que tange a manutenibilidade legibilidade e capa
226. te identificado na etapa anterior Os componentes de software devem ser sucessivamente refinados em n veis maiores de detalhamento at que possam ser codificados e testados O projeto deve ser traduzido para uma forma pass vel de execu o pela m quina A fase de implementa o realiza esta tarefa isto cada unidade de software do projeto detalhado implementada A fase de Testes inclui diversos n veis de testes a saber teste de unidade teste de integra o e teste de sistema Inicialmente cada unidade de software implementada deve ser testada A seguir os diversos componentes devem ser integrados sucessivamente at se obter o sistema Finalmente o sistema como um todo deve ser testado Uma vez testado o software deve ser colocado em produ o Para tal contudo necess rio treinar os usu rios configurar o ambiente de produ o e muitas vezes converter bases de dados O prop sito da fase de Implanta o e Entrega disponibilizar o software para o cliente garantindo que o mesmo satisfaz os requisitos estabelecidos Isto requer a instala o do software e a condu o de testes de aceita o Quando o software tiver demonstrado prover as capacidades requeridas ele pode ser aceito e a opera o iniciada Encerrado o processo de desenvolvimento com a entrega do sistema ao cliente diz se que o sistema est em opera o quando o software utilizado pelos usu rios no ambiente de produ o Contudo indubita
227. tem de ser temporalmente posterior sua data de admiss o 3 6 3 Dicion rio de Dados O Dicion rio de Dados uma listagem organizada de todos os elementos de dados pertinentes ao sistema com defini es precisas para que os usu rios e desenvolvedores possam conhecer o significado dos itens de dados manipulados pelo sistema A Figura 3 21 apresenta a nota o adotada neste texto para elabora o de Dicion rios de Dados dado ou estrutura opcional dados ou estruturas alternativas ou exclusivo repeti o de dados ou estruturas onde n representa o n mero m nimo de repeti es e m o n mero m ximo Se n e m n o s o especificados significa zero ou mais repeti es delimitadores de coment rios atributo determinante Figura 3 21 Nota o para Dicion rios de Dados Engenharia de Software Notas de Aula Cap tulo 3 Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 36 Os exemplos mostrados a seguir ilustram diversas situa es e o emprego das nota es a O cliente pode possuir um telefone Cliente cpf nome endere o telefone b O cliente pode possuir mais de um telefone ou mesmo nenhum Cliente cpf nome endere o telefone c O cliente pode possuir at tr s telefones Cliente cpf nome endere o telefone 3 d O cliente pode possuir telefone comercial residencial ou ambos Cli
228. teste ou conjunto de teste DELAMARO et al 2007 Definido um conjunto de casos de teste T executa se P com T e verificam se os resultados obtidos Se os resultados obtidos coincidem com os resultados esperados ent o nenhum defeito foi identificado e diz se que o software passou no teste Se para algum caso de teste o resultado obtido difere do esperado ent o um defeito foi detectado e o software n o passou no teste De maneira geral fica por conta do testador baseado na especifica o do programa decidir sobre a corre o da execu o DELAMARO et al 2007 A Figura 5 1 ilustra um cen rio t pico da atividade de teste Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 73 Espec P Sucesso ou Falha Testador Figura 5 1 Atividade de Teste Para se poder garantir que um programa P n o cont m defeitos P deveria ser executado com todos os elementos de D P Seja um programa exp com a seguinte especifica o exp int x int y x D exp corresponde a todos os pares de n meros inteiros x y pass veis de representa o A cardinalidade de D exp 2 2 onde n n mero de bits usado para representar um inteiro Em uma arquitetura de 32 bits H D exp 2 Se cada teste puder ser executado em 1 milissegundo seriam necess rios aproximadamente 5 85 milh es de s culos para executar todos
229. tir de uma declara o bem definida do problema Oferece um conjunto de crit rios para avalia o da qualidade de uma determinada solu o com respeito ao problema a ser resolvido S o objetivos do Projeto Modular de Programas Permitir a constru o de programas mais simples Obter m dulos independentes Permitir testes por partes Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 62 Ter menos c digo a analisar em uma manuten o Servir de guia para a programa o estruturada Construir m dulos com uma nica fun o Permitir reutiliza o O Projeto Modular procura simplificar um sistema complexo dividindo o em m dulos e os organizando hierarquicamente O sistema subdividido em caixas pretas que s o organizadas em uma hierarquia conveniente A vantagem do uso da caixa preta est no fato de que n o precisamos conhecer como ela trabalha mas apenas utiliz la As caracter sticas de uma caixa preta s o sabemos como devem ser os elementos de entrada isto as informa es necess rias para seu processamento sabemos como devem ser os elementos de sa da isto os resultados oriundos do seu processamento conhecemos a sua fun o isto que processamento ela faz sobre os dados de entrada para que sejam produzidos os resultados n o precisamos conhecer como ela realiza as opera es nem
230. tivas de tamanho mais cedo no processo de software e sem os problemas de depend ncia em rela o tecnologia foram propostas outras medidas em um n vel de abstra o mais alto O exemplo mais conhecido a contagem de Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 106 Pontos de Fun o PFs que busca medir as funcionalidades do sistema requisitadas e recebidas pelo usu rio de forma independente da tecnologia usada na implementa o A An lise de Pontos de Fun o APF um m todo padr o para a medi o do tamanho de uma aplica o de software que estabelece uma medida de tamanho do software em Pontos de Fun o PFs Os objetivos da APF s o HAZAN 2001 e Medir as funcionalidades do sistema requisitadas e recebidas pelo usu rio e Medir projetos de desenvolvimento e manuten o de software sem se preocupar com a tecnologia que ser utilizada na implementa o O processo para contagem de PFs compreende sete passos mostrados na Figura 8 2 e descritos sucintamente adiante Uma descri o um pouco mais detalhada do m todo da An lise de Pontos de Fun o apresentada no Anexo A Para uma vis o completa do m todo recomenda se a leitura de VAZQUEZ SIM ES ALBERT 2005 Determinar o Tipo de Contagem Identificar o Escopo de Contagem e a Fronteira da Aplica o Contar as Contar as Fun es
231. tos de fun o n o ajustados os pontos de fun o n o ajustados PFNA refletem as funcionalidades fornecidas pelo sistema para o usu rio Essa contagem leva em conta dois tipos de fun o de dados e transacionais bem como sua complexidade simples m dia ou complexa e Contagem das fun es de dados as fun es de dados representam as funcionalidades relativas aos requisitos de dados internos e externos aplica o S o elas os arquivos l gicos internos e os arquivos de interface externa Ambos s o grupos de dados logicamente relacionados ou informa es de controle que foram identificados pelo usu rio A diferen a est no fato de um Arquivo L gico Interno ALI ser mantido dentro da fronteira da aplica o isto armazenar os dados mantidos atrav s de um ou mais processos elementares da aplica o enquanto que um Arquivo de Interface Externa AIE apenas referenciado pela aplica o ou seja ele mantido dentro da fronteira de outra aplica o Assim o objetivo de um AIE armazenar os dados referenciados por um ou mais processos elementares da aplica o sendo contada mas que s o mantidos por outras aplica es e Contagem das fun es transacionais as fun es transacionais representam as funcionalidades de processamento de dados do sistema fornecidas para o usu rio S o elas as entradas externas as sa das externas e as consultas externas As Entradas Externas EEs s o processos elementares que pr
232. tre dois conjuntos de entidades A e B e Se A for total em R todo A est associado a um B melhor colocar a chave de B B em A como mostra o exemplo da Figura 4 8 e Se B for total em R todo B est associado a um A melhor colocar a chave de A HA em B e Nos demais casos melhor transpor a chave que dar origem a uma coluna mais densa isto que ter menos valores nulos Diagrama E R Eas 1 1 Pe 0 1 Funcion rio O gt Fun Dep Fun Diagrama Relacional Funcion rio OH Departamento Figura 4 8 Exemplo de Relacionamento 1 1 Engenharia de Software Cap tulo 4 Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 56 Relacionamentos 1 N Neste caso deve se transpor a chave da tabela correspondente entidade de cardinalidade m xima N para a tabela que representa a entidade cuja cardinalidade m xima 1 como mostra a Figura 4 9 Diagrama E R 0 1 gt 0 N HA HB HA Diagrama Relacional A Q O Figura 4 9 Relacionamentos 1 N no Diagrama Relacional Um 4 pode estar associado a v rios Bs mas um B s pode estar associado a um 4 logo se deve transpor a chave prim ria de 4 para B A Figura 4 10 mostra um exemplo desta situa o lota Diagrama E R 1 1 0 N Departamento gt Dep Fun Dep Diagrama l l Relacional Departamento OG Funcion rio Figura 4 10 Exemplo de Relacionamento 1 N Relacionamentos N N No caso d
233. tware necess rio observar a disponibilidade do recurso Assim importante definir a partir de que data o recurso ser necess rio por quanto tempo ele ser necess rio e qual a quantidade de horas necess rias por dia nesse per odo o que para recursos humanos convencionamos denominar dedica o Observe que j entramos na estimativa de dura o Assim aloca o de recursos e estimativa de dura o s o atividades realizadas normalmente em paralelo No que se refere a recursos humanos outros fatores t m de ser levados em conta A compet ncia para realizar a atividade para a qual est sendo alocado fundamental Assim preciso analisar com cuidado as compet ncias dos membros da equipe para poder realizar a aloca o de recursos Outros fatores como lideran a relacionamento interpessoal etc importantes para a forma o de equipes s o igualmente relevantes para a aloca o de recursos humanos a atividades 8 5 5 Estimativa de Dura o e Elabora o de Cronograma De posse das estimativas de esfor o e paralelamente aloca o de recursos poss vel estimar o tempo cronol gico dura o de cada atividade e por conseguinte do projeto como um todo Se a estimativa de esfor o tiver sido realizada para o projeto como um todo ent o ela dever ser distribu da pelas atividades do projeto Novamente dados hist ricos de projetos j conclu dos na organiza o s o uma boa base para se fazer essa distrib
234. u o de cada vers o dos itens PRESSMAN 2011 SANCHES 2001b Ap s a identifica o dos ICs devem ser planejadas as linhas base dentro do ciclo de vida do projeto Uma linha base ou baseline uma vers o est vel de um sistema contendo todos os componentes que constituem este sistema em um determinado momento Nos pontos estabelecidos pelas linhas base os ICs devem ser identificados analisados corrigidos aprovados e armazenados em um local sob controle de acesso denominado reposit rio central base de dados de projeto ou biblioteca de projeto Assim quaisquer altera es nos Engenharia de Software Notas de Aula Cap tulo 7 Ger ncia da Qualidade Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 95 itens da em diante s poder o ser realizadas atrav s de procedimentos formais de controle de modifica o PRESSMAN 2011 SANCHES 2001b O passo seguinte do processo de GCS o controle de vers o que combina procedimentos e ferramentas para identificar armazenar e administrar diferentes vers es dos ICs que s o criadas durante o processo de software PRESSMAN 2011 SANCHES 2001b A ideia que a cada modifica o que ocorra em um IC uma nova vers o ou variante seja criada Vers es de um item s o geradas pelas diversas altera es enquanto variantes s o as diferentes formas de um item que existem simultaneamente e atendem a requisitos similares SANCHES 2001b Uma das mais impo
235. ui o No entanto muitas vezes uma organiza o n o tem ainda esses dados dispon veis Embora as caracter sticas do projeto sejam determinantes para a distribui o do esfor o uma diretriz inicial til consiste em considerar a distribui o mostrada na Tabela 8 2 PRESSMAN 2011 Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 111 Tabela 8 2 Distribui o de Esfor o pelas Principais Atividades do Processo de Software Planejamento Especifica o e Projeto Implementa o Teste e Entrega An lise de Requisitos At 3 De 10 a 25 De 20 a 25 De 15 a 20 De 30 a 40 De posse da distribui o de esfor o por atividade e realizando paralelamente a aloca o de recursos pode se criar uma rede de tarefas com o esfor o associado a cada uma das atividades PFLEEGER 2004 A partir dessa rede pode se estabelecer qual o caminho cr tico do projeto isto qual o conjunto de atividades que determina a dura o do projeto Um atraso em uma dessas atividades provocar atraso no projeto como um todo Finalmente a partir da rede de tarefas deve se elaborar um Gr fico de Tempo ou Gr fico de Gantt estabelecendo o cronograma do projeto Gr ficos de Tempo podem ser elaborados para o projeto como um todo cronograma do projeto para um conjunto de atividades para um m dulo espec fico ou mesm
236. uivos l gicos internos Em adi o ao item anterior necess rio prote o contra perdas de dados que foi projetada e programada no sistema Al m do item anterior altos volumes trazem considera es de custo no processo de recupera o Processos para automatizar a recupera o foram inclu dos minimizando a interven o do operador 9 Processamento complexo a complexidade de processamento influencia no dimensionamento do sistema e portanto deve ser quantificado o seu grau de influ ncia com base nas seguintes categorias Processamento especial de auditoria e ou processamento especial de seguran a foram considerados na aplica o Processamento l gico extensivo Processamento matem tico extensivo Processamento gerando muitas exce es resultando em transa es incompletas que devem ser processadas novamente Exemplo transa es de auto atendimento banc rio interrompidas por problemas de comunica o ou com dados incompletos Processamento complexo para manusear m ltiplas possibilidades de entrada sa da Exemplo multim dia Pontua o Sado Dor NO o Nenhum dos itens descritos Apenas um dos itens descritos Dois dos itens descritos Tr s dos itens descritos Quatro dos itens descritos Todos os cinco itens descritos Engenharia de Software Anexo A An lise de Pontos de Fun o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 139 10 Reusabilidade a preocupa o c
237. uncionais ii Em rela o execu o de linhas de c digo teste de caminhos poss veis O esfor o de teste deve ser compensat rio ou seja deve haver um balanceamento entre tempo custo do teste e a quantidade de defeitos encontrados O n mero de defeitos encontrados segue uma curva logar tmica ou seja embora ainda possam existir defeitos o esfor o para encontr los passa a ser muito grande fazendo com que a atividade de teste comece a ser percebida como muito custosa KOSCIANSKI SOARES 2006 e Quando testar Dentre as abordagens poss veis destacam se duas 1 teste como uma atividade do processo de software testar no final ii teste como um processo paralelo ao processo de desenvolvimento recomend vel planejar e projetar casos de teste medida que o processo de desenvolvimento progride A execu o dos casos de teste pode ser feita em atividades destinadas para este fim Deve se levar em conta ainda que testes de unidade dependem da produ o das unidades ao longo do processo de desenvolvimento Testes de Integra o dependem do ciclo de vida incrementos itera es e da estrutura subsistemas casos de uso podendo ser programados em intervalos espec ficos Por fim a execu o de testes de sistema deve ocorrer nas entregas e portanto tamb m dependente do ciclo de vida e Como testar Diz respeito defini o de t cnicas de teste para cada fase de teste Ainda que seja poss vel testar um sist
238. vas de esfor o s o feitas com base apenas no julgamento dos especialistas uma tabela como a Tabela 8 1 pode ser utilizada em que cada c lula corresponde ao esfor o necess rio para efetuar uma atividade no escopo de um m dulo espec fico Uma tabela como essa pode ser produzida tamb m com base em dados hist ricos de projetos similares j realizados na organiza o Quando estimativas de tamanho s o usadas como base pode se considerar um fator de produtividade indicando quanto em termos de esfor o necess rio para completar um projeto ou m dulo descrito em termos de tamanho Assim uma organiza o pode coletar dados de v rios projetos e estabelecer por exemplo quantos em homens hora uma medida de esfor o s o necess rios para desenvolver um ponto de fun o medida de tamanho Esses fatores de produtividade devem levar em conta caracter sticas dos projetos e da organiza o Assim pode ser til ter v rios fatores de produtividade considerando classes de projetos espec ficas Assim como em outras situa es quando uma organiza o n o tem ainda dados suficientes para definir seus pr prios fatores de produtividade modelos emp ricos podem ser usados Existem diversos modelos que derivam estimativas de esfor o a partir de dados de LOC ou PFs Por exemplo o modelo proposto por Bailey Basili PFLEEGER 2004 estabelece a seguinte f rmula para se obter o esfor o necess rio em pessoas m s para desenvolver um
239. velmente o software sofrer mudan as ap s ter sido entregue para o cliente Altera es ocorrer o porque erros foram encontrados porque o software precisa ser adaptado para acomodar mudan as em seu ambiente externo ou porque o cliente necessita de funcionalidade adicional ou aumento de desempenho Muitas vezes dependendo do tipo e porte da manuten o necess ria a manuten o pode requerer a defini o de um Engenharia de Software Notas de Aula Cap tulo 2 Vis o Geral do Processo de Desenvolvimento Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 8 novo processo onde cada uma das fases do processo de desenvolvimento reaplicada no contexto de um software existente ao inv s de um novo Ainda que as atividades do processo de desenvolvimento guardem certa rela o de preced ncia como os par grafos anteriores sugerem n o verdade que cada uma das atividades tenha de ter sido necessariamente conclu da para que a pr xima possa ser iniciada Muito pelo contr rio as atividades do processo de desenvolvimento podem ser organizadas de maneiras bastante diferentes Para capturar algumas formas de se estruturar as atividades do processo de desenvolvimento s o definidos modelos de processo Um modelo de processo ou modelo de ciclo de vida pode ser visto como uma representa o abstrata de um esqueleto de processo incluindo tipicamente algumas atividades principais e a ordem de preced ncia entre e
240. vidualmente A seguir s o testados os m dulos que chamam esses m dulos previamente testados Esse procedimento repetido at que todos os m dulos tenham sido testados PFLEEGER 2004 Neste caso apenas drivers s o necess rios Seja o exemplo da Figura 5 1 Usando a abordagem de integra o ascendente os m dulos seriam testados da seguinte forma Inicialmente seriam testados os m dulos do n vel inferior E F e G Para cada um desses testes um driver teria de ser constru do Conclu dos esses testes passar amos ao n vel imediatamente acima testando seus m dulos B C e D combinados com os m dulos por eles chamados Neste caso testamos juntos B E e F bem como C e G Novamente tr s drivers seriam necess rios Por fim testar amos todos os m dulos juntos Figura 5 1 Exemplo de uma hierarquia de m dulos Integra o descendente ou top down A abordagem neste caso precisamente o contr rio da anterior Inicialmente o n vel superior geralmente um m dulo de controle testado sozinho Em seguida os m dulos chamados pelo m dulo testado s o combinados e testados como uma grande unidade Essa abordagem repetida at que todos os m dulos tenham sido incorporados PFLEEGER 2004 Neste caso apenas stubs s o necess rios Tomando o exemplo da Figura 5 1 o teste iniciaria pelo m dulo A e tr s stubs para B C e D seriam necess rios Na sequ ncia seriam testados juntos A B C e D sendo necess ri
241. vimento baseada em um modelo entrada processamento sa da No paradigma estruturado os dados s o considerados separadamente das fun es que os transformam e a decomposi o funcional usada intensamente Neste texto discutimos as atividades do processo de desenvolvimento de software luz do paradigma estruturado Assim sendo a atividade de an lise de requisitos conduzida tomando por base esse paradigma 3 5 M todos de An lise de Requisitos Segundo o Paradigma Estruturado Para a realiza o das atividades de an lise m todos e t cnicas podem ser empregados visando guiar o trabalho H diversos m todos e t cnicas de an lise estruturada Dentre os m todos destacam se An lise Estruturada de Sistemas GANE SARSON 1983 DE MARCO 1983 An lise Estruturada Moderna YOURDON 1990 e An lise Essencial de Sistemas MCMENAMIN PALMER 1991 De maneira geral todos esses m todos t m em comum a orienta o a processos e a aplica o da t cnica de Modelagem de Fluxos de Dados Esta t cnica foi proposta no contexto dos m todos precursores de An lise Estruturada GANE SARSON 1983 DE MARCO 1983 Uma caracter stica marcante da aplica o da t cnica de Modelagem de Fluxos de Dados na An lise Estruturada era a abordagem top down para a decomposi o funcional de sistemas partir da vis o geral do sistema e ir descendo em uma vis o hier rquica a n veis de detalhes cada vez maiores Posteriormente outras
242. z de apontar a exist ncia de defeitos e n o a aus ncia deles Muitas vezes a atividade de teste empregada pode ter sido conduzida sem planejamento sem crit rios e sem uma sistem tica bem definida sendo portanto os testes de baixa qualidade MALDONADO FABBRI 2001 Engenharia de Software Cap tulo 5 Implementa o e Teste de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 72 Assim o objetivo projetar casos de teste que potencialmente descubram diferentes classes de erros e faz lo com uma quantidade m nima de esfor o PRESSMAN 2011 Ainda que os testes n o possam demonstrar a aus ncia de defeitos como benef cio secund rio podem indicar que as fun es do software parecem estar funcionando de acordo com o especificado A ideia b sica dos testes que os defeitos podem se manifestar por meio de falhas observadas durante a execu o do software Essas falhas podem ser resultado de uma especifica o errada ou falta de requisito de um requisito imposs vel de implementar considerando o hardware e o software estabelecidos o projeto pode conter defeitos ou o c digo pode estar errado Assim uma falha o resultado de um ou mais defeitos PFLEEGER 2004 Do ponto de vista psicol gico o teste de software uma atividade com certo vi s destrutivo ao contr rio das outras atividades do processo de desenvolvimento de software A perspectiva de teste requer um modo de olhar um pro
243. za os resultados da medi o permitem uma comunica o efetiva com os v rios interessados no desenvolvimento A falta de medidas de projeto por outro lado prejudica de forma geral o seu acompanhamento uma vez que pode haver um problema mas ele n o est sendo percebido por aqueles que podem direcionar esfor os para a sua solu o Assim medidas t m um importante papel na r pida identifica o e corre o de problemas ao longo do desenvolvimento do projeto Com a sua utiliza o fica muito mais f cil justificar e defender as decis es tomadas Afinal o gerente de projeto n o decidiu apenas com base em seu sentimento e experi ncia mas tamb m fundamentado na avalia o de indicadores que refletem uma tend ncia de comportamento futuro Essa tend ncia n o derivada apenas das experi ncias no projeto corrente mas tamb m de experi ncias semelhantes de outros projetos da organiza o conhecimento organizacional e at mesmo de fora dela VAZQUEZ SIM ES ALBERT 2005 Engenharia de Software Notas de Aula Cap tulo 8 Ger ncia de Projetos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 105 No que tange ger ncia de projetos estabelecer classes de projetos e coletar algumas medidas pode ser bastante importante para apoiar a realiza o de estimativas Por exemplo se uma organiza o tem indicadores para produtividade tamanho esfor o e custo R tamanho para diversas classes de projetos

Notas de Aula - Engenharia de Software -v2014

Contents

Download Pdf Manuals

Related Search

Related Contents